Docker#

The codingconcepts/edg image uses edg as its entrypoint, so any arguments you pass to docker run are forwarded directly to the CLI.

Running a built-in workload#

Built-in workloads don’t need a config file, so no volume mount is required:

docker run --rm codingconcepts/edg:v0.2.0 workload bank all \
  --driver pgx \
  --url "postgres://root@host.docker.internal:26257?sslmode=disable" \
  -w 10 \
  -d 1m

Any workload subcommand works the same way:

# Create the schema only
docker run --rm codingconcepts/edg:v0.2.0 workload tpcc up \
  --driver pgx \
  --url "postgres://root@host.docker.internal:26257?sslmode=disable"

# Seed, run, and tear down
docker run --rm codingconcepts/edg:v0.2.0 workload tpcc all \
  --driver pgx \
  --url "postgres://root@host.docker.internal:26257?sslmode=disable" \
  -w 50 \
  -d 5m

Running a custom workload with a volume#

Mount the directory containing your config file(s) into the container:

docker run --rm \
  -v ${PWD}/custom_workloads:/config \
  codingconcepts/edg:v0.2.0 all \
  --driver pgx \
  --config /config/prod_env.yaml \
  --url "postgres://root@host.docker.internal:26257?sslmode=disable" \
  -w 10 \
  -d 5m

Individual lifecycle commands work the same way:

docker run --rm \
  -v ${PWD}/custom_workloads:/config \
  codingconcepts/edg:v0.2.0 up \
  --driver pgx \
  --config /config/prod_env.yaml \
  --url "postgres://root@host.docker.internal:26257?sslmode=disable"

Use host.docker.internal to reach databases running on the host machine. For databases running in other containers, use a shared Docker network and the container name as the hostname.