IBM Cloud Automation Manager, a primer.

Published in

IBM Cloud

13 min readAug 28, 2018

The development community is adopting containers at a remarkably breakneck pace. Organizations are looking to containerize their workloads for different reasons. Whether it’s the packaging advantage of containers, their smaller size (compared to VMs), or their ‘build once, run anywhere’ attribute, the main motivation that is commonly shared across individuals and organizations alike — the agility and ephemeral nature of containers.

But with all of their benefits, enterprises consider containers to be bleeding edge, and are cautiously (and curiously) accepting the reality that the world is adopting hybrid architectures composed of containers and VMs that work side-by-side in multi-cloud platforms. This “new world order” of containers + VMs isn’t without its challenges and complexities when dealing with operations and workload management.

To this intention, and while it is industry-wide agreed that VMs (and infrastructure in general) are here to stay for the foreseeable future, this made some very smart people think of ways to bring some qualities of the container world to VMs. Welcome to the exciting world of Infrastructure as Code (IaC).

In this article, I introduce IBM Cloud Automation Manager, an enterprise-ready Infrastructure as Code (IaC) platform that provides a single pane of glass to provision VM-based alongside Kubernetes-based workloads by simply using templates (text files).

IBM Cloud Automation Manager

IBM Cloud Automation Manager (or CAM for short) was released late 2017 alongside IBM Cloud Private, IBM’s enterprise-grade Kubernetes platform. Simply put, CAM is an enterprise-ready Infrastructure as Code (IaC) manager that allows you to:

Automate the provisioning of workloads, whether virtual machines and/or containers and their infrastructure pre-requisites.
Compose and orchestrate services made out of both VMs and containers.
Integrate multiple Infrastructure as Code and Configuration Manager solutions.
Provision workloads on multiple clouds (whether public or private).
Integrate with DevOps toolchains.
Integrate with day-2 ITSM solutions.

As seen in the diagram above, IBM Cloud Automation Manager has 3 main user-visible components:

Terraform, which handles the provisioning of cloud and infrastructure resources using providers such as VMware vSphere, Microsoft Azure, IBM Cloud Platform, Amazon Web Services, Google Cloud Platform and even OpenStack.
Chef, which does configuration management and compliance automation. Chef normally takes over the provisioning after Terraform to start deployment and configuration of middleware and applications.
Service Composer, which is where administrators can author, compose and design services that are made out of not only multiple VMs, but also Kubernetes resources by invoking Helm charts.

Take this scenario for example: A common practice is to have front-end apps deployed on containers and databases (or legacy middleware) deployed on VMs, and to take things up a notch, containers might be living on a public cloud while databases might reside behind an enterprise firewall.

Service Composer helps organizations create hybrid workloads of containers, public cloud resources, and on-premise VMs with the click of a button. This simplicity comes in handy at the end of the DevOps toolchain, when environments need to be deployed on demand for Dev, Test, QA and then Production.

In simple terms, with IBM Cloud Automation Manager, administrators and developers alike are able to define where and how target environments should look like, author declarative code, save and then version to Git. And because environments are written as declarative templates, they can be re-produced and re-deployed over and over.

What does it solve?

Well, many things. First of all, administrators can automate most (if not all) of the processes that come with provisioning environments, avoiding manual processes that are tedious and error prone.

With CAM and Terraform, administrators have to simply declare how they want the environment to look, launch the provisioning, and forget all about it. Terraform will figure out how to deploy.

See the following image, which displays a typical deployment procedure:

Imagine having an application made out of 10 VMs and then having to repeat these steps for each and every environment in a typical enterprise scenario: Dev, QA, UAT, Production and DR, that’s roughly a total of 50 VMs…

CAM’s automation reduces provisioning time from weeks to hours (dare I say minutes?).

Second, it solves the issue of configuration drifts. Gone are the days when applications don’t behave uniformly when the environments they sit on are supposedly identical. Configuration drifts happen when somebody, somewhere messed up and never reflected the config change to rest of the environments. This happens quite often in a typical Dev, QA, UAT, Production and DR deployment scenario.

