This is the 8th part of a series of articles under the name "Play Microservices". Links to other parts:
Part 1: Play Microservices: Bird's eye view
Part 2: Play Microservices: Authentication
Part 3: Play Microservices: Scheduler service
Part 4: Play Microservices: Email service
Part 5: Play Microservices: Report service
Part 6: Play Microservices: Api-gateway service
Part 7: Play Microservices: client-web service
Part 8: You are here
Part 9: Play Microservices: Security
The source code for the project can be found here:
Contents:
- Summary
- Tools
- Integration via Docker-compose
- To do
Summary
In the parts 1 to 7, we have developed our microservice application services independently. Those services are:
- Auth service (plus a database and a cache service)
- Job Scheduler service (plus a database, a kafka broker and a database for kafka broker)
- Email job executor service
- Report service (plus a database, a kafka broker and a database for kafka broker)
- An api-gateway service which acts as an entry-point to all other services.
- A client-web service
Now it's time to bring everything together. But before, lets have a look at the tools we need.
Tools
The tools required In the host machine:
Integration via Docker-compose
If you have followed the previous sessions, you should now have the following folder structure for all our services.
- Inside play-microservices folder, create a file named .env and set the contents to:
AUTH_SERVICE_PORT=9001
AUTH_POSTGRES_PORT=5432
AUTH_REDIS_PORT=6379
ZOOKEEPER_PORT=2181
KAFKA1_PORT=9092
SCHEDULER_MONGODB_PORT=27017
SCHEDULER_SERVICE_PORT=9002
EMAIL_SERVICE_PORT = 9003
POSTFIX_PORT=25
REPORT_SERVICE_PORT = 9004
REPORT_MONGODB_PORT=27018
API_GATEWAY_PORT=5010
CLIENT_PORT = 3000
- This file make it easier for us to handle the ports used by different services.
- Now, let's create a file called docker-compose.yml inside the play-microservices folder. This file will be used to integrate all the services. The contents of the docker-compose file can be found here.
Some notes on the docker-compose.yml file
As depicted in the services diagram, the services exhibit a hierarchical dependency tree. Therefore, inside the docker-compose file, we need to orchestrate the services in such a way that when a service starts, its dependencies are started and running in advance. To achieve this, we use healthcheck
of docker compose. for example, for auth-db, which is a postgres service, for the healthcheck
part we have:
healthcheck:
test: ["CMD-SHELL", "pg_isready"]
interval: 10s
timeout: 1s
retries: 5
- Auth service has dependency to auth-db service. For the
depends_on
condition we have:
depends_on:
auth-db:
condition: service_healthy
- Seting condition to
service_healthy
guarantee that auth service will not run unless the auth-db is ready and running.- We have other
healthcheck
definitions for zookeeper, kafka and mongodb services.- One other thing to consider in our docker-compose file is the secrets. Each service may have a secret that need to be passed to other services. We use docker-compose secrets capability. When we define a secret for a service, Docker will create a file for that secret inside the container at
/run/secrets/secret-name
path. for example, We have defined a secret forauth-access-public-key
. We pass this secret to other services that may need authentication service public key for verifying tokens signed by authentication service.
secrets:
auth-access-public-key:
file: auth/auth-service/keys/access_token.public.pem
- Open a terminal, cd to play-microservices folder and run
docker-compose up -d --build
. Wait until all services run. Go tohttp://localhost:3000/
and voila! Our application is ready to be tested.
To do
- deploy to a CI/CD environment via Jenkins
- Add and run tests
Top comments (0)