mirrors/90DaysOfDevOps
1
0
Fork 0
mirror of https://github.com/MichaelCade/90DaysOfDevOps.git synced 2024-12-22 21:53:14 +07:00
Code Issues Packages Projects Releases Wiki Activity
main
90DaysOfDevOps/2022/Days/day62.md
Nitin Mishra 17ee0ab726
Add code reference to day 62
2022-12-23 18:00:32 +05:30

9.1 KiB
Raw Permalink Blame History

title published description tags cover_image canonical_url id
#90DaysOfDevOps - Testing, Tools & Alternatives - Day 62 false 90DaysOfDevOps - Testing, Tools & Alternatives devops, 90daysofdevops, learning null null 1049053

Testing, Tools & Alternatives

As we close out this section on Infrastructure as Code we must mention testing our code, the various tools available and then some of the alternatives to Terraform to achieve this. As I said at the start of the section my focus was on Terraform because it is firstly free and open source, secondly, it is cross-platform and agnostic to environments. But there are also alternatives out there that should be considered but the overall goal is to make people aware that this is the way to deploy your infrastructure.

Code Rot

The first area I want to cover in this session is code rot, unlike application code, infrastructure as code might get used and then not for a very long time. Let's take the example that we are going to be using Terraform to deploy our VM environment in AWS, perfect and it works the first time and we have our environment, but this environment doesn't change too often so the code gets left the state possibly or hopefully stored in a central location but the code does not change.

What if something changes in the infrastructure? But it is done out of band, or other things change in our environment.

  • Out of band changes
  • Unpinned versions
  • Deprecated dependencies
  • Unapplied changes

Testing

Another huge area that follows on from code rot and in general is the ability to test your IaC and make sure all areas are working the way they should.

First up there are some built-in testing commands we can take a look at:

Command Description
terraform fmt Rewrite Terraform configuration files to a canonical format and style.
terraform validate Validates the configuration files in a directory, referring only to the configuration
terraform plan Creates an execution plan, which lets you preview the changes that Terraform plans to make
Custom validation Validation of your input variables to ensure they match what you would expect them to be

We also have some testing tools available external to Terraform:

  • tflint

    • Find possible errors
    • Warn about deprecated syntax and unused declarations.
    • Enforce best practices, and naming conventions.

Scanning tools

  • checkov - scans cloud infrastructure configurations to find misconfigurations before they're deployed.
  • tfsec - static analysis security scanner for your Terraform code.
  • terrascan - static code analyser for Infrastructure as Code.
  • terraform-compliance - a lightweight, security and compliance-focused test framework against terraform to enable the negative testing capability for your infrastructure-as-code.
  • snyk - scans your Terraform code for misconfigurations and security issues

Managed Cloud offering

  • Terraform Sentinel - embedded policy-as-code framework integrated with the HashiCorp Enterprise products. It enables fine-grained, logic-based policy decisions, and can be extended to use information from external sources.

Automated testing

  • Terratest - Terratest is a Go library that provides patterns and helper functions for testing infrastructure
  • Terratest makes it easier to write automated tests for our infrastructure code. It provides a variety of helper functions and patterns for common infrastructure testing.
  • find code at 2022/Days/IaC/Terratest
  • To Run this application
    • git clone #repo_url#
    • cd test
    • go mod init "<MODULE_NAME>"
      MODULE_NAME would be github.com/<YOUR_USERNAME>/<YOUR_REPO_NAME>
    • go mod init github.com/
    • go run

go mod init "<MODULE_NAME>" would create go.mod file into test folder.

  • The go.mod file is the root of dependency management in GoLang.
  • All the modules which are needed or to be used in the project are maintained here in go.mod file.
  • It creates entry for all the packages we are going to use/import in our project.
  • It reduces effort for getting each dependencies manually.

On running go test for the first time you would get go.sum file created.

  • go.sum file is created when go test or go build is executed for the first time.
  • It installs all the packages with specific version(latest)
  • we do not need to edit or modify this file.

Worth a mention

  • Terraform Cloud - Terraform Cloud is HashiCorp’s managed service offering. It eliminates the need for unnecessary tooling and documentation for practitioners, teams, and organizations to use Terraform in production.

  • Terragrunt - Terragrunt is a thin wrapper that provides extra tools for keeping your configurations DRY, working with multiple Terraform modules, and managing remote state.

  • Atlantis - Terraform Pull Request Automation

Alternatives

We mentioned on Day 57 when we started this section that there were some alternatives and I very much plan on exploring this following on from this challenge.

Cloud Specific Cloud Agnostic
AWS CloudFormation Terraform
Azure Resource Manager Pulumi
Google Cloud Deployment Manager

I have used AWS CloudFormation probably the most out of the above list and native to AWS but I have not used the others other than Terraform. As you can imagine the cloud-specific versions are very good in that particular cloud but if you have multiple cloud environments then you are going to struggle to migrate those configurations or you are going to have multiple management planes for your IaC efforts.

I think an interesting next step for me is to take some time and learn more about Pulumi

From a Pulumi comparison on their site

"Both Terraform and Pulumi offer the desired state infrastructure as code model where the code represents the desired infrastructure state and the deployment engine compares this desired state with the stack’s current state and determines what resources need to be created, updated or deleted."

The biggest difference I can see is that unlike the HashiCorp Configuration Language (HCL) Pulumi allows for general-purpose languages like Python, TypeScript, JavaScript, Go and .NET.

A quick overview Introduction to Pulumi: Modern Infrastructure as Code I like the ease and choices you are prompted with and want to get into this a little more.

This wraps up the Infrastructure as code section and next we move on to that little bit of overlap with configuration management in particular as we get past the big picture of configuration management we are going to be using Ansible for some of those tasks and demos.

Resources

I have listed a lot of resources down below and I think this topic has been covered so many times out there, If you have additional resources be sure to raise a PR with your resources and I will be happy to review and add them to the list.

See you on Day 63