CompTIA Cloud+ CV0-003 Exam: Automation and Orchestration Techniques

Objective: Given a scenario, apply proper automation and orchestration techniques.

As you continue your journey into learning about the cloud, you will discover that the process of automation is often critical to the success of any organization that uses cloud resources. In fact, automation is often one of the main reasons that organizations choose to migrate to the cloud. Automation enables tasks and processes to occur without the need of any human interaction. Automation speeds up the provisioning of instances, prevents human input errors, and reduces the cost of deploying a solution or product.
In this guide you will learn about some key automation topics, including Infrastructure as Code (IaC), configuration management, and orchestration scripting. You will also explore continuous integration/continuous deployment (CI/CD) and secure scripting.

Topics:
- Infrastructure as Code (IaC)
- Continuous Integration/Continuous Deployment (CI/CD)
- Version Control
- Configuration Management
- Containers
- Automation Activities
- Secure Scripting
- Orchestration Sequencing

1. What are the two different approaches to IaC?
2. True or false: Continuous deployment is a process that extends continuous integration to deploy new releases as they are made available on the main branch.
3. In version control, what is the process of creating a new development branch called?
4. In configuration management, the _____ is the configuration file that is used to configure the instance.

Answers:
1. Declarative and imperative/procedural
2. True
3. Checkout
4. Playbook

Infrastructure as Code (IaC)
Imagine a scenario in which your manager tells you that you need to deploy some virtual machines (VMs) in your organization’s cloud infrastructure so that the organization’s developers have a testing platform for the code they are writing. Initially, the developers will need 100 virtual machines, all of which have similar components, but some components in each virtual machine need to be different (such as user accounts, passwords, software installation, and storage space size).
You are also informed that as the project progresses, the developers will need additional virtual machines, again all similar to one another but with a few customizations. You start to realize that just creating these virtual machines might become a full-time task. In addition to the time it will take to manually configure each virtual machine, you are concerned that you might make mistakes along the way, resulting in misconfigured systems that will cause headaches for the developers. Fortunately for you, there is a better solution.
Infrastructure as Code (IAC) is a process in which you can use configuration files or scripts to deploy and manage systems, including virtual machines and containers. Many public cloud vendors provide a native IaC solution. There are third-party IaC solutions as well.
There may be some confusion over the differences between Infrastructure as Code, configuration management, and orchestration. In fact, the lines that separate these three concepts are often blurred. Review the “Configuration Management” and “Orchestration Sequencing” sections in this guide for more details.

Infrastructure Components and Their Integration

There are generally two primary IaC approaches: declarative and imperative. For systems that use declarative IaC, the configuration file contains a collection of data that defines the components of a resource. For example, if you’re creating a declarative IaC configuration file for an AWS S3 bucket that is created by AWS Cloud Formation, values like the type of resource and bucket name would be defined like the following:
S3Bucket:
- Type: AWS::S3::Bucket

- Properties:
BucketName: mybucket

In an imperative approach you describe how the resource is to be created. For example, the AWS command-line interface (CLI) enables you to create code that defines a resource using the imperative approach, like the following example that defines an AWS S3 bucket:

$ BUCKET="mybucket"
$ if ! 'aws s3api list-buckets --query Buckets[*].Name |
grep $BUCKET > /dev/null'; then aws s3api create-bucket
--bucket $BUCKET; else echo "This bucket exists"; fi

In a nutshell, the preceding code defines a variable called BUCKET and sets the value of this variable to mybucket. Then it checks to see whether a bucket called mybucket already exists. If it does, an error message is displayed (“This bucket exists”). If the bucket doesn’t exist, it will be created.
For the CompTIA Cloud+ certification exam, don’t get too hung up on the specifics of the code. The important point to remember is that a declarative approach describes what resource to create without stating how to reach the end state, whereas the imperative approach describes how to create the resource with all steps to reach the end state.

Continuous Integration/Continuous Deployment (CI/CD)
Many software vendors utilize a traditional software release approach in which software is released at specific intervals. For example, an organization may have a yearly release cycle, so each year a new major release of the software occurs. During the year there might also be minor releases or bug fix releases, depending on potential flaws or security holes that are discovered in the software. The advantage of this method of releasing software is that normally the organization gets time to test the software before it is released, which should result in a more stable program/product. However, the disadvantage of this release method is that it can take up to a year before new features are released, which may allow competitors to capture more market share if their software is released more often.

