History

Pim Kunis b6a0f95ee4 add devShell for ansible swarm		2024-03-02 14:46:10 +01:00
..
inventory	remove unused ansible group variables	2024-02-10 23:37:47 +01:00
playbooks	rename jellyfin -> media stack	2024-02-13 00:11:26 +01:00
roles	add bazzar to media stack	2024-02-24 21:45:29 +01:00
.envrc	add devShell for ansible swarm	2024-03-02 14:46:10 +01:00
ansible.cfg	remove legacy code	2024-02-08 23:53:02 +01:00
flake.lock	add devShell for ansible swarm	2024-03-02 14:46:10 +01:00
flake.nix	add devShell for ansible swarm	2024-03-02 14:46:10 +01:00
README.md	remove unused ansible group variables	2024-02-10 23:37:47 +01:00

README.md

Docker Swarm

On each of our machines, we deploy a virtual machine that participates in a Docker Swarm. However, only one VM is a manager (maestro) while two are workers (bancomart and vpay). This lack of redundancy in the cluster is deliberate: in case all nodes are down (e.g. misconfiguration or power outage) manual action would need to be taken in order to restore the cluster. In case of only one manager node, the cluster is always able to restore itself automatically.

While the operating system of the VMs is managed by NixOS, cluster creation and the deployment of workloads is done through Ansible. In my opinion, Ansible is a perfect fit for environments that tend to change a lot (such as a container cluster).

Stacks

On top of the Docker Swarm, we host several services deployed as Docker Stacks:

Secret decryption

The Ansible playbooks assume you have the password to Ansible vault present at ~/.config/home/ansible-vault-secret.