Development environment

Specifications for including services and tools in Ebury Dockerised Development Environment (ED2K)

Problem Description

We do not have mechanisms for starting or stopping just set of tools and services needed for a particular task, and this is leading to either big micro management of the development environment, or degraded performance in developer laptop.

Background

Over the time, the number of containers running locally, and the resources consumed, have been increasing. Specifically, shared resources between services, which was at the beginning just an ngnix proxy and a shared network, have grown to include Localstack, Kafka, Mongo, etc.

Solution

ED2K common services

Group the resources between minimal and specific, and then create also make targets for stopping those particular subsets.

  • core: nginx, dns, redis
  • aws
  • kafka
  • kafka-connect
  • audit
  • ...

Create different docker-compose files for each subset.

  • docker-compose.yml
  • docker-compose.aws.yml
  • docker-compose.kafka.yml
  • ...

Create make targets for starting and stopping each individual subsets

.PHONY: start
start: start-aws start-kafka start-core

.PHONY: start-core
start-core:
    @docker-compose --project-name ed2k --file docker-compose.yml up --detach

.PHONY: start-aws
start-aws: start-core
    @docker-compose --project-name ed2k-aws --file docker-compose.aws.yml up --detach

.PHONY: start-kafka
start-kafka: start-kafka
    @docker-compose --project-name ed2k-kafka --file docker-compose.kafka.yml up --detach

....

.PHONY:
stop: stop-core

.PHONY: stop-core
stop-core: stop-aws stop-kafka
    @docker-compose --project-name ed2k --file docker-compose.aws.yml down

.PHONY: stop-aws
stop-aws:
    @docker-compose --project-name ed2k-aws --file docker-compose.aws.yml down

.PHONY: stop-kafka
stop-kafka: stop-kafka-connect
    @docker-compose --project-name ed2k-kafka --file docker-compose.kafka.yml down

Ebury services on top of ED2K

Following the same philosophy, services on top of ED2K infrastructure shall split containers between:

  • core: The minimum subset for the service to work with others (web application, database, internal cache, some backend tasks and daemons, infrastructure in localstack)
  • additional targets for specific projects (e.g the multipayments backend)
  • administration: Tools for managing side services (Redmin, Adminer, Flower, ...)

However, with those services it is less feasible to split in separate compose files, since they would be different compose projects and networking would be even more complicated. Service extension, which we are using in several projects, would not be possible.

The same results can be achieved by specifying each service in the docker-compose up command instead of using a generic up, and with docker-compose stop && docker-compose rm instead of a generic down.

Alternatives

  • Major refactor in all projects for using multiple docker-compose files.
  • Migrate to docker swarm.
  • Migrate to a remote development environment

Caveats

Bulk management of containers, volumes and networks (i.e. for doing a complete cleanup), and managing multiple stacks (i.e. BOS + EburyOnline + Verify) is not covered in this document.

Operation

ED2K is used by developers locally and in Eburybox test environments, but also Demo and Sandbox environments.

Security Impact

None.

Performance Impact

Performance in development laptops is expected to improve.

Resource usage and costs in Demo and Sandbox environments is expected to be reduced.

Developer Impact

Developers will need to reset their development environments, but database volumes can be kept.

Data Consumer Impact

N/A

Deployment

Change will be backwards compatible in Demo and Sandbox environments, but further changes in deployment scripts will be needed in order to benefit from less resource usage.

Dependencies

N/A

References

N/A