Patterns in a Containerized World (Matthias Luebken Technology Stream)
1 like535 views
The document discusses the concept of 'module containers,' which are lightweight, self-sufficient Linux processes used for modularizing applications. It outlines eight properties of module containers—immutable, disposable, and adaptive, among others—and various patterns for assembling them, such as sidecar and ambassador patterns. Additionally, it addresses best practices for creating Docker images and emphasizes the importance of designing cloud-native applications that can adapt to changing environments.
![“Containers […] are
destined to become
analogous to
objects in object-
oriented software
systems”](https://image.slidesharecdn.com/matthiasluebkencontainer-patterns-2016-161028095834/85/Patterns-in-a-Containerized-World-Matthias-Luebken-Technology-Stream-12-320.jpg)
Patterns in a Containerized World (Matthias Luebken Technology Stream)
- 2. @luebken
- 9. “ Easily create lightweight, portable, self-sufficient containers from any application.”
- 10. Since containers are a great way of package and deliver software …
- 11. What if we use containers to modularise our application?
- 12. “Containers […] are destined to become analogous to objects in object- oriented software systems”
- 13. “This makes a container not just a program, but rather, a part of a program.” “A Container Is A Function Call”.
- 14. Independently releasable Separate processing types Different loads Different teams Reuse Crash isolation Use differentlanguages / versions / libraries POCs
- 15. 1. Properties of a module container Outline 2. Patterns for assembling these
- 19. A Module Container is 1. Linux process 2. API 3. Descriptive 4. Disposable 5. Immutable 6. Self-contained 7. Small 8. Adaptive
- 20. 1. Linux Process
- 21. 1. Linux Process • React to signals • Return exit codes • Use standard streams • Handle arguments Examples: module-container.md#1-linux-process
- 22. 2. API
- 23. 2. API • ENV variables • Available ports • Volume mounts • Lifecycle hooks Examples: module-container.md#2-api
- 24. 3. Descriptive
- 25. 3. Descriptive • Use standard labels (e.g. proposal generic labels) • url, summary, vcs-url … • Use custom labels: • io.openshift.wants • io.openshift.expose-services Examples: module-container.md#3-descriptive
- 26. Standardising Labels • https://github.com/projectatomic/ ContainerApplicationGenericLabels • http://label-schema.org/rc1/
- 27. 4. Disposable
- 28. 4. Disposable • Don’t rely on a particular instance • Be aware of shots at your cattle • Be robust against sudden death Examples: module-container.md#4-disposable
- 29. 5. Immutable
- 30. 5. Immutable • Don’t change your container after build • Strive or a dev/prod parity Examples: module-container.md#5-immutable
- 32. 6. Self-contained • Add dependencies on build time • Sensible defaults Examples: module-container.md#6-self-contained
- 33. 7. Small
- 34. 7. Small • Don’t use large base images • Use the minimal footprint Examples: module-container.md#6-small
- 35. 8. Adaptive
- 36. 8. Adaptive • Anticipate the environment & react to change • Software appliance • Container reinitiates of config changes • http://autopilotpattern.io
- 37. A Module Container is 1. Linux process 2. API 3. Descriptive 4. Disposable 5. Immutable 6. Self-contained 7. Small 8. Adaptive
- 38. 1. Properties of a module container Outline 2. Patterns for assembling these
- 41. A group of closely related containers. Deployed as a single unit and share namespaces.
- 43. Pattern: Sidecar / Sidekick Enhance & extend the main container. K8S: transparently. Netflix: platform features. UDSA Node Backend MAIN CONTAINER Redis Cache SIDECAR Pod
- 45. Pattern: Adapter Standardise and normalize output. E.g. logging and metrics. localhost or A Node Backend MAIN CONTAINER Monitoring Adapter ADAPTER Pod
- 47. Proxy a local connection to the world: Service Discovery, Client Side LB, Circuit Breaker A Node Backend MAIN CONTAINER Service Discovery AMBASSADOR Pattern: Ambassador localhost (Pod)
- 48. Pattern: Container chains Defined order of starting and stopping sidecar containers. A Node Backend MAIN CONTAINER Storage Config SIDECAR Discovery SIDECAR Network Config SIDECAR (Pod)
- 49. Summary Module container 1. Linux process 2. API 3. Descriptive 4. Disposable 5. Immutable 6. Self-contained 7. Small Assembling • Sidecar • Adapter • Ambassador • Chains Properties of a module container. Patterns of assembling github.com/luebken/container-patterns @luebken
- 51. Credits • https://www.flickr.com/photos/skynoir/8241460998 (Cover image) • https://www.flickr.com/photos/amlz/8664728590 (Lego) • https://www.flickr.com/photos/guidedbycthulhu/6810361241 (Socket) • https://www.flickr.com/photos/seektan/2074853585/ (Label) • https://www.flickr.com/photos/gullevek/2122873934 (Trash) • https://www.flickr.com/photos/grantmac/4852826923 (Lock) • https://www.flickr.com/photos/mhirano/13236048424 (Hand)
- 53. Old slides
- 56. General Docker image guidelines by the OpenShift team • Reuse images • Maintain compatibility within tags • Avoid multiple processes • Use exec in wrapper scripts • Clean temporary files • Place instructions in the proper order • Mark important ports • Set Environment Variables • Avoid Default Passwords • Avoid SSHD • Use volumes for persistent data https://docs.openshift.com/container-platform/3.3/creating_images/guidelines.html
- 57. Guidance for Docker Image Authors by Project Atomic • Use MAINTAINER • Know the difference between CMD and ENTRYPOINT • Always use exec in wrapper scripts • Always EXPOSE important ports • Use Volumes appropriately • Use USER http://www.projectatomic.io/docs/docker-image-author-guidance/
- 58. Best practices for writing Dockerfiles by Docker • Containers should be ephemeral • Use a .dockerignore file • Avoid installing unnecessary packages • Run only one process per container • Minimize the number of layers • Sort multi-line arguments • Build cache https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
- 60. Container Patterns •For designing “cloud” applications. •Container runtime agnostic. •Are there general applicable patterns? •How would we describe them? •What are concrete examples and best-practices? Differentiate Not app per container Not host container
- 61. Related Work • 12factor.net apps • Cloud-native application architectures: Matt Stine Free Ebook • Microservices • Continuous Delivery
- 63. nginx Proxy Rails Frontend A Go Backend A Node Backend An Application
- 65. nginx Proxy Rails Frontend A Go Backend A Node Backend Redis Cache Logging Adapter Service Ambassador TODO clean up notes
- 66. Links / References http://blog.james-carr.org/2013/09/04/parameterized-docker-containers/ https://docs.docker.com/articles/dockerfile_best-practices/ http://tldp.org/LDP/abs/html/exitcodes.html (Exit Codes for “Proper Linux Process”) http://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/ (Pets vs Cattle) http://www.projectatomic.io/docs/docker-image-author-guidance/ (Dockerfile) http://www.hokstad.com/docker/patterns (Dev patterns) http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html (Composite Patterns) http://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43438.pdf (Borg by Google inspiration for Kubernetes / Pods) http://techblog.netflix.com/2014/11/prana-sidecar-for-your-netflix-paas.html (Sidecar Netflix) WALK THROUGH
- 67. Other / old slides
- 68. More info: ● https://docs.giantswarm.io/fundamentals/user-services/container-injection/ ● https://docs.giantswarm.io/fundamentals/user-services/service-discovery/ Example: Service Discovery @ Giant Swarm
- 69. Reasons for splitting up Independently releasable Separate processing types Different loads Different teams Reuse of containers Crash isolation Different release cycles Use different languages / versions / libraries