Embed Size (px)
Citation preview
Matthias Lübken
Container Patterns
@luebken
“ Easily create lightweight, portable, self-sufficient containers
from any application.”
Since containers are a great way of package and deliver software …
What if we use containers to modularise our application?
“Containers […] are destined to become
analogous to objects in object-oriented software
systems”
“This makes a container not just a program, but rather, a part of a program.”
“A Container Is A
Function Call”.
Independently
releasableSeparate processing types
Different loadsDifferent teams
Reuse
Crash isolation
Use different languages / versions / libraries
POCs
1. Properties of a module container
Outline
2. Patterns for assembling these
github.com/luebken/container-patterns
“Module-Container”
A Module Container is
1. Linux process
2. API
3. Descriptive
4. Disposable
5. Immutable
6. Self-contained
7. Small
8. Adaptive
1. Linux Process
1. Linux Process• React to signals
• Return exit codes
• Use standard streams
• Handle arguments
Examples: module-container.md#1-linux-process
2. API
2. API• ENV variables
• Available ports
• Volume mounts
• Lifecycle hooks
Examples: module-container.md#2-api
3. Descriptive
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
Standardising Labels
• https://github.com/projectatomic/ContainerApplicationGenericLabels
• http://label-schema.org/rc1/
4. Disposable
4. Disposable
• Don’t rely on a particular instance
• Be aware of shots at your cattle
• Be robust against sudden deathExamples: module-container.md#4-disposable
5. Immutable
5. Immutable
• Don’t change your container after build
• Strive or a dev/prod parity
Examples: module-container.md#5-immutable
6. Self-contained
6. Self-contained
• Add dependencies on build time
• Sensible defaultsExamples: module-container.md#6-self-contained
7. Small
7. Small
• Don’t use large base images
• Use the minimal footprintExamples: module-container.md#6-small
8. Adaptive
8. Adaptive
• Anticipate the environment & react to change
• Software appliance
• Container reinitiates of config changes
• http://autopilotpattern.io
A Module Container is
1. Linux process
2. API
3. Descriptive
4. Disposable
5. Immutable
6. Self-contained
7. Small
8. Adaptive
1. Properties of a module container
Outline
2. Patterns for assembling these
nginxProxy
RailsFrontend
A Go Backend
A NodeBackend
nginxProxy
RailsFrontend
A Go Backend
A NodeBackend
Redis Cache
Logging Adapter
Service Ambassador
A group of closely related containers. Deployed as a single unit and share namespaces.
A NodeBackend
Redis Cache
Logging Adapter
Service Ambassador
Pattern: Sidecar / SidekickEnhance & extend the main container. K8S: transparently. Netflix: platform features.
UDSA NodeBackend
MAIN CONTAINER
RedisCache
SIDECAR
Pod
A NodeBackend
Redis Cache
Logging Adapter
Service Ambassador
Pattern: AdapterStandardise and normalize output. E.g. logging and metrics.
localhost or
A NodeBackend
MAIN CONTAINER
Monitoring Adapter
ADAPTER
Pod
A NodeBackend
Redis Cache
Logging Adapter
Service Ambassador
Proxy a local connection to the world: Service Discovery, Client Side LB, Circuit Breaker
A NodeBackend
MAIN CONTAINER
Service Discovery
AMBASSADOR
Pattern: Ambassador
localhost
(Pod)
Pattern: Container chainsDefined order of starting and stopping sidecar containers.
A NodeBackend
MAIN CONTAINER
StorageConfig
SIDECAR
Discovery
SIDECAR
NetworkConfig
SIDECAR
(Pod)
SummaryModule 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
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)
Old slides
Other image guidelines
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
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/
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/
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
Related Work
• 12factor.net apps
• Cloud-native application architectures:Matt Stine Free Ebook
• Microservices
• Continuous Delivery
Closely Related Work
nginxProxy
RailsFrontend
A Go Backend
A NodeBackend
An Application
POC github.com/luebken/container-api
nginxProxy
RailsFrontend
A Go Backend
A NodeBackend
Redis Cache
Logging Adapter
Service Ambassador
TODO clean up notes
Links / Referenceshttp://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
Other / old slides
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
Reasons for splitting upIndependently releasable Separate processing types Different loads Different teams Reuse of containers Crash isolation Different release cycles Use different languages / versions / libraries
