Cross-Functional Architecture And Tools For Cloud-Based Operating Models
Several different mechanisms are available for integrating configuration management tools like Ansible, Chef, and Puppet with the Agile Cloud Manager.
The method that you choose will depend on which configuration management tool your organization uses and on what your workflows end up looking like.
Each configuration management tool has its own form of detailed scripts with names like PlayBooks or CookBooks. Therefore, you must design a way of inserting the configuration management scripts through one or more of the various points of integration offered by the Agile Cloud Manager.
Some of the points of integration include:
With Ansible, most of the configuration is pulled into each compute instance.
Therefore, for example, you might have a cloud-init script for each compute instance download and install Ansible, and then download and run a collection of PlayBooks to provision the compute image more completely than might otherwise be possible using the limited length of cloud-init scripts.
You can specify the location of the cloud-init script in either of the following two possible locations within an Agile Cloud Manager system template:
Also, with Ansible, you might optionally consider using the Agile Cloud Manager’s Postprocessor scripts to signal remotely hosted tools such as Ansible Tower to complete additional work before the Agile Cloud Manager’s workflow continues.
With Chef or Puppet, by contrast, most of the configuration is pushed from a remote service into each instance.
Therefore, with Chef or Puppet, you might rely more on the Agile Cloud Manager’s Preprocessors and Postprocessors in addition to possibly relying on pipeline code that runs before or after a given Agile Cloud Manager CLI command within a pipeline workflow.
Preprocessors, Postprocessors, and pipeline code can send signals to remotely hosted Chef or Puppet servers with information that results in those remote servers performing operations on specific compute instances.
The lifecycle of each piece of infrastructure must also be considered.
We recommend replacing existing instances with new instances instead of patching existing instances.
By replacing, you make it possible to disable remote login to each instance before each instance is moved into live service in production. Disabling remote login permanently for each instance improves security.
For example, cloud-init might run Ansible during instantiation and then disable remote login as the final step of instantiation.
Or with Chef or Puppet, a Postprocessor or a pipeline command might trigger Chef or Puppet to place the new AutoScaling Group or Kubernetes cluster under the management of a remote Chef or Puppet server as soon as the AutoScaling Group or Kubernetes cluster has been created.
And then Chef or Puppet can be responsible for the AutoScaling Group or Kubernetes cluster’s configuration until a different Agile Cloud Manager CLI command might later destroy the entire AutoScaling Group or Kubernetes cluster.