| Ansible | |
|---|---|
 | |
| Participants | |
| Skills | Sysadmin stuff |
| Status | R&D |
| Niche | |
| Purpose | |
| Tool | No |
| Location | |
| Cost | |
| Tool category | |
Ansible-logo.png {{#if:No | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:No | [[Tool Cost::{{{Cost}}} | }}
Code
The codebase that is used to manage our infra can be found on our gitea instance. Note that this repo is marked as private since it contains secrets stored in an ansible-vault
Setting it up
Make sure you have the following dependencies installed. Note that this documentation assumes a linux based system. You are on your own if you use something different. Also, be very, very careful if you edit these files under windows, since that can mangle the line endings. This code will break unless you use LF line endings.
- ansible
- ansible-vault
- git
First, ask someone to add you to the nurdspace organization. Next, use git to checkout this codebase:
cd git git clone git@gitea.vm.nurd.space:NURDspace/ansible.git
Next, create a file ~/.nurdspace-vault.pw file containing a single line with the plaintext password used for the ansible-vault.
Making changes
For now, everyone who has write access to this repo is able to make changes. This implies that you *must* keep your local copy uptodate and be aware of merge conflicts whenever you commit. In the future, we might move to gitops.
Structure of an ansible repository
An ansible repo consists of roughly three different pieces. First, you have roles. A role defines a set of tasks that is performed around a certain subject. Next, there is an inventory, a list of hosts with optional groups in the INI file format. Finally, there are playbooks. A playbook defines which roles apply to which host(s) or groups as defined in the inventory.
The inventory
The inventory is a file in INI format which describe hosts to which the ansible codebase is applicable. This file uses INI headers to define groups. Eg, in our codebase we currently have two groups:
[all] some-host-name.vm.nurd.space [debian] some-host-name.vm.nurd.space
The choice to which a host belongs determines what code will run on that host. Check out the playbooks to see what is applied to where
Writing a playbook
We use playbooks, which can be seen as a collection of tasks we want to perform on our infra. At the time of writing, we have two playbooks:
- bootstrap-debian.yml
- managedvm.yml
Both do the same thing, but bootstrap-debian.yml performs an apt upgrade + reboot once it is finished
Writing a role
Create a new subdirectory underneath operations/ansible/roles. The name you pick here is used inside of the playbook to reference this role. A role has the following required directory structure:
role/tasks
Within this directory, a file named 'main.yml' should be created, which will contain all tasks that belong to this role. Depending on what you do with the role, you optionally need to create one or two of the following, for templated and static files respectively:
role/templates role/files
Working with secrets
Our codebase stores secrets in encrypted json format under operations/ansible/secrets/nurdspace.json. This file is automagically included in the ansible context if you use the wrappers as found under operations/ansible/scripts/. Editing these secrets requires 'ansible-vault' and the well-known password. All sensitive material (passwords, secrets, private keys, etc) *MUST* be stored in this file.
Running ansible
Following are some example commands showing how ansible works. All of this code assumes that you are situated in the ansible subdirectory of the operations repo.
Deploy a new debian vm
./scripts/ansible-playbook bootstrap-debian.yml -l some.host.name
Run ansible on some host
./scripts/ansible-playbook managedvm.yml -l some.host.name
Apply a specific tag(role) to some host
./scripts/ansible-playbook managedvm.yml -l some.host.name -t some-role
Applying a specific tag(role) to all hosts
./scripts/ansible-playbook managedvm.yml -t some-role