History

Pim Kunis 9e04839c5a use kubenix to create cyberchef resources		2024-03-23 17:24:39 +01:00
..
inventory	remove bancomart VM from docker swarm	2024-03-13 22:41:02 +01:00
playbooks	use kubenix to create cyberchef resources	2024-03-23 17:24:39 +01:00
roles	move cyberchef to k3s	2024-03-23 12:48:30 +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.