And because Terraform templates are text files that are stored in Git, it simplifies integration into existing DevOps tools (such as Jenkins) to help automate the dev-test-prod promotion alongside the application.

Third, just like application code, infrastructure should be versioned. Infrastructure encompasses everything in a software-defined environment, so in the example of VMware we’re talking, amongst other things, Storage I/O Control, Admission Control, vSwitch config, Port Groups, HA Affinity rules, OS customizations (think sysprep), core count, and also sometimes the type of CPU the VM is emulating to enable and disable processor features.

Infrastructure doesn’t stop there, it also includes /etc/hosts files, IP configuration, DNS entries, iptables rules, apt-get/yum repos and then, perhaps, middleware configuration might also be part of the responsibility of the infrastructure team, depending on the organization structure.

Tracking and versioning all aspects of an environment while consolidating VM and container artifacts allow configurations to be branched, forked, rolled-back and then promoted from Dev, QA, UAT, and then Production alongside every other element in an app development delivery process.

Fourth, Infrastructure as Code allows Ops to rebuild instead of fixing when things go wrong. It has been proven time and again that rebuilding an entire environment and then rolling back to a known working version will save time and effort helping achieving SLOs and SLAs.

Finally, it saves on disk space. Currently, organizations rely on VM templates, VM snapshots and a spaghetti of VM clones to quickly provision environments. This is an operational nightmare and wastes disk space, which incidentally opened the doors for storage appliance companies to introduce expensive deduplication technologies.

Infrastructure as Code allows for replacing clones of VM images with text files that store descriptive declarative statement that reflect configurations and end targets.

IBM Cloud Automation Manager Concepts

Before digging into CAM, there are some concepts that need to be explained.

IBM Cloud Private: IBM Cloud Automation Manager is a Dockerized application that runs on top of IBM Cloud Private, the documentation on how to deploy it can be found here. Although available on DockerHub, CAM is tightly integrated with IBM Cloud Private as its Kubernetes platform for authorization, RBAC and others functions.

Git: Although Git isn’t bundled as part of CAM, it is highly recommended that all the templates and content libraries that are created are stored and versioned on a Git repo. This is also a pre-requisites for air-gapped environments that can’t reach github.com where IBM stores its sample templates.

Terraform: By default, IBM Cloud Automation Manager only manages Terraform. Terraform is the module within CAM that talks to and provisions infrastructure. CAM comes with a bunch of Terraform Providers pre-packaged such as: IBM Cloud, AWS, Azure, GCP and OpenStack and the list is growing. Bringing-Your-Own-Provider (BYOP) can be done by following this link. Terraform has dozens of providers for different types of clouds and infrastructure which can be found here.

Chef: Chef is a configuration management tool responsible to deploy and configure simple and complex software from templates (also called cookbooks). There are cookbooks for thousands applications from major software vendors available from http://supermarket.chef.io.

Note: Terraform and Chef overlap in some situations, IBM Cloud Automation Manager takes care of segregating responsibilities, where Terraform will mostly do infrastructure and Chef will mostly do configuration and software deployment.

CAM Content Provider (or CAMC Provider): After Terraform completes the provisioning of the VM and if a Chef template is chosen as part of the deployment, CAM engage the CAMC Provider. The CAMC Provider is nothing more than an gateway to a Chef server that takes care of configuration management, middleware and application deployment.

There are few things to note here:

The CAMC Provider isn’t installed as part of the CAM installation by default, it’s an optional step that should be executed within CAM. This basically installs a Chef Server on a separate VM.
The standard Chef that comes with CAMC is pre-populated with some Chef cookbooks also referred to as ‘Pre-Built Content’ covering mostly IBM Oracle and LAMP cookbooks. It is however, the responsibility of administrators to populate other cookbooks from the thousands of cookbooks available on Chef Supermarket onto the Chef server and this can be done with Chef’s client: knife. Follow this link to understand how to properly manage Chef.
Although CAM will deploy Chef by default, organizations can choose another configuration manager such as Ansible, Puppet or even their own existing Chef servers. What’s powerful here is that within CAM, organizations can deploy multiple CAMC Providers and multiple configuration managers. For a tutorial on deploying Ansible instead of or alongside Chef, follow this link.

