Our local development environment and our production environment serve two very different purposes. Currently we used Docker & Docker Compose to serve for a test network on the Rust side with 2 or more peers connect & synchronize data.
# Build a docker image tagged as "saito-app" according to the recipe
# specified in `Dockerfile`
docker build --tag saito-app --file Dockerfile .
What does the .
at the end of the command stand for?
docker build
generates an image starting from a recipe (the Dockerfile
) and a build context. You can picture the Docker image you are building as its own fully isolated environment.
The only point of contact between the image and your local machine are commands like COPY
or ADD
: the build context determines what files on your host machine are visible inside the Docker container to COPY
and its friends.
CONF_FILE=config_file_path W_PWD=password_string docker-compose -f docker-compose.test.yml up -d --build
For now, we just support docker-compose.test.yml
for network tests, therefore there are no docker-compose.yml
to actually run nodes on PRODUCTION. That's why you need to add the parameter -f
in command above.
What are CONF_FILE
& W_PWD
? If you look at the docker-compose.test.yml
file, you can easy-find these variables.
CONF_FILE
is the peer configuration file - in this case it is configuration/peers.yml
.W_PWD
is the wallet password - in this case it is asdf
.Why i didnt put them directly into that docker-compose
file? Because they're sensitive values and we want flexible to fill it by ourselves - via cli parameters and only we know it. Another reason, we can easy-configure via github ci vars once we need.
docker ps
docker logs saito_app # view logs on node 1
docker logs saito_app_node1 # view logs on node 2
...
docker stop saito_app saito_app_node1