Container Patterns Matthias Lbken plus give feedback GiantSwarm.io - - PowerPoint PPT Presentation

▶
container patterns
SMART_READER_LITE
LIVE PREVIEW

Container Patterns Matthias Lbken plus give feedback GiantSwarm.io - - PowerPoint PPT Presentation

Jan 26, 2024 480 likes •1.08k views

Container Patterns Matthias Lbken plus give feedback GiantSwarm.io Simple Microservice Infrastructure build for developers. Deploy your containers in seconds. Scaling with your needs: Public, Private, On-Prem Docker is an

slide-1
SLIDE 1

Matthias Lübken

Container Patterns

slide-2
SLIDE 2

plus give feedback

slide-3
SLIDE 3
slide-4
SLIDE 4

GiantSwarm.io

Simple Microservice Infrastructure build for developers. Deploy your containers in seconds. Scaling with your needs: Public, Private, On-Prem

slide-5
SLIDE 5

Docker is an open-source project to easily create lightweight, portable, self-sufficient containers from any application.”

“

slide-6
SLIDE 6

nginx Proxy Rails Frontend A Go Backend A Node Backend

An Application

slide-7
SLIDE 7

Use multiple containers to modularize your application.”

“

slide-8
SLIDE 8

Some reasons

  • Independently releasable
  • Separate processing types
  • Different loads
  • Different teams
  • Reuse of containers
  • Crash isolation
  • Different release cycles
  • Use different languages / versions / libraries
slide-9
SLIDE 9

Container Patterns?

  • Are there general applicable patterns?
  • How would we describe them?
  • What are concrete examples and best-practices
  • Context:

○ Cloud cluster applications ○ They should be container runtime agnostic

slide-10
SLIDE 10

Related work

  • 12-Factor apps
  • Cloud-native application architectures
  • Microservices
  • Continuous Delivery
slide-11
SLIDE 11

Outline

Building blocks

  • Modular container
  • Pods

Composite patterns

  • Sidecar
  • Ambassador
  • Adapter
  • Chains
slide-12
SLIDE 12

Modular container

slide-13
SLIDE 13

nginx Proxy Rails Frontend A Go Backend A Node Backend

An Application

slide-14
SLIDE 14

Modular Container

We define a modular container as the collection of these 6 properties:

  • 1. Proper Linux process
  • 2. Explicit interfaces
  • 3. Disposable
  • 4. Immutable
  • 5. Self-contained
  • 6. Small
slide-15
SLIDE 15
  • 1. Proper Linux Process

Containers should behave as a proper Linux process and be nice to their init process.

  • React to signals
  • Return proper exit codes
  • Use standard streams
slide-16
SLIDE 16

Best practices (Proper Linux Process)

  • React to signals:

○ React on e.g. SIGINT, SIGTERM, etc. ○ Don’t daemonize your processes ○ Make your process foreground (e.g. use exec)

  • Return proper exit codes:

○ 0 (OK), 1 (General error) …

  • Use stdin, stdout, stderr:

○ Log to stdout. Don’t concern with routing and storage

slide-17
SLIDE 17
  • 2. Explicit interfaces

Dependencies to other containers should be made explicit by defining its interfaces.

  • CLI arguments
  • Environment variables
  • Network / Port
  • Document via labels
slide-18
SLIDE 18

Best practices (Explicit interfaces)

  • CLI arguments

○ Use a lib for parsing / validating

  • Environment variables

○ Set defaults in the image ○ Overwrite with `docker -e`

  • Network / Ports

○ Expose port via EXPOSE in Dockerfile

  • Document via labels

○ E.g. LABEL INSTALL="docker run ...

slide-19
SLIDE 19
  • 3. Disposable Containers

Containers should be treated as disposable artefacts. The application shouldn’t rely on a particular container instance to be running. Pets vs. Cattle: Treat your container as part of a cattle. You number them and when get sick you shoot them.

slide-20
SLIDE 20

Best practices (Disposable Containers)

  • Only keep ephemeral state

○ Don’t assume this state between two requests

  • Robust against sudden death

○ If the container gets interrupted pass on your current job.

  • Minimal setup

○ If more setup needed let the scheduler know

slide-21
SLIDE 21
  • 4. Immutable

Once a container image is build it shouldn’t be changed. State should be extracted and changes to the container should be applied by rebuilding.

slide-22
SLIDE 22

Best practices (Immutable)

  • Strive for dev / prod parity
  • Extract runtime state in volumes
  • Anti-pattern: docker exec
slide-23
SLIDE 23
  • 5. Self-contained

The container should only rely on the Linux kernel. All other dependencies should be made explicit and added dynamically.

slide-24
SLIDE 24

Best practices (Self-contained)

  • Add dependencies at build time

○ Build Uber-Jar and include webserver

  • Strive for zero-config deployment
  • Generate dynamic config files on the fly
  • Anti-Patterns:

○ Put config into a volume ○ Put code into a volume *

slide-25
SLIDE 25
  • 6. Small

