Everyone knows it: setting up a development environment is always a hassle, especially when it comes to SGX. So this section aims to help with this. Our developers usually work with an SGX capable hardware, see 5.2, develop within a Docker container, or just execute the build with Docker.
Two ways to work are presented here:
- Run worker and clients in docker but chain(s) and on host
- Run everything inside a docker container
We open a range of ports to the host such that the services inside docker can talk to multiple chains running on the host
docker run --name integritee-dev-worker -it --expose 9944-9999 -v $(pwd):/home/ubuntu/worker -e MYUID=$(id -u) -e MYGUID=$(id -g) integritee/integritee-dev:0.2.2 /bin/bash
Use tmux -u
to run several things in parallel inside the container
to re-enter docker later:
docker start -a -i integritee-dev-worker
The paradigm here is that the files are living on the host file system, but they are mounted into the Docker container. The build commands are executed from within the Docker container.
This is the Docker image we use: https://hub.docker.com/r/integritee/integritee-dev.
In general, we have two repositories that are relevant for running a complete test-setup:
The launch scripts assume that those two repositories reside in the same directory.
Steps to get a running setup:
- Mount the current directory containing the integritee-worker and integritee-node into the Docker container and start a bash session inside:
docker run -it --mount "type=bind,src=$(pwd),dst=/opt/shared" --workdir /opt/shared integritee/integritee-dev:0.2.2 /bin/bash
# If you want to expose the default ports of the services to the host, you can supply some `-p` args:
docker run -it --mount "type=bind,src=$(pwd),dst=/opt/shared" --workdir /opt/shared -p 9944:9944 -p 2000:2000 -p 3443:3443 integritee/integritee-dev:0.2.2 /bin/bash
- Now you have access to the shell in the Docker container. So you can start the builds.
# First build the node
# See documentation for the build flags in: https://github.com/integritee-network/integritee-node#build-and-run
cd integritee-node
git checkout sdk-v0.13.0-polkadot-v0.9.42
cargo build --release --features "skip-extrinsic-filtering"
# Go to parent-directory.
cd ../
# Build the worker: in this example we compile it in the offchain worker mode.
cd worker
git checkout sdk-v0.13.0-polkadot-v0.9.42
# Build the offchain-worker in software mode if you don't have the SGX hardware set up.
# How to enable hardware mode in Docker can be found here in chapter 5.2.3.3.
SGX_MODE=SW WORKER_MODE=offchain-worker WORKER_FEATURES=dcap make
# The output file will be in the ./bin folder.
# Then you can spawn two workers and the integritee-node with the launch script.
./local-setup/launch.py ./local-setup/config/two-workers.json
# Enter the same Docker container with a bash session.
docker exec -it <container-id> bash
# Have a look at the logs with the handy tmux scripts (the logs are only populated if the launch.py was used).
cd worker/local-setup
./tmux_logger.sh
# The demo scripts can be executed in yet another terminal session where you enter the same running Docker container.
# Replace the <container-id> with the value returned upon container creation with the above command.
docker exec -it <container-id> bash
# This script also shows what kind of commands you can execute with the CLI.
cd worker/cli
# Match the ports that are defined in the simple config
FLAVOR_ID=offchain-worker TEST=first ./demo_shielding_unshielding.sh -p 9944 -P 2000
# Check available commands of the CLI.
cd ./bin
./integritee-cli --help
# For trusted commands to talk with an enclave.
./integritee-cli trusted --help
Hints
- The rust build cache is preserved when you exit the container. Hence, when you continue to develop you can just type
docker start <container-id>
and thendocker exec -it <container-id> bash
to re-enter the build environment as you left it!