bisgardo / concordium-docker Goto Github PK

The catchup is optionally performed in an init container.

The Docker Compose file currently references the latest patch version of the v1.18 line of releases.

I cannot find documentation on which versions are currently supported nor general policies on the subject, but the documentation lists only v1.19 through v1.22 as "stable" versions. All older ones are "archived".

The latest patch version v1.18.6 was released just a few months ago so could still be supported as of this writing but it isn't clear if it is or for how long.

It's the only dashboard there is so no need to spell it out. The style (pioneered by the txlog profile for enabling transaction logging) is to use short profile names.

The old feature has been removed as of node version 4.2.2 (see #24 (comment)).

There should be a commit that updates the link to the now-removed parts of the Concordium Node docs that explained it such that it references the last commit that contained it. A followup commit should then replace the text with a reference to the former commit.

This probably makes #29 partially or entirely irrelevant.

It may not always be obvious from the output of Docker Compose if/how a deployment is misconfigured. For example, when the txlog profile is enabled, the env var TXLOG_PGPASSWORD must be provided. If not, the container crashes with an error that requires at least a bit of internal knowledge to make sense of:

error: Invalid value for '--db <config>': invalid connection string: unexpected EOF

Also, it's very easy to miss this message in a flood of logs and not notice that the service stopped.

The status service should do some consistency checks on startup to see if the environment seems consistent. If so, it may exit successfully. Otherwise, it will continuously emit logs to explain what it detected.

An extension could be to stay on and continuously monitor the health of the deployment using whatever Docker/Compose API/SDK enables this. At this point the service might start turning into the dashboard proposed in #23.

If I have a Postgres DB running, what would I need to include (in mainnet.env?) to make the node use the DB to collect all finalised transactions?

See https://www.arthurkoziel.com/validate-helm-chart-values-with-json-schemas/.

Metrics are ingested into a dedicated volume. As this volume is relevant only when the feature is enabled, it should be moved from the main spec to an override file.

The solution (I think) is to set OOB_CATCHUP_REFRESH_AGE_SECS to a value larger than the Unix time of "now". It would also be nice if it could be done in a more obvious way, like making it a negative value.

My goal is to start fresh on a new host. My end result should be:

1. a mainnet node + new service tx logger
2. a testnet node + new service tx logger

None of these nodes should run the legacy tx logger from the node itself.

Pain points right now:

1. mainnet-txlog.env enables legacy logging (I think?).
2. mainnet-txlog.env doesn't contain an entry for PGPASSWORD to be used? Did I miss this?

3. concordium-docker/docker-compose.yaml

   Line 60 in 0bcd493

   - "10000:10000" # gRPC

   makes the port for the node hardcoded (again, I think). This prevents me from running 2 nodes on the same host, using this, correct?

Ideally, I would:

1. clone this repo
2. edit mainnet-txlog.env with the correct PGPASSWORD and PGDATABASE that I've setup for the mainnet service logging
3. edit testnet-txlog.env with the correct PGPASSWORD and PGDATABASE that I've setup for the testnet service logging
4. Do NODE_NAME=concordium-explorer-mainnet ./run.sh mainnet-txlog
5. Do NODE_NAME=concordium-explorer-testnet ./run.sh testnet-txlog
6. Be happy with 2 running nodes with tx logging through the service.

The above doesn't seem possible in it's current form, right?

We currently build both cmake, flatc, and protoc from source. This adds a lot of time to the build for things that could just be downloaded pre-compiled.

We should only build such tools ourselves if the desired version isn't released in binary form.

A repository can apparently be set up easily using GitHub Pages.

Transaction logging is enabled with a profile in the main spec. It currently only supports logging transactions into an external PostgreSQL instance. An override txlog-local (which activates the txlog profile) would enable them to be ingested into a DB container running as part of the deployment instead.

Related to #59.

It's just a warning emitted at the end of the build but would be nice to get rid of it nonetheless.

Compose v2 has been out for a while now. We should ensure that the Compose deployment works with it.

The front- and backends should be moved to the main Compose spec. Only the TimescaleDB running inside the deployment should be in an override. Related to #58.

As the builtin feature is dying, it's probably sufficient to add a chart for the new transaction logger service.

The port values corresponding to a particular network will be set in the .env files.

Ensure that TRANSACTION_LOGGER_PGPASSWORD etc. are documented in the README or in a new file that includes the parts from legacy-transaction-logging.md that are not actually legacy (i.e. PostgreSQL setup).

See #24.

It doesn't look like GitHub supports this (for Markdown at least). This project (and possibly this Action using it) looks interesting.

Mostly a fun little challenge.

The dashboard should show what is running (can integrate with Docker Compose?) and maybe some interesting metrics like current block height, catchup status etc.

If running outside the deployment (probably shouldn't), then it could also be used to manage the setup (start, stop, configure). Or maybe that would be a separate dashboard...

Hi, I feel I'm almost there, but getting a weird error. I've updated all paths to the correct location on my Unraid install, however I can't figure out what to change for the Envoy install?

Any hints?

.env file:

NODE_TAG=3.0.1-2_1
NODE_NAME=https://concordium-explorer.nl 
COMPOSE_PROJECT_NAME=mainnet
DOMAIN=mainnet.concordium.software
GENESIS_DATA_FILE=./genesis/mainnet-0.dat
NODE_IMAGE=bisgardo/concordium-node:3.0.1-2_1
NODE_DASHBOARD_IMAGE=bisgardo/concordium-node-dashboard:node-3.0.1-2_1

.yaml file:

version: '3.9'
services:
  node_oob_catchup:
    image: curlimages/curl:latest
    pull_policy: always
    user: root
    volumes:
    - data:/mnt/cache/appdata/ccdnode/data
    entrypoint:
    - /bin/sh
    - -c
    - |
      [ -f /mnt/cache/appdata/ccdnode/data/blocks.mdb ] ||
        curl -sSf https://catchup.${DOMAIN}/blocks_to_import.mdb -o /mnt/cache/appdata/ccdnode/data/blocks.mdb
  node:
    image: ${NODE_IMAGE}
    entrypoint: /concordium-node
    environment:
    - CONCORDIUM_NODE_DATA_DIR=/mnt/cache/appdata/ccdnode/data
    - CONCORDIUM_NODE_CONFIG_DIR=/mnt/cache/appdata/ccdnode/config
    - CONCORDIUM_NODE_CONSENSUS_IMPORT_BLOCKS_FROM=/mnt/cache/appdata/ccdnode/data/blocks.mdb
    - CONCORDIUM_NODE_CONSENSUS_GENESIS_DATA_FILE=/mnt/cache/appdata/ccdnode/genesis.dat
    - CONCORDIUM_NODE_CONNECTION_BOOTSTRAP_NODES=bootstrap.${DOMAIN}:8888
    - CONCORDIUM_NODE_RPC_SERVER_ADDR=0.0.0.0
    - CONCORDIUM_NODE_PROMETHEUS_SERVER=1
    - CONCORDIUM_NODE_PROMETHEUS_LISTEN_ADDRESSS=0.0.0.0
    # Defer container start until the init containers have completed successfully.
    # Note that no logs are emitted on stdout until all containers have started.
    # Also, this syntax requires Docker Compose v. 1.29+.
    depends_on:
      node_oob_catchup:
        condition: service_completed_successfully
    networks:
    - concordium
    ports:
    - "8888:8888"   # P2P
    - "10000:10000" # gRPC
    - "9090:9090"   # Prometheus (metrics)
    volumes:
    - ${GENESIS_DATA_FILE}:/mnt/cache/appdata/ccdnode/genesis.dat
    - data:/mnt/cache/appdata/ccdnode/data
    - config:/mnt/cache/appdata/ccdnode/config
    build:
      context: .
      args:
        tag: ${NODE_TAG}
  node-collector:
    image: ${NODE_IMAGE}
    entrypoint: /node-collector
    environment:
    - CONCORDIUM_NODE_COLLECTOR_URL=https://dashboard.${DOMAIN}/nodes/post
    - CONCORDIUM_NODE_COLLECTOR_GRPC_HOST=http://node:10000
    - CONCORDIUM_NODE_COLLECTOR_NODE_NAME=${NODE_NAME}
    depends_on:
    - node
    networks:
    - concordium
    restart: on-failure # service may time out before the node is operational
  node-dashboard-grpc-proxy:
    image: envoyproxy/envoy:v1.18-latest
    pull_policy: always
    entrypoint: /usr/local/bin/envoy --config-path /etc/envoy/envoy.yaml
    depends_on:
    - node
    networks:
    - concordium
    ports:
    - "9901:9901" # admin
    - "9999:9999" # proxy
    volumes:
    - ./node-dashboard/envoy.yaml:/etc/envoy/envoy.yaml:ro
  node-dashboard:
    image: ${NODE_DASHBOARD_IMAGE}
    depends_on:
    - node-dashboard-grpc-proxy
    networks:
    - concordium
    ports:
    - "8099:80" # web
    build:
      context: ./node-dashboard
      args:
        tag: main
volumes:
  data:
  config:
networks:
  concordium:

Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: 
process_linux.go:495: container init caused: rootfs_linux.go:60: mounting
 "/boot/config/plugins/compose.manager/projects/bisgardo/node-dashboard/envoy.yaml" 
to rootfs at "/var/lib/docker/btrfs/subvolumes/a96c66fb08d1462628c64dc89188004102cf4c320738bd40abf457d5d1d6c1ae/etc/envoy/envoy.yaml" 
caused: not a directory: unknown: 
Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type```

The credentials must of course be stored in a secret.

See also #20.

The files generally don't work with any version of the software they're building.

We already set default versions for dependencies such that the user doesn't have to (we also don't expect the user to change them). A useful value of tag would be "the minimum version that the file works with". This would get bumped whenever we need to change the build procedure because of breaking changes. This is valuable for documentation in case you at some point need to build an older version.

We would still set the "currently active tag" in the readme and it would change more often than the default tag. With this change, it's more important to highlight the need for explicitly setting the tag value and not rely on the default one.

The documentation doesn't mention how the Docker Compose deployment should be stopped safely. As the suggested commands run in non-detached mode, it's only natural to Ctrl-C the running process, which apparently is equivalent to docker-compose stop.

This sends a SIGTERM signal to the running containers with a 10 sec deadline for the containers to stop. Once the deadline has passed, the containers are killed with SIGKILL.

As the node may take longer than 10 sec to stop, a safer solution is to explicitly use e.g. docker-compose --timeout=60 stop in all cases to increase the timeout.

In the Docker Compose setup, the oob_catchup container just checks whether the blocks.mdb file exists to determine if it should download it. This means that the data may potentially be so old that fetching a fresh blob of OOB data would be worth it. A reasonable cutoff might be a week.

Can be done by passing the credential file in a bind mount as in this example.

It's not clear how to do it in a way that allows a simple method of switching between passing credentials or not. But at least the documentation should include instructions on how it may be added.

The Docker Compose specs (mostly) don't require that the images are built using the dockerfiles in the project. In particular, the official Docker images of the node work just fine. The documentation should explain this fact and give an example of using at least the official mainnet image.