A container should have the least amount of code possible to fulfill its job.

slide-26
SLIDE 26

Best practices (Small)

  • Build from scratch
  • Use small base-image

○ busybox, alpine

  • Reuse custom base image
  • Anti-Pattern: VM Container
slide-27
SLIDE 27

Recap: Modular Container

We define a modular container as the collection of these 6 properties:

  • 1. Proper Linux process
  • 2. Explicit interfaces
  • 3. Disposable
  • 4. Immutable
  • 5. Self-contained
  • 6. Small
slide-28
SLIDE 28

nginx Proxy Rails Frontend A Go Backend A Node Backend

slide-29
SLIDE 29

nginx Proxy Rails Frontend A Go Backend A Node Backend

Redis Cache Logging Adapter Reverse Proxy

slide-30
SLIDE 30
slide-31
SLIDE 31

Pods

  • Group closely related containers
  • A single deployable unit
  • Share all available namespaces
  • The pod as a whole and the individual containers

can be limited

slide-32
SLIDE 32

Share namespace

  • Sharing the same network namespace and access to the same IP

and port namespace

  • Sharing the IPC namespace for communicating e.g. Unix sockets,

shared memory, system message queues

  • Share the same hostname via the UTS namespace
  • Share the PID namespace and can see each others processes

(not supported by docker)

  • Sharing the same volumes
slide-33
SLIDE 33

Outline

Building blocks

  • Modular container
  • Pods

Composite patterns

  • Sidecar
  • Ambassador
  • Adapter
  • Chains
slide-34
SLIDE 34

http://blog.kubernetes.io/2015/06/the- distributed-system-toolkit-patterns.html

slide-35
SLIDE 35

A Node Backend

Redis Cache Logging Adapter Reverse Proxy

slide-36
SLIDE 36

Pattern: Sidecar / Sidekick

  • Enhance & extend the main container.
  • K8S: transparently. Netflix: platform features.

UDS A Node Backend

MAIN CONTAINER

Redis Cache

SIDECAR

Pod

slide-37
SLIDE 37

A Node Backend

Redis Cache Logging Adapter Reverse Proxy

slide-38
SLIDE 38

Pattern: Adapter

Standardise and normalize output. E.g. logging and metrics.

localhost or A Node Backend

MAIN CONTAINER

Logging Adapter

ADAPTER

Pod

slide-39
SLIDE 39

A Node Backend

Redis Cache Logging Adapter Reverse Proxy

slide-40
SLIDE 40

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)

slide-41
SLIDE 41

More info:

  • https://docs.giantswarm.io/fundamentals/user-services/container-injection/
  • https://docs.giantswarm.io/fundamentals/user-services/service-discovery/
slide-42
SLIDE 42

Pattern: Container chains

Defined order of starting and stopping sidecar container.

A Node Backend

MAIN CONTAINER

Storage Config

SIDECAR

Discovery

SIDECAR

Network Config

SIDECAR

(Pod)

slide-43
SLIDE 43

Recap

Building blocks

  • Modular container
  • Pods

Composite patterns

  • Sidecar
  • Ambassador
  • Adapter
  • Chains
slide-44
SLIDE 44
slide-45
SLIDE 45

GiantSwarm.io bit.ly/container-patterns @luebken

slide-46
SLIDE 46

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)
slide-47
SLIDE 47

Credits

  • https://www.flickr.com/photos/skynoir/8241460998 (Cover image)
  • https://www.flickr.com/photos/tinker-tailor/8378048032/ (Help us image)
slide-48
SLIDE 48
slide-49
SLIDE 49
  • ld slides
slide-50
SLIDE 50

A Node Backend

CONTAINER

+

Redis Cache

Fat Container

slide-51
SLIDE 51

A Node Backend

CONTAINER

+

Service Discovery

Fat Container

slide-52
SLIDE 52

A Node Backend

CONTAINER

+

Logging Adapter

Fat Container

slide-53
SLIDE 53

Linked Containers

Docker Link A Node Backend

CONTAINER

Redis Cache

CONTAINER

slide-54
SLIDE 54

A Node Backend

MAIN CONTAINER

Service Discovery

AMBASSADOR

Linked Container

Docker Link

slide-55
SLIDE 55

Shared volume

Host volume A Node Backend

MAIN CONTAINER

Logging Adapter

ADAPTER

slide-56
SLIDE 56

NodeJS Example

https://github.com/giantswarm/giantswarm-firstapp-nodejs/blob/master/server.js

server.listen(httpPort, httpAddress); process.on('SIGTERM', function() { console.log("Received SIGTERM. Exiting."); server.close(function () { process.exit(0); }); });

slide-57
SLIDE 57

Pods Examples

  • Redis cache via unix socket
  • Monitoring adapters
  • Cache init via named pipe
slide-58
SLIDE 58

Best practices (2) (Explicit

dependencies)

  • Volumes

○

slide-59
SLIDE 59

Container Runtime (Explicit contracts)

  • Start containers with --icc==false && --link:other-

container