In ihrem Talk haben sie ihre Erkenntnisse geteilt: wie sie Docker einsetzen und welche positiven und negativen Erfahrungen sie dabei bereits gemacht haben. Dabei sind sie auf sinnvolle Anordnung von Docker-Befehlen eingegangen, auf sinnvolle Docker-Registries, auf Staging und Verlinkung von Containern über Hardwaregrenzen hinweg, auf Continuous Deployment und all das andere lustige Zeug, was sie so mit Docker machen.
4. INTRODUCTION
• One existing application
• Have it available for several different legal entities
• No way to implement multitenancy the existing
application
12. VARIANT 2
• Connection between containers
• Not via docker linkage
• Via /etc/host entry and environment variable
• Interpreting startup shell script in container
18. VARIANT A
• Classic approach
• Running applications on the metal
• Physical servers, each needs to be configured for the
application
• One server that runs the application containers
20. VARIANT B
• More flexibility
• Every physical server is basically the same
• Installation done via script in a few minutes each
• Containers can then be run on any server
• Images contain all the needed configuration
25. VARIANT D
• Configure containers to point to proxies
• Proxies manage certificates
• Proxies pass through containers
• Allows multiple containers per system to run in
parallel while they can be addressed on their own
34. COMMON BASE IMAGES
• Common stuff in common base image
• As much as possible in base image
• Define versions of tools explicitly
• Lowers registry size
35. GROUP COMMANDS
• Try to combine commands with „&&“
• Less intermediate containers
• Increases build performance
• Lowers registry size
38. ORDER COMMANDS
• Stable commands as early as possible
• ADD commands as late as possible
• Caching increases build performance
• Lowers registry size
41. USE SCRIPTS
• Running containers can be complicated on the
console
• Scripts can improve readability and memorability
• Improved speed and less failures
• Reusability
42. BUILD CONTINUOUS
• Use scripts in continuous integration server as well
• We use „Execute shell command“ jobs
• e.g.: flens web build && flens web rerun
43. USE PROXIES
• Proxy on the physical machines (e.g. nginx)
• Containers listen only to localhost device
• Nginx handles incoming requests and passes on
• Nginx handles security
• More than one container of a given type
• By symlinking nginx config files you can switch from one slot to another
44. USEVOLUMES
• Volumes are directories mounted from the
physical host
• Files in a volume are visible from inside the
container (and writeable)
• Useful for logging, syncing data, etc…
45. READ-ONLY CONTAINERS
• A read only container cannot write to its own file system
• Can only write to volumes
• Perfectly immutable containers are easily interchangable!
• Build and distribute containers even more freely
• No unexpected states, defined income -> defined outcome
48. QUIRKS OF DOCKERFILES
• COPY vs ADD
• ADD can be a URL,ADD extracts tar.gz files automatically
• ENTRYPOINT vs CMD
• CMD can be overwritten at startup, ENTRYPOINT cannot
• Both are possible in a single Dockerfile
• ENTRYPOINT/CMD syntax
• determines if the executable is started directly or in a shell
49. QUIRKS OF DOCKERFILES
• COPY vs ADD
• ADD can be a URL,ADD extracts tar.gz files automatically
• ENTRYPOINT vs CMD
• CMD can be overwritten at startup, ENTRYPOINT cannot
• Both are possible in a single Dockerfile - this combines them!
• ENTRYPOINT/CMD syntax
• determines if the executable is started directly or in a shell
51. TRUSTYOUR OWN SKILLS
• Young technology, many tutorials, everybody else
knows it better
• Linking is fine, but not for us
• Configuring /etc/hosts at startup works wonders
• Try to use your own solution
52. DON’T USE LINKAGE
• Not possible over real machine boundaries
• Often leads to problems during startup
• Use /etc/hosts and environment parameters
53. DOCKER IN DOCKER
• Our infrastructure builds docker images
dynamically
• Our infrastructure is dockerized
• Do we need „docker in docker?“
54. DOCKER IN DOCKER
•Docker in docker is possible
• docker run -- privileged flens/mw:1.23
•Container runs inside flens/mw
•Problems during update of outer app
55. DOCKER IN DOCKER
•We used client/server docker communication
•Client = flens/mw
•Server = Docker of host system
•Similar to boot2docker
•All container runs on host system
56. IT’S CHEAPER
• We can use off the shelf servers
• We can use virtualized servers
• We can distribute easily over different server
providers
• Easily scalable
57. IT’S BETTER
• Release on touch of a button
• Deployment on touch of a button
• Transparent versioning of all apps
• Transparency of OS environment running the apps
• Environment is now part of dev process and versionable