Docker Containers for 1 click Chia™ simulator setup
These examples show valid setups using the Chia Simulator for both docker run and docker-compose. Note that you should read some documentation at some point, but this is a good place to start.
docker run --name chia-simulator -d --expose=8555 -v ~/.chia:/root/.chia ghcr.io/chia-network/chia-simulator:latest
Syntax
docker run --name <container-name> -d ghcr.io/chia-network/chia-simulator:latest -v /path/to/simulator/files:/root
optional: accept incoming rpc calls: --expose=8555
optional: persiststantly use the same simulator -v ~/.chia/simulator:/root/.chia/simulator
version: "3.6"
services:
chia-simulator:
container_name: chia-simulator
restart: unless-stopped
image: ghcr.io/chia-network/chia-simulator:latest
ports:
- "8555:8555"
volumes:
- ~/.chia/simulator:/root/.chia/simulator
You can modify the behavior of your Chia Simulator container by setting specific environment variables.
Set the timezone for the container (optional, defaults to UTC).
Timezones can be configured using the TZ
env variable. A list of supported time zones can be found here
-e TZ="America/Chicago"
To use your own keys pass a file with your mnemonic as arguments on startup
-e mnemonic=<your-24-word-mnemonic>
or pass keys into the running container with your mnemonic
docker exec -it <container-name> venv/bin/chia keys add
alternatively you can pass in your local keychain, if you have previously deployed chia with these keys on the host machine
-v ~/.local/share/python_keyring/:/root/.local/share/python_keyring/ -e fingerprint="<fingerprint>"
-e reward_address="<reward-address>"
-e auto_farm="false"
You can persist whole db and configuration, simply mount it to Host. If you are using multiple simulators, please read the simulator naming documentation below.
-v ~/.chia/simulator:/root/.chia/simulator
-e name="<simulator-name>"
To only start the simulator pass
-e start_wallet="false"
Log file can be used by external tools like chiadog, etc. Enabled by default.
To disable log file generation, use
-e log_to_file="false"
version: "3.6"
services:
chia-simulator:
container_name: chia-simulator
restart: unless-stopped
image: ghcr.io/chia-network/chia-simulator:latest
ports:
- "8555:8555"
environment:
# If you would like to add keys manually via mnemonic words
# mnemonic: "today grape album ticket joy idle supreme sausage oppose voice angle roast you oven betray exact memory riot escape high dragon knock food blade"
TZ: ${TZ}
# Enable log file generation
# log_to_file: true
volumes:
- /home/user/.chia/simulator:/root/.chia/simulator
You can connect to the simulator's shell and easily run commands
docker exec -it chia-simulator /bin/bash
or
You can run commands externally with venv (this works for most chia & cdv CLI commands)
docker exec -it chia-simulator venv/bin/chia plots add -d /plots
You can see status from outside the container
docker exec -it chia-simulator venv/bin/chia dev sim status
or
docker exec -it chia-simulator venv/bin/chia show -s -c
To get new wallet, execute command and follow the prompts:
docker exec -it chia-simulator venv/bin/chia wallet show
docker build -t chia-simulator --build-arg CHIA_BRANCH=latest --build-arg DEV_TOOLS_BRANCH=main .
The Dockerfile includes a HEALTHCHECK instruction that runs one or more curl commands against the Chia RPC API. In Docker, this can be disabled using an environment variable -e healthcheck=false
as part of the docker run
command. Or in docker-compose you can add it to your Chia service, like so:
version: "3.6"
services:
chia-simulator:
...
environment:
healthcheck: "false"
In Kubernetes, Docker healthchecks are disabled by default. Instead, readiness and liveness probes should be used, which can be configured in a Pod or Deployment manifest file like the following:
livenessProbe:
exec:
command:
- /bin/sh
- -c
- '/usr/local/bin/docker-healthcheck.sh || exit 1'
initialDelaySeconds: 60
readinessProbe:
exec:
command:
- /bin/sh
- -c
- '/usr/local/bin/docker-healthcheck.sh || exit 1'
initialDelaySeconds: 60
See Configure Probes for more information about configuring readiness and liveness probes for Kubernetes clusters. The initialDelaySeconds
parameter may need to be adjusted higher or lower depending on the speed to start up on the host the container is running on.