The ARM to z of Multi- Architecture Microservices Christy Norman - - PowerPoint PPT Presentation

▶
the arm to z of multi architecture microservices
SMART_READER_LITE
LIVE PREVIEW

The ARM to z of Multi- Architecture Microservices Christy Norman - - PowerPoint PPT Presentation

Mar 09, 2023 288 likes •769 views

The ARM to z of Multi- Architecture Microservices Christy Norman Perez Chris Jones Open Source Developer, IBM Open Source Developer, IBM Agenda Demo Building images What is "multi-arch?" Demo Shipping images

slide-1
SLIDE 1

The ARM to z of Multi- Architecture Microservices

Chris Jones Open Source Developer, IBM Christy Norman Perez Open Source Developer, IBM

slide-2
SLIDE 2
  • What is "multi-arch?"
  • Challenges
  • Benefits
  • The path of multi-arch

Agenda

  • Demo – Building images
  • Demo – Shipping images
  • Demo – Running Swarm
  • Q&A
slide-3
SLIDE 3

What are we talking about?

slide-4
SLIDE 4
slide-5
SLIDE 5
slide-6
SLIDE 6
  • User experience

across architectures is the same

  • Expand your project

Goals

slide-7
SLIDE 7

Why should you care?

slide-8
SLIDE 8
  • Grow your project
  • Strengths of other platforms

Benefits

slide-9
SLIDE 9

Vendor lock-in

slide-10
SLIDE 10

Benefits to others

slide-11
SLIDE 11
slide-12
SLIDE 12

Challenges

slide-13
SLIDE 13

$ uname –m ppc64le $ docker run –it ubuntu standard_init_linux.go:178: exec user process caused “no such file or directory” $ docker run –it ppc64le/ubuntu * root@eb7051894530:/#

Usability

slide-14
SLIDE 14

$ uname –m arm64 $ docker run –it rethinkdb standard_init_linux.go:178: exec user process caused “no such file or directory” $ docker run –it arm64/rethinkdb docker: Error response from daemon: repository arm64/rethinkdb not found: does not exist or no pull access.

Availability

slide-15
SLIDE 15
slide-16
SLIDE 16
  • Users have to remember they are on a different

architecture

  • Arch-dependent (Devs?) image names harm usability

(ref frozen images script?)

  • Siloed projects cause heartbreaks

Summary

slide-17
SLIDE 17

Tools

slide-18
SLIDE 18
  • actual hardware
  • cross-compiling
  • full-system emulation (QEMU)
  • user-mode emulation (binfmt_misc)

Building binaries and images

slide-19
SLIDE 19
  • Allows you to run ELF binaries that weren’t

compiled on your host architecture

  • Maps non-native binaries to arch-specific

interpreters (e.g. QEMU)

  • Pre-Configured in Docker for Mac!

binfmt_misc

slide-20
SLIDE 20

binfmt_misc

qemu-arm qemu-ppc64le qemu-amd64

qemuX

binfmt_misc

slide-21
SLIDE 21

$ uname -m x86_64 # docker run ppc64le image $ docker run -it --rm ppc64le/busybox:latest uname -m ppc64le

Docker for Mac

slide-22
SLIDE 22

# build ppc64le image on non-native hardware $ docker build -v qemu-static-ppc64le -t awesome-app- ppc64le -f Dockerfile.ppc64le .

Building using binfmt_misc

https://github.com/multiarch/qemu-user-static

slide-23
SLIDE 23

Cross-compiling

slide-24
SLIDE 24

# go $ GOOS=linux GOARCH=arm go build # java $ javac HelloWorld.java

examples

slide-25
SLIDE 25

Cross-Compile Workflow

java-app> ├── Dockerfile.build ├── Dockerfile.arm ├── Dockerfile.amd64 ├── Dockerfile.ppc64le ├── Dockerfile.s390x └── HelloWorld.java

slide-26
SLIDE 26

Cross-Compile Workflow

# Dockerfile.build FROM openjdk COPY HelloWorld.java HelloWorld.java RUN javac HelloWorld.java Dev system (amd64): $ docker build -t hwj -f Dockerfile.build . # repeatable build env $ docker run --name hello-world-temp hwj # need container $ docker cp hello-world-temp:HelloWorld.class . # copy out of container

slide-27
SLIDE 27

Cross-Compile Workflow

Dev system (amd64): $ docker build -t clnperez/hello-world-arm -f Dockerfile.arm . $ docker push clnperez/hello-world-arm # Dockerfile.arm FROM arm32v7/openjdk COPY HelloWorld.class HelloWorld.class CMD ["java", "HelloWorld"] ARM user: $ docker run clnperez/hello-world-arm Hello World!

