Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using Docker in the Real World


Published on

Looking at how people, with current deployments, can start using docker with out having to replace anything. Also giving a migration path that allows testing the separate pieces and migrating over slowly without painting yourself into a corner. Also covering why you might want to do this and the problems it may help to solve.

Published in: Technology

Using Docker in the Real World

  1. 1. Using Docker in The Real World PHP Craft 2015 Tim Haak @tim_haak
  2. 2. Who I am Tim Haak What do I do: Consulting as a developer across the stack Though focusing on php and web and linux side of the world. @tim_haak
  3. 3. So you heard docker was great
  4. 4. Though so many options
  5. 5. Why would you want docker Repeatability Can allow simpler scaling No difference of libraries between dev and live Shrink wrapping Versioning Simple rollback of libraries programs Multiple version of programs on the same pc Isolation More lightweight that virtualization
  6. 6. What doesn't it solve Replication/Resiliency Bad code Its a tool that help with specific problems Its not a magic bullet
  7. 7. Part of Dev/Ops Why Dev/Ops/Automation Remove the fear of breaking Simple Roll forward or back Free you time for more important things You can't manage what you can't see
  8. 8. But how The following are tips and methods on how to bring it into your organisation. Not an exact recipe. Take the bits that make sense for you. Assumes you already have systems that tend to the monolithic application side.
  9. 9. Start with something simple Don't start with your biggest critical app You will fail Take small steps that keep moving you to a better place Start with a non critical piece of your architecture
  10. 10. Examples Log processing ? Dashboard ? Basically something that if its off while your working things out will not be a problem
  11. 11. Run your own registry Docker images are available Don't forget to add a ssl cert
  12. 12. Docker Registry docker run -d -p 443:5000 --restart=always --name registry -v `pwd`/auth:/auth -e "REGISTRY_AUTH=htpasswd" -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd -v `pwd`/certs:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key registry:2 mkdir auth docker run --entrypoint htpasswd registry:2 -Bbn timhaak securepass > auth/htpasswd
  13. 13. How to use Docker Registry URL: docker login --email="" --password="securepass" --username="timhaak"
  14. 14. Put one person on it Who Cares With The Need Skills Not the new intern/junior developer
  15. 15. Why Only one person will go through the wrong path pain Faster iteration while learning Can back out a wrong path quickly Rest of the team only see the final simpler path
  16. 16. Store configs externally While your starting mount the configs etc via a volume into the container Easier debugging You don't have to rebuild the container to update Other members of your team can just edit the file Allows you to use something like Ansible to generate the configs
  17. 17. Known good state When restarting the image. DELETE the previous container then restart. This way your always starting from a know good state. The only thing that can change is the config. Make sure that docker cleans up previous containers and starts new ones on reboot. That way rebooting always puts you into a good state docker rm -f image_name docker start -d -v /config/config -p 321:321 timhaak/awesome1
  18. 18. Dev Environment Before working on your live servers. Start but using docker as you dev environment. Its safer Faster testing Don't have to worry about testing You can make sure you have all the required packages. Though we all know exactly whats installed on our servers :)
  19. 19. Mongo This is actually a good candidate for service bring into docker Add a docker version into a replica set Make sure it will only be a slave while testing If you mess something up your can just remove it as the other servers will still have a copy of the data. Don't for get to store the data in a volume
  20. 20. Add DNS Rest Api Sounds hard but isn't Allow of adding and removing servers from DNS rotation You can't get it wrong (Especially when your panicking) Can eventually be automated Please secure it ie
  21. 21. Where many people are
  22. 22. Where we want to get to DockerDocker Docker Docker Native Native
  23. 23. HaProxy / Load Balancer This is actually one of the most important pieces of the system as it allows you to switch out or test underlying application servers. You don't have to use HaProxy its just one of the more popular ones to use and actually gives very nice reporting. Also its been quiet battle tested. There are good node and go alternatives. I would look to setting up an api here to change config. Fairly easy agains haproxy.
  24. 24. SSL Off loader / Load balancer This is a good place to start bringing docker into your live environment. (Assuming you have a monolithic app) Fairly simple to test. Makes your system more resilient. Allows you to do things like fix cache headers etc. Once in place can simplify your updates. Starts you down the path of microservices
  25. 25. Initial testing Just spin up a temporary server for initial testing. If you can't do it with your infrastructure look at one of the cloud servers providers that charge for only the time you use. Locally you can look at (R0.09 per hour.) Setup server and install docker (I hope your using something like Ansible)
  26. 26. Initial testing Set up your config Run the docker container If you change your host file it should all just work
  27. 27. Make it live With this you'll have to move the port that your application server listens on. This is the most dangerous bit. Especially if you have a single server. Though once you've got the pieces all working together switching docker images in and out become quiet simple.
  28. 28. Wrap the code Ok so how do you now wrap the actual application server into docker. You don't want to mess up the current server incase you get something wrong. Also you want to make sure its using the same files as the current server. Well you've got the image that you've been testing on your local pc while doing dev?
  29. 29. Wrap the code Start it up on the live server mounting the current server's web directory as a volume into the docker container running on a new different port. Don't you have to stop the old server? No the only problem you may have is with things like cache files or if your using locks.
  30. 30. Wrap the code Test the server on the new port is it all working. No client will see it as the load balancer not using it. But its on the same server should have access to everything it needs. If everything is working tell your load balancer to switch to the new server's port. Check the live site if its all working great. If not switch back. The only delay will be you as you never stopped the old server.
  31. 31. Going forward You can now start moving more services into docker. As you feel secure in that its work start removing the unused programs and cruft from the old server. This will reduce the chance of problems. Also you are now decreasing the things that need to updated and managed on the base pc.
  32. 32. Future things to look at The follow are things you may want to start looking at Some are available now some are near future. Though each does increase the complexity which you may not want to do
  33. 33. VPN Something that seems to be over looked quiet often as people move to micro service and more servers. Is secure communication. Main advantage is safe zones so you don't have to wrap everything. As an example servers talking to a centralised redis cache
  34. 34. Link your servers docker run -d --name tinc --net=host --device=/dev/net/tun --cap-add NET_ADMIN --volume /srv/tinc:/etc/tinc jenserat/tinc start -D
  35. 35. Auto Discovery / Config Eventually your going to want to have your containers auto configure them selves as they start up There are a couple options here each will depend on your personal preference.
  36. 36. Alternatives
  37. 37. Tools On Top SkyDNS2 - DNS Discovery curl -XPUT http://etcd1/v2/keys/skydns/local/skydns/dns/ns/ns1 -d value='{"host":""}' confd - config generation/update
  38. 38. $client = new Client($server); $client->set('/foo', 'fooValue'); // Set the ttl $client->set('/foo', 'fooValue', 10); // get key value echo $client->get('/foo'); // Update value with key $client->update('/foo', 'newFooValue'); // Delete key $client->rm('/foo'); // Create a directory $client->mkdir('/fooDir'); // Remove dir $client->rmdir('/fooDir');
  39. 39. Replication
  40. 40. Live migration v=mL9AFkJJAq0&
  41. 41. Networking Lots of active work here but no clear winner as yet. Though most only provide a single network. Still waiting for one that can give you more SDN functionality. Basically single network and ability to move containers in and out easily. Though if you know what your doing using Pipework and openvswitch you could build your own system. Though very few people would have this requirement.
  42. 42. @tim_haak Thanks