- The PoC is functional, with some caveats.
- The workflow implemented via AWX can be achieved via any workflow, pipeline, ect.
- The Initial Configuration of the base vm to host nested vms is for a rhel distro.
- The rdp, and desktop setup was useful to troubleshoot any kickstarts that did not deploy correctly during the second stage, Packer build Stage. (vnc into the nested vm to see where it was hung.)
- Utilizing ST stig kickstart files is possible but not implemented. Changes still needing implementation are the partitioning and disk allocation during the installation.
- For testing the ISO was staged on the VM manually.
- Utilization of the nested virtualization in the test and build uses libvirt and not ESXi Builder or Provider, may be useful for doing quick dev stuff.
- An additional parameter needs to be accounted for in the custom vagrant ansible file to account for the confirmation to destroy a built vm. Currently passing in a
'echo "y" | vagrant destroy'
, however likely a switch to quiet prompt. - Screenshot.py works and can be used to provide a "proof.txt" style of confirmation of task execution.
- There may already be a functional vagrant plugin already that meets the intent. (Vagrant-camera did not work)
- If a working plugin exists...implementation via an ansible shell/command task is feasible.
- If a working vagrant plugin does not exist; conversion of the python script to an ansible module is a viable course
- At this time, not a priority to implement; no real use case being forecasted.
PoC is functional and can provide a quick adhoc testing environment.
However, use case for implementation for a business need is not apparent at this time.
- Make the Base VM
- Base VM is the VM that nested virtualization will occur on.
- Libvirt_packer_ansible playbook
Pakr Vagr Libvirt
-
Create a testing workflow, AWX Demo.
- Examples below shows stages.
- Workflow approvals required after each stage completion (approval/disapprove).
- Workflow Execution can be ran from any point if the required files and dependencies exist (Prior workflows already ran).
- Example uses:
Creating new base boxes via kickstarts (WF2) Updating the Selection VM settings Dict, the Selection Var, ect. (WF3)
Synch proj., exec play, request for approval -> condition based action.
- Packer Build w/ vagrant post provision
- Provision and use vagrant post processor to create base.box
make test vm thingys
- Create Dynamic vagrantfile* with selection conditional for vagrant box,
enabling vagrant up, down, halt, and stuffs.
- Build Nested vm using libvirt and vagrant box
-
Add template or additonal tasks with appropriate to dynamically launch
additional tasks / playbooks with vagrant provisioner.- Created marker for afterline task in vagrant file.
-
Implement Custom Vagrant Ansible Module for running vagrant commands
Vagrant Custom Plugin Readme
Using AWX Workflow templates to synch repositories, launch jobs, and kick off Next Stage Workflows.
Personal reasons I like AWX is the organic synchronization of projects, creds storage, and others, but most
importantly - visual context.
Packer Build w/ post vagrant provisioner to build box
Moving these to seperate workflow.
- Need to create a task to launch the packer build of the base vm.
Going to move externally to segrate workflow tasks
Make vm test thingys - Need to come up with logic for choosing the pkr.hcl file...
Going to move externally to segrate workflow tasks
Make vm test thingys - Need to ensure task for vagrant install libvirt plugin is done
Re-use and "agnosticize" things.
- template for vars to be imported from file for vagrantfile.
- Create a j2 template to generate vars for the vagrantfile
config.yaml
- Box Selection: config.vm.box = "file:https://boxes/libvirt-{{box_name}}" based on selection in config.yaml
Below is the applicable portion of the "Agnosticized" vagrantfile.
```ruby
# encoding: utf-8
# -*- mode: ruby -*-
# vi: set ft=ruby :
require 'yaml'
# Load Dynamic Vars from config.yaml generated file
current_dir = File.dirname(File.expand_path(__FILE__))
configs = YAML.load_file("#{current_dir}/config.yaml")
vagrant_config = configs['configs'][configs['configs']['select']]
base_name = vagrant_config['base_box']
Vagrant.configure('2') do |config|
config.vm.box = "file:https://boxes/"+box_name
#....other variables below.....
```
-
Declare values for the vars to be imported into the "agnosticized" vagrant.
These are defined in two places, but are nested. Might not sense, but thoughts that it will
help potential playbook -> role conversion. -
Use a template to create the mappings and yaml.
- Finally, the Select variable, will be the conditional selection criteria for what keys are parsed
by the Vagrantfile when conducting actions that generate or interact with vms.
```yaml
---
# Default VM Selection
vm_selection: "Centos7"
# Name, box_name.box, cpus, memory, driver
VARS_VAGRANT_SYSTEM_SETTINGS:
- ["centos7","centos7.box","2","2048","default_driver",]
- ["rocky8","rocky8.box","2","2048","default_driver",]
#- ["test3","base_box","cpu","memory","default_driver",]
```
The outputted file and further development thoughts exist at the link above.
Though this is a PoC, and there would need to be extension of functionality.
It should be pretty simple to implement with a few conditional tasks.
Also, expansion for quick dev environments could be optimized by including flavor based inputs, similiar to the AMI flavors listed.
Multiple options exist. As this PoC is using the AWX workflow to execute; will default to utilize
protected credentials on the AWX Controller.
AWX Documentation / Ansible Tower Official Docs.
Cheatsheets:
-
With the custom vagrant module: vagrant destroy needs an additional param, to account for confirmation. - Simple vagrant commands
-
Attempt change via encrypted awx and
vagrant ssh -c "echo {{pass}} | passwd root --stdin
Need to see if this will cause log entry, or if needing to export to an env Var and reference the env var within the task.- Similiar to sourcing a clouds.yaml or clouds.rc file.