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.

Preparing your dockerised application for production deployment


Published on

You’ve got your application dockerised for development. That process is working smoothly, and you’re gaining a lot of the benefits that docker gives you - environments are trivial to setup, independent of platform, and they are consistent for everyone on your team.

How do you go about taking the next step so that your application is deployed into a scalable and reliable production setup?

How do you create deployment artefacts which are built with consistency and transparency? How do you manage environment variables between staging and production environments? How do you perform actions / schedule processes in one environment and not another?

In this talk we will discuss what you need to do to get your dockerised application ready for deployment into a production environment.

Published in: Technology
  • Hello! Who wants to chat with me? Nu photos with me here
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Preparing your dockerised application for production deployment

  1. 1. Preparing your dockerised application for production deployment Dave Ward Globe Online Ltd PHP UK Conference 17th Feb 2017
  2. 2. Docker Benefits For Us • Quick to setup dev environments • Identical environments • Flexible resource allocation • Test site creation • Confidence in deployment • Stable releases • Amazing rollbacks • Easy scaling • Trivial Service Upgrades • Easy Continuous Deployment • Simple Configurations • Increased Productivity • “It worked on my machine” • Lightweight • Fewer Production Incidents • Zero Failed Releases • EnvironmentVersion Control • Resource Isolation • More Frequent Releases
  3. 3. Who Uses Docker In Development?
  4. 4. Who Uses Docker In Production?
  5. 5. What is Docker?What is Docker?
  6. 6. ‘Development’ Images • Based from trusted image • Mounted code that’s been committed to a custom image • Pushed to an image repository • No environment/secrets management • Dependencies installed post container start • Possibly setup with series docker run commands • Mounted volumes allow IDE usage
  7. 7. run push Dependencies commit IMAGE Docker in Development CONTAINER build pull mount
  8. 8. These are great for • Speed • Getting developers up and running • Development environment Consistency • Only need docker to develop • IDE development
  9. 9. Issues • No accountability of image creation • Not transparent • Not fit for scaling • Environment Specific • No logging • Disorganised repository • Not Immutable
  10. 10. Production Image Goals Immutable Ephemeral
  11. 11. Production ready artefacts • Automated Builds • Application Code • Pre-installed dependencies • Composer • Bower • Environment Capable
  12. 12. docker run Dependencies IMAGE Docker in Production CONTAINER docker build
  13. 13. A proposed repository structure • Your repository is now one level up. • Project environment is now under version control • /appcode : application code only • /appdata : data only container of appcode • docker-compose.override.yml • • docker-compose.prodsite.yml • /[services]
  14. 14. The Power of Three git clone cd your-app docker-compose up -d
  15. 15. Automated Builds • Builds a deployment artefact • Automatic or manual trigger • Error Handling • Build context taken from Dockerfile location • Repository Links • Remote Build triggers • Webhooks • Dockerhub does not use cached layers
  16. 16. git clone davidsimonward/phpukconference.git cd phpukconference git checkout -b develop docker build -f -t davidsimonward/phpukconference:latest . docker push davidsimonward/phpukconference:latest
  17. 17. Advantages • Images built in this way are built exactly as specified. • The Dockerfile is available to anyone with access to your Docker Hub repository. • Your image repository is kept up-to-date with code changes automatically.
  18. 18. Application Code
  19. 19. run push Dependencies commit IMAGE Docker in Development CONTAINER build pull mount
  20. 20. docker run Dependencies IMAGE Docker in Production CONTAINER docker build
  21. 21. Development Production Dockerfile instructs application code to be copied into the phpfpm image on build. Application Code is exposed for Nginx container. Application code is mounted into data only container. Nginx and PHP-FPM use volumes from this container
  22. 22. DEMO
  23. 23. Dependencies
  24. 24. run push Dependencies commit IMAGE Docker in Development CONTAINER build pull mount
  25. 25. docker run Dependencies IMAGE Docker in Production CONTAINER docker build
  26. 26. Development Production Dependencies installed as part of the docker image build. Instructions in Dependencies installed post container run. docker run --rm -v $(pwd):/app composer/composer install -vvv —ignore-platform-reqs docker exec -it PHPUKConference composer install -vvv Entrypoint script
  27. 27. DEMO
  28. 28. Private Dependencies?
  29. 29. Base Image
  30. 30. Config/Secrets
  31. 31. Some Solutions • ‘Baking’ it into the image • EnvironmentVariables • Volume Mounts • Secrets Store • Orchestration Specific Solutions
  32. 32. Docker Secrets
  33. 33. • Docker 1.13 • Only currently available to swarm services • Manages • Usernames and passwords • TLS certificates and keys • SSH keys • Other important data such as the name of a database or internal server • Generic strings or binary content (up to 500 kb in size)
  34. 34. • echo "noway-caiman-mumble" | docker secret create db_password - • docker service create --secret="db_password"…….. -e DB_PASSWORD_FILE=“/run/secrets/db_password" my:image Simple Example Start preparing your images now!
  35. 35. Logging Strategies
  36. 36. DataVolumes • Store logs in data volume on host • Reduce chances of data loss due to failed container • Easy to backup host volume • Not good for elastic architecture When to use? • On non-production systems when longer lasting logs are required.
  37. 37. Docker Logging Driver • Reads stdout and stderr output generated by containers • `docker run --log-driver syslog ……` • Native to Docker • Easy to configure • Centralises logs in a single location When to use? • Quick and easy solution when customised application logs are not required.
  38. 38. Application Logging • Each container uses internal methods for logging • Logging Framework • Monolog • Easy to implement • Applications independent of containers and host • Highly Customisable • Performance Overhead? When to use? • Use when you require a high degree of control over each application’s logging implementation
  39. 39. Dedicated Logging Container • Manage logging from within Docker environment • Part of architecture • Removes dependencies on the host machine • Simplifies scaling • Application containers need to be aware of the logging container, and vice versa When to use? • Use when you’d like a more flexible logging architecture with a central place to aggregate logs.
  40. 40. Logging via Sidecar • Similar to dedicated container for logging • Each container has it’s own dedicated logging container • Fully customise each application’s logging solution • Both the application and logging container must be treated as a single unit • Difficult to set up • May consume more resources than a dedicated logging solution When to use? • Use in a large, distributed architecture where you still need fine-tuned control over your logging solution
  41. 41. Other Processes
  42. 42. Supervisord • Run more than one process in container • Benefits • Greater Control of processes • Better management of processes • Base Image • PHP-FPM • Crontab • Workers
  43. 43. Container Monitoring
  44. 44. Container Metrics of interest • Container CPU –Throttled CPUTime • Container Memory – Fail Counters • Container Memory Usage • Container Swap • Container Disk I/O • Container Network Metrics
  45. 45. Monitoring Solutions
  46. 46. Common Mistakes • Creating images from running containers • Deploying with ‘latest’ tag • Storing credentials in the image. • Creating images from running containers • Doing too much in your script (e.g. composer install) • Leads to really a long start up time • Relying on IP Addresses
  47. 47. Deployment Process • UpdateTask Definition • Image for phpfpm container is updated • Update Service to use newTask Definition • Easily roll back to previousTask Definition • Immutable! • Confidence • Zero downtime deployments • Draining Connections
  48. 48. Questions?