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 cleanely 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 three methods:
-
From the command line. A suitably configured, see the xyz guide, Ansible Control Node, Server, or laptop can invoke a new config deployment by invoking
ansible-playbook main.ymlwith the appropriate parameters. This is illustrtaed below. -
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 invokes Ansible Agnostic Deployer automatically.
-
Via front-end application or script which makes an API call to a suitably configured Ansible Tower server with appropriate Ansible Agnostioc Deployer Project(s) and a Job Template for the _config.::
Ansible Agnostic Deployer, from now on referred to as AAD, deploys configs via a 6 stage process, discussed in more detail below. This provides config creators considerable flexibility, without complexity, to control the deployment process and more importantly to abstract the higher level software and configuration stages from the Provider centric Cloud Deployment stage.
This is key, as it allows developers to simply add a new cloud deployment template (discussed below) at any point, expanding the number of target clouds or virtualization environments that their config can be deployed to. As new Cloud Providers are added then configs can, relatively, easily be extended to be deployed on the new platform.
<<<< CURRENT EDITING POINT >>>>
The repository contains various Ansible playbooks, templates, and other support files used to provision different software (OpenShift, Ansible Tower, …) onto Cloud Infrastructure (AWS, Ravello, …). The key files and directories include:
-
./docs/Start here -
./ansibleThe execution environment -
./ansible/main.ymlThe entry point for a deployment -
./ansible/configsHome to the configs to deploy
The Contributors Guides explore the relevant structures in significantly more detail:
AAD deployments start by invoking a common main.yml with environmental
variables identifying the config and the cloud platform to deploy plus other meta-data.
e.g. ansible-playbook main.yml -e "env_type=three-tier-app cloud_provider=aws"
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-some-nodes-example
In this stage AAD is the entry playbook and is typical used for setting up any infrastucture etc prior to launching a cloud deployemnt. Typical tasks would 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 avaialble
This stage is unique in the flow in that the config creator doesn’t supply a playbook but typically has to provide cloud specfic 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)
-
Microsfoft Azure
Example: AWS configs use CloudFormations templates to deploy their infrastructure so this can be provied
|
Note
|
A Cloud Creators document exists to faciliate adding further clouds to AAD. Wish list items include:
|
At this point the infrastucure should be up and running but typically in a totally unconfugured state.
Typical tasks:
-
Setup yum repos or equivilent
-
sshkey housekeeping - for example inserting additional keys and configuration -
Prepare
bastionhosts orjumpboxes
Documnetation: docs/Creating_congfigs
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-some-nodes-example ocp-clientvm ocp-workshop three-tier-app
lightbulb ocp-gpu-single-node openshift-demosAbove configs subject to change over time
A typical Config is
three-tier-app
├── README.adoc
├── destroy_env.yml
├── env_vars.yml
├── files
├── post_infra.yml
├── post_software.yml
├── pre_infra.yml
├── pre_software.yml
└── software.yml