Helm: Helm charts are to Kubernetes what Terraform templates are to VMs. They also are a type of Infrastructure as Code that allow authoring of Kubernetes resources such as deployments, services, replica sets, stateful sets, volumes, ingress rules etc… With Helm charts, developers can package container information and Kubernetes resources as templates, version them and deploy them on-demand, while avoiding the tedious tasks of managing the Kubernetes aspect of things.

Software Repository: This is where software binaries will be residing. Normally this should be an NFS share that has ample capacity to store large binaries such as IBM WebSphere, Oracle, Apache, MySQL and other software. This is important for packages that are not publicly accessible, not available on a public repo such as via apt-get/yum or if CAM is residing in an air-gapped environment (with no internet connectivity).

Administrators should populate the Software Repository with binaries based on a directory structure, to do that, follow the link here. For IBM specific software, I highly recommend using PUCL to prepare the software repo, follow this link.

Following is a diagram that describes how CAM, Terraform and Chef come together.

Templates Library: A template is nothing more than a Terraform template that declares a VM (or other cloud resources) based on some specifications. All information about the VM such as CPU, disk size, cloud provider is defined there. The Template Library lists all the available templates that are available for provisioning. This is where administrators will spend time creating, authoring and editing Terraform templates.

Service Library: A service is a collection of templates executed as one process. IBM Cloud Automation Manager can chain the provisioning and creation of CAM Templates and ICP Helm charts while providing the possibility to pre-set variables and composable execution plans. At the time of writing (CAM 2.1.0.3), provisioning of templates within a service is sequential, however optional parallelism is on the roadmap. What’s more is that within the Service Library, the output parameters from one template can be used as an input to another.

Service Library is where administrators will spend time creating, authoring, editing and then publishing CAM services to the Service Library.

Service Composer: Within the Service Library resides the Service Composer. This is CAM’s management console that allows authoring of CAM Services. After the creation of CAM templates (Terraform), administrators can head to the Service Composition section of the Service Library to drag and drop the created CAM templates and/or Kubernetes Helm charts (from IBM Cloud Private) based on a decided sequence and/or decision. Service Composition can also call REST APIs for third party integration and send emails.

Decision: A Decision is simply a prompt that a CAM user will face during the provisioning of a service. For example, the service could prompt the user for the size of the VM or whether the workload should be deployed on a Dev or Production environment. During the creation of the service, administrators can choose different CAM templates for each environment. Alternatively, administrators could potentially use Docker versions of certain software for Dev and Test, but then deploy VM based versions for Production.

A REST hook is a powerful tool that allows CAM to tell something to do something. For example, using REST hooks, CAM can plug-in onto an IPAM to request and fetch IP addresses that can be used as parameters (more on that later). REST hooks could also register the newly created service or template to a Change Management Database (CMDB).

Parameters and Shared Parameters: One of the powerful features of CAM are Parameters and Shared Parameters.

Parameters are data that can be fed onto CAM templates. Things like CPU cores, RAM size, OS could be parameterized and not hard coded within the CAM templates. This is important as it brings modularity and flexibility. CAM templates authors could also choose to prompt users for these parameters or pre-set them during the creation of the templates. One good example of parameters are OS passwords and private ssh keys, no one wants to see those hard coded in templates.

The image above depicts how Terraform consumes parameters so they are not hard coded onto the CAM templates.

For example, $(var.folder), $(var.name), $(var.cpu), and $(var.ipv4_prefix_length) are parameters that can be prompted and populated during VM creation or centrally stored within CAM for modularity and do-it-once purposes.

