diff options
| author | EuAndreh <eu@euandre.org> | 2019-05-26 11:51:51 -0300 |
|---|---|---|
| committer | EuAndreh <eu@euandre.org> | 2019-05-26 11:51:51 -0300 |
| commit | da00227813b1fbeebae8c90e2122a8b73acb1af9 (patch) | |
| tree | edbd087c4868d78a709b1290cf241a4a439e527e /TODOs.org | |
| parent | Add 1 git-crypt collaborator (diff) | |
| download | toph-da00227813b1fbeebae8c90e2122a8b73acb1af9.tar.gz toph-da00227813b1fbeebae8c90e2122a8b73acb1af9.tar.xz | |
Automate provisioning and deployment of VPS
In order to perform that I had to remove Terraform's =.tfstate= files from the
repository. Terraform does support "backends" for storing the state files, but I
settled for storing it on a separate repo (vps-state).
For now it solves the state management problem:
- it has history of states;
- all state files are GPG encrypted;
- there's no coordination however, but only the CI should perform a deploy in
order to avoid race conditions.
I had to add GPG and SSH keys to sr.ht to achieve that:
- SSH public key to my profile to authorize it to push to vps-state repo;
- SSH private key to the secret builds.sr.ht environment to enable push to the
repository from the pipeline;
- GPG public key to git-crypt to make it possible for the pipeline to unlock the
encrypted content;
- GPG private key to the secret builds.sr.ht environment to enable decrypting
git-crypt content from the pipeline.
In order to avoid divergent environment from local and CI, the ./provision.sh
script is ran through nix-shell.
Diffstat (limited to 'TODOs.org')
| -rw-r--r-- | TODOs.org | 4 |
1 files changed, 4 insertions, 0 deletions
@@ -18,9 +18,13 @@ We could try to share a shared volume, but that would be a consistency nightmare The other option is to always recreate everything, with downtime. The advantage is that we get actual immutable deployments with stateful storage, but there would be downtime for every deployment. This is due to the nature of most of the packaged applications being single node *only*. +There's also the IP reputation issue: recreating everything from scratch every time would lead to new droplets with new IP addresses, which is not a good thing to be changing in a server box. + A reasonable alternative would be to redeploy everything on a different node, with a different TLD, and manually check that. But that would be just like an staging environment, with all of it's downsides too. In this situation, I if go on with automating the deployment I'd rather pick the downtime option. + +I'll start with other services other than email and consider alternatives later. ** WAITING Configure DNS from Terraform * Must ** Fully deployable from code |
