TJ CSL
  • TJ CSL
  • Services
    • Ion
      • Development
        • Overview
        • Setup
          • Docker Setup
          • Vagrant Setup
        • Environment
        • Fixtures
        • PR Workflow
        • Style Guide
        • Maintainer Workflow
        • Repository Maintenance
        • Data Generation
      • Production
      • User Experience
        • User Interface
    • Director
      • Development
        • Vagrant Setup
        • PR Workflow
        • Style Guide
        • Maintainer Workflow
      • Production
    • Workstations
    • Signage
      • Setup
      • Administration
      • Monitoring
      • Troubleshooting
      • Experimental
        • IonTap
        • SignageAdmin
    • Remote Access
      • Setup
      • Administration
    • Cluster
      • FAQ
      • Setup
        • SSH Setup
      • Administration
      • Slurm
      • Slurm Administration
      • Borg
    • Printing
      • Setup
      • Troubleshooting
    • WWW
      • Administration
      • Sites
        • Web Proxy
      • Setup
      • Troubleshooting
    • Academic Services
      • Tin
      • Othello
        • Administration
        • Setup
  • Technologies
    • Web
      • Nginx
      • Django
      • PHP-FPM
      • Node.js
      • Supervisord
    • DBs
      • PostgreSQL
      • MySQL
    • Authentication
      • Passcard
        • GPG Usage
      • SSHD
        • SSH Passwordless Login
      • FreeIPA
    • Storage
      • NFS
      • Ceph
        • Setup
        • Backups
        • CephFS
    • Operating Systems
      • Ubuntu Server
      • AlmaLinux
      • Debian
    • Tools
      • Ansible
      • Slack
      • GitBook
      • GitLab
        • Setup
        • Updating
    • Virtualization
      • QEMU/KVM
      • Libvirt
    • Advanced Computing
      • MPI
      • Tensorflow
    • Networking
      • Netbox
      • Cisco
      • Netboot
      • DNS
      • DHCP
      • NTP
      • BGP
    • Mail
      • Postfix
      • Dovecot
    • Monitoring
      • Prometheus
      • Grafana
      • Sentry
      • Uptime Robot
  • Machines
    • VM Servers
      • Utonium
      • Blossom
      • Bubbles
      • Buttercup
      • Antipodes
      • Chatham
      • Cocos
      • Galapagos
      • Gandalf
      • Gorgona
      • Overlord
      • Waverider
      • Torch
    • Ceph
      • Karel
      • Stobar
      • Wumpus
      • Waitaha
      • Barrel
      • Valdes
    • HPC Cluster
      • Zoidberg
    • Borg Cluster
    • Compute Sticks
    • Other
      • ASM
      • Duke
      • Snowy
      • Sauron
      • Sun Servers
        • Altair
        • Centauri
        • Deneb
        • Sirius
        • Vega
        • Betelgeuse
        • Ohare
    • Switches
      • Core0
      • Xnor
      • Xor
      • Imply
    • UPS
    • History
      • 2008 Sun AEG
      • 2011 Sun Upgrades
      • 2017 VM Disaster
      • 2018 Purchases
      • 2018 Cephpocalypse
    • VLANs
    • Remote Management
      • iLO
      • LOMs
    • Understudy
      • Switch Configuration
      • Server Configuration
        • Setting Up the Operating System
        • Network Configuration
        • Saruman
        • Fiordland
  • General
    • Sysadmins List
    • Organization
    • Documentation
      • Security
      • Runbooks
    • Communication
      • Terminology
    • Understudies
    • Account Structure
    • Machine Room
    • Branding
    • History
      • Fridge
      • The Brick
  • Procedures
    • Data Recovery
    • Account Provisioning
    • tjSTAR
      • Tech Support
    • Onboarding
      • New Sysadmin Onboarding
  • Guides
    • VM Creation
    • sshuttle Usage
    • Linux Wifi Setup
    • VNC Usage
    • Password Changes
    • Sun Server RAID Configuration
  • Policies
    • Data Release Policy
    • Upgrade Policy
    • Account Policy
    • Election Policy
  • Obsolete
    • Arcturus
    • Chuku
    • Cray SV1 Supercomputer
    • Ekhi
    • Mihr
    • Moloch
    • Sol
    • Rockhopper
    • Kerberos
    • LDAP
    • Agni
    • Moon
    • Apocalypse
    • AFS
      • OpenAFS
      • Setup
      • Client Setup
      • Administration
      • Troubleshooting
      • Directory Structure
      • Backups
      • Cross-Cell Authentication
    • Observium
    • OpenVPN
Powered by GitBook
On this page
  • Organization
  • CSL's Role Management
  • Running Ansible
  • Advanced usage
  • Trivia
  1. Technologies
  2. Tools

Ansible

PreviousToolsNextSlack

Last updated 6 years ago

Ansible is an automation tool that allows us to run scripts to configure services and devices across the lab. Our goal with Ansible is to have the ability to bring up every service by only running the ansible plays.

For the purposes of the Lab, "ansibilize" is a word that refers to making a set of systems operate under the control of Ansible plays completely.

To see more about how to use ansible, refer to this link:

Organization

In order to effectively use Ansible, you need to know it's vocabulary.

  • Hosts are machines that Ansible can manage

  • Groups are sets of hosts defined in the hosts file

  • Modules contain a single thing for Ansible to do. There is a file module for doing file operations, an apt module for installing packages, a shell module for running shell commands, etc. All modules can be found at .

  • Tasks are a set of Modules to be run in order. Tasks can also include tasks from other files.

  • Roles are assigned to Groups and contain a single entrypoint task at roles/<role_name>/tasks/main.yml. Each role can also contain its own files at roles/<role_name>/files, and ditto for templates.

  • Plays define a set of Roles to apply to a set of Groups. Usually it's a many Role to one Group relationship per play.

All Ansible configuration files are written in . The best way to learn YAML is by reading existing YAML files. It's structured a bit like JSON, only indentation based like Python. So instead of

{"dictionary-key": ["list-value1", "list-value2"]}

you have

dictionary-key:
  - list-value1
  - list-value2

CSL's Role Management

Running Ansible

First, you will want to install Ansible either by using your OS's package manager or pip install ansible.

Then, you should cd to the place you have cloned your Ansible repository, and run the following command:

ansible-playbook -i hosts --ask-vault-pass <target_play>.yml

Before ansible can be run on a remote host, the remote host must have python installed.

Advanced usage

The other thing is the --extra_vars flag the ansible-playbook command. You can pass in a variable to make the play do a fresh install of all built-from-source packages, uninstall a previous version of a package, and I would say more but that's about it. You should read the play to figure out how that works.

Trivia

  • The Ansible is a fictional FTL communication device appearing in the Ender's Game series, used by aliens to manage their entire fleet

There are two roles that should be applied to almost every machine: common and auth. common installs a good suite of common utilities, and auth allows the machine to have login. Other than that, we usually assign our roles on a per-group basis, although that isn't too modular. support has its own role, but unfortunately doesn't yet.

You will usually need access to the ansible_vault password in before you can run any important plays, as a module in auth needs to access an encrypted file. For more ansible-playbook options, you should run ansible-playbook --help.

The Ansible plays for running the are very complicated and take advantage of some cool things Ansible has to offer.

The first thing is the when directive, added to the end of any module, specifying when a module should be run. Just like in common and auth, different package managers with different packages names are used on different systems, but by only running apt when on and yum when on , we can account for that.

https://docs.ansible.com/
https://docs.ansible.com/ansible/latest/modules/modules_by_category.html
YAML
Kerberos
AFS
CephFS
Passcard
Cluster
Ubuntu
CentOS