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
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.
W_PWD? If you look at the
docker-compose.test.yml file, you can easy-find these variables.
CONF_FILEis the peer configuration file - in this case it is
W_PWDis the wallet password - in this case it is
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 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