Marathon<\/a><\/noindex>\u00a0<\/li>\n<\/ul>\n<\/p>\n
7. Infrastructure as Code (IaC)<\/h2>\n
<\/p>\n
Brief description of the technology<\/h3>\n
\n And here we are at the final section. Usually, this technology and the related tasks do not fall under the responsibility of automation engineers. And there are reasons for that. Firstly, in many organizations, infrastructure issues are managed by the DevOps department, and development teams don't concern themselves too much with what enables the pipeline to function or how to maintain everything related to it. Secondly, let's be honest, the practice of 'Infrastructure as Code (IaC)' is still not widely implemented in many companies. However, it has definitely become a popular trend, and it's important to try to be involved in related processes, approaches, and tools. Or at least stay informed.<\/p>\n
Let\u2019s start with the motivation for using this approach. We have already discussed that to run tests in GitlabCI, we need at least the resources to launch a Gitlab Runner. To run containers with browsers\/emulators, we need to allocate a VM or a cluster. In addition to the testing resources, we need a significant amount of power to maintain development, staging, and production environments, which also includes databases, automated schedules, network configurations, load balancers, user permissions, and more. The key issue lies in the efforts required to support all of this. There are several ways in which we can make changes and roll out updates. For instance, in the context of GCP, we can use the UI console in the browser and perform all actions by clicking buttons. An alternative can be using API calls to interact with cloud entities or employing the gcloud command-line utility for the necessary operations. However, when there is a truly large number of various entities and infrastructure elements, it becomes difficult or even impossible to perform all operations manually. Moreover, all these manual actions are uncontrolled. We cannot submit them for review before execution, utilize a version control system, or quickly revert changes that led to an incident. To address such issues, engineers have created and are still creating automated bash\/shell scripts, which are not much better than the previous methods, as they are not particularly easy to read, understand, maintain, and modify quickly in a procedural style.<\/p>\n
In this article and practical guide, I use two tools related to IaC practice: Terraform and Ansible. Some believe it makes no sense to use them simultaneously since their functionalities are similar and interchangeable. However, the reality is that they are designed to address completely different tasks. The fact that these tools should complement each other was confirmed during a joint presentation by developers from HashiCorp and RedHat. The conceptual difference is that Terraform is a provisioning tool for managing servers themselves, while Ansible is a configuration management tool aimed at installing, configuring, and managing software on those servers.<\/p>\n
Another key distinguishing feature of these tools is their coding style. Unlike Bash and Ansible, Terraform uses a declarative style based on describing the desired end state that needs to be achieved. For instance, if we plan to create 10 VMs and apply changes via Terraform, we will have 10 VMs. If the script is applied again, nothing will happen, as we already have 10 VMs, and Terraform is aware of this because it maintains the current infrastructure state in a state file. On the other hand, Ansible follows a procedural approach, and if we ask it to create 10 VMs, we will get 10 VMs on the first run, just like with Terraform. However, after rerunning, we will end up with 20 VMs. This is the crucial distinction. In the procedural style, we do not store the current state and merely describe the sequence of steps that should be executed. Of course, we can handle different scenarios and add checks for resource existence and current state, but it is pointless to spend our time and effort controlling this logic. Moreover, it increases the risk of making mistakes.\u00a0<\/p>\n
Summarizing the above, it can be concluded that Terraform, with its declarative notation, is more suitable for provisioning servers, while configuration management tasks are better delegated to Ansible. Having understood this, let's look at usage examples in the context of automation.<\/p>\n
Value for Automation Infrastructure<\/h3>\n
\n It's important to understand that the test automation infrastructure should be viewed as part of the company's overall infrastructure. This means that all IaC practices must be applied globally to the resources of the entire organization. Who is responsible for this depends on your processes. The DevOps team is more experienced in these matters and sees the whole picture. However, QA engineers are more involved in the automation build process and the structure of the pipeline, which allows them to better identify all necessary changes and opportunities for improvement. The best option is to work together, sharing knowledge and ideas to achieve the expected results.\u00a0<\/p>\n
Let me provide a few examples of using Terraform and Ansible in the context of test automation and the tools we discussed earlier:<\/p>\n
1. Describe the necessary characteristics and parameters of VMs and clusters using Terraform.<\/p>\n
2. Install the necessary testing tools with Ansible: Docker, Selenoid, Selenium Grid, and load the required versions of browsers\/emulators.<\/p>\n
3. Describe the characteristics of the VM in which the GitLab Runner will be launched using Terraform.<\/p>\n
4. Install GitLab Runner and the necessary accompanying tools with Ansible, and set configurations and settings.<\/p>\n
Illustration of the Current State of the Infrastructure<\/h3>\n
\n![\"DevOps](\"\/wp-content\/uploads\/2020\/04\/5d793a800a4ef62e181e6cb3a3f0544e.png\")
<\/p>\n
Resources for study:<\/h3>\n
<\/p>\n