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.

1. Matthias Lübken
Container Patterns

2. @luebken

3. github.com/openshift/origin

7. projectatomic.io

8. github.com/opencontainers

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

17. github.com/luebken/container-patterns

18. “Module-Container”

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

31. 6. Self-contained

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

39. nginx
Proxy
Rails
Frontend
A Go
Backend
A Node
Backend

40. nginx
Proxy
Rails
Frontend
A Go
Backend
A Node
Backend
Redis
Cache
Logging
Adapter
Service
Ambassador

41. A group of closely related containers.
Deployed as a single unit
and share namespaces.

42. A Node
Backend
Redis
Cache
Logging
Adapter
Service
Ambassador

43. Pattern: Sidecar / Sidekick
Enhance & extend the main container.
K8S: transparently. Netflix: platform features.
UDSA Node
Backend
MAIN CONTAINER
Redis
Cache
SIDECAR
Pod

44. A Node
Backend
Redis
Cache
Logging
Adapter
Service
Ambassador

45. Pattern: Adapter
Standardise and normalize output.
E.g. logging and metrics.
localhost or
A Node
Backend
MAIN CONTAINER
Monitoring
Adapter
ADAPTER
Pod

46. A Node
Backend
Redis
Cache
Logging
Adapter
Service
Ambassador

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

50. Dankeschön.
@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

55. Other image guidelines

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

62. Closely Related Work

63. nginx
Proxy
Rails
Frontend
A Go
Backend
A Node
Backend
An Application

64. POC github.com/luebken/container-api

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