How to develop applications with Docker which are in separate repositories

Question

The stack consists of a few applications/microservices need to be connected to run locally in development, and each is within its own repository

E.g. frontend, db, api

If each app has its own Dockerfile, and docker-compose.yml that list the required services to run that one application, what practices are recommended for development of the whole stack?

Answer 1

We have front-end Angular running on Apache (prod) or Node (dev). All bog-standard request are handled normally, all requests to API container have /imanapicall in the url and are proxied to the API container based on the fact that the url contains /imanapicall. This is standard practice. Fe container is stateless.

We have Node running the API, it is stateless and simply requests data from the database and sends it back to the front-end.

We have node running Restify but Express is more popular.

Then most people use MongoDB but we use some weird db stuff.

Important thing is to expose ports between containers, make sure firewalls aren't being a pain. For dev purposes you probably want to expose ports for all containers to host also so you can debug more easily by for example hitting an Express endpoint directly to make sure it's giving me what I want.

PS: statelessness is important to support scaling, so I can introduce a load balancer and not worry which server it hits. Only db container holds state.

FURTHER TO YOUR COMMENT ...

Each tier (database, API, etc) has its own Git repo. Each Git repo has an automated Jenkins job that does a build (on a push to the repo) and on success pushes a new Docker image.

We then have another Git repo that is responsible for pulling it all together. This repo basically consist of a docker compose file to pull all the relevant containers and run them.

FINE DETAIL ...

During development of the database tier no difficulties arise.

However, during development of the API tier, for example, this tier is dependent on the database tier, so a Docker container for the database tier will need to be running when developing the API tier. Can use compose for this also.

When developing front-end tier, this relies on both the database and API tiers. It's best to use a generic solution during development that allows all containers to be stood up in their latest Docker image state and ignore those that are irrelevant for current purposes.

For example, when developing front end, bring up all three containers from the latest images. Ignore the front end container and use your front end development environment as usual. Point the front end development environment to the API container.

Ignoring the containers that are irrelevant for the development of the tier you are working on means you can use a common approach when brining up Docker containers for all tiers without having a specific solution for each.