Continuous integration (CI) and continuous deployment (CD) are two processes that, when combined, result in rapid and continuous release of software. The two terms are often confused, likely because the word continuous appears in both terms. The differences between the two are as follows:
- Continuous integration is a process followed by developers (typically software developers). A software program that uses a version control utility (see the “Version Control” section in this guide) employs a main branch of development that is used when the software is released to customers. Developers don’t work directly on the main branch, but rather on their own branch. When the continuous integration process is used, developers merge the changes in their branch back into the main branch as often as possible (not exactly continuously, but that is the goal), and the changes are validated through some automated testing process. This results in the main release branch being continuously validated and updated.
- Continuous deployment is a process that extends continuous integration to deploy new releases as they are made available on the main branch (after testing has occurred). A similar process, called continuous delivery, also is used to deploy new releases rapidly, but this process requires a human to approve the release.

Version Control
One of the biggest headaches that developers must deal with is different versions of source code. Sometimes you just need to “go back” to a previous version of code (or roll back to a previous stable release). Maintaining these versions manually can be cumbersome, error prone, and time-consuming.
Compounding the problem is that multiple programmers work together on a single piece of source code. A large program can have tens of thousands of lines of code with different programmers responsible for different portions of the code.
Version control software can handle the complicated task of maintaining different versions of source code. The most popular version control system used today is called Git. Git utilizes repositories to store the different versions of the files that the developers are generating. Typically, a “central” repository contains all of the changes that have been committed to the main project. Additionally, each developer has his or her own copy of this central repository stored locally on his or her own system.

Here are some key version control terms:
- Clone: To create a local repository from the central repository, a clone process is performed. This process results in all of the central repository being duplicated on the local system (including all branches).
- Branch: The main branch contains the most recent release version of the project. Each developer typically creates a separate branch, which is a duplicate of the main branch (or another branch) at the time the developer’s branch was created. Additional branches may be made for specific reasons, such as for bug fixes or the need to develop a new feature.
- Checkout: To create a new branch, a developer uses a process called a checkout. This process will create a new branch, using the name provided by the developer. Typically, this new branch is a copy of the main branch at the time the new branch was created, but branches can be made from any other branch.
- Merge: A merge is the process of combining changes made to a file in one branch with a different version of the same file in another branch. In some cases a merge may be performed automatically, but if there are complex differences between the two versions of the file, a human may need to manually perform the merge.
To understand configuration management, consider the topic of Infrastructure as Code. The purpose of IaC is to use computer-readable configuration files, in conjunction with an IaC tool, to deploy an instance, like a virtual machine or storage device.
Configuration management is a slightly different process in which existing instances are modified, often based on a computer-readable configuration file in conjunction with a configuration management tool. For example, configuration management may be used to create a user account, install software, or modify the network settings on a virtual machine.
Popular configuration management tools include Chef, Puppet, Ansible, and SaltStack. Most major cloud vendors also provide their own configuration management tools.
It is important to note that configuration management and IaC perform similar operations, and many tools will act as both an IaC and a configuration management tool.
There may be some confusion over the differences between Infrastructure as Code, configuration management, and orchestration. In fact, the lines that separate these three concepts are often blurred. Review the “Infrastructure as Code” and “Orchestration Sequencing” sections in this guide for more details.

Playbook
In configuration management, the playbook is the configuration file that is used to configure the cloud resource. As with IaC, some configuration management tools, like Chef and Ansible, employ a procedural playbook in which the playbook contains instructions on how to perform the tasks needed to configure the instance. Other configuration management tools, like Puppet and SaltStack, use a declarative style that describes the desired end result.

Automation Activities
Automation is the process of performing tasks to achieve a desired outcome without requiring any human intervention. In cloud computing, automation is a crucial part of a successful deployment because many tasks must take place in a timely fashion, which isn’t possible if they always need to be performed by a human.

You have already seen examples of automation in this guide:
- During the continuous integration of CI/CD, the testing process that occurs during the merge is automated.
- During the continuous deployment of CI/CD, deployment happens automatically without the need for a human to start the task.
This section will cover some additional automation activities that are typically found in a cloud infrastructure.

Routine Operations
Many different types of routine operations can be automated in the cloud. For example, you could automate the process of creating resources as needed, like storage devices. Or you could automate the collection of metric data and have this data sent to a software tool that will analyze the data. Other routine operations could include the following:
- Backing up data of a critical system
- Automating changes to firewall rules
- Sending notifications of updates or system changes to users or customers

