This document gives an overview of the process of writing either a new config from scratch or copying and modifying an existing config. Well designed configs, can easily and cleanly be abstracted to allow deployment to multiple different Public and Private Clouds including AWS, Azure.
A config is simply a lab, workshop, or other deployment that has been defined and encapsulated in a series of playbooks, variable files, and templates in a config directory. This allows Ansible Agnostic Deployer to deploy it simply and repeatedly on one or more Cloud Platforms.
configs are typically deployed via one of 3 methods:
-
From the command line. A suitably configured Ansible Control Node, or laptop, can invoke a new config deployment by invoking
ansible-playbook main.yml -e @./configs/<CONFIG_NAME?sample_vars.ymlor other variable file with the appropriate parameters. See Three Tier App for an example. -
Via a front-end application such as Red Hat Cloud Forms or ServiceNow which provides a user friendly catalog or "portal" type interface to the end user and can invoke the appropriate ansible command directly or via a "wrapper" script.
-
It is also possible to invoke a config by creating AgnosticD as an Ansible Tower Project and defining configs as jobs. Going forward this pattern will influence the future evolution of AgnosticD. Once a config is defined as a job it can either be directly invoked or via a front-end application or script making an API call to an Ansible Tower server.
AgnosticD deploys configs via a 6 stage process, discussed in more detail below. This provides config creators considerable flexibility, without undue complexity, to control the deployment process in a modular manner and enables you to abstract the Cloud Specific steps (e.g. AWS ec2 or Microsoft Azure) from the application or OS specific steps. Greatly enhancing Cloud Portability.
The last point is key, as it allows developers to simply add new Cloud Platforms at a latter date, or provide their configs with multi-cloud support from day 1. The term Cloud Provider includes the ability to add a virtualization platform (e.g. KVM, Hyper-V), Public Cloud Platform (e.g. Google Cloud Engine), or a container based platform such as OpenShift or Docker.
Currently supported platforms (via Cloud Providers):
-
AWS EC2
-
Azure
Configs are located in the ansible/configs/ directory:
README.adoc linklight ocp-ha-disconnected-lab quay-enterprise
ans-tower-lab linklight-demo ocp-ha-lab rhte-ansible-net
ansible-cicd-lab linklight-engine ocp-implementation-lab rhte-lb
ansible-provisioner linklight-foundations ocp-multi-cloud-example rhte-oc-cluster-vms
archive linklight-networking ocp-storage-cns rhte-ocp-workshop
bu-workshop linklight-networking-all ocp-workloads simple-multi-cloud
just-a-bunch-of-nodes ocp-clientvm ocp-workshop three-tier-app
lightbulb ocp-gpu-single-node openshift-demosAbove configs subject to change over time
A typical Config is well illustrated by Three Tier App.
three-tier-app
├── README.adoc # Config specific README
├── destroy_env.yml # Teardown playbook to remove the config when finished
├── env_vars.yml # Default vars containing configuration variables
├── files # Sub-directory for templates, cloud provider files etc
├── pre_infra.yml # Stage 0 Playbook
├── post_infra.yml # Stage 2 Playbook
├── pre_software.yml # Stage 3 Playbook
├── software.yml # Stage 4 Playbook
├── post_software.yml # Stage 5 Playbook
├── sample_vars.yml # Sample user supplied vars (cloud provider, ids etc)
└── topology.png # Optional topology diagram
secret.yml normally lives in your home direcotry - anywhere outside of the
AgnosticD repository itself. They should never be committed to Git!
Example secret files include;
osp_auth_username: alice osp_auth_password: toomanysecrets ...
You can see that these are sensitive credentials.
When running AgnosticD, it’s normal to "pass in" your secrets like this;
user@host: ansible-playbook main.yml -e@~/secret.yml -e@configs/...
When ansible starts to deploy a config the process involves 2 logically distinct phases, Infrastructure and Software, each broken up into 3 Steps. This is illustrated below:
AAD deployments start by invoking a common main.yml with an environmental
variable file identifying the cloud platform to deploy plus other meta-data.
e.g. ansible-playbook main.yml -e @configs/three-tier-app/sample_vars.yml
main.yml- import_playbook: "configs/{{ env_type }}/pre_infra.yml"
- import_playbook: "cloud_providers/{{ cloud_provider }}_infrastructure_deployment.yml"
- import_playbook: "configs/{{ env_type }}/post_infra.yml"
- import_playbook: "configs/{{ env_type }}/pre_software.yml"
- import_playbook: "configs/{{ env_type }}/software.yml"
- import_playbook: "configs/{{ env_type }}/post_software.yml"For config developers the above stages provide 5 hooks for customizing the configuration of your environment and 1 hook for customizing it for one or more cloud providers (e.g. AWS, Azure, etc).
An example config is provided by ansible/configs/just-a-bunch-of-nodes
In this stage AAD is the entry playbook and is typical used for setting up any infrastructure etc prior to launching a cloud deployment. Typical tasks could include:
-
Creating necessary ssh keys
-
Moving any ssh keys into place, setting permissions etc
-
Creating any payloads to be used in later stages e.g. repo files etc
-
Ensuring cloud credentials are available
This stage is unique in the flow in that the config creator doesn’t supply a playbook but typically has to provide cloud specific configuration data.
Clouds are selected via the value of the cloud_provider variable and supported
clouds can be found in ansible/cloud_providers. Currently supported are:
-
Amazon Web Services (AWS)
-
Microsoft Azure
Example: AWS configs use CloudFormations templates to deploy their
infrastructure so this can be provided. Take a look at Three Tier Apps
Cloud Formation Template.
Notice it is written in Jinja2 and can easily be extended to deploy more, or
less servers, plus you can change the Operating Systems, software payloads
etc. This is done by overriding the default variables found in
env_vars.yml.
|
Note
|
A Cloud Creators document exists to facilitate adding further clouds to AAD. Wish list items include:
|
In this stage AgnosticD can execute any "post infrastructure" tasks. It is not uncommon for this phase to do nothing but it provides a convenient hook for any tasks that may need to be run after building your Cloud Infrastructure. For example running any smoke tests that may be required.
At this point the infrastructure should be up and running but typically in a un-configured state. This stage provides a convenient hook for running any tasks that may be needed before software payload deployment. For example"
-
Running any pre software tests
-
Setup software dependant yum repos or equivalent
-
Retrieving any licenses etc.
-
sshkey housekeeping - for example inserting additional keys and configuration -
Prepare
bastionhosts orjumpboxes
In this stage AgnosticD deploys any software payloads onto the infrastructure. This could be as simple as installing Apache or as complex as installing and configuring an N-tier application.