Provisioning Overview

This section describes the concept and advantages of using provisioning.

Use Case

John Smith is head of development at an important bank. The bank's IT personnel consists of several dev and QA teams that build and test different parts of the online banking application and use different combinations of virtualization providers. His teams must constantly create new Environments for short, medium and long term use on the bank's Environment.

The Dev and QA teams work with heterogeneous providers and have tons of procedures, which are hard to maintain and have to be built ad hoc. In the near future new providers will be supported, which means more work on building new provisioning workflows.

John urgently needs a state-of-the-art solution to containerize the application infrastructure and components. His wish list includes the following:

• I want to use standardized images.
• I do not want to waste money: resources only have to be available when there is a real need for them. I want to tear down deployment targets & Environments after each successful deployment.
• I want to keep track of what is going on during the release. Release artifacts and processes should always be visible, not hidden in containers.
• I do not want to be forced into a choice: I want an agnostic solution that allows my team to work both in hybrid and traditional Environments.

  

• I want to define the application architecture only once. After setting up the infrastructure I want containers to be automatically promoted along the pipeline and finally get rid of the tedious task of releasing artifacts!
• I want to standardize the service infrastructure. All team members should work on identical Environments.

John is not a risk-taker. He is well aware of the importance of performing a gradual implementation of the new DevOps practices to always have control over the process and reduce risks. A key component of this approach is the transition of the current architecture towards microservices. He also knows change is unavoidable and will greatly reduce workload. His teams simply want to write and test code, not to worry about systems, and his superior is very concerned about Environment costs and sees this approach as a way of optimizing expenses. John decides to stay on the safe side and designs a two-stage implementation plan: first he wants to focus on the application infrastructure and then on the containerization of components:

Provisioning process of the Application Infrastructure: ramp-up and teardown

Provisioning process of the Component Containerization:

Luckily, over the past years his company has been using CDA to automate application releases. As of CDA v12, his teams no longer have to depend on manually writing and maintaining different provisioning workflows for different providers. CDA is capable of separating the provisioning logic and have a truly independent application deployment infrastructure for workflows. CDA does not replace the existing tools, but helps to orchestrate them, which is more reliable, agile and saves time.

To do so, CDA provisions the required application ready infrastructure as part of the Environment creation process. Users can also add rules and the period of time they need the Environment to remain available.

This is what John had to do before to create a new Environment:

With CDA, John's life has changed for good:

CDA allows to provide connection and configuration details to Stack Providers (for example, VMware, Docker) through an intuitive interface that maps images from public or private repositories to a deployment target type.

Main Concepts

To use this functionality, simply add one or more Stack Providers, create a Stack Template and then define the Blueprint which is going to be used to provision the Environment. When executing the provisioning workflow, CDA will notice that one or more deployment targets are on a certain Stack Provider and some definitions, like attributes, will be automatically defined.

What is a Stack Template?

A Stack Template is a description of the physical image. A Stack Template maps the images of the external provisioning tools to CDA deployment target custom types. For example, a Tomcat Docker image can be mapped to a deployment target custom type "Tomcat".

What are Stack Providers?

Stack providers are the "engine" or "technology" which allows to create Stacks based on Stack Templates. They provide the infrastructure and middleware on which the components will run: that is; Stack Providers host the image. On top of this engine there is an Application, which can be rolled out using CDA.

What is a Blueprint?

A Blueprint is the prescription for the creation of a CDA Environment (which, in turn, contains multiple CDA Deployment Targets). A Blueprint consists of a Stack Template and the corresponding Deployment Target types needed to provision the Environment.

What is a Stack?

A Stack is the group of services that make up an Application deployed to an Environment. A Stack is a physically running instance of a Blueprint. Depending on the virtualization or cloud provider, a Stack can be mapped to a container or a virtual machine instance of the Stack Template.

A Stack contains all infrastructure/platform layers with the exception of the CDA Applications deployed and is provisioned by third-party tools like Docker or VMware vSphere.

Stacks are very useful to deploy multiple services at once without needing to define them one by one.

Recommended Design Sequence

1. Install the Provisioning Provider Packs
2. Meet the system requirements.
3. Add a Stack Provider
4. Create a Stack Template based on the Stack Provider you have defined.
5. Create a Blueprint.
6. Provision an Environment: Provisioning Environments.