Containerize your app @ TYPO3 camp Venlo 2017

Best practices talk on how to containerize, test and run an application using (Docker) containers. Presented at TYPO3 camp Venlo, the Netherlands. Note that slides are mainly meant as a summary of the talk.

Transcript

1. Containerizing your application using Docker While standing on the shoulders of giants instead of cowboys… Hi TYPO3 Camp 2017!
2. Who am I? Freelance developer Co-organizer of DomCode @lucasvanlierop
3. Why this talk? • Contribute to container adoption • Warn for pitfalls and drawbacks • Provide guidance rather than a complete practical introduction. • Not just about Docker • Not just about containers
4. What to expect? • Basic explanation of containers • Some best practices • My favorite setup • Experiment: applying design principles • Questions (just yell in the meantime)
5. So what is a (Linux) container? • Place where a process feels at home • Also a pretty lonely (isolated) place. • It all starts with an image (distro + libraries + runtime + default config) • If your run an image it becomes a container (like class → object) • Can have dependencies like config, storage, networking
6. Some advantages • Images can be really small • Images are easy to extend • Less abstraction, back to shell commands • Consistency between dev/test/prod • Predictable! • Almost no overhead → fast • There are many tools! • Force automating everything • Suited for Web/Desktop/CLI apps
7. • There are many tools!... • There's still complexity (just somewhere else) • Running (persistent) databases in a container is still a challenge • That said databases are probably the most stable part of a typical app Are there disadvantages too?
8. General best practices for building images • Use official base images (stand on the shoulders of giants) • Take a look around at hub.docker.com • Be aware of unoffical (cowboy) images • Use specific versions of base images. • Keep images small in size • Optimize layers...when your done. • Think about readability • Update often (scheduled builds)
9. Best practices for tool images • Consider entrypoint for CLI tools • Handle signals! (using trap/tini/--init) • Use 'exec' if you want to take over PID 1
10. Best practices for app images • Complex image → app does too much • Consider splitting app • Containers are perfect for m(icro/ini/edium) services. • Pack image and application together for production • Docker has many more best practices on their website!
11. Some best practices for development • Mount source code • Mount persistent files (database, uploads) • Mount local config/cache (composer, npm) • Separate application and build tools • Run tools as yourself (uid/gid) • Helper scripts for containerized tools • log to stdout
12. Some best practices for production • Leave out dev tools (xdebug, composer etc.) • Leave out crap (tests, documentation, dev related config) • Mount persistent files like uploads • Do not keep state (that you can't rebuild) • Consider running a container as read only • Containerized database? → do research first • Run as non root user • Use health checks • Spend time on setting up logging
13. Building your app • No special tools should be required • You can run all build tools in a container • Even docker-compose runs in a container • Minimum: Docker engine + Make or bash • Build production assets
14. Testing your app • Write a lot of tests • Run test in CI • Build image after successful test • Run image • Smoke test using curl • System test using Selenium
15. My current setup – tools • Just GNU Make + containerized Docker Compose • CI (TravisCi or GitLab Ci) • Image Repository (Docker Hub or AWS CR) • Traefik proxy • Production: plain Docker or Swarm on DO/AWS VM's
16. My current setup – services • Different application concerns in different containers: Httpd/Runtime/Db/Cache/Queue • Different runtimes in different containers: PHP/Nodejs • Different helper concerns in different containers: Gulp (watch), Mailcatcher, Selenium
17. My current setup – app versions Different versions of application. PHP example: • Base: PHP + libs + exts • Dev: base + xdebug + env vars + mount • Build: base + composer + zip + git + mount • Prod: base + copy of built application
18. My current setup – environments • Multiple Environments like dev/ci/staging/prod • All have their own docker-compose file • All have own config files • Configuration is passed via env vars
19. ? Questions, Suggestions, remarks?
20. Thanks!! If you have more questions: Twitter @lucasvanlierop