The document discusses using Docker containers to build replicable development environments that allow monitoring of social media mentions. It recommends using a single container that contains the full application stack rather than separate containers for each component. Data volumes can be used to share data between containers running the same database, which allows deploying new containers quickly while improving the deployment time by 80%. However, there is still room for further optimizing the workflow.
13. docker run -d -v /var/lib/mysql -name db_data tianon/true
14. docker run -d --volumes-from db_data mention/awesome-app
15. Where are we?
● Multiple running containers (CI, local, staging)
● One hour to deploy (80% improvement!)
● Yet even more room to improve
● Still at an early stage
Docker also references shoes! (Discovered through mention)
Fast growing team:
3 to 12 in one year half
1st US employee just hired (see http://www.slideshare.net/Clementdelangue/how-we-hired-our-first-us-employee-in-two-weeks)
Structure dev workflow: more testing, new environments, etc
Work from different workstations, setup workstations in minutes.
Mention technical stack
Environments have to run everywhere, from workstations to data-center.
Vagrant’s snapshots not easy to distribute
Things are moving fast: Vagrant just announced Vagrant Cloud (see http://www.vagrantup.com/blog/vagrant-1-5-and-vagrant-cloud.html)
Why not Docker, designed for that? No overheard on servers, “natively” run on Mac (with Boot2Docker https://github.com/boot2docker/boot2docker)
Vagrant as a VM manager, Docker to deploy the app!
Ready to put our app in a container! 2 native ways to achieve that:
- Interactive mode
Interactive
Easy to start
Flexible
Non-extensible
“Black-box”, what’s really inside?
Package => commit => not repeatable
- Docker files
Explicit manifest of what’s inside the container
Repeatable build
Extensible
Harder to maintain
Slow to build for test purpose
Provisioning tool (Puppet, Chef): to explore!
For the moment, mainly for ease of testing and deployment, we decided to build only one container container embedding the full stack.
If you consider Docker in production, build several containers each for one part, looks like a good strategy since it will let you move containers to another machine.
How-to orchestrate them ? Currently doing with bash scripts. Look at Fig (http://orchardup.github.io/fig/)
Data-containers (docker’s volumes)
common pattern while building container. They are basically containers which do nothing more than mounting and sharing a volume to other containers.
Run a container named db_data based on tianon/true image which mounts /var/lib/mysql
Run a container using volumes from db_data container, here /var/lib/mysql.
Now I can kill this container, no data lost.
Multiple running containers
CI (Jenkins)
Local dev env
Integration server (don’t need Vagrant, no overhead)
Run the same, EVERYWHERE
Lot of room for improvement
Private index to publish images
Improve Sharing folders performance
solved with Vagrant 1.5 rsync? iNotify, still in progress
NFS share from guest to host
Maintain container Dockerfile
Go to production ?
Still at the early stage
Tools to speed-up / facilitate deployment
Fig (http://orchardup.github.io/fig/)
Flynn (https://flynn.io/)
Dokku (https://github.com/progrium/dokku)
Fast growing community: https://docs.google.com/presentation/d/1P6y6WdgZwfrG5dZELTgtAPbOUNoPiKy4ib2mquRScTI/edit#slide=id.p
Track Docker’s news with mention
Happy to discuss about your XP!