Marcin Jahn | Dev Notebook
  • Home
  • Programming
  • Technologies
  • Projects
  • About
  • A logo of LinkedIn
  • A logo of GitHub
  • cirro.services
  • Home
  • Programming
  • Technologies
  • Projects
  • About
  • An icon of the Networking section Networking
    • HTTP Protocol
    • OSI Model
    • TCP Procol
    • UDP Protocol
    • WebSocket
    • HSTS
    • DNS
    • Server Name Indication
    • gRPC
  • An icon of the Security section Security
    • OAuth2
      • Sender Constraint
    • Cryptography
      • Cryptography Basics
    • TPM
      • Overiew
      • TPM Entities
      • TPM Operations
  • An icon of the Linux section Linux
    • Gist of Linux Tooling
    • System Calls and libc
    • SELinux
    • Containers
    • Bash Scripting
    • Linux From Scratch
    • Networking
  • An icon of the Kubernetes section Kubernetes
    • Meaning and Purpose
    • Cluster
    • Dev Environment
    • Kubernetes API
    • Objects
    • Pods
    • Scaling
    • Events
    • Storage
    • Configuration
    • Organizing Objects
    • Services
    • Ingress
    • Helm
  • An icon of the Observability section Observability
    • Tracing
  • An icon of the SQL Server section SQL Server
    • Overview
    • T-SQL
  • An icon of the MongoDB section MongoDB
    • NoSQL Overview
    • MongoDB Overview
    • CRUD
    • Free Text Search
  • An icon of the Git section Git
    • Git
  • An icon of the Ansible section Ansible
    • Ansible
  • An icon of the Azure section Azure
    • Table Storage
    • Microsoft Identity
  • An icon of the Google Cloud section Google Cloud
    • Overview
  • An icon of the Blockchain section Blockchain
    • Overview
    • Smart Contracts
    • Solidity
    • Dapps
  • An icon of the Networking section Networking
    • HTTP Protocol
    • OSI Model
    • TCP Procol
    • UDP Protocol
    • WebSocket
    • HSTS
    • DNS
    • Server Name Indication
    • gRPC
  • An icon of the Security section Security
    • OAuth2
      • Sender Constraint
    • Cryptography
      • Cryptography Basics
    • TPM
      • Overiew
      • TPM Entities
      • TPM Operations
  • An icon of the Linux section Linux
    • Gist of Linux Tooling
    • System Calls and libc
    • SELinux
    • Containers
    • Bash Scripting
    • Linux From Scratch
    • Networking
  • An icon of the Kubernetes section Kubernetes
    • Meaning and Purpose
    • Cluster
    • Dev Environment
    • Kubernetes API
    • Objects
    • Pods
    • Scaling
    • Events
    • Storage
    • Configuration
    • Organizing Objects
    • Services
    • Ingress
    • Helm
  • An icon of the Observability section Observability
    • Tracing
  • An icon of the SQL Server section SQL Server
    • Overview
    • T-SQL
  • An icon of the MongoDB section MongoDB
    • NoSQL Overview
    • MongoDB Overview
    • CRUD
    • Free Text Search
  • An icon of the Git section Git
    • Git
  • An icon of the Ansible section Ansible
    • Ansible
  • An icon of the Azure section Azure
    • Table Storage
    • Microsoft Identity
  • An icon of the Google Cloud section Google Cloud
    • Overview
  • An icon of the Blockchain section Blockchain
    • Overview
    • Smart Contracts
    • Solidity
    • Dapps

Ansible

Overview

It is used for automation of configuration processes. You inform Ansible what is the DESIRED state and Ansible will try to achieve it, no matter what the CURRENT state is. Example: you want to have a file in a spcified location with a specified content. There ar ea few possible starting points:

  • the file does not exist - Ansible will create it
  • the file exist, but has a different content - Ansible will update the file
  • the file exists and has the right contnet - Ansible will do nothing

Manual -> Automation

Evolution of automation:

  1. Manual setup
  2. Writing scripts (.sh, .ps, etc.)
  3. Using Ansible ad-hoc
  4. Writing Ansible playbooks

Difference between scripting and Ansible is that in a script we need to say exactly what to do and cover various cases. Ansible takes care of these difficulties. We just say what we want to have in the end and not how to do that.

Modules

Ansible relies on modules. There are many of them for various operations (like for file operations, macOS setup, specific device setup, etc.).

Most modules are idempotent, some are not.

Every module can have some return values (i.e. a file module returns SHA checksum of the file afer modifications, owner of the file and other things).

Documentation

ansible-doc command is useful, i.e. ansible-doc copy gives information about copy module.

Ad-hoc commands

ansible command allows to run one chosen module with specified inputs.

--dry-run allows to see what the result would be without doing any actual changes.

Playbooks

Playbooks are defined in YAML files and contain tasks that should be done.

Example:

---
- name: Ensure ~/.gitconfig copied from master.gitconfig
  hosts: localhost
  tasks:
  - copy: src="../master.gitconfig" dest="~/.gitconfig"

We can have many “plays” in the same file:

---
- name: Ensure ~/.gitconfig copied from master.gitconfig
  hosts: localhost
  tasks:
  - copy: src="../master.gitconfig" dest="~/.gitconfig"
  
- name: Ensure homebrw packages are installed
  hosts: localhost
  tasks:
  - homebrew: name=bat state=latest
  - homebrew:
      name: jq
      state: latest

Tasks

The task’s parameters can be defined in multiple ways, like the two homebrew tasks above.

Plays can have tags, which allow to limit the plays that we want to execute from a given file (tags).

A task can have a condition (when), i.e.: when: ansible_os_family == 'RedHat' will run the task only if the host’s OS is in the Red Hat family.

Task can have a name.

Task can ignore_errors: yes to not stop the play if it fails.

Tasks can store their outputs in variables with register: my-variable There is a task that prints these variabes, it’s called debug. i.e.: debug: var=my-variable. Outputs are in JOSN format and we are able to debug a specific subset of it (my-variable.some-parameter ).

Command to run a playbook

ansible-playbook my-playbook.yml

-v flag shows more info. It can be added multiple times to increase verbosity level.

Multiple hosts

Although Ansible can work just with localhost, it is also suitable to configure multiple hosts. They are referred to as INVENTORY.

Inventory can be defined as a set of files in a chosen directory. They can be grouped under various labels. This helps us to target subsets of our inventory. “all” group is the top level group, contains all of the hosts.

We can use both ad-hoc commnands and playbooks agains inventory. Example of an ad-hoc command:

ansible -m command -a "git config --global --list" docker-containers

In the case above, I’d run the command agains hosts that are in the “docker-containers” group (docker containers can be hosts!).

ansible-inventory command manages inventory.

--list shows all hosts in our inventory.

Connections

We can use various connection types to reach hosts. For example, we could use the local connection to create some docker containers on our localhost (with the docker_container module) and then, use the docker connection to do something on these containers.

ansible-pull

Noramlly, there is a central Manager Node that runs the playbooks on the hosts (push model). Ansible can also work in a different fashion. Each host can use ansible-pull which connects to some VCS, pulls playbooks and runs them on the host.

Ansible Galaxy

Galaxy enables community to share ROLES and COLLECTIONS (kind of Roles V2). These are constructs that sit between a module and a playbook.

Galaxy is like a package source for Ansible (same as .NET and NuGet or Node.JS and npm)

© 2023 Marcin Jahn | Dev Notebook | All Rights Reserved. | Built with Astro.