refactor(cd): improve Docker and gcloud usage without Cloud Build

[gustavovalverde]

Motivation

We had a Dockerfile that was good enough but could be improved to be used on multiple scenarios, and caching leverage could also be improved (it's changed on this PR, but caching is not used

We've also experienced multiple issues with Cloud Build, from increasing timeouts at build time, not inheriting branch names, to not having a way to check logs directly from GitHub. This motivated using GHA as the default pipeline for all our requirements.

Pipelines could also be simpler, by leveraging the use of variables, secrets and removing repeated or not needed steps, or even merging manual and automated deployments on a single file.

Solution

Docker

• Use a configurable Dockerfile through ARG and ENV
• Use a specific rust version to reduce unexpected behaviors from upgrades (and ensure support up to a specific version)
• Use bullseye instead of buster for Debian to reduce vulnerabilities and use more up to date libraries
• Implement cargo-chef for docker layers caching
• Move zebrad executable to /usr/local/bin to be able to use it without pointing to a custom path
• Compile tests without running them, to be able to run them after deployment

Pipeline

• Remove cloud build dependency
• Move Sentry endpoint to secrets
• Use a single yml for auto & manual deploy

GCP

• For short-term stability, focus on a single zone with the broadest set of resources and features.
• Migrate to Google Artifact Registry and make it publicly available
• Use SSD instead of normal hard drives
• Use compute-optimized machine types: https://cloud.google.com/compute/docs/compute-optimized-machines

Fixes: #2418 #3447
Partially: #3432

Review

I've already tested single deployments (manual). Automated deployment was not particularly changed in the way it gets deployed. It's just using the same Dockerfile as the manual deployment (it already was a dockerized deployment).

@dconnolly @conradoplg @teor2345

Reviewer Checklist

• Review Dockerfile commands and order of cargo execution
• Confirm merged actions design
• Confirm Cloud Build removal as a sane option

Follow Up Work

• Use self-hosted runners (GHA runners don't have enough power to build in a timely fashion)
• Use OpenID Connect instead of the long-lived API keys for GH-actions deployments #3419
• Apply most of these practices to the Tests pipeline refactor(test): dockerize tests and run sync in detached mode #3459
• Auto-delete old Google Cloud instance templates #2090
• Add the Google Cloud Instance ID to Sentry, so we can search logs #2220
• Most of these deployments are better suited for Kubernetes (but that's a longer discussion)

[codecov]

Codecov Report

Merging #3431 (ef82699) into main (499ae89) will increase coverage by 0.05%.
The diff coverage is 75.08%.

@@            Coverage Diff             @@
##             main    #3431      +/-   ##
==========================================
+ Coverage   78.34%   78.39%   +0.05%     
==========================================
  Files         267      273       +6     
  Lines       31526    31855     +329     
==========================================
+ Hits        24698    24972     +274     
- Misses       6828     6883      +55     

[dconnolly]

Looking great, some small questions to resolve before we merge!

[gustavovalverde]

I think we're done.

I've implemented the parameter caching with a specific action to trigger a docker build for this specific use: https://github.com/ZcashFoundation/zebra/blob/docker-actions-refactor/.github/workflows/zcash-params.yml

And then use the resulting artifact in our day-to-day Dockerfile:
https://github.com/ZcashFoundation/zebra/blob/docker-actions-refactor/docker/Dockerfile.build#L55-L58

[teor2345]

This looks great, let's get it merged!

(I'd like to merge separately from the test PR, so we can bisect any failures and revert if needed.)

[teor2345]

I opened #3489 for the test failures, they seem unrelated.
(They have also happened in another PR recently.)