Network/Ansible: Difference between revisions

Latest revision as of 21:55, 6 September 2024

Ansible

Participants
Skills	Sysadmin stuff
Status	Active
Niche
Purpose
Tool	Yes
Location
Cost
Tool category

Ansible

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

Code

The codebase that is used to manage our infra can be found our gitlab. Note that this repo is marked as private since it contains secrets stored in an ansible-vault.

Deployment of code

We use ansible-puller on each managed system which pulls the code from a repository. This is scheduled to run each hour. During development you can test code using the debug-ansible-playbook command manually.

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

Making changes

We use GitOps to deploy changes onto this system. This means that you always need to commit your code to gitlab before you can deploy changes onto a system. Once your code is committed, login to a system and run the debug-ansible-playbook command. By default, this will use site.yml as the playbook. Optionally, you can pass a custom playbook for more rapid development.

@@ Line 2: / Line 2: @@
 |Name=Ansible
 |Skills=Sysadmin stuff,
-|Status=R&D
+|Status=Active
 |Picture=Ansible-logo.png
-|Tool=No
+|Tool=Yes
 }}
 == Code ==
-The codebase that is used to manage our infra can be found [https://gitea.vm.nurd.space/NURDspace/ansible| on our gitea instance]. Note that this repo is marked as private since it contains secrets stored in an ansible-vault
+The codebase that is used to manage our infra can be found [https://git.nurd.space/bofh/ansible|on our gitlab]. Note that this repo is marked as private since it contains secrets stored in an ansible-vault.
+== Deployment of code ==
+We use [https://github.com/teslamotors/ansible_puller ansible-puller] on each managed system which pulls the code from a repository. This is scheduled to run each hour. During development you can test code using the <tt>debug-ansible-playbook</tt> command manually.
 == Setting it up ==
@@ Line 16: / Line 19: @@
 * 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@github.com:NURDspace/operations.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.
+We use GitOps to deploy changes onto this system. This means that you always need to commit your code to gitlab before you can deploy changes onto a system. Once your code is committed, login to a system and run the <tt>debug-ansible-playbook</tt> command. By default, this will use <tt>site.yml</tt> as the playbook. Optionally, you can pass a custom playbook for more rapid development.
-== 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