| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 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;
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Extend on how to use =vps-state= to store Terraform state.
|
| |
|
|
| |
Expand on the decision of using =vps-state= to store Terraform files.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Add =Nice to have= task on docker-compose version
|
| |
|
|
| |
Add notes on creating backups, and questions on the best strategies available.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
