From NURDspace

Jump to: navigation, search
Skills Sysadmin stuff
Status R&D
Tool No
Tool category


Ansible-logo.png {{#if:No | [[Tool Owner::{{{ProjectParticipants}}} | }} {{#if:No | [[Tool Cost::{{{Cost}}} | }}


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

Next, create a file ~/ 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:



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:


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:


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

Run ansible on some host

./scripts/ansible-playbook managedvm.yml -l

Apply a specific tag(role) to some host

./scripts/ansible-playbook managedvm.yml -l -t some-role

Applying a specific tag(role) to all hosts

./scripts/ansible-playbook managedvm.yml -t some-role
Our site is hosted by Site4U
Our connectivity is made available by BIT
To BIT's website