Container management and development of a process towards keeping Docker images up to date and secure may seem like a daunting task, especially at scale. Stale images lead to security vulnerablities, and this is a very real concern when administrators can let containers run for weeks at a time without updates.
Like most early adopters, we struggled for some time to adjust our concept of a maintenance cycle within a container-driven paradigm. However, over time, we’ve evolved a moderately sane method for keeping our containers up to date and secure:
Develop Comprehensive Tests for the Container
### Tests Provide test coverage for your application, and include them in the application repository. A discussion of test writing is far out of scope for this post. Some discussions and resources, some relating to Drupal:
- Relation between BDD and TDD
- How to do Test Driven Development (TDD) in Drupal?
- Drupal Extension to Behat and Mink’s documentation
Ensure that the image can (optionally) be launched with the tools and means to test itself. To avoid polluting production images with testing tools and libraries, we allow an environment variable to control the installation of testing tools when launching the container.
Build the Image and Run Tests
Build/Push Image to Repo On Success
Upon successful testing, configure the CI service to trigger a build and push to the image repository. For our public images, this is DockerHub. For our private images, this is the Amazon EC2 Container Registry.
Configure cron for builds
Most CI services offer . Travis provides repository cronjobs upon request. Triggering a nightly rebuild and test will pull in security fixes automatically, and re-test the image using those new changes.
Deploy Rolling Updates for Instance Nodes
In low-traffic periods, update the running containers with the new images stored in the repository. How this occurs depends entirely on your infrstructure and setup.