Page History

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.
   

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. 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