Updates
Consider a situation in which you have dozens (or even hundreds) of Linux virtual machines in your cloud infrastructure. Each of those operating systems needs to have updates applied routinely. Using an automation process, you could push out updates to all of the operating systems without needing any human interaction.

Scaling
See “Auto-scaling” in “High Availability and Scaling in Cloud Environments.”

Shutdowns
Having compute devices, like virtual machines and containers, running results in an expense to the organization. If you are aware of compute devices that don’t need to be running during specific periods of time (like the weekends), you can automate the shutdown of these instances to save the organization money.

Restarts
There are sometimes reasons to restart a compute device. For example, if you install a new kernel on a Linux-based virtual machine, the operating system requires a reboot for the new kernel to take effect. If you have automated the process of updating your organization’s Linux virtual machines, you will likely want to also automate the restart process when the updates include a new version of the kernel.

Create Internal APIs
An application programming interface (API) is a method to allow two applications to communicate. A client application sends an API request across the network, and the server performs operations based on this client request. Many of the systems that you communicate with use APIs to perform tasks (even if you are not aware that APIs are being used).
APIs can be created automatically on the server side by using automation tools. This capability is important when new servers are created automatically, such as through a scaling process.

Secure Scripting
One of the challenges in working with automation is that you will often be creating scripts (programs) to perform automation, configuration, and orchestration tasks. These scripts may end up being standard language scripts, like Python, or scripts that are specific to a cloud vendor.
This section will focus on some of the security concerns that you must consider when writing automation scripts.

No Hardcoded Passwords
Although automation scripts don’t require humans to run, they will likely be executed by users who didn’t create the script for either testing purposes or in situations in which they want to manually start a process. For example, if you have an automation script that starts a virtual machine, users may want to use that script to create a virtual machine for their own purposes.
Typically, these users will need to be able to view the script to execute it. For this reason, the script should never contain any passwords. The script uses these passwords to gain elevated privileges (see the following “Use of Individual Service Accounts” section), and if a user is able to see the password, that user may be able to gain this elevated privilege manually and perform unauthorized actions.
Instead of hardcoding passwords, consider using a password vault or key-based authentication. See the following “Password Vaults” and “Key-Based Authentication” sections for more details.

Use of Individual Service Accounts
When the script is executed, it should take on a service account (or service role) to perform its actions. This service account would have privileges that a regular user, like the user running the script, doesn’t have.

Password Vaults
Because you don’t want to store passwords within scripts, an alternative called a password vault can be used instead. With a password vault, a cloud-based service stores passwords (and other secrets, like keys) and provides them as needed to scripts or other processes. The script can be configured to ask the password vault to provide the password to authenticate and perform the required actions.
Also see the “Secret Management” section here.

Key-Based Authentication
See the “Public Key Infrastructure (PKI)” section here.

Orchestration Sequencing
Recall that Infrastructure as Code is the process of using a configuration file to deploy an instance. This process works well if you want to deploy a single instance (or a collection of similar instances) that are unrelated to other instances, but what if you need to deploy an entire system of instances that are related to one another?
For example, suppose you need to deploy a virtual machine that runs software that generates data. This software is then sent to a database, and the results are accessible via a website. This means you need to deploy three instances: a virtual machine, a database server, and a web server. In fact, you may need to deploy these instances in a specific order for the entire system to work correctly.
This process of deploying instances that relate to one another in a specific order is called orchestration sequencing. With orchestration, you can deploy that database server first, then gather information about it (like its IP address), and use that information to deploy the virtual machine so the VM sends information to the database. Then you can have the orchestration process deploy the web server and have the web server connect to the database to display the information.
Many IaC tools include orchestration sequencing, but some do not.
There may be some confusion over the differences between Infrastructure as Code, configuration management, and orchestration. In fact, the lines that separate these three concepts are often blurred. Review the “Infrastructure as Code” and “Configuration Management” sections in this guide for more details.

Quiz:
1. Which IaC approach would the following file be?
S3Bucket:
Type: AWS::S3::Bucket
- BucketName: mybucket A.Orchestration B.Declarative C.Imperative D.Configuration management
2. Which IaC approach would the following file be?
--bucket $BUCKET; else echo "This
3. Software is automatically deployed to the customer based on whenever a change is made on the main branch. This is an example of which of the following? A.Continuous integration B.Continuous deployment C.Continuous delivery
4. To create a local repository from the central repository, a _____ process is performed. A.Duplication B.Copy C.Sync D.Clone

Answers:
1. Declarative
2. Imperative
3. Continuous deployment
4. Clone