It is possible to run agnosticd with containers. This way you just need a container runtime, usually podman for Linux and Docker for mac. The tools/execution_environments directory contains builds scripts for our supported Execution Environment (EE).

Please see the OpenStack tutorial.

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:

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):

See setup_runtime playbook:

Sample user supplied vars.

Default vars containing configuration variables.

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;

You can see that these are sensitive credentials.

When running AgnosticD, it’s normal to "pass in" your secrets like this;

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:

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:

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.

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"

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.

In the final stage AgnosticD would typically perform a number of tasks including:

The private key and SSH config are stored in output_dir. In order to access the instances after provision you need access to output_dir. If you’re developping from your laptop, that should be transparent since output_dir will be persistent across calls of ansible-playbook.

On the other hand, when you’re provisioning from Tower or Controller (or from RHPDS), you need output_dir to be persistent across jobs and that is done by the 2 following roles:

Make sure the secrets and variables are set so those roles are executed:

Roles:

Variables:

An OpenShift Workload is simply a workload that is applied to an existing, running, OpenShift cluster. For example if you wish to deploy 3Scale, Prometheus, or a MicroService application you can define it as a Workload then simply and consistently deploy it with a single command to your OpenShift cluster.

This document assumes more than a passing familiarity with OpenShift but if you just want to "copy and hack" an existing Workload take a look at the OpenShift 3Scale workload.

Other OpenShift Workloads here. OpenShift Workloads all begin ocp-workload- and follow the traditional structure of an Ansible Role.

In this document we will explain how one could setup their laptop for AgnosticD deployment with OpenStack.

If you are a Red Hatter, you can use rhpds.redhat.com to request access to our OpenStack cluster:

To return a message to show to the lab provisioner, set msg. For example:

To set messages on several lines then call agnosticd_user_info with loop. Multiline messages cannot be passed as a text block with embedded linebreaks due to how these messages are processed by current automation.

Blank lines may be included in your message output by sending an empty message string.

User info messages are meant to be delivered by automation to users of the provisioned environments. A body may be specified in the same way as msg to override a standard message. Content for body should precede other messages if provided.

Messages sent this way will be saved to user-info.yaml in the output directory, set by output_dir.

To set data to be consumed by other automation, such as the Babylon Events UI/Bookbag, set data when calling agnosticd_user_info.

Data values are saved as a dictionary to user-data.yaml in the output directory.

To use this data through bookbag Asciidoc deployed by the Babylon Events UI we recommend setting AsciiDoc macros:

When provisioning a multi-user environment with AgnosticD you will want to deliver separate messages to each user. For example, a secure unique password for each user, a separate OpenShift namespace per user, etc.

User messages and data are set similarly to environment messages and data, but adding a user argument to agnosticd_user_info:

Messages set with msg may be multi-line when combined with user. This makes it easier to loop over a range of users. If msg is called repeatedly for the same user then messages will be joined with a newline character.

User data dictionary values are combined with any values previously set for the same user. If the same key is set twice for a user then the previous value is replaced. Environment data, set by calls to agnosticd_user_info without user will not be exposed to users.

All user data and messages is collected in user-data.yaml with user data stored as a dictionary under the key "users".

Please follow the Git Style Guide.

Note: during the review process, you may add new commits to address review comments or change existing commits. However, before getting your PR merged, please squash commits to a minimum set of meaningful commits. This can be done directly in the github web UI.

If you’ve broken your work up into a set of sequential changes and each commit pass the tests on their own then that’s fine. If you’ve got commits fixing typos or other problems introduced by previous commits in the same PR, then those should be squashed before merging.