Introduction to AgnosticD - a Cloud Agnostic Ansible Deployer

AgnosticD allows users to deploy various types of infrastructure to major cloud platforms and by design to be extensible in both the cloud platforms it supports and they type of infrastructure it deploys. Extensively used daily within Red Hat example use cases include:

Over the coming weeks we’ll dive into how AgnosticD works and how it can be extended both in what it deploys (configs and workloads) and what it can deploy to via cloud providers. And don’t be mislead by the term cloud provider, this could also be a Virtualization Platform such as kvm or Hyper-V or a Container platform. In fact AgnosticD has excellent support for OpenShift.

In Part 3 we’ll examine in more depth how AgnosticD works under the covers but just to get started AgnosticD can be considered a 2 phase deployer (infrastructure and software), with each phase being further sub-divided into 3 stages:

With each stage being mapped onto either a config specific playbook, or in the case of cloud provider a cloud provider implementation being executed in sequence.

The associated playbooks for each configuration are encapsulated in configs which we’ll explore in more depth in Part 4: How "Configs" work and how to write one. A well written config can support both a basic un-configured deployment i.e. just the base instances themselves through to a full blow deployment including software fully configured and ready to run e.g ansible-tower.

It’s worth highlighting that a single config can be deployed in many completely different configurations by varying the var files passed to it. For example the previously mentioned ansible-tower can be deployed with different projects, job-templates, and other resources or indeed be deployed in both test and prod stages just by varying the input vars.

Most users will not have to write code but instead write desired configuration and re-use existing configs.

Now continue to Part 2 Getting Started with AgnosticD