| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Create a new backup entry before running =terraform apply=, which may (or may
not) destroy the current machine.
This shouldn't be an issue for the backup itself, since all of the data should
be stored in a separate Block Storage Volume, but we can take advantage of the
sevices already needing to be taken down in order to perform a full backup of
the data.
|
| |
|
|
|
|
|
| |
Before possibly tearing down the machine, while all services are stopped (after
the =docker-compose down= command), create a new backup with the current data.
The backup tag should include the commit SHA of the deployment.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Make content of .envrc available to subsequent build jobs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
