Use variables for execution explorer deployment

[dapplion]

• Generalize explorer deployment with variable.
• Add explorer.yml to hold those variables.

Includes the variables used in #49

@parithosh we can generalize the handling of secrets in a following PR

@parithosh I've committed a proposed explorer.yml here but please feel free to update the actual one used for mainnet-shadow-fork-7

[parithosh]

This is the value present inside the docker container after the volume mapping , so the original value of /custom_config_data/genesis.json would be correct since the volume mapping is - "{{testnet_dir}}:/custom_config_data"

[dapplion]

Right, I used execution_explorer_genesis_cont_path as container path, so it's defined next to where you do the volume mapping. Both work but using execution_explorer_genesis_cont_path feels less error prone long term

[parithosh]

So your idea is that you can modify the execution_explorer_genesis_cont_path to rep some other file path, whereas in the current approach you'd have to search for the hardcoded paths?

[parithosh]

Our manner of secret handling involves keybase. I'm open to ansible vault secrets as an alternative, but that might need to be a deeper discussion including some others on the team.

[dapplion]

Our manner of secret handling involves keybase. I'm open to ansible vault secrets as an alternative, but that might need to be a deeper discussion including some others on the team.

What about having variables that depend on secrets documented in each group like

explorer.yml

# Set in secrets.yaml
# explorer_postgres_password: "{{ lookup('pipe', 'keybase fs read /keybase/team/ethereum.devops/eth2/merge-devnets/merge-devnet-3/explorer-postgres') }}"

Then in a gitignored secrets.yaml you have

explorer_postgres_password: "{{ lookup('pipe', 'keybase fs read /keybase/team/ethereum.devops/eth2/merge-devnets/merge-

And in my gitignored secrets.yaml I have the secret specified in some other way

[parithosh]

The issue with a generic secrets.yaml file is that every role needs to have access to all the secrets. It isn't an issue per-se, but it isn't really best practice. We can try it out if you think its a big QoL improvement, the secrets only exist in local disk anyway.

[dapplion]

The issue with a generic secrets.yaml file is that every role needs to have access to all the secrets. It isn't an issue per-se, but it isn't really best practice. We can try it out if you think its a big QoL improvement, the secrets only exist in local disk anyway.

Good point, getting this right and generic is tricky. Would make sense to commit something at least and them each one can customize it's local file while we figure out the best solution? You can commit your version of the file with keybase key loading

[parithosh]

Sure. One nice thing about the secrets.yaml approach is that its easier to switch secret management systems, you can use ansible vault, keybase or a number of other approaches without it hurting anything.