Introduction

  1. Introduction information Introduction to Ansible — Ansible Community Documentation
    1. Ansible is an orchestration/automation tool, just like Chef or Puppet which are other alternatives to ansible, but ansible main advantage is that it can work through ssh, so target machines don't need ansible installed.
    2. ansible solves the problem of performing 'day-1' operations of infrastructure (installing os, dependency packages, network configurations, etc) source: DevOps: Difference between Ansible and orchestrators like Kubernetes - Stack Overflow
    3. Big advantage is that it uses declarative playbooks (define what you want done) instead of imperative scripting (define what you want and how). 
    4. day-0; get all of your infrastructure; hardware/public-cloud etc. day-1; use something like Ansible to setup the infrastructure components (EC2 nodes, hardware servers or GCE instances) day-2; install k8s on them to start running containerized workloads day-3; use k8s native mechanisms to deploy and manage and monitor applications
      (Day 2 and 3 is ideal, but i think we will just deploy the containers through our build system not k8s)
    5. Ansible can help with availability, and we will use it to test, like if an ioc needs another ioc to run for testing, specifying which machine and what resources, ansible should handle that deployment.
  2. Why Ansible
    1. Reduces complexity and runs anywhere.
    2. Lets you automate any task,
    3. Manage and maintain system configuration
    4. Agentless, the managed nodes only need to be accessible via ssh and sftp or scp, and python installed.
    5. Quote from Developing modules — Ansible Community Documentation - 'If you need functionality that is not available in any of the thousands of Ansible modules found in collections, you can easily write your own custom module.' We can make our own as well which is important for like ioc deployment because thats a lot of manual steps
  3. How it works Ansible Tutorial for Beginners: Playbook & Examples (spacelift.io)
    1. A control node (machine with ansible installed) sends commands/instructions to host/managed nodes/machines.
    2. Ansible structure: 
      1. Units of code that the control node executes on the managed nodes are modules
      2. Each module is invoked by a task
      3. An ordered list of tasks form a playbook
      4. The managed nodes are represented in a simplistic inventory file
      5. Collection is a distribution format for Ansible content such as playbooks, roles, modules, plugins.
        1. find collections here Ansible Galaxy - Collections
    3. The user defines the playbooks using YAML

Ansible practice

  1. Get some mock machines (can use containers for this) Building an inventory — Ansible Community Documentation
  2. 1st attempt: docker network create -d bridge my-net
    1. docker run --network=my-net -itd --name=container3 busybox
    2. docker pull alpine
    3. docker container run --name target --network my-net -it --rm alpine /bin/ash
      1. apk update
      2. apk add openssh
      3. ssh-keygen -A
    4. docker container run --name controller --network my-net -it --rm alpine /bin/ash
      1. apk update
      2. apk add openssh
      3. ssh-keygen
      4. enter for all options
      5. save the public key on this controller "/root/.ssh/id_ed25519.pub" to the target container at "~/.ssh/authrorized_keys"

  3. 2nd attempt

    1. docker pull ubuntu

    2. docker run -it -d -p 2200:22 --name ssh-access-server ubuntu:latest

    3. docker exec -it ssh-access-server bash
      1. apt update
        apt install openssh-server -y
        apt install vim -y
        vim /etc/ssh/sshd_config
        Search for PermitRootLogin and make it Yes
        service ssh start
        service ssh status
        passwd

  4. TODO: 3rd attempt - try using any of the nodes in our ad-build-dev cluster as the managed nodes. (problem is they are inaccessible outside of the cluster), so may try vm's?

Ansible in Build System

  1. TODO: need to figure out how we can roll out the ansible playbooks, for something like buildroot , like

    1. Do we want it specified in the manifest (BOM) of the app
    2. or do we want to have predefined playbooks for the control node and we just pass in arguments depending on the system
    3. Ex use case: if a package needs updating, we just give an installer and some arguments like a filepath, and ansible will automatically handle that. A passive system if you will (it'll modify whenever changes are detected)
    4. Ansible (control nodes) in containers - Ansible ecosystem documentation
      1.  
      2. There is built-in support for ansible in containers which is good for our build system so we can run on the ad-build cluster like everything else

      3. How to make execution environment Introduction to Execution Environments - Ansible ecosystem documentation

      4. Then you would have to use ansible-navigator to actually run any playbooks against the execution environment. Think of it like this: one main controller/container that has ansible-navigator, which creates jobs that runs playbooks to other ansible runners (containers that run once and are killed once completed).
      5. Potential problem: seems like this is only useful if you have the redhat automation controller 15. Execution Environments — Automation Controller User Guide v4.5 (ansible.com). And we are moving to rocky linux so may be an issue
      6. Potential solution: There is an open source automation controller Ansible AWX | Ansible Collaborative, which theoretically achieves the same goal as redhat automation controller, but its backed by the community rather than redhat
        1. This provides web UI, REST API (for our backend to communicate/cli with), and task engine (to manage jobs/playbooks)
  2. We may or may not need a fancy automation controller, if we did we'd use the open-source AWX. 
    1. What we will have is any change to configuration (Deployment database) through the CLI, would send a push event to the ansible controller, then that could start the playbooks. 
    2. And can have a slow loop that checks if the configuration actually matches whats deployed out there. 
    3. SLAC IT for example has an ansible configuration setup, they have all their playbooks in one repo, and a bunch of configuration files. Then they run it when they need to.
    4. TODO: Practice some basic playbooks to get a feel, see above attempts, (Try docker one again?)
  • No labels