Skip to content

End-to-end automation to configure systems, deploy software, and orchestrate advanced workflows.

Notifications You must be signed in to change notification settings

tallgray/ansible

Repository files navigation

EFFICIENT CONFIG MANAGEMENT WITH ANSIBLE by SITE

End-to-end automation to deploy software, configure users, maintain hosts, structure containers, and more! This project will be designed around a lab development environment consisting of six (6) virtual machine hosts: a workstation on Ubuntu desktop, a file server on CentOS, a Minikube install on Ubuntu, and three (3) Docker hosts on Ubuntu: a master and two workers. The _site_before_roles.yml is a single playbook format for establishing the baseline setup of all hosts. This is NOT the way to efficiently model configuration management with Ansible. As such, the site.yml file along with sub-directories host_vars and roles represent a 'best practices' model of efficient configuration management with Ansible. By comparing the two, you may gain practical working knowledge of how to experiment and work with the two models in order to develop your Ansible skills.

Note: regarding this project, you may want to refer to the assumptions at the bottom of the page OR the links below to my articles and videos, which can provide additional context, relevence and practicality of the use-case scenarios.

Efficient Config Management with Ansible: From SSH Setup to Playbook Optimization

VIRTUAL MACHINE HOST INVENTORY (HOSTNAME | FUNCTION | OS | RECOMMENDED):

  • ubuntu | workstation | Ubuntu | 2vCPU/2GigMem (will act as the sys admin node)
  • samba1 | file server | CentOS | 2vCPU/2GigMem
  • minik | minikube | Ubuntu | 4vCPU/6GigMem (will act as cluster and docker compose node)
  • docker | docker master | Ubuntu | 2vCPU/2GigMem
  • docker1 | worker | Ubuntu | 2vCPU/2GigMem
  • docker2 | worker | Ubuntu | 2vCPU/2GigMem

The packages installed on each node are installed by the Ansible playbooks. You can vary the hostnames and OS, but the playbooks will need to be modified accordingly.

CONTAINERIZED APPLICATION IMAGE MANIFEST (REPOSITORY):

Note: the (link) is a container image with applications used for DevOps automation and site administration

  • Grafana with Prometheus (TBD)
  • Jenkins (TBD)

ENVIRONMENT SETUP & USAGE GUIDE:

  1. Create the 6 virtual machines with hostnames and operating systems listed under 'VIRTUAL MACHINE HOST INVENTORY (HOSTNAME | FUNCTION | OS)'.
  2. Create a GitHub account and repository. Once you've created your new repository, view it and select the Code drop down and make a note of its link under the SSH tab.
  1. Connect to the workstation host and create a user with sudo permission (provided you are root OR your account has sudo permissions).
  • 'useradd ansible'
  • 'usermod -aG sudo ansible'
  1. Assume the new user and create SSH key pair for an automation role and define a custom file name.
  • 'su - ansible'
  • 'ssh-keygen -t ed25519 -C "ansible" -f id_ansible'
  1. Confirm creation of the key pairs and display the public key.
  • 'ls -la ~/.ssh'
  1. Install Git and Ansible package from apt repository.
  • 'sudo apt -y install git'
  • 'sudo apt -y install ansible'
  1. Display the public SSH key and add it to your GitHub account through settings (top right drop-down) then SSH and GPG keys, test access from shell console, and configure it.
  1. Clone this project repository to your local machine that that is now running Git and Ansible. Note: a new sub-folder will be created in whatever directory you are currently in and it will match the name of this repository and contain its entire directory structure and file content.
  1. Change the directory to the repository subfolder.
  • 'cd ansible/dev/site'
  1. Scan for inventory host keys and add them to your known_hosts file.
  • 'ansible-playbook _ssh_keyscan.yml'
  1. Copy the public SSH key we created in step 5 to all inventory hosts authorized_keys file.
  • 'ansible-playbook _bootstrap.yml -k -K'
  1. You are now setup to operate from your workstation as an Ansible controller that will function as the automation orchestrator with sudo privelege on all inventory hosts. This will be an all powerful superuser account, so guard its private key and be mindful of where you put it. This would be a good time to take Day 0 snapshots of the virtual machines, because if the systems get corrupted, you will have a known-good restoration point from which to start over. Otherwise, proceed with deploying the site model using the playbooks _site_before_roles.yml and/or site.yml or go freestyle and experiment with cli usage options like: --list-tags, --list-hosts, --list-tasks, --skip-tags, -l, -t, -u. The full list of options is available by typeing ' ansible-playbook --help'.
  • 'ansible-playbook site.yml'
  1. Finally, mirror this project to your new dev playground GitHub repository, then get familiar with Git functions: status, diff, add, commit and push. These commands are critical for proper usage of the git protocol.
  • 'git push --mirror https://github.com/YOUR-USER/YOUR-REPOSITORY.git'
  • 'cd ..'
  • 'rm -rf ansible.git'
  • 'cd YOUR-REPOSITORY'
  • 'git status'
  • 'nano README' (make a change and save)
  • 'git diff README.md'
  • 'git add README.md'
  • 'git status'
  • 'git commit -m "update to readme file"'
  • 'git push origin main'

ASSUMPTIONS:

It is assumed that the hosts in INVENTORY are running SSH server and accessible via SSH by root or a sudo user that you defined when the virtual machines were created. Also, it is assumed that DNS name resolution works to resolve the hostnames to IP addresses. If not, add each host resolution to the INVENTORY file like such 'docker ansible_host=192.168.0.130'

About

End-to-end automation to configure systems, deploy software, and orchestrate advanced workflows.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published