Parameters are bound to single templates. So what happens when CAM templates need to share certain parameters? Enter Shared Parameters. Shared Parameters allow administrators to parameterize certain data that repeat amongst CAM templates. For example, in an Azure, IBM Cloud or AWS scenario, CAM templates might require the name/ID of the cloud region, which normally don’t change often. Cloud regions such as: us-east-1, eu-central-1, eu-west-1 could be shared parameters and used across multiple templates.

Another example of Shared Parameters usage in VMware Clusters: Imagine having multiple VMware Clusters within an organization and each clusters have different preset settings such as port groups, datastores, or IP gateways. Shared parameters bring sanity and organization to deployments.

Parameters and Shared Parameters are even more powerful when combined with Decisions as each decision could point to different parameters and shared parameters.

The concept of Shared Parameters promotes role separation, a cloud admin can be in charge of managing these and choose what parameters should be preset and which can be fiddled or selected by the cloud user/consumer.

Spend some time watching this video titled, IBM Cloud Private to deploy IBM Cloud Kubernetes Service Clusters, which shows how almost all the features I covered in this article come together.

A day in the life

We’ve covered the basics of IBM Cloud Automation Manager and explained the different moving parts that make up CAM. Below is a brief description of what CAM administrators will face day in day out managing CAM.

A day in the life of a CAM Administrator

Normally, CAM administrators need to worry about the following:

IBM Cloud Private and IBM Cloud Automation Manager alignment (namespaces, persistent volumes, node selectors, NFS shares, LDAP and RBAC etc..).
Cloud providers, whether these are VMware vSphere clusters, OpenStack environments or public clouds such as AWS, Azure, GCP, IBM Cloud or even Bring-Your-Own-Provider.
Centralized repository on Git to store, manage, fork and version Terraform and Chef templates.
Content publishing, which involves managing, building and then publishing CAM content. CAM content are simply CAM templates (Terraform or Terraform+Chef).
Service publishing of CAM templates or CAM templates+IBM Cloud Private Helm charts by composing services that consume parameters, request decisions, prompt users for information and integrate with 3rd party tools and platform using REST hooks.
In the case of private clouds (VMware and OpenStack) Preparation of OS templates. CAM administrators should be responsible for building and maintaining OS templates that will be used during provisioning of workloads. For example, in the case of Linux, configuration of cloud-init, Logical Volume Manager, apt-get/yum repos etc.. for Windows, things like sysprep, Windows Updates, Windows Features and Active Directory should be accommodated for and thought through.
In the case of private clouds (VMware and OpenStack) Preparation of Networking and IP subnets. CAM administrators should have worked out a list of valid IP subnets, vSwitches, port groups, floating IPs, DNS and gateways that can be used in CAM.
In the case of private clouds (VMware and OpenStack) Preparation of Storage. CAM administrators should know about storage tiers and datastores available for VMs.

A day in the life of a CAM User/Consumer

CAM users will eventually consume the templates and services built by CAM Administrators, this means:

CAM users will be greeted with a template library and a service library where they can browse versions of templates and services already provisioned for them by the CAM administrators.
Template libraries are where users will execute distinct provisioning.
Service libraries are where users will execute services made out of multiple templates.
CAM users will also be able to manage the workloads that they have provisioned. Examples of such actions are (Start, Stop, Pause, Destroy, Delete resources).
If the CAM user is a developer or part of the DevOps team, then such executions of templates and services can be easily integrated to their DevOps tool chain. By using the CAM API, developers can call the provisioning of templates and services from within Jenkins or any other deployment tool.

Conclusion

Of course, there are far more features that I haven’t covered such as the ability to integrate CAM workloads with IBM Cloud Private’s ELK, as seen here, how to use CAM’s template designer to author Terraform templates without learning Terraform syntax as seen here or even how to use CAM’s API to call the service composer from a third party orchestration tool as seen here.

In conclusion, IBM Cloud Automation Manager is meant for infrastructure departments who crave the agility and speed experienced when using Docker and Kubernetes (such as with IBM Cloud Private) and want to bring these capabilities to infrastructure and VMs.

For more information please consult the following links: