Development can be done running local docker containers. First docker-compose
is used to launch containers for each service. Most containers do not start the service directly, allowing this to be done manually from inside the container (eg using VS Code Dev Containers). Commands for each service are given below.
git clone git@github.com:paulscherrerinstitute/scicat-ci.git
git submodule update --init --recursive --remote
The docker-compose builds the containers from the Dockerfile of each submodule, thus using the submodule checked out to a particular commit.
It is often the case that when setting up the environment one wants the components to be checked out automatically to the latest on main. The command above (git submodule update --init --recursive --remote
) does that but might break any component where a non-backwards compatible change was applied.
We reference in the config of each components the latest commit (.git-commit-sha) of the submodule where the docker-compose was run and worked the last time, whenever the submodule commit is different from the one referenced in the scicat-ci repo.
To build a container based on a different commit one has to checkout first the submodule to the commit (or branch) of interest.
Build the docker containers with the suitable profiles:
export COMPOSE_PROFILES=<MY_PROFILES>
docker-compose -f docker-compose.yaml up -d --force-recreate --build --no-deps
All the application containers (excluding the db -mongo- and the db_seeding -mongo_seed-) are meant to be used for development so docker-compose starts, rather than the applications, environments where the development environment of each application is set up. This means that, to run the application, one has to attach to the container and start it.
Here are the two most common use cases, spinning up the backend and fronted; the new backend and the frontend.
- Export the COMPOSE_PROFILES:
export COMPOSE_PROFILES=be,fe
- run docker-compose:
docker-compose -f docker-compose.yaml up --force-recreate --build --no-deps -d
This will start four containers: the be container, the fe one, the mongodb database and a short-lived one, called mongodb_seed_be that puts some example data into the be db of mongo.
- Export the COMPOSE_PROFILES:
export COMPOSE_PROFILES=be_next,fe
- run docker-compose:
docker-compose -f docker-compose.yaml up --force-recreate --build --no-deps -d
As before, this will start four containers: the be_next container, the fe one, the mongo database and a short-lived one, called mongodb_seed_be_next that puts some example data into the be_next db of mongo.
Since the configuration of the frontend with the new backend has slightly changed, remember to set the accessTokenPrefix
value to "Bearer " in the config.json file of the fe, before starting the frontend application.
The docker-compose.yaml
file is constructed to prepare containers with all dependencies but not to start the services. This is generally done by overriding the command with an infinite loop.
cd /home/node/app
npm start
cd /home/node/app
npm start
The frontend uses a custom Dockerfile with the following modifications:
cd /frontend
npm start -- --host 0.0.0.0
A custom Dockerfile is used because the production image uses the node alpine base image which does not crosscompile on macOS.
cd /home/node/app
npm start
cd /home/node/app
npm start -- --host 0.0.0.0
cd /home/node/app
npm start
cd /usr/src/proposals
python src/main.py
Simply browse to localhost:8888
This compose file creates a new docker volume with test data. Removing this requires adding --volumes
when shutting down the containers:
docker-compose -f docker-compose.yaml down --volumes
If this is omitted it may eventually lead to your docker virtual disk filling up. If this happens, remove old volumes:
docker volume prune
docker system prune -v