[container] Implement UPDATE_CHECK for container configuration replacment

[TrevorBenson]

Describe the bug/feature

Bug

Containers which start running a specific node version will update the configuration files automatically to an incompatible set of configuration files result in a crash of the container.

Feature

The feature is to implement UPDATE_CHECK logic similar to other scripts and tools provided. With the default value of N the container will always start with valid configuration files and only require the defined NETWORK for the entrypoint.sh script to determine which configs to use. The original logic to dynamically update the configuration files can be restored by enabling the

To Reproduce
Steps to reproduce the behavior:

1. Pull a container image from before a recent breaking change was merged into master branch.
2. Start the container providing a NETWORK to use, do not mount configuration files to $CNODE_HOME/priv/files which match the node binary.
3. The container updates the configuration files from the master branch, no longer compatible with the built in node.
4. Observe errors in docker logs

Expected behavior
A container image should be persistent in its behavior and should continue to work as it was originally designed. Unless the operator chooses to modify the container, update its configuration files, or change it in some way it should continue to work persistently and without fail.

Version:

• OS: Ubuntu 23.04, RockyLinux 8/9 etc.
• Product version: docker.io/cardanocommunity/cardano-node:1.35.7 (just for a reproduction reference point)
• Cardano Node version: 1.35.7
• Network you're connecting to: Any

[TrevorBenson]

I've created a branch (two actually) to implement support for UPDATE_CHECK. I figured I would start a short discussion here before opening a PR for code review.

Branch 1

issue/1750-container-update-check-guild-mainnet

This branch changes the container entrypoint to include UPDATE_CHECK support.

• Moves jq to earlier in workflow as identified by @Fuma419 in 8.9.1 docker image release contains 8.7.3 bins #1748 in commit a75e01d

• All configs for each network are copied statically into the container inside /conf commit 0d3bb77

• The container image now sets a persistent ENV value of UPDATE_CHECK=N in files/docker/node/dockerfile_bin instead of entrypoint.sh in commit 9b219a2

• At container startup the configs are copied to the "$CNODE_HOME"/files/ via the load_configs() function based on the network in commit 8dd6991

• The guild-mainnet logic is restored in commit e59873e

• When the SPO wants the original logic:

  • Persistently: Override the image environment variable on container create/run by using --env, -e=env like --env UPDATE_CHECK=Y
  • Dynamically: Set an environment file during create/run using --env-file=file like --env-file=/opt/cardano/cnode/.env.
    • When the environment file contains UPDATE_CHECK=Y the container will update configs and scripts.
    • When the environment file does not define UPDATE_CHECK the container will use the configs it was built with, allowing a "rollback" to built in configs.

Fork image support:

• The G_ACCOUNT environment variable inherits the GITHUB_REPOSITORY_OWNER automatically from the forked repository.
• Set G_ACCOUNT repository environment variable for Actions DOCKER_USER and DOCKER_PASSWORD repository environment variable for Actions if it wants to push to Docker Hub a production image.
• The forked repository runs the workflow dispatch manually and sets the correct Branch to deploy for testing.
  • If PR Ensure CNVERSION matches GUILD_DEPLOY_BRANCH regardless of the workflow branch. #1749 is approved then automatic building occurs. Could also update the workflow so that test containers are uploaded to ghcr.io by default, since they are private this would allow SPO fork repositories to streamline obtaining the image for testing it under docker/podman/k8s.
• Setting G_ACCOUNT in the containers environment or environment file will get updates from any fork.
  • Removing G_ACCOUNT from an env file will cause the image to use cardano-community when UPDATE_CHECK=Y

I did not include G_BRANCH logic in this branch. Prior discussion with tool/repo maintainers was a preference to only publish containers that use the master branch. I feel this promotes a SPO fork to submit PR's with code that benefits all SPOs. This is my own opinion however, so other contributors may feel having G_BRANCH directly in the entrypoint is preferred, which could easily be added in a separate PR with its own testing.

I see three options available for replacing / getting G_BRANCH logic:

1. As image configs are now persistent, the SPO fork simply builds a new container image with any new commits.
2. Create a branch in the SPO fork that adds the G_BRANCH logic required. When the fork syncs from alpha/master of cardano-community for the latest changes the branch containing the additional logic is either merged or cherry picked.
3. Gain consensus that supporting updates from branches other than master in the default image is preferred and add G_BRANCH logic demonstrated in moving pr 1743 to node 8.9.1 #1747

Branch 2

issue/1750-container-update-check

Doesn't include commit e59873e. This is just in case it is preferred to handle this "simulated network" via the suggestion to mount a volume to $CNODE_HOME/priv/files to completely override the configuration files.

---

@Fuma419 This may eliminate the need for G_BRANCH logic. Also should remove the need to persist the G_ACCOUNT build arguments into the container image instead of setting it for the generated container when needed.

@rdlrt @Scitz0 @redoracle If there are no blockers with the proposed changes to behavior I will open a PR submit one of the two branches for PR review, whichever is preferred.

[redoracle]

I need time to check the branches, but if it has been tested and the dynamic config download is still possible then I have no objections.

Remember the documentation needs to be updated accordingly in the branch before merging.

[TrevorBenson]

I need time to check the branches, but if it has been tested and the dynamic config download is still possible then I have no objections.

Remember the documentation needs to be updated accordingly in the branch before merging.

It appears to be working.

1. In a fork I merged the following change directly into master https://github.com/TrevorBenson/guild-operators/pull/22/files
2. I run the container image generated from the issue/1750 branch without the above commit podman run -it -e NETWORK=preview -e UPDATE_CHECK=Y -e G_ACCOUNT=TrevorBenson localhost/cardanocommunity/cardano-node:issue-1750
3. Exec into bash
4. Examine the alpha preview topology file:

   $ grep 9999 /conf/preview/topology.json 
   

5. Check for topology file found in CNODE_HOME:

   $ grep 9999 /opt/cardano/cnode/files/topology.json
           {"address": "preview-node-test-change.play.dev.cardano.org", "port": 9999}
   

So without G_ACCOUNT being passed in it should properly update the configs for any network from cardano-community as described above.

[TrevorBenson]

@redoracle PR #1754 has been opened. When you get a moment please review the documentation, I placed it in the tips.md file. Let me know if there is anything you feel is missing.