No description
Find a file
2022-07-31 22:40:10 +02:00
hardware Update Flake inputs 2022-06-22 18:52:20 +02:00
keys Start migration to NixOS for storage1 2021-11-29 02:04:29 +01:00
modules Update Flake inputs 2022-07-27 23:50:41 +02:00
profiles Add gitlab-runner 2022-07-19 08:54:18 +02:00
scripts Add new storage1 deploy-rs config 2021-11-26 00:14:44 +01:00
ssh_keys Assign floating ip to backend1 2021-07-24 03:02:54 +02:00
.envrc Move Synapse on hcloud and deploy it with Terraform + NixOs 2021-07-15 13:38:22 +02:00
.gitignore Update packages and deploy using deploy-rs 2021-11-25 00:33:28 +01:00
.sops.yaml Start migration to NixOS for storage1 2021-11-29 02:04:29 +01:00
config.tf Move Synapse on hcloud and deploy it with Terraform + NixOs 2021-07-15 13:38:22 +02:00
dns.tf Add Cotrun so matrix calls can work behind NAT 2022-07-27 02:37:42 +02:00
environment.nix Use nixpkgs from flake input as NIX_PATH 2022-07-31 22:40:10 +02:00
flake.lock Update Flake inputs 2022-07-27 23:50:41 +02:00
flake.nix Use nixpkgs from flake input as NIX_PATH 2022-07-31 22:40:10 +02:00
instances.tf Adapt network config to new vSwitch 2022-04-01 01:22:29 +02:00
outputs.tf Move Synapse on hcloud and deploy it with Terraform + NixOs 2021-07-15 13:38:22 +02:00
README.md Update documentation 2018-04-25 19:00:15 +02:00
secrets.enc.yml Switch to Mullvad VPN 2022-07-27 05:14:22 +02:00
shell.nix Add Cotrun so matrix calls can work behind NAT 2022-07-27 02:37:42 +02:00
UNLICENSE Add UNLICENSE 2021-07-08 19:23:39 +02:00

Self-hosting

This project maintains the entire configuration of our self-hosted services. All configuration should be done exclusively in this repo so that everything is versioned and we have a reliable and esay way to restore the production to any given state. The deployement of the configuration is done with Ansible. Everything respects the basic Ansible principle that your configuration should be idempotent. It means that that the configuration is completely independent of the current state of the server so whatever the state of the server is, the resulting state should always be the same. Because of this you shouldn't hesitate to run Ansible often to make sure that the configuration works and the server is in the expected state. If you run ansible-playbook two times in a row, the second execution should result in no changes to be made.

Deploying the configuration

The following command deploys the complete configuration.

ansible-playbook -i production playbook.yml --ask-vault-pass

For this to work, you must of course have ansible installed and have ssh access to the server(s). You will be prompted for the vault password, ask for it if you don't have it.

Deploying specific parts of the configuration

You probably don't want to deploy the entire configuration every time you make a small change. You can deploy specific roles by providing a list of tags. Checkout playbook.yml to see which tag matches a specific role. Here is an example of deploying only the wiki and the reverse proxy:

ansible-playbook -i production playbook.yml --ask-vault-pass --tags wiki,traefik