keep-prd: Bcoin + Electrum #591
Conversation
Much like lesser envs with the addition of a custom storage class for SSDs and running a 2 replica StatefulSet.
|
These are up and syncing |
For this to have any chance of working with Electrum we need to make sure tx-index is enabled. It's in the opening paragraph of their instructions 😅.
Trying to see how we do on mainnet against a fully indexed bcoin node.
Clarifying which domain the cloudflare origin cert is for. We need to do this because the cluster will support origin certs for multiple domains. We're setting the replica count to 2 for HA, now that we know Electrum works with bcoin.
| name: mainnet | ||
| selector: | ||
| app: bitcoin-node | ||
| type: bcoin |
There was a problem hiding this comment.
The repetitiveness between name, type, labels, and selectors in these configs is slowly driving me insane. These all feel like opportunities for screwups down the line---updating A but not B, resulting in weird behavior that's hard to diagnose. Starting to lean towards some sort of hybrid where we use a generator to create the configs, and then commit the generated configs for good diffing in PRs...
Anyway, way outside the scope of this PR.
There was a problem hiding this comment.
I took setting up prd as an opportunity to revisit labels. The idea is to match lesser environment deployments to these labels, so they're all the same.
There was a problem hiding this comment.
If you want to have a separate discussion about labeling patterns I'm happy to do that.
There was a problem hiding this comment.
I actually like that labels, names, and types are all related, I think it was a good update. What I'm saying instead is that this consistent style may be an opportunity to work to define something once and get a matching YAML, vs having to repeat it 3 times in 20 lines. I realize that can be a slippery slope though; definitely worth a separate discussion.
There was a problem hiding this comment.
Ah I see, with you there. This config layer needs some attention for sure, and I'm not sure Helm is the answer.
I think part of me has intentionally kept this layer as dumb as possible until there's an opportunity to research a more elegant solution.
| accessModes: [ReadWriteOnce] | ||
| resources: | ||
| requests: | ||
| storage: 450Gi |
There was a problem hiding this comment.
Have we captured somewhere that we should be monitoring this to make sure we can react before we run out of disk?
There was a problem hiding this comment.
We'll have an alert policy for disk space in GCP Monitoring, otherwise no.
There was a problem hiding this comment.
I think that's all we need, just making sure it's on the radar.
| valueFrom: | ||
| secretKeyRef: | ||
| name: bcoin | ||
| key: http-api-key |
There was a problem hiding this comment.
For my own understanding, this tells the bcoin node the API key others will use to interact with it?
| reclaimPolicy: Retain | ||
| allowVolumeExpansion: true | ||
| mountOptions: | ||
| - debug |
There was a problem hiding this comment.
Again for my own edification, what does debug do as a mount option?
There was a problem hiding this comment.
This should print debugging info on mount to help troubleshoot if things go sideways.
| accessModes: [ReadWriteOnce] | ||
| resources: | ||
| requests: | ||
| storage: 450Gi |
There was a problem hiding this comment.
This is obviously the first time I've taken a deep look at our Electrum deployment heh---does it replicate so much data that it needs the same amount of storage as our main node?
There was a problem hiding this comment.
It doesn't, but I wasn't entirely sure of the ratio and I felt like if something we sideways we may not have enough time.
I figured if it was at least as large as bcoin storage we wouldn't have any issues. A bit of a sledgehammer.
Fresh on the heels of #575 we're setting up some mainnet Bcoin deployments.
Bcoin
This is more or less the same as what we did ^ with some beefcaked configs:
Electrum
Here we provide a production deployment for Electrum. This looks much like our lesser environments except I've stripped all of the
tbtcreferencing in the resource names. Notably the Service config is missing. I'll do this in the next step when we're ready to expose to the internet.Something else to note here. keep-dev and keep-test configs are absent from this PR. This is due to us maintaining those configs with the tbtc-maintainers repo. As we phase out maintainers I'll shift the Electrum configs, with naming refactors to this repo.