| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The email will be send for both sucessfull and failed runs.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This way we can implement dynamic (provision-time) Floating IP, instead of a
hardcoded pre-created Floating IP address.
Related changes:
- remove =terraform-godaddy= provider, use =digitalocean_record= instead;
- create =generated-known-hosts= after provisioning instead of during
=setup.sh=: use the =$(terraform output public_floating_ip)= value to make this
file dynamic;
- remote the =$PINNED_IP= and =$TF_VAR_floating_ip= variables;
- add type and descriptions to variable declarations in Terraform recipe.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The =terraform-godaddy= package supports only Terraform 0.11 as of now.
It is not packaged by default by nixpkgs, and the =postInstall= hook is required
because Terraform looks for providers usinthe the =terraform-provider-$name=
template, which the package doesn't follow.
I had to remove the loop on vps.tf since it requires Terraform 0.12. I'll either
wait for =terraform-godaddy= to upgrade to 0.12 or try to do it myself if it
bothers me enough.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The previous solution would hardcode the server IP. This way we can change the
server IP address that is hosting everything and keep the SSH keypair.
Previously changing the IP address would require either calling the
=./rotate-ssh-keys.sh= script or manually changing the IP address on the
known-hosts.txt file.
The IP address being duplicated itself was a code smell.
Both SSH keypair and IP address can now be changed independently.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This way I can dynamically control whether to destroy and recreate all the
existing infrastructure entirely from scratch.
The advantages of doing so are:
- test the non-existence of local state on every deployment;
- make sure I can always recreate everything from scratch.
The disadvantages are:
- slower deployment times;
- longer downtime during deployments.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The deployment is not quite working, and I'm unable to test right now:
DigitalOcean is returning 503 for my requests.
As of this commit, I can run =ansible-playbook provider.yml= more than once and
it will actually be idempotent.
Notes:
- SSH fingerprint are now taken from the public key file instead of manually
supplying it in the terraform template using the =digitalocean_ssh_key=
resource;
- use Ansible instead of ad-hoc Bash scripts for provisioning the Droplets
created by Terraform;
- use the =filename.env.extension= to create the concrete files in CI;
- use the =user_data= to add the know SSH key pair to the newly created Droplet;
- add =rotate-ssh-keys.sh= utils;
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Embed SSH keypair directly into git-crypt.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
