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.
Streamlining Python Development: A Guide to a Modern Project Setup
Preparing your dockerised application for production deployment
1. Preparing your dockerised application for
production deployment
Dave Ward
Globe Online Ltd
PHP UK Conference
17th Feb 2017
2.
3.
4. 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
8. What is Docker?What is Docker?
http://geekyplatypus.com/dockerise-your-php-application-with-nginx-and-php7-fpm/
9. ‘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
11. These are great for
• Speed
• Getting developers up and running
• Development environment Consistency
• Only need docker to develop
• IDE development
12. Issues
• No accountability of image creation
• Not transparent
• Not fit for scaling
• Environment Specific
• No logging
• Disorganised repository
• Not Immutable
16. 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
• Dockerfile.build
• docker-compose.prodsite.yml
• /[services]
17. The Power of Three
git clone git@bitbucket.org:you/your-app.git
cd your-app
docker-compose up -d
18. 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
20. 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.
24. 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
29. Development Production
Dependencies installed
as part of the docker
image build.
Instructions in
Dockerfile.build
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
39. • 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)
40. • 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
https://docs.docker.com/engine/swarm/secrets/
Simple Example
Start preparing your images now!
42. 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.
43. 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.
44. 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
45. 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.
46. 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
48. Supervisord
• Run more than one process in container
• Benefits
• Greater Control of processes
• Better management of processes
• Base Image
• PHP-FPM
• Crontab
• Workers
53. 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 run.sh script (e.g. composer install)
• Leads to really a long start up time
• Relying on IP Addresses
54. 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