Overall Satisfaction with Docker
Docker is transforming our confidence in build and release as well as developer onboarding. Docker containerization finally is fulfilling the promise that Chef never did, giving us environmental consistency across developers, build, various environments and production. We've been eliminating deployment time errors by encapsulating the entire operating system, language core components, security patches, etc., into the application build time. This has reduced the complexity of getting developers up and running. No longer do developers and operations have to understand the full workings of the dependencies within an application in order to run and deploy it--instead, we only need to know how to get Docker running and deployed to get our applications up and running. This allows us to have truly ephemeral environments and dependency management and eases autoscaling.
- Environment consistency via full application and operating system encapsulation
- Securing software runtime by ensuring that the whole environment is easily and quickly discarded and re-run from a known good state--as well as putting all dependencies of the operating system and patches into the built artifact
- Easing developer setup time (up and running immediately without installing various software dependencies and configuring ports/etc.)
- The ecosystem has many minimal base images for software but this could use more focus on secure base images
- Many useful Docker commands are not built in as shortcuts to the CLI, but instead need to be managed as other aliases (e.g. `docker rm $(docker ps -a)` to remove all running and stopped containers)
- It's not always easy for people to optimize the caching layers of docker images--an auditing tool that suggests the order of Dockerfile commands for cache optimization would be handy
- We've been able to simplify deployment/testing environments
- We've reduced infrastructure cost by deploying autoscale Docker containers
- We've gained build/release confidence that we didn't have before
- Chef
Before Docker, we were using Chef to manage our deployments. Chef didn't provide the environmental consistency and release confidence we needed. We had a split process between how the build servers, the developers and the deployed environments were managing the software dependencies (core OS, language runtime, security patches, etc.). Now all of those things are built into our application as part of the deployable artifact (the whole application rather than just the business logic). Additionally, developers can build Dockerfiles without having to learn Ruby--and operations can treat the applications more as a black box--only worrying about keeping the infrastructure running (rather than babysitting the application).