zeta-chain
Not able to build zeta-chain node
Describe the Bug
When I run docker build . -f Dockerfile
[+] Building 1.2s (12/20)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.34kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 230B 0.0s
=> [internal] load metadata for docker.io/library/golang:1.22-alpine3.18 0.0s
=> [internal] load metadata for docker.io/library/alpine:3.18 0.0s
=> [internal] load build context 0.8s
=> => transferring context: 17.26MB 0.8s
=> [builder 1/8] FROM docker.io/library/golang:1.22-alpine3.18 0.0s
=> [stage-1 1/7] FROM docker.io/library/alpine:3.18 0.0s
=> CACHED [builder 2/8] RUN apk --no-cache add git make build-base jq openssh libusb-dev linux-headers bash curl python3 py3-pip 0.0s
=> CACHED [builder 3/8] WORKDIR /go/delivery/zeta-node 0.0s
=> CACHED [builder 4/8] COPY go.mod . 0.0s
=> CACHED [builder 5/8] COPY go.sum . 0.0s
=> ERROR [builder 6/8] RUN go mod download 0.4s
------
> [builder 6/8] RUN go mod download:
#14 0.292 go: go.mod requires go >= 1.22.7 (running go 1.22.3; GOTOOLCHAIN=local)
------
executor failed running [/bin/sh -c go mod download]: exit code: 1
It's expected for image to be built.
Building on macOS Sonoma Version 14.5
p.s. It's the same issue from your github action - https://github.com/zeta-chain/node/actions/runs/12237577778/job/34133645670
https://github.com/zeta-chain/zetacored-docker is our actively supported way of running zetacored in docker.
I can fix this up if you really need it. What do you use to automate the upgrades?
https://github.com/zeta-chain/zetacored-docker is our actively supported way of running zetacored in docker.
I can fix this up if you really need it. What do you use to automate the upgrades?
This would be much needed for us, so our nodes can run. We don't use anything to automate upgrade unfortunately. zetacored-docker is not working for us since it's wiping disk and downloading full node snapshot and we run archive nodes.
zetacored-docker is not working for us since it's wiping disk and downloading full node snapshot and we run archive nodes.
You set ZETACHAIN_SNAPSHOT_TYPE=archive and mount a persistent volume on /root?
zetacored-docker is not working for us since it's wiping disk and downloading full node snapshot and we run archive nodes.
You set
ZETACHAIN_SNAPSHOT_TYPE=archiveand mount a persistent volume on/root?
But it would still download snapshot every time, right? And for archive node it's 5Tb. Not sure for mounting persistent disk on /root, who this will effect nodedata, it'll be persistet, but wiping and snapshot download would be still present?
But it would still download snapshot every time, right?
If the snapshot restore completes it will not be restored again so long as you have a persistent volume mounted on /root.
I did attempt to test archive snapshot restore yesterday. It did end up failing around ~1TB, I think there are some issues with cloudflare and range headers.
Cool, we'll try this out. But is there a change you can provide image earlier on the dockerhub so we have nodes running until we switch to zetacored-docker?
My recommendation for now would be to just bind mount the v24 binary in your existing setup (or use your current workaround), and then complete the following procedure to migrate to zetacored-docker.
To migrate, you would need to perform the following procedure to bypass the snapshot download, inserting your own existing node data:
- Set environment variables:
MONIKER=WhateverYouLike(required)ZETACHAIN_SNAPSHOT_TYPE=archive(it will otherwise default tofullnode)
- Start the container, but prepare to stop it again shortly in the next step.
- Stop the container after
/root/init_startedappears, which should happen quickly. - Copy the empty file
/root/init_startedto/root/init_completed. This presence of these two empty files indicate that the container is completely set up, which prevents snapshot redownload. - Copy
/root/.zetacored/datafrom your existing archive node to/root/.zetacored/datain your new node. - Start the container
One of the key features of zetacored-docker is that it automatically will handle mandatory zetacored software upgrades by leveraging a pre-configured cosmovisor.
@nebojsa-ristovic, were you able to complete the migration to zetacored-docker?
Hi @CryptoFewka We did not do it yet but plan to tackle PoC next week.
One concern we have is that we have a process running in our cluster which is downloading unknown executables automatically and running them - that is a compliance nightmare for us and might prevent us from going this route. Ideally, we would have options to go with comsovisor OR zetacored docker container we can manage using standardized container lifecycle.
downloading unknown executables
I wouldn't describe the software updates as "unknown". It's not like someone can just push and run arbitrary executables on your system. When a software upgrade is proposed on chain, you have plenty of time to ensure it's validity.
All the binaries in our software upgrade proposals have checksums that you can independently verify by running make release-build. The checksum of your local build will match what's in the software upgrade proposal.
We also use actions/attest-build-provenance to attest that the release binaries were build by github actions rather than by a user manually.
Ideally, we would have options to go with comsovisor OR zetacored docker container we can manage using standardized container lifecycle.
Nothing prevents you from building your own image. But we do have a really hard time supporting things that we do not run ourselves. We don't notice when the old docker workflow was broken because we ourselves do not use it.
For reference, here is exactly what we run and how we run it:
- pruned fullnodes running in kubernetes via zetacored-docker which are fully automated and we never touch.
- archive nodes running on bare metal servers via systemd services. We manually push out new binaries with ansible.
- validator nodes which run on AWS VMs. We manually push out new binaries with ansible.