docker article (2 Part Series)
Docker is becoming more and more popular and seems like every company is now turning to it to make the development and deployment process more efficient. The reason is that docker solves some common problems that have been around for quite a while in software development.
Most of the modern applications have similar setups. They all use a combination of different technologies to assemble a complete application functionality. An example would be an app that uses combination of following services:
Node.js for Webserver
ReactJs for frontend
MongoDb as a database
Messaging system - Redis
Orchestration tool - Ansible
Now if you have a little development experience, you already know that these technologies each have a version the application depends on. Also the application isn’t an isolated thing that just floats around. It needs to run in an environment, which could be a development, test or a production environment. Since the environments can differ in OS, version, hardware etc, it’s obvious that the application and its technologies with their respective versions should work the same on different environments.
Without docker, this means that each environment that the application runs on (local dev environment, a test or production server) needs to be configured with the correct versions of these services so that application can run properly.
So the following PROBLEMs arise
Compatibility of each service with the underlying OS
Compatibility of each service with the libraries and dependencies of OS (One service requires versionX of OS library. Another service - versionY of same library)
Every time version of any service updates, you might need to recheck compatibilities with underlying OS infrastructure
“Matrix from Hell"
For a new developer to setup the environment with right OS and Service versions
Each service has and can manage its required OS dependencies for itself, bundled and isolated in its own container
Change the components without affecting the other services
Change underlying OS without affecting any of the services
As a result, docker should avoid the typical “works on my machine” cases. In the development process, for example, developers and testers will have the identical environments where the application runs, since this environment is packaged in docker containers, which just like a file, can be transferred around as an artifact.
Also to make things easier for developers, there are already hundreds of ready docker images with different environments in the official docker repository. For example, if I need a Postgres DB for local app development, I can just pull a ready Postgres image with the version I need and with a single command I can have a Postgres DB running locally. Even better, if I need 2 different versions of Postgres DB for 2 separate applications, no problem too. I can pull the second docker image and start another Postgres instance with a different version using a single command.