Designing a Docker Stack for Symfony apps: lessons learned

1. It’s all about eXperience
Gaetano Giunta
Symfony Live
Sept 2016
Designing a Docker Stack
for Symfony apps:
lessons learned

2. If you have never heard of used
Docker
A.I am living under a rock
B.I am living on the moon
01

3. What is it,inone phrase
Definition according to Me™
"just like a VM, but lighter"

4. Getting started iseasy
Getting off the hook on the other hand…
"just like a VM, but lighter"
all it takes to get started:
docker run -ti ubuntu:15.10 bash

5. Where the magic stops
• how to share application data with the container?
• how to access the apps in the container (map container ports to the
host)?
• how to start multiple containers together and connect them?
• how to access the log files from the application?

6. Then things get tricky
• mapping of user ids to properly handle filesystem permissions
• linking containers when there are circular dependencies (solved with recent
Docker versions)
• applying security updates to existing containers
• and more…
• for some more of the fine details, see f.e. this blog post:
http://blog.kaliop.com/en/blog/2015/05/27/docker-in-real-life-the-tricky-parts/

7. Docker Compose tothe rescue!
• a single file describes multiple containers
• a single command to start/stop them all together
• permits further automation (via eg. introduction of variables)

8. A Docker stack for Symfony apps
A.Source code?
B.https://github.com/kaliop-uk/websummercamp2016
02

9. Introducing the stack
• apache
• mysql
• memcached
• solr
• php cli
• varnish
• nginx
plus
• control panels for all of the above
• phpmyadmin
• maildev (an smtp server for development purposes)
• dockerui (a container monitoring the whole container stack [Inception!])

10. In1000 words
Ascii art rocks!

11. How it works
All the things someone else has figured out for you
• configuration of the applications is mounted as volume, not copied into the
image
a simple service restart is sufficient to take changes into account
• application source code is kept on the host computer
no risk of losing changes when rebuilding containers
no need to have containers running GUI or IDEs
• all log files accessible from the host, in one place
• use ssh-agent to avoid developers storing their own private keys inside the
containers

12. How it works, II
All the things someone else has figured out for you
• allow developers to change some variables, while providing good defaults
• a configuration file is provided, which has all the variables that developers can customize
• a 2nd configuration file has to be created with local changes (empty is fine)
• ex: id of the user account on the host computer, or github credentials
• the config file with local changes is not committed to git
• not tied to a specific project
can be quickly converted for usage of Drupal / eZPublish / etc…
• two of them can be run in parallel

13. How it works, III
All the things someone else has figured out for you
• the containers have to replicate as much as possible a production
environment
the base images used are Debian or Ubuntu (the platforms we
generally deploy on)
• the applications are started using service start and service stop commands
• cronjob tasks definitions are kept as part of the sources of the stack
• developers can access 2 Symfony environments using one stack
• one via http (ie. DEV), one via https + Varnish (ie. UAT)

14. Demo time
At last!

15. I’ll be here all night
THANK YOU
https://github.com/kaliop-uk/websummercamp2016
• @gggeek
• www.kaliop.co.uk