Page History

...

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? Got one working here - BuildSystem/ansible/test_with_images at main · ad-build-test/BuildSystem (github.com)

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
   - done document it
   1. :
   Practice some basic playbooks to get a feel, see above attempts, (Try docker one again?) Test Ansible playbooks using Docker - DEV CommunityTODO: 
   1. to get started - create basic playbook with placeholders for like cvs stuff or anything that you dont want affected on servers.
      1. This playbook will be used to deploy IOCs on dev or production. so like all the steps you do manually should be on a script, and into a playbook.
      2. This should start from the CLI with 'bs run deployment <arg> <arg>' like specifying dev/prod and/or ioc name