Network/Ansible

Ansible
Participants
Skills	Sysadmin stuff
Status	R&D
Niche
Purpose
Tool	No
Location
Cost
Tool category

Ansible

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:

• manage.yml

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