Mise à jour de l'image docker de mon noeud pour le calcul de la distance

Suite à Oracle de distance sur la ĞDev - #9 by cgeek

Je vais configurer mon noeud forgeron pour le calcul de la distance. J’ai choisi de tout mettre dans un seul compose plutôt que d’avoir deux services indépendants, mais ce n’est pas forcément une bonne idée. J’aimerais discuter avec @Pini pour voir s’il ne vaudrait pas mieux garder un compose simplissime pour le validateur et de connecter l’oracle de distance simplement en utilisant le bon volume et le bon réseau. Cela permettrait d’éviter l’interruption de service sur le validateur uniquement pour mettre à jour l’oracle de distance (par exemple pour changer le niveau de logs).

Quoi qu’il en soit voici les étapes que j’ai suivies :

1. go offline pour l’interruption (s’y prendre 2h à l’avance)

gcli smith go-offline
transaction submitted to the network, waiting 6 seconds...
smith went offline MemberGoOffline(344)

Peut être retrouvé avec

query MyQuery {
  calls(limit: 10, orderBy: block_height_DESC, where: {pallet_containsInsensitive: "authority"}) {
    id
    pallet
    name
    block {
      height
    }
  }
}

2. modification du docker-compose

Avant

services:
  duniter-smith:
    image: duniter/duniter-v2s-gdev:latest
    restart: unless-stopped
    ports:
      - 127.0.0.1:9615:9615
      - 127.0.0.1:9933:9933
      - 127.0.0.1:9944:9944
      - 30333:30333
    volumes:
      - data-smith:/var/lib/duniter/
    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_NODE_NAME=HugoTrentesaux-smith
      - DUNITER_VALIDATOR=true
      - DUNITER_PRUNING_PROFILE=light
      - DUNITER_PUBLIC_ADDR=/dns/gdev.trentesaux.fr/tcp/30333
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333

volumes:
  data-smith:

Après

services:
  duniter-smith:
    image: duniter/duniter-v2s-gdev:latest
    restart: unless-stopped
    ports:
      - 127.0.0.1:9615:9615
      - 127.0.0.1:9933:9933
      - 127.0.0.1:9944:9944
      - 30333:30333
    volumes:
      - data-smith:/var/lib/duniter/
    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_NODE_NAME=HugoTrentesaux-smith
      - DUNITER_VALIDATOR=true
      - DUNITER_PRUNING_PROFILE=light
      - DUNITER_PUBLIC_ADDR=/dns/gdev.trentesaux.fr/tcp/30333
      - DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333

  distance-oracle:
    image: duniter/duniter-v2s-gdev:latest
    entrypoint: docker-distance-entrypoint
    environment:
      ORACLE_RPC_URL: "ws://duniter-smith:9944"
      ORACLE_RESULT_DIR: "/var/lib/duniter/chains/gdev/distance/"
      ORACLE_EXECUTION_INTERVAL: "1800"
      ORACLE_MAX_DEPTH: "5"
      ORACLE_LOG_LEVEL: "debug"
    volumes:
      - data-smith:/var/lib/duniter
  
volumes:
  data-smith:

3. redémarrage du service (échec)

docker compose down
docker compose pull
docker compose up -d
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "docker-distance-entrypoint": executable file not found in $PATH: unknown

J’ai aussi essayé de supprimer le volume au cas où qqc aurait changé dedans :

docker compose down -v
docker compose up -d
# même erreur

(attention, si vous faites ça vous perdez vos session keys à moins de réinjecter les mêmes et vous changez de peerid, donc c’est pas très pratique)

Oui pour l’instant la feature est mergée mais il faut délivrer l’image Docker.

1 Like

J’ai changé de stratégie et ai partagé une proposition plus modulaire ici : Oracle de distance dans un docker - #7 by HugoTrentesaux

Mais il reste toujours à publier l’image docker. Ce n’est plus possible manuellement sur master ?

image

Apparemment, c’est réservé aux branches release/runtime : .gitlab-ci.yml · master · nodes / rust / Duniter v2S · GitLab

rules:
  - if: $CI_PIPELINE_SOURCE != "merge_request_event" && $CI_COMMIT_BRANCH =~ /^(release\/runtime-)[0-9].*/

Mais pour ce genre de cas ça pourrait être pratique de l’autoriser sur master, ne serait-ce que pour mettre à jour les bootnodes.

Ce n’est pas juste ça, le job dépend aussi de la milestone qui est déduite du nom de la branche de release.

Si tu veux absolument une nouvelle image dès maintenant, tu peux :

  1. soit la builder en local avec docker build -t "duniter-v2s-701:avec-oracle" -f docker/Dockerfile . par exmple
  2. soit créer un nouveau job dans la CI très inspiré de .deploy_docker_multiplatform

La solution 1 me semble la plus rapide et la moins invasive compte tenu du fait que nous allons bientôt rebooter la ĞDev.

J’avais déjà essayé de faire une image en local pour tester ma config, mais apparemment il faut fouiller un peu plus que ça :

> docker build -t "duniter-v2s-701:avec-oracle" -f docker/Dockerfile .
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            Install the buildx component to build images with BuildKit:
            https://docs.docker.com/go/buildx/

Sending build context to Docker daemon  85.34MB
Step 1/34 : FROM debian:bullseye-slim as target
 ---> 8d18562eded9
Step 2/34 : FROM --platform=$BUILDPLATFORM rust:1-bullseye as build
failed to parse platform : "" is an invalid component of "": platform specifier component must match "^[A-Za-z0-9_-]+$": invalid argument

Donc je laisse tomber pour l’instant, j’attendrai la nouvelle image pour tester, et quand j’aurai testé avec succès je mettrai à jour la documentation avec les deux options : un docker-compose ou deux.