There is a common misunderstanding among developer teams that the templates used to run the deployments are faultless sources of truth when using infrastructure as code tools. Though, configuration drift is one of the fundamental challenges for architecture built using tools like the Terraform.
Configuration drift occurs when the actual state of the infrastructure starts to accumulate changes and deviates from the particular configurations defined in the code. Regardless of your performance in DevOps, configuration drift can happen for many reasons, like modifying, adding, or removing resources.
Terraform state
To understand how the drift configuration happens, you must first understand how Terraform drift can occur. Besides containing environmental metadata, the most significant function of the terraform state is that it’s the single source for the truth of your backed-end APIs.
Terraform uses resource mapping and a declarative approach to configure and bind each remote object to a particular resource. Then, this association is recorded in the Terraform state file.
Learning how to solve infrastructure problems using terraform takes time, and students in this course must find ways of getting extra time for practice.
How drift creeps in
Though the terraform state keeps things tidy and clear when you make changes to the terraform CLI, the changes outside the platform remain invisible to the terraform state until you apply the next terraform command.
For instance, if you change the VM size configuration using the manual update process, the state file will not be able to detect any of the changes made. This virtual machine size configuration could either be a cloud portal or a cloud CLI. When working with virtual machines of the terraform, there is usually a high degree of flexibility in managing and configuring the virtual machines. The terraform provider allows you to manage the required state of virtual machine resources.
You can be provided with vsphere_virtual_machine support resources that support the standard VMDK-baked virtual disks. You must understand that these virtual resources do not support raw device mappings for physical storage devices.
The terraform state waits during the various parts of the VM deployment to make sure that the virtual machine is in the expected state before any further proceeding.
You can also run a non-Terraform process through automation to achieve the same effect, and none of the changes will be detected.
In rare cases, you can identify these changes by simultaneously using the terraform plan command with the terraform apply command. There are changes that will break the state and can only be solved manually.
Be keen and cautious when making any changes to the resources outside the terraform. Any slight change may lead to modifications that will result in deployment failures by destructively affecting the state of the resources.
Identifying these changes is often stressful, and you need to pay detailed attention to avoid causing further problems. You can get your essay assignments written by professional writers from a-writer.com and direct all your efforts to your project.
Drift detection strategies
You can detect drift by comparing the state of the terraform file with the monitoring metrics provided. Comparison is made between the terraform state file and the information from the provider’s API to detect any discrepancies likely to indicate configuration drift. There are several practices for monitoring terraform state instances.
You can use various Terraform tricks to perform a health check. The health check operates in two modes, full check or minimal check. With the full check, the service will attempt to verify internal components’ status and the PostgreSQL.
There is also the use of metrics and telemetry. The Terraform state supports exporting container-level resource utilization metrics that collect some runtime metrics. You can use this data to gain real-time visibility into your installation. In addition, these metrics can also be used to detect and alert you in case of anomalous incidents, changes in utilization trends, and performance degradation.
The READ method
Another way to detect drift is by using the provider’s READ method to capture the state of the schema and make sure that it’s synchronized to the state of your file. In this case, the state is synchronized from the API to the terraform state. It’s vital to ensure that all attributes defined in the schema are kept in proper records and updated as per the provider’s code. In most cases, the “type” attribute is usually optional.
Terraform schema is often defined using several primitive types and aggregate types. Some aggregate types are converted into value pairs when in the state.
This is why sometimes it’s omitted from the config and record keeping in the READ state. If you would like to demonstrate the importance of capturing all states, you can consider configurations that interpolate the optional value in the terraform state to another particular resource.
You can use the provider’s CREATE and UPDATE functions to normalize inputs in the case of sanitized string inputs. Updates can be carried out after the modification process. You can read the files using the file function in the terraform state. The contents are read at the given paths and then returned as a string.
After the modification, the terraform will have a stale state that will result in deviation or be detected on the subsequent plan or applied as terraform refreshes the state and tries to reconcile the difference.
Applying default values to unspecified attributes can also work well with the READ method. So, after you modify your Terraform state file, ensure that you call the READ method to keep the state synchronized.
Suppose the resource doesn’t exist even after the implementation of the READ function. In most cases where the remote system is not a great read-after-write consistent, the resource creation usually returns no error or no resource state.
Terraform refresh
With the fact that it’s very tiresome comparing files manually, you can use the terraform refresh method to detect drift. When comparing files manually, you can’t often rely on the good practice being performed universally. Just use the command for the drift detection and the remedies provided.
In the past, most DevOps engineers used terraform refresh to validate the configuration updates. The Terraform commands for the drift detection read the state of the managed remote objects and then update the state file as per the instructions. Ensure that the remote resources are correctly configured, as this method can cause serious issues if incorrectly configured.
Before you use the Terraform refresh, you need to define your passwords on your Terraform manually. It’s highly required for all processes that require authentication. Terraform provides you with disparate features that will allow you to generate strings. The Terraform random password provides two different resources that will enable you to generate the random strings.
Terraform plan
After making changes to the remote objects outside the Terraform, you must remedy drift in the state file. Perform a simple refresh using the terraform plan command and apply the refresh-only option.
The refresh-only option natively integrates the functionality into the plan, and terraform applies. These two main commands are used together to trigger the deployment of the resources. You can follow three steps to run the deployment of resources.
Begin with the init command. It initializes your resource provider and helps validate the terraform template files. Then, run your terraform plan. This command validates the deployments before the real process starts, and it can help check what results you will get in the final step.
After that, use the terraform to run the deployment. This final command targets the particular environment and deploys specific resources from the files or template files.
During this process, the terraform.state file is created in the apply step, which helps store the updated state of the deployment process. Remember that running this command will identify the integrated refresh functionality.
Running new terraform plan sequence operation
When you run a new terraform plan sequence operation, the plan identifies the detected changes between what’s expected to be a terraform.state VM file and the APIs response from the actual running VM. You will see the “~ “character that indicates change and the “– “character that shows the removal of a component. The “+” character indicates that the terraform will deploy in the new component.
Besides identifying these changes, the terraform is telling you that it will read and write the new Standard-B2ms over Standard_DS2_v2.
There are different infrastructures as code tools that can help you detect drifts. These tools include.
CloudQuery
This is an open-source cloud asset inventory that SQL powers. It extracts all the resources from the desired cloud provider, then formats them before loading the formatted resources into PostgreSQL. As a result, a drift detection command is created on top of PostgreSQL to turn the drift problem into a data issue.
After installing the CloudQuery CLI, you can continue detecting the S3 bucket drifts. As explained in the above paragraph, the first command of the process fetches all the resources from the particular cloud provider and puts them on the PostgreSQL table.
The output of this process will clearly show the results that are managers and ones that are unmanaged. You will also find out that most buckets have drifted due to the bugs.
The benefits of using CloudQuery include:
- Fast enumeration of the cloud resources with the fetch command.
- Support for scanning multiple state files.
- Easy detection of unmanaged resources with a simple drift scan command.
Driftctl
This free, open-source tool warns, detects, and warns you of any signs of infrastructure drift. So, the tool detects, tracks and alerts you on both managed and unmanaged drift that may happen.
The benefits of using this tool include detecting drifts on managed and unmanaged resources with just a command. It also supports the scanning of multiple state files when using infrastructure as code tools.
Conclusion
There is a lot of complexity in managing the drift in the infrastructure as code architecture when using Terraform. Learning about the new methods used in the detection of drift will help you understand how you can navigate these challenges. It will also help you understand the correct tools that can be used to correct the drift issues with the project. Remember that mitigating configuration drift is vital in ensuring that your infrastructure as code is free of misconfigurations.
