Improves Environmental Consistency and Runtime Security
March 07, 2017

Improves Environmental Consistency and Runtime Security

Adam Eivy | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

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).
Honestly, sometimes I skip the use of Docker when developing Node.js apps since they encapsulate the web server component and make runtime really easy--but for deployment, I always build a Docker image--it's the only way to know that what I'm deploying is what the build server tested. Additionally, when onboarding new developers on complex services, I've found Docker to be invaluable--now we just say, "run the Docker compose" instead of "install this, then that, then configure these ports, then make sure your OS is the right version for this dependency and stop this other service with conflicting ports before you run this, etc."