\n\nAssuming that the reader of this blog has a fair idea of the docker ecosystem!
\n
Docker has changed the world of software development! Since the last few years, docker has helped the developer community, enterprises, and startups to create solutions quickly and effectively. Also, deployment is relatively hassle-free with docker (conditions apply). And worth mentioning is, it resolves the “Works fine on my system” problem.
\nWell, just not docker, there are many container ecosystems available as an alternative to Docker. For example, Mesos by Apache and Vagrant by Hashicorp. Docker is more loved for what it is not, and that is Bulky! Docker is otherwise lightweight, works mostly with Linux and eventually was identified by Kubernetes in 2015. But, that story... some other time!!
\nStraight to the context, Docker Compose! Docker compose is a powerful utility that is bundled with Docker installation. Docker-Compose can be used for production and development, to make things virtually seamless.
\nDocker is doing a great job when it comes to describing and developing microservices.
\nWhile working on microservices where quite a few ( being reasonably complicated, in our example 6 ) containers talk to each other to complete a task and since it is an end to end task, the whole thing looks very complicated. To rectify :
\nthe developer has two choices, create a script in a scripting language of choice, or choose docker-compose. Well, docker-compose is an easier option.
\nHere in this kind of practical example, we are going to demonstrate a similar situation, where multiple containers talk to each other. We are going to use docker-compose as our primary tool to build and deploy images.
\nExactly! What is the problem? As such, there is no problem, but it may arise if we do not program or develop it well in an integrated manner. Programming a component and managing it well reduces the time-to-production to a greater degree.
\n\n\nI am not a great programmer; I am just a good programmer with great habits.
\n\n
\n- Martin Fowler
\n
While designing and developing complicated systems where microservices are involved, integration and debugging become cumbersome.
\nTo ease it up docker-compose acts a friend.
\nFor the example above we are going to write a docker-compose. Docker-Compose has got powers to
\nFirst things first, the Dockerfile.
\nStarting from the API. The API needs a docker image to build. The following is the Dockerfile for the same.
\nFROM node:alpine\nWORKDIR '/app'\nCOPY ./package.json ./\nRUN npm install \nCOPY . .\nCMD ["npm", "run", "start"]Since the other two components, listener and frontend are also written in JavaScript the Dockerfile does not change at all for them too, for this particular example.
\nThe following is a two-liner Dockerfile for gateway. The conf file targets apiserver and frontend. Please have a look at the configuration file in the repository itself.
\nFROM nginx\nCOPY ./nginx.conf /etc/nginx/conf.d/default.confThe other 2 components :
\nFirst things first, file version. Since it is all yaml out there, the file version tells docker-compose about the data structure. The data structure which is expected by docker \"compose\".
so we start the docker-compose as
\nversion: '3'All the components in the docker-compose are known as services. Next, we are going to write some services. Yes, the services we have written for our business.
Message Queue :
\nThe message queue shall use softwaremill/elasticmq image out of the box and the applications will access that on port 9324. The service description in docker-compose shall look like this.
mqserver:\n image: softwaremill/elasticmq\n ports:\n - '9324:9324'That is analogous to docker run -it -p '9324:9324' softwaremill/elasticmq.
A bit more complicated service next, mongodb.
\nmongodbdb: \n depends_on: \n - mqserver\n image: mongo\n container_name: mongo\n volumes:\n - /data/db:/mongodata\n ports:\n - '27017:27017'There are a couple of things one may notice more here.
\ndepends_on shall wait for the container of mqserver service to come up, before mongodbdb service goes on air.
\n\nDocker is only liable to check the containers when we use depends_on, if you want to check whether your service (which you have embedded) is ready to use or not, use
\nhealthcheckandlink.
Apart from this, we are mounting a volume and exposing ports for an image mongo which gets pulled directly from the docker container registry. container_name will give the service a name, so that it can be discovered *in the network. *Kind of a domain name in the internal docker-compose network.
Now the developer's proprietary API service:
\napiserver:\n restart: always\n depends_on: \n - mqserver\n - mongodbdb\n\n build:\n dockerfile: Dockerfile\n context: ../fs-express-api/.\n volumes:\n - /app/node_modules\n environment: \n - NODE_ENV=production\n - AWS_SQS_URL=http://mqserver:9324/\n - AWS_SQS_FQ_URL=http://mqserver:9324/queue/fsqueue\n - AWS_ACCESS_KEY=na\n - AWS_SECRET_ACCESS_KEY=na\n - AWS_REGION=REGION\n - QUEUE_NAME=fsqueue\n - MONGODB_CONNECTION=mongodb://mongo:27017/fsorder\n - API_APP_PORT=5000\n ports:\n - '5000:5000'The buildtag will be used by the docker-compose build command to build an image. The build is defined as Dockerfile and the context is docker context, the directory which you want to use as context. Equivalent to: docker build -f filename.
The more you are seeing here is environment and restart options. Environment variables are used to set environment variables while running the image. This is another part where docker-compose comes handy. Think about setting all nine environment variables with docker run.
restart is a bit interesting. One may specify a restart policy if the application crashes, which leads to stopping the docker image itself. always specifies to restart the container if it exit.
In the environment section, one can see mqserver and mongo, instead of the regular localhost and loopback address. This is because when we run docker-compose, it creates a DNS recordset of all the services mentioned. The services can be referred to by their names. A slight deviation here may happen when the container is explicitly named. Here, container_name = mongo is used for service mongodbdb. Hence, the other containers in the environment shall refer to it by mongo and not mongodbdb.
The pollingmod and frontend services are quite the same.
\n pollingmod:\n restart: always\n depends_on: \n - mqserver\n - mongodbdb\n build:\n dockerfile: Dockerfile\n context: ../polling-mod/\n volumes:\n - /app/node_modules\n environment: \n - AWS_QUEUE_URL=http://mqserver:9324/queue/fsqueue\n - AWS_ACCESS_KEY=na\n - AWS_SECRET_ACCESS_KEY=na\n - AWS_REGION=REGION\n - MONGODB_CONNECTION=mongodb://mongo:27017/fsorder \n\n frontend:\n build:\n dockerfile: Dockerfile\n context: ../fs-frontend\n volumes:\n - /app/node_modules\n - ../fs-frontend:/app\n stdin_open: true\n ports:\n - '3000:3000'Finally, the gateway. So, a gateway is created on the front using Nginx to make the development production-grade. If you go through the gateway code you will find that the services are accessed by their name frontend and apiserver.
upstream frontend{\n server frontend:3000;\n}\n\nupstream apiserver{\n server apiserver:5000;\n}The Nginx container opens port 80 to an external port 5500. The Nginx container keeps configuration where the user can see just one port 5500 from out of the system, everything else is gray.
\n