Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a A to Z of a Multi-platform Docker Swarm: Building, Shipping, and Running Multi-arch Images
Semelhante a A to Z of a Multi-platform Docker Swarm: Building, Shipping, and Running Multi-arch Images (20)
Último
Último (20)
A to Z of a Multi-platform Docker Swarm: Building, Shipping, and Running Multi-arch Images
- 1. FROM ARM to Z: building, shipping, and running a multi-platform Docker swarm Chris Jones Open Source Developer, IBM Christy Perez Open Source Developer, IBM
- 2. • What is "multi-arch?" • Why is this needed? • How to ... • Examples • docker manifest Agenda • Demo – Building images • Demo – Shipping images • Demo – Running Swarm • Q&A
- 3. What are we talking about?
- 4. • GOAL: User experience across architectures is the same What
- 7. Why should I care?
- 8. $ docker run –it ubuntu standard_init_linux.go:178: exec user process caused “no such file or directory” $ uname –m s390x $ docker run –it s390x/ubuntu root@eb7051894530:/# Why
- 9. $ docker run –it rethinkdb standard_init_linux.go:178: exec user process caused “no such file or directory” $ uname –m aarch64 $ docker run –it aarch64/rethinkdb docker: Error response from daemon: repository aarch64/rethinkdb not found: does not exist or no pull access. Why
- 11. • The user had to remember he was on a different architecture • Arch-dependent image names harm usability • Siloed projects cause heartbreaks What went wrong?
- 12. • Grow your project • Strengths of other platforms Benefits
- 14. • actual hardware • hardware assisted virtualization (KVM) • full-system emulation (QEMU) • user-mode emulation (binfmt_misc) • cross-compiling How Building and running binaries
- 15. binfmt_misc
- 16. • 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
- 18. # create magic number (ELF header bit) mappings $ docker run –rm –privileged multiarch/qemu-user- static:register # verify our magic numbers were added, aka our # Rolodex has been created. $ ls /proc/sys/fs/binfmt_misc/ aarch64 arm ppc64le s390x … binfmt_misc – ppc64le e.g.
- 19. # download interpreter $ curl -fsSL https://github.com/multiarch/qemu-user- static/releases/download/v2.8.1/x86_64_qemu-ppc64le- static.tar.gz -o ~/x86_64_qemu-ppc64le-static.tar.gz # unzip to /usr/bin/qemu-ppc64le-static $ tar -xvzf ~/x86_64_qemu-ppc64le-static.tar.gz -C /usr/bin/qemu-ppc64le-static binfmt_misc – ppc64le e.g.
- 20. # docker run ppc64le image and mount bin $ docker run -it --rm -v /usr/bin/qemu-ppc64le- static:/usr/bin/qemu-ppc64le-static / ppc64le/busybox:latest uname –m uname -m ppc64le binfmt_misc – ppc64le e.g.
- 21. # docker run ppc64le image $ docker run -it --rm ppc64le/busybox:latest uname -m uname -m ppc64le Docker for Mac
- 23. $ GOOS=linux GOARCH=arm go build complex cross-compiling in go
- 24. Advice (Wisdom?)
- 25. ├── Dockerfile ├── Dockerfile.aarch64 ├── Dockerfile.armhf ├── Dockerfile.ppc64le ├── Dockerfile.s390x ├── Dockerfile.simple ├── Dockerfile.solaris ├── Dockerfile.windows Makefiles, Dockerfiles & build scripts • Multiple Dockerfiles (e.g. Dockerfile.armf) • Don't hard-code in arch in packages, etc.
- 26. • If you must... • ifdefs & build constraints Optimizations zfs.go:// +build linux freebsd solaris zfs_unsupported.go:// +build !linux,!freebsd,!solaris
- 27. Where does docker fit?
- 28. • Multi-arch support in registry (Jan 2016) • Skopeo Project (https://github.com/projectatomic/skopeo) • Phil Estes' tool (https://github.com/estesp/manifest-tool) • PR to add "docker manifest" (PR #27455) History
- 29. What's a manifest? • Image metadata - Layers - References - OS - Arch - etc.
- 30. What's a manifest list? • A multi-arch "image" • Contains image manifests • Engine decides which to pull • Not tied to image name • Extra image detail myrepo/mylist amd64 image amrhf image ppc64le image
- 31. docker manifest
- 32. • "Shallow pull" of image: manifest only • Pushing multi-architecture image names to registry `docker manifest` command
- 33. # create interactively using cli $ docker manifest create tophj/busybox busybox / aarch64/busybox armhf/busybox ppc64le/busybox / s390x/busybox $ docker manifest annotate tophj/busybox / armhf/busybox --os linux --arch arm --osFeature f1 $ docker manifest push tophj/busybox docker manifest
- 34. # or create using yaml $ docker manifest push -f clnperez_hw.yaml docker manifest - yaml
- 35. docker manifest inspect tophj/busybox docker manifest inspect busybox docker manifest
- 36. Putting it all together: docker swarm
- 37. tophj/demo
- 38. tophj/demo • tophj/ppc64le-demo • tophj/x86_64-demo • tophj/armhf -demo • tophj/s390x-demo
- 39. ├── 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
- 40. # 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
- 41. # 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
- 42. $ 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
- 43. # 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
- 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
- 47. Thank You! Go forth and multi-arch! @docker#dockercon
Notas do Editor
- Christy As part of our introduction,talk about what the LTC is, and what we do there. Phil's intro here is good:https://www.youtube.com/watch?v=9Ku_n91puUw
- What are we talking about
- Note
- Sooo. A lot of these aren’t actually supported, maybe put some red X’s through those. (add in an le to the end of ppc64?) toph Lots of architectures When we talk about multi-architecture, what we mean is being able to run docker on a variety of platforms and devices with different underlying architectures (arm, x86, power, z, etc.) Our goal is that your user experience running docker on say, an x86 server will be the same as it is using a raspberry pi. GOAL: Creating one workload for multiple architectures
- We want the same container to be run on an x86 server farm, as a raspberry pi toaster you use to implement RFC 7168
- We want the same container to be run on an x86 server farm, as a raspberry pi teapot you use to implement RFC 7168 (coffee pot protocol)
- tophj
- Spend some time talking about how in dockerhub images are architecture specific, and the only way to tell right now is by the image name / repository MAKE SURE WE HIGHLIGHT THIS AS AN EXAMPLE OF IMAGE NAME DEPENDENCIES
- “Also you read a blog post about a cool new project, and then you try and run it and you can’t”
- Siloed projects cause heartbreaks Maybe a picture here of all the open github issues?
- Siloed projects cause heartbreaks (siloed projects being a project that only cares about one architecture) Maybe a picture here of all the open github issues?
- Benefits OF MAKING YOUR PROJECT MULTI-ARCH FRIENDLY... Catchy name for the self-sustaining circle? COOS (circle of open source?) More people who see your project, means the more people who use your project, which means the more people who contribute to your project The more usability your project has, the more people who see your project, the more people who contribute to your project, the more useful your project will become Benefits of other platforms (z will run your project at huge scale, while ARM will force it to be more efficient) Rooting out bugs, i.e. race conditions, etc. Two different mindsets, arm folks will worry about everything being super efficient, while the z folks will worry about everything scaling properly
- christy
- christy
- This guy lives in your operating system,much like his twin brother lives in the basement an Innotech. He is given a rolodex of binary to interpreter mappings, and his only job is to point the operating system at the right interpreter.
- Why are we showing people how to use this? Tie it back to a compelling use in a project: 1) if you build a container for a non-native arch, test it 2) if you need to use an image that you don't have available, you can just run one that does exit for another architecture!3) ??
- Tophj (maybe)
- tophj
- Mention that when doing a docker build, you can have a FROM scratch image and then copy in the binary into the image
- christy
- If you want to put in assembly,put it in a file that only compiles for your arch, and have a slowpath ready for other architectures. You can easily compile only that file using go's build constraints, or run an optimized path using ifdef's.
- christy
- Find and shame Phil This slide is about History of multi-arch with Docker Support in registry added for the manifest list type in Manifest Version 2, Schema 2. SHOW an example of a manifest list(mf v2s2). Trying to describe these is too complicated without an example. Skopeo: originally created by Antonio Murdaca (runcom) and now lives at projectatomic, Skopeo is able to inspect images without pulling them from a registry, fetch images by layers, but lacks mutli-arch image creation, which leads to Phil’s Tool: estesp, fork of Skopeo that supports multi-arch image name creation and inspection. DO NOT TALK IN DEPTH ABOUT MANIFEST LISTS YET! Mention that phil has given a talk about this at previous dockercon (watch to see what he talked about!) Support in engine for pulling manifest lists was added in 2016, but hasn’t been put into CLI
- Images live in docker hub, and with them lives information about them.That"about" info is the manifest.
- A manifest is just the identifying metadata that describes the binary data of the image. Think of it as almost the same information you see if you do a docker inspect of an image. Manifest lists are traversed by your docker engine to find the right layers to pull depending on os & arch If this doesn't make sense quite yet, wait until we get to the demo of using them a bit later.
- christy
- Shallow pull of image aka docker manifest inspect Creating multi-architecture images (why do this)
- Might want to mention they have to login, and not to create one going to tophj
- You can use inspect not only to inspect a manifest list (multiple images) but also to do a shallow pull of a singular manifest
- tophj
- We want the same container to be run on an x86 server farm, as a raspberry pi toaster you use to implement RFC 7168
- We want the same container to be run on an x86 server farm, as a raspberry pi toaster you use to implement RFC 7168
- Christy + tophj + ???