slide-28
SLIDE 28

Manifest lists

slide-29
SLIDE 29

Manifest list

  • A multi-arch "image” *
  • Engine decides which to pull
  • Extra image detail
  • Use in place of image name

anywhere

myrepo/mylist

amd64 image arm image ppc64le image

*but not

slide-30
SLIDE 30
  • Create & push manifest list to registry
  • "Shallow pull" (inspect) of image
  • Inspect manifest lists

`docker manifest` command

slide-31
SLIDE 31

# create interactively using cli $ docker manifest create ubuntu / arm/ubuntu / amd64/ubuntu / ppc64le/ubuntu / s390x/ubuntu # push to registry $ docker manifest push ubuntu

docker manifest

slide-32
SLIDE 32

# or create using yaml $ docker manifest push

  • f clnperez_hw.yaml

docker manifest - yaml (soon)

slide-33
SLIDE 33

$ docker manifest inspect ubuntu | grep “arch”

"architecture": "amd64", "architecture": "arm", "architecture": "arm64", "architecture": "386", "architecture": "ppc64le", "architecture": "s390x",

docker manifest

slide-34
SLIDE 34

Project structure

slide-35
SLIDE 35

├── Dockerfile.amd64 ├── Dockerfile.arm ├── Dockerfile.ppc64le ├── Dockerfile.s390x ├── Dockerfile.windows

Makefiles, Dockerfiles & build scripts

  • Multiple Dockerfiles (e.g.

Dockerfile.arm32v7)

  • FROM can be passed in as

an ARG

  • Can use manifest inspect to

get arch-specific FROM

  • Be mindful of hardcoding

arch values

slide-36
SLIDE 36
  • If you must...
  • ifdefs & build constraints

Optimizations

zfs.go:// +build linux freebsd solaris zfs_unsupported.go:// +build !linux,!freebsd,!solaris

slide-37
SLIDE 37

Putting it all together

slide-38
SLIDE 38

tophj/qcon

slide-39
SLIDE 39

tophj/qcon

  • tophj/qcon:arm64
  • tophj/qcon:amd64
  • tophj/qcon:ppc64le
  • tophj/qcon:s390x
slide-40
SLIDE 40

├── Dockerfile.armhf ├── Dockerfile.ppc64le ├── Dockerfile.s390x ├── Dockerfile.x86_64 ├── img │ ├── captain_logo.png │ ├── captain.png │ ├── christy_logo.png │ ├── christy.png │ ├── pink.png │ └── tophj.png └── server.go

docker swarm demo

slide-41
SLIDE 41

# create our tophj/demo manifest list which points to our # architecture specific images $ docker manifest create tophj/demo tophj/x86_64-demo \ tophj/armhf-demo tophj/ppc64le-demo tophj/s390x-demo

docker swarm demo

slide-42
SLIDE 42

# annotate to change armhf to arm $ docker manifest annotate tophj/demo tophj/armhf-demo \

  • -os linux --arch arm

# finally push the manifest list $ docker manifest push tophj/demo

docker swarm demo

slide-43
SLIDE 43

$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 3nisms9qfi27ko0683bylxyud s390 Ready Active 7jwo7d5braat1l6n63j8xfue6 * x86_64 Ready Active Leader n5tqx2yk77123sjiapqwmu14e armhf Ready Active u30pwzlt5hthwbbsdok8nxyh8 ppc64le Ready Active

docker swarm demo

slide-44
SLIDE 44

# start the swarm service using the multi-arch image name $ docker service create

  • -mode global --name dockercon -p 8082:8080 tophj/demo

# start a simple load-balancer for fun $ docker run -itd -p 80:81 --name nginx -v /christy/nginx:/etc/nginx nginx # visit the IP of your load balancer in your browser # be sure to refresh for multi-arch fun

docker swarm demo

slide-45
SLIDE 45

docker swarm demo

slide-46
SLIDE 46
  • Server image:

https://c1.staticflickr.com/4/3519/3462607995_150a6b2624_b.jpg

  • HtcpcpTeapot image:

https://commons.wikimedia.org/wiki/File:Htcpcp_teapot.jpg

  • Raspberry Pi is a trademark of the Raspberry Pi Foundation.
  • https://github.com/dockersamples/docker-swarm-visualizer
  • ARMHF VM from Scaleway
  • X86 VM from DigitalOcean
  • Gophers: http://gopherize.me

References & Legal

slide-47
SLIDE 47

Thank You!

Go forth and multi-arch!

@qcon #qcon