DEV Community: AF uarabei

GCP CI/CD Pipeline: Build Docker images after commits to a repo branch (Google Cloud Source Repositories)

AF uarabei — Fri, 23 Sep 2022 18:09:40 +0000

In this article we will learn how to connect GCP's code versioning service (Cloud Source Repositories) to Cloud Build to automate building Docker images and pushing them to GCP Container Registry.

Cloud and containers have truly revolutionized deployment and management of web infrastructure. Ability to build docker images triggered by a push or a pull request allows developers focus more on code and less on infrastructure.

The process of setting up this pipeline will follow these steps:

Create a repository in Cloud Source Repositories
Push source code files to our repo
Create a trigger in Cloud Build service
Set trigger to build a Docker image when there is a new commit to the specified branch

1. Creating a repository in Cloud Source Repositories

Navigate to Cloud Source Repositories using sidebar or a search bar at the top.

Verify that you are creating your repository in the correct project and then click Add repository button in the top right corner:

Since we will be using GCP's version control we need to select Create new repository option and click Continue:

Next we will need to enter the name of our repo and select the project. Click Create button after you are done:

For the final step we will clone our newly created repository to our local machine using the instructions provided:

You can upload your code to the repo using either SSH (1st option) or using gcloud CLI. I will let reader decide which option to use.

2. Source files

For this project we will have 2 sources files:

Dockerfile:



FROM python:3.7-slim
RUN pip install flask
WORKDIR /myapp
COPY main.py /myapp/main.py
CMD ["python", "/myapp/main.py"]

main.py:



from flask import Flask

app = Flask(__name__)


@app.route('/')
def index():
    return 'CI/CD pipeline with GCP Cloud Source Repositories and Docker'


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Following the instructions push these files to the repo and verify that they are uploaded:

3. Creating a Cloud Build trigger

If you are using Cloud Build for the first time you will be asked to enable the API first. Click Enable to activate this API. It might take a minute, it is normal.

Click on Triggers in the sidebar:

To create a new trigger click on the Create new trigger button at the bottom of the page:

On the trigger creation page we will need to pay attention to 4 important parts:

Trigger name
Event that will trigger the action (I left it as default Push to a branch)
Source repository (click on the dropdown and select your repo and the branch that this trigger will monitor)
Configuration type (select Dockerfile)

After you are done click Create to finish setting up the trigger.

To test our trigger we will first invoke it manually by clicking RUN button:

A popup will appear asking for confirmation. Click Run trigger:

If we click the History option in the sidebar on the left we can see the build history:

My build has succeeded:

4. Verifying that Dockerimage is built automatically

GCP has a service for storing container image called Container Registry.

Navigate to Contianer Registry and you should see your image there:

And finally, lets do a test with a test push. Let's modify our main.py file and push changes to the repository. I modified the text a little and added v2.0:



from flask import Flask

app = Flask(__name__)


@app.route('/')
def index():
    return 'CI/CD pipeline with GCP Cloud Source Repositories and Docker v2.0'


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Commit and push new changes to the repo. It should run the trigger automatically. You should see a running process in the History tab (mine completed really fast):

Let's go to the container registry and verify that the new image there:

There will be two images, one from running the trigger manually and the second one from pushing code to the tracked branch.
And yes, as we can see the new image is there!

That's it. You have created a CI/CD pipeline that builds a Docker image when new code is committed to the tracked branch!

GCP CI/CD Pipeline: Build Docker images after commits to a repo branch (Github)

AF uarabei — Fri, 23 Sep 2022 18:08:59 +0000

In this article we will learn how to create a CI/CD pipeline on GCP using Cloud Build, Github, and Docker.

For this article I will be using this repository.

1. Create a trigger

First we would need to navigate to Code Build. Select the Triggers tab in the sidebar and Create Trigger:

Enter the name of your trigger and select Connect new repository in the Source section:

You will see a sidebar that will appear on the right hand side with different options for repositories supported by Cloud Build. I am using Github, so I selected the first option. Click Continue:

You will be asked to authorize Cloud Build to access your github account and repositories:

Select your github account and repository for this trigger:

Then select the Dockerfile in the Configuration section and hit Create at the bottom of the page:

You should see your newly created trigger with the connected repo:

2. Run trigger manually

Let's test our trigger by running it manually first.
Next to your trigger there is a button RUN:

A sidebar will popup on the right hand side asking you to confirm the details of deployment. Press Run Trigger:

I can see the new image in the Container Registry. Mine is called github.com. But it is there. The trigger is working!

3. Run trigger automatically

And finally, let's push new code to the repository and test the trigger for automatic build.

I will let reader do the code pushing.

If you want to see current or past builds, Code Build has a section called History in the sidebar on the left. It is a great to monitor builds.

When I pushed new code to my repository a new build was triggered right away and it appeared in the History section:

That's it! Thank you for reading.

Terraform: My experience taking the exam

AF uarabei — Thu, 21 Jul 2022 03:31:37 +0000

After writing several articles about Terraform I finally felt prepared I took the exam. I am glad that I passed that I passed. Now I am a certified Terraform Associate.

In this final chapter of the series I will tell you about the exam and what I think about it.

Registration

Registration for the exam is available on this page. Weird thing about the portal is that it required a Github account. The unfortunate part is that my Github email is different from my personal email tied to Credly where I have all of my certification badges. If you are like me and prefer to have your Credly badges in one place make sure to register a Github account for that email and use it for registering for the exam.

Registration itself is straight forward. You pay $70.50USD and select date and time using PSI portal. After registration you will get an email with required links and you are all set.

Before the Exam

PSI would allow you to access the exam page 30 minutes prior to the exam. In this time you would need to download PSI secure browser which is about 180MB so make sure your internet connection allows for timely. Then you would need to install it and grant the necessary permissions like screen recording, access to camera and microphone.

When you launch PSI browser it will run a check and ask you to close applications that PSI does not allow during exam. For me it asked to close other Browsers and Ipad mirroring service (I didn't even know I had such process running in the background). Closing all those apps will pass the PSI browser checks and you will be presented with the next task.

The browser will ask you to take a picture of your government issued ID and taking sweeping videos of your sitting area (horizontal and vertical).

Once you are done with that you will be connected to the proctor with a new chat window. The proctor will verify your name and the sitting area. He may ask you to show him the table and/or ask you to remove certain items. If he is happy with what he sees he will start the exam.

Exam

The exam is 1 hour long and mine had 57 questions in it. All questions were multiple choice and some True/False questions here and there. I was done in about 30 minutes.

After you submit your answers you will be given the result right away.

Thoughts about questions

I passed with a score of 86%. I think I could have done better, but a pass is a pass.

I covered most of the topics for this exam in the series, though some questions threw me off.

This is the list of topics I wish I covered more:

Built-in functions
CLI commands and available options/flags
Workspaces

If you are using this series as a prep for the exam, I would recommend going through official study guide with tutorials to make sure you cover all the bases.

Conclusion

This wraps up this series. I hope you learned something. Good luck!

Terraform Cloud with VCS Workflow(Github)

AF uarabei — Sun, 17 Jul 2022 21:22:51 +0000

VSC integrations are a popular and, quite frankly, a useful tool that allow collaboration between many people. In this article we will learn how to add a Github integration to our Terraform Cloud.

It is assumed that you already have a Terraform Cloud account and an organization.

Select your organization and click 'Setting' tab:

There will be a button 'Connect to version control':

You will be presented with 3 options for your workflow. We are interested in 'Version Control Workflow':

I am interested in Github and that's what I will select:

After selecting your VCS provider you will see a popup asking you to grant permissions to Terraform Cloud to access your Github. Click 'Authorize Terraform Cloud':

If everything went well you will see a list of your repositories.

I will select the repo that used for this blog series:

Then we will be redirected to a settings confirmation page. Important fields here are the 'Apply Method' and 'VSC Branch'. Once you have confirmed the settings click 'Update VSC settings' button at the bottom of the page:

After that you will a green success message text:

This is it. You have now connected your Github account to Terraform Cloud!
Thank you for reading and see you in the next article!

Terraform State Migration and State Refresh

AF uarabei — Thu, 14 Jul 2022 05:58:54 +0000

Terraform state migration

We have learned a lot about Terraform's backend and its features. But there is one important topic that is usually skipped by new learners. This topic is state migration.

There are many reasons why you may have a need to migrate your state: moving to cloud, switching cloud providers, centralizing state management, and many others.

Luckily, Terraform developers thought about this issue and provided us with tools to make this process manageable.

Code for this article can be found HERE

We will start with a local backend and then migrate to AWS S3 backend.

First let's create a configuration with a local backend in terraform.tf:



# terraform.tf

# Local backend
terraform {
  # Provider-specific settings
  required_providers {
    aws = {
      version = ">= 2.7.0"
      source  = "hashicorp/aws"
    }
  }
  # Terraform version
  required_version = ">= 0.14.9"
}

Reinitialize the backend, validate, plan, and apply:



$ terraform init
# output
Terraform has been successfully initialized!

$ terraform validate
# output
Success! The configuration is valid.

$ terraform plan
# output
Plan: 25 to add, 0 to change, 0 to destroy.

$ terraform apply
# output
Apply complete! Resources: 25 added, 0 changed, 0 destroyed.

Verify that resources have been deployed using a state list command:



$ terraform state list
# output
data.aws_ami.ubuntu
data.aws_availability_zones.available
data.aws_region.current
aws_eip.nat_gateway_eip
aws_internet_gateway.internet_gateway
aws_nat_gateway.nat_gateway
aws_route_table.private_route_table
aws_route_table.public_route_table
aws_route_table_association.private
aws_route_table_association.public
aws_security_group.private_sg
aws_security_group.public_sg
aws_security_group_rule.private_in
aws_security_group_rule.private_out
aws_security_group_rule.public_http_in
aws_security_group_rule.public_https_in
aws_security_group_rule.public_out
aws_security_group_rule.public_ssh_in
aws_subnet.private_subnet
aws_subnet.public_subnet
aws_vpc.vpc
module._server_from_local_module.data.aws_ami.ubuntu
module._server_from_local_module.aws_instance.web_server
module.another_server_from_a_module.data.aws_ami.ubuntu
module.another_server_from_a_module.aws_instance.web_server
module.autoscaling_from_github.data.aws_default_tags.current
module.autoscaling_from_github.data.aws_partition.current
module.autoscaling_from_github.aws_autoscaling_group.this[0]
module.autoscaling_from_github.aws_launch_template.this[0]
module.autoscaling_from_registry.data.aws_default_tags.current
module.autoscaling_from_registry.data.aws_partition.current
module.autoscaling_from_registry.aws_autoscaling_group.this[0]
module.autoscaling_from_registry.aws_launch_template.this[0]
module.my_server_module.data.aws_ami.ubuntu
module.my_server_module.aws_instance.web_server

We know that our local backend works and we can now learn how to migrate our state to an S3 bucket on AWS.

Details on how to create an S3 bucket and a DynamoDB table can be found in this article. You will need these values:

S3 bucket name
DynamoDB table name
Your region

Backend settings are inside the terraform.tf file and we need to modify it to let Terraform know about new backend. I commented out the local backend for demonstration purposes:



# terraform.tf

# Local backend
# terraform {
#   # Provider-specific settings
#   required_providers {
#     aws = {
#       version = ">= 2.7.0"
#       source  = "hashicorp/aws"
#     }
#   }
#   # Terraform version
#   required_version = ">= 0.14.9"
# }

terraform {
  backend "s3" {
    bucket         = "terraform-state-migration"
    key            = "dev/aws_infrastructure"
    region         = "ca-central-1"
    dynamodb_table = "tf-state-mig"
    encrypt        = true
  }
  # Provider-specific settings
  required_providers {
    aws = {
      version = ">= 2.7.0"
      source  = "hashicorp/aws"
    }
  }
  # Terraform version
  required_version = ">= 0.14.9"
}

All that is left to do is migrate our backend to S3:



$ terraform init -migrate-state
# output
Initializing modules...

Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. No existing state was found in the newly
  configured "s3" backend. Do you want to copy this state to the new "s3"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes


Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v4.18.0

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Let's check if the resources are still there:



$ terraform state list
# output
data.aws_ami.ubuntu
data.aws_availability_zones.available
data.aws_region.current
aws_eip.nat_gateway_eip
aws_internet_gateway.internet_gateway
aws_nat_gateway.nat_gateway
aws_route_table.private_route_table
aws_route_table.public_route_table
aws_route_table_association.private
aws_route_table_association.public
aws_security_group.private_sg
aws_security_group.public_sg
aws_security_group_rule.private_in
aws_security_group_rule.private_out
aws_security_group_rule.public_http_in
aws_security_group_rule.public_https_in
aws_security_group_rule.public_out
aws_security_group_rule.public_ssh_in
aws_subnet.private_subnet
aws_subnet.public_subnet
aws_vpc.vpc
module._server_from_local_module.data.aws_ami.ubuntu
module._server_from_local_module.aws_instance.web_server
module.another_server_from_a_module.data.aws_ami.ubuntu
module.another_server_from_a_module.aws_instance.web_server
module.autoscaling_from_github.data.aws_default_tags.current
module.autoscaling_from_github.data.aws_partition.current
module.autoscaling_from_github.aws_autoscaling_group.this[0]
module.autoscaling_from_github.aws_launch_template.this[0]
module.autoscaling_from_registry.data.aws_default_tags.current
module.autoscaling_from_registry.data.aws_partition.current
module.autoscaling_from_registry.aws_autoscaling_group.this[0]
module.autoscaling_from_registry.aws_launch_template.this[0]
module.my_server_module.data.aws_ami.ubuntu
module.my_server_module.aws_instance.web_server

We can also check our bucket to see if the state file was created there:

We already covered the benefits of storing backend remotely and how it is often the best choice when there are many people working on infrastructure and they need to collaborate.

Congratulation! You have just migrated your backend from a local machine to a remote location. This is a valuable skill because most of the time you would start working on a new project locally and migrate it to a remote backend afterwards. Now you know how to do it.

Let's migrate our remote backend back to our local machine.

This is relatively easy. All we need to do is delete the backend block from the Terraform settings and force Terraform to fall back to the default local backend.

This is the modified terraform.tf file:



# terraform.tf

# Local backend
terraform {
  # Provider-specific settings
  required_providers {
    aws = {
      version = ">= 2.7.0"
      source  = "hashicorp/aws"
    }
  }
  # Terraform version
  required_version = ">= 0.14.9"
}

We will go through the same steps as before. Validate, initialize with -migrate-state flag, check state list:



$ terraform validate
# output
Success! The configuration is valid.

$ terraform init -migrate-state
Initializing modules...

Initializing the backend...
Terraform has detected you're unconfiguring your previously set "s3" backend.
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "s3" backend to the
  newly configured "local" backend. No existing state was found in the newly
  configured "local" backend. Do you want to copy this state to the new "local"
  backend? Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes



Successfully unset the backend "s3". Terraform will now operate locally.

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v4.18.0

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Let's check the state list:



$ terraform state list
# output with list of resources...

Finally, let's destroy our resources:



$ terraform destroy
# output
Destroy complete! Resources: 25 destroyed.

This is it. We migrated our backend to an S3 bucket from local machine and back. Give yourself a round of applause!

Terraform makes it really easy to migrate your state file wherever you need and I absolutely love this feature.

Terraform state refresh

When you run terraform refresh Terraform reads the settings of all existing resources belonging to the current configuration and updates Terraform state to ensure that things match. This command only modifies the state. Refresh is run automatically as a part of plan and apply commands.

This command is useful to deal with what is known as configuration drift. There are instances when we need to go and modify an existing resource. With terraform refresh we can let Terraform know about these changes and prevent configuration drift where the settings of remote resources differ from the Terraform configuration.

To demonstrate how this command works we will intentionally introduce a configuration drift by modifying a tag of an EC2 instance manually. Then we will run the refresh command and let Terraform state be in sync with the real configuration of our resources.

If your configuration is not up run the apply command:



$ terraform apply

Let's see the state list and select an instance to modify:



$ terraform state list
# output
data.aws_ami.ubuntu
data.aws_availability_zones.available
data.aws_region.current
aws_eip.nat_gateway_eip
aws_internet_gateway.internet_gateway
aws_nat_gateway.nat_gateway
aws_route_table.private_route_table
aws_route_table.public_route_table
aws_route_table_association.private
aws_route_table_association.public
aws_security_group.private_sg
aws_security_group.public_sg
aws_security_group_rule.private_in
aws_security_group_rule.private_out
aws_security_group_rule.public_http_in
aws_security_group_rule.public_https_in
aws_security_group_rule.public_out
aws_security_group_rule.public_ssh_in
aws_subnet.private_subnet
aws_subnet.public_subnet
aws_vpc.vpc
module._server_from_local_module.data.aws_ami.ubuntu
module._server_from_local_module.aws_instance.web_server
module.another_server_from_a_module.data.aws_ami.ubuntu
module.another_server_from_a_module.aws_instance.web_server
module.autoscaling_from_github.data.aws_default_tags.current
module.autoscaling_from_github.data.aws_partition.current
module.autoscaling_from_github.aws_autoscaling_group.this[0]
module.autoscaling_from_github.aws_launch_template.this[0]
module.autoscaling_from_registry.data.aws_default_tags.current
module.autoscaling_from_registry.data.aws_partition.current
module.autoscaling_from_registry.aws_autoscaling_group.this[0]
module.autoscaling_from_registry.aws_launch_template.this[0]
module.my_server_module.data.aws_ami.ubuntu
module.my_server_module.aws_instance.web_server

I chose module.my_server_module.aws_instance.web_server. Let's see what kind of data Terraform state has on this instance:



$ terraform state show module.my_server_module.aws_instance.web_server

# output

# module.my_server_module.aws_instance.web_server:
resource "aws_instance" "web_server" {
    ami                                  = "ami-04a579d2f00bb4001"
    arn                                  = "arn:aws:ec2:ca-central-1:490750479946:instance/i-0d09c23db0e4dbb51"
    associate_public_ip_address          = true
    availability_zone                    = "ca-central-1a"
    cpu_core_count                       = 1
    cpu_threads_per_core                 = 1
    disable_api_termination              = false
    ebs_optimized                        = false
    get_password_data                    = false
    hibernation                          = false
    id                                   = "i-0d09c23db0e4dbb51"
    instance_initiated_shutdown_behavior = "stop"
    instance_state                       = "running"
    instance_type                        = "t2.micro"
    ipv6_address_count                   = 0
    ipv6_addresses                       = []
    monitoring                           = false
    primary_network_interface_id         = "eni-01fef74a6aff22cac"
    private_dns                          = "ip-10-0-0-224.ca-central-1.compute.internal"
    private_ip                           = "10.0.0.224"
    public_ip                            = "3.97.16.128"
    secondary_private_ips                = []
    security_groups                      = []
    source_dest_check                    = true
    subnet_id                            = "subnet-0f1f35c97902550da"
    tags                                 = {
        "Name"      = "Web Server from module"
        "Terraform" = "true"
    }
    tags_all                             = {
        "Name"      = "Web Server from module"
        "Terraform" = "true"
    }
    tenancy                              = "default"
    user_data_replace_on_change          = false
    vpc_security_group_ids               = [
        "sg-08fc17f9b71be12fd",
    ]

    capacity_reservation_specification {
        capacity_reservation_preference = "open"
    }

    credit_specification {
        cpu_credits = "standard"
    }

    enclave_options {
        enabled = false
    }

    maintenance_options {
        auto_recovery = "default"
    }

    metadata_options {
        http_endpoint               = "enabled"
        http_put_response_hop_limit = 1
        http_tokens                 = "optional"
        instance_metadata_tags      = "disabled"
    }

    root_block_device {
        delete_on_termination = true
        device_name           = "/dev/sda1"
        encrypted             = false
        iops                  = 100
        tags                  = {}
        throughput            = 0
        volume_id             = "vol-04f7e86e0d3cdcd7a"
        volume_size           = 8
        volume_type           = "gp2"
    }
}

I will introduce drift by adding a tag to this instance:

Now we run the refresh command:



$ terraform refresh

If we check the data about this instance we can see that name (look at tags and tags_all) was updated to refresh-demo:



$ terraform state show
module.my_server_module.aws_instance.web_server

# output
# module.my_server_module.aws_instance.web_server:
resource "aws_instance" "web_server" {
    ami                                  = "ami-04a579d2f00bb4001"
    arn                                  = "arn:aws:ec2:ca-central-1:490750479946:instance/i-0d09c23db0e4dbb51"
    associate_public_ip_address          = true
    availability_zone                    = "ca-central-1a"
    cpu_core_count                       = 1
    cpu_threads_per_core                 = 1
    disable_api_termination              = false
    ebs_optimized                        = false
    get_password_data                    = false
    hibernation                          = false
    id                                   = "i-0d09c23db0e4dbb51"
    instance_initiated_shutdown_behavior = "stop"
    instance_state                       = "running"
    instance_type                        = "t2.micro"
    ipv6_address_count                   = 0
    ipv6_addresses                       = []
    monitoring                           = false
    primary_network_interface_id         = "eni-01fef74a6aff22cac"
    private_dns                          = "ip-10-0-0-224.ca-central-1.compute.internal"
    private_ip                           = "10.0.0.224"
    public_ip                            = "3.97.16.128"
    secondary_private_ips                = []
    security_groups                      = []
    source_dest_check                    = true
    subnet_id                            = "subnet-0f1f35c97902550da"
    tags                                 = {
        "Name"      = "refresh-demo"
        "Terraform" = "true"
    }
    tags_all                             = {
        "Name"      = "refresh-demo"
        "Terraform" = "true"
    }
    tenancy                              = "default"
    user_data_replace_on_change          = false
    vpc_security_group_ids               = [
        "sg-08fc17f9b71be12fd",
    ]

    capacity_reservation_specification {
        capacity_reservation_preference = "open"
    }

    credit_specification {
        cpu_credits = "standard"
    }

    enclave_options {
        enabled = false
    }

    maintenance_options {
        auto_recovery = "default"
    }

    metadata_options {
        http_endpoint               = "enabled"
        http_put_response_hop_limit = 1
        http_tokens                 = "optional"
        instance_metadata_tags      = "disabled"
    }

    root_block_device {
        delete_on_termination = true
        device_name           = "/dev/sda1"
        encrypted             = false
        iops                  = 100
        tags                  = {}
        throughput            = 0
        volume_id             = "vol-04f7e86e0d3cdcd7a"
        volume_size           = 8
        volume_type           = "gp2"
    }
}

Lastly, I will destroy the infrastructure because I have no use for it anymore:



$ terraform destroy -auto-approve

Please note that this command only updates the state to match any manual changes to the resources. If you want to make permanent changes it is recommended that you modify the configuration and reapply the changes.

Thank you for reading. We got pretty far into Terraform and I hope that people find these articles helpful. See you in the next article!

Terraform Enhanced Backend on Terraform Cloud with AWS access keys

AF uarabei — Fri, 01 Jul 2022 21:39:16 +0000

Enhanced backend in Terraform means a backend that can store state AND perform operations for configuration management.

Terraform has 2 enhanced backends that can store state and execute operations:

local backend (default, stored locally)
remote backend (used in Terraform Cloud)

We worked with local backend quite extensively throughout these series. This article will show how to use Terraform Cloud and remote backend that will allow us to store backend remotely and execute commands like plan and apply with the output showing in the local terminal.

In this article we will setup our Terraform configuration to work with Terraform Cloud and a remote backend.

Here is the plan for this tutorial:

Create a workspace
Setup remote backend in our configuration
Initialize our Terraform configuration
Add AWS access tokens to the Terraform Cloud to allow remote execution of commands

The code for this tutorial can be found HERE

In a previous article I covered how to create a Terraform Cloud account and an organization.

In order to proceed you will need to login into your Terraform Cloud account and get the name of your organization:

We will also need a workspace for our. Click on "New workspace". Make sure that you have selected the correct organization.

Select the CLI-driven workflow:

Enter the name (optionally add description) and press Create workspace:

And our organization has a new workspace. Good job!

Now we will see how to use it in our configuration. First, let's create a remote backend and point Terraform to it. Make sure that you put the correct organization and workspace names:



# terraform.tf

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "terraform-blog"

    workspaces {
      name = "demo-app-on-aws"
    }
  }
}

It is assumed that you done terraform login and added Terraform API token.

Since we changed the settings we need to reinitialize Terraform:



$ terraform init
# Output
Initializing modules...

Initializing the backend...

Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.

If you get this error:



│ The "remote" backend encountered an unexpected error while reading the
│ organization settings: unauthorized

It means that your Terraform Cloud API token is not valid anymore. This problem can be fixed by running terraform login and going the steps. You can also find a step-by-step guide in this article.

Let's see what happens when we try to execute a dry-run:



$ terraform plan
# Output
Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.

Preparing the remote plan...

To view this run in a browser, visit:
https://app.terraform.io/app/terraform-blog/demo-app-on-aws/runs/run-fACfrx3XtjhNh1zW

Waiting for the plan to start...

Terraform v1.2.4
on linux_amd64
Initializing plugins and modules...
╷
│ Error: error configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.
│ 
│ Please see https://registry.terraform.io/providers/hashicorp/aws
│ for more information about providing credentials.
│ 
│ Error: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, request send failed, Get "http://169.254.169.254/latest/meta-data/iam/security-credentials/": dial tcp 169.254.169.254:80: i/o timeout
│ 
│ 
│   with provider["registry.terraform.io/hashicorp/aws"],
│   on main.tf line 3, in provider "aws":
│    3: provider "aws" {
│ 
╵
Operation failed: failed running terraform plan (exit 1)

We are interested in the first part of the output indicating that plan is running remotely:



Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.

Preparing the remote plan...

To view this run in a browser, visit:
https://app.terraform.io/app/terraform-blog/demo-app-on-aws/

Waiting for the plan to start...

We also got an error stating that we did not provide valid credentials for the AWS provider.

Terraform Cloud allows us to add credentials as environment variables inside the workspace. Please note that you need your AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY to complete the next step.

Select your workspace. You will see a Variable tab at the top. Click that and you will arrive at the screen where you can add environment variables. That's where we will put our AWS credentials that will allow Terraform to deploy resources remotely.

Now it's time to add our AWS access tokens to the environment. Select Environment variable radio button. AWS_SECRET_ACCESS_TOKEN will need to have the "sensitive" checkbox selected. This is important. Value field is where the actual key will go. See the picture for details:

This how it is supposed to look like after you are done. Pay attention how AWS_ACCESS_KEY is public, yet AWS_SECRET_ACCESS_KEY is private.

Let's do another dry to verify that Terraform can use access to manage the infrastructure:



$ terraform plan
# output
Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.

Preparing the remote plan...

To view this run in a browser, visit:
https://app.terraform.io/app/terraform-blog/demo-app-on-aws/

Waiting for the plan to start...
# lots of output here with resources
Plan: 25 to add, 0 to change, 0 to destroy.

And let's apply the changes:



$ terraform apply
# lots of output but you should see this at the end
Apply complete! Resources: 25 added, 0 changed, 0 destroyed.

Verify that resources with the list command:



$ terraform state list
data.aws_ami.ubuntu
data.aws_availability_zones.available
data.aws_region.current
aws_eip.nat_gateway_eip
aws_internet_gateway.internet_gateway
aws_nat_gateway.nat_gateway
aws_route_table.private_route_table
aws_route_table.public_route_table
aws_route_table_association.private
aws_route_table_association.public
aws_security_group.private_sg
aws_security_group.public_sg
aws_security_group_rule.private_in
aws_security_group_rule.private_out
aws_security_group_rule.public_http_in
aws_security_group_rule.public_https_in
aws_security_group_rule.public_out
aws_security_group_rule.public_ssh_in
aws_subnet.private_subnet
aws_subnet.public_subnet
aws_vpc.vpc
module._server_from_local_module.data.aws_ami.ubuntu
module._server_from_local_module.aws_instance.web_server
module.another_server_from_a_module.data.aws_ami.ubuntu
module.another_server_from_a_module.aws_instance.web_server
module.autoscaling_from_github.data.aws_default_tags.current
module.autoscaling_from_github.data.aws_partition.current
module.autoscaling_from_github.aws_autoscaling_group.this[0]
module.autoscaling_from_github.aws_launch_template.this[0]
module.autoscaling_from_registry.data.aws_default_tags.current
module.autoscaling_from_registry.data.aws_partition.current
module.autoscaling_from_registry.aws_autoscaling_group.this[0]
module.autoscaling_from_registry.aws_launch_template.this[0]
module.my_server_module.data.aws_ami.ubuntu
module.my_server_module.aws_instance.web_server

Awesome! We have connected Terraform Cloud, added AWS API tokens in a secure manner. Now we can create, modify, and destroy resources using our local terminal with the state store remotely.

Finally, let's destroy the resources:



$ terraform destroy
# output
Apply complete! Resources: 0 added, 0 changed, 25 destroyed.

You can also view the history of commands executed by this backend by clicking on Runs tab within your organization:

This wraps up this tutorial. Thank you for reading! See you in the next article.

Terraform Standard Backends: HTTP Backend

AF uarabei — Wed, 29 Jun 2022 02:07:59 +0000

Another backend type which we will explore is called HTTP backend.

This type of backend allows us to store state using a REST client.

State will be fetched using GET, updated via POST, and finally destroyed using DELETE.

This backend also supports state locking which, as we learned previously, is an incredibly handy feature. When locking is enabled you can use LOCK and UNLOCK requests to include the lock info in the body. The endpoint will return 423:Locked or 409:Conflict if the lock is active and 200:OK if there is no lock.

This is how you add an HTTP backend:

# terraform.tf

terraform {
  backend "http" {
    address = "http://myrest.api.com/foo"

    lock_method    = "PUT"
    lock_address   = "http://myrest.api.com/foo"

    unlock_address = "http://myrest.api.com/foo"
    unlock_method  = "DELETE"
  }
}

This was a very short article, but since we are on the topic of backends I thought this simple backend will be a good addition.

Thank you for reading! See you in the next article!

Terraform Standard Backends: S3 with versioning and state locking with DynamoDB

AF uarabei — Tue, 28 Jun 2022 02:11:26 +0000

We learned a little bit about Terraform's state and backend in the previous article. Now it is time to explore Terraform's Standard Backend in more detail.

Standard backends allow us to store the state remotely while modifying it locally through CLI. In essence it means that state is stored remotely while all Terraform operations are performed locally. We have seen an example of such backend in the previous article where we configured an AWS S3 bucket to store the state. We were still able to add resources, plan, and apply changes locally on our machine.

Here is the link to the Terraform documentation regarding S3 backend.

We can see that Terraform several backends. The following picture shows the list of the currently available backends. Official docs also have the settings you'd need to configure to make it work for each backend.

One of the attractive features of cloud storage like S3 is that they come with file versioning. This means that state is versioned with minimal effort. Since this feature is outside of Terraform you need to find out how to enable versioning on your bucket.

Another benefit of cloud storage is that you can enable encryption of the state file. Enabling Server-side encryption for your bucket will add an extra layer of security to the Terraform state file.

State locking on AWS S3

Locking is not supported out of the box for S3 backend, we need to enable it using AWS DynamoDB table.

To enable this feature you will to do the following:

Create an S3 bucket. Enable Versioning and Default Encryption
Create a DynamoDB table and select a name for Partition Key and table name (this is important). I chose table name "TF-locking" and partition key "lockID". Leave other settings as default and hit 'Create Table'.

Modify the settings inside terraform.tf to let Terraform know about your new table. See the snippet below.
We have successfully configured locking on S3! ```terraform

terraform.tf

terraform {
backend "s3" {
bucket = "terraform-state-remote"
key = "dev/aws_infrastructure"
region = "ca-central-1"

dynamodb_table = "TF-locking"
encrypt        = true

}

# other settings below ...
}


&nbsp;

Last thing we need to do is to run `init` command with reconfigure flag:
```bash


$ terraform init --reconfigure

To see locks you need to go the table you created and select 'View Items' and if there are any existing locks they would be displayed in the lockID column in the AWS console.

Thank you for reading! See you in the next article!

Terraform State

AF uarabei — Wed, 22 Jun 2022 01:10:12 +0000

Terraform blocks and modules are the things you use to build your infrastructure, but state is how you manage it after deployment.

A Terraform state is a record of the managed infrastructure. Each time you make an execution plan and attempt to create or modify resource, Terraform will compare your configuration to the existing state.

Local backend

The location of the state file is specified in Terraform backend. By default the state is stored locally, in the working directory inside the terraform.tfstate file. Data is stored in the JSON format and is relatively human-readable. Please note that you should not modify this file. It is extremely rare for anyone to modify it and even in those instances you should know exactly what you are doing.

Backend settings are often specified in the terraform.tf file inside the terraform block. Not specifying a backend is equivalent to this code:

terraform {
  backend "local" {
    path = "terraform.tfstate"
  }

  # other settings...
}

Viewing state

We can see what the current state contains by running terraform show command. Please note that if do not have any running resources the state file will be empty. You can run terraform apply to deploy resources and they will be visible in the show output.

$ terraform show

This command will output a lot of data and sometimes we are just interested in a more compressed view with just a list of resources and their names.
This can be view with the state list command:

$ terraform state list

Terraform state locking

We have touched a little bit on how critical the state is to Terraform and its operation. At some point you might want to have other people to work or manage your Terraform configuration. This is when you want to implement controls to lock the state to prevent accidental updates or changes to the state.

State locking does exactly that. When you have several people working on existing infrastructure you want control when and how changes to it are made. Locking will prevent corruption and it is something that everyone working with Terraform should know about.

To demonstrate Terraform state lock I will first apply my configuration with terraform apply but I will not enter yes to confirm the apply. The deployment will be paused. At this stage the state will be locked.

I will open another terminal window and run apply command again I get this output:

$ terraform apply
╷
│ Error: Error acquiring the state lock
│ 
│ Error message: resource temporarily unavailable
│ Lock Info:
│   ID:        3853fd24-37f7-06be-f354-a6bb5bd4270b
│   Path:      terraform.tfstate
│   Operation: OperationTypeApply
│   Who:       andreyf@Andreys-MacBook-Pro-2.local
│   Version:   1.1.9
│   Created:   2022-06-22 01:03:41.259138 +0000 UTC
│   Info:      
│ 
│ 
│ Terraform acquires a state lock to protect the state from
│ being written
│ by multiple users at the same time. Please resolve the issue
│ above and try
│ again. For most commands, you can disable locking with the
│ "-lock=false"
│ flag, but this is not recommended.

As we can see Terraform encountered an error acquiring the state lock and realizes that there are 2 concurrent apply commands.

If there are several people working on a configuration and pushing changes, it helps to set the -lock-timeout=100s which sets the timeout of 100 seconds to the apply command and waits for the lock to be released before applying changes. Here is an example with 300 seconds (5min):

$ terraform apply -lock-timeout=300s

Not all Terraform backends support, but some do. Here is a list of the backends that support state locking:

Local backend
Remote backend (Terraform Enterprise, Terraform Cloud)
AWS S3 backend (with DynamoDB)
Google Cloud Storage backend
Azure Storage backend

Terraform state backend authentication

Terraform state may contain a lot of sensitive data and protecting the state from unauthorized access is extremely important. Storing the state remotely allows team members to access it too, but it also exposes it to access from other people. Supported backends handle authentication differently.

Terraform S3 standard backend with environment variable authentication

This backend configuration allows us to store the state file inside an S3 bucket.

To setup this backend you would need to create an S3 bucket, make sure that Block ALL PUBLIC ACCESS checkmark is selected because we are trying to protect our state.

Then we need update the backend inside the terraform.tf file:

# terraform.tf

terraform {
  backend "s3" {
    bucket = "my-demo-terraform-state-bucket"
    key    = "dev/s3_terraform_state"
    region = "ca-central-1"
  }

  # more settings below...
}

key specifies where the state file will be stored inside the bucket.

We already imported AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY in installation and usage section this should work. If you need a refresher this is how it's done:

$ export AWS_ACCESS_KEY="my_key"
$ export AWS_SECRET_ACCESS_KEY="my_secret_key"

Since the backend was changed we need to run terraform init command to initialize the backend.

In this exercise we covered two things: setting up an S3 bucket state location and reviewed using environment variables for authentication.

Terraform Remote Enhanced Backed with user token authentication

This is a service provided by Terraform. It allows users to store state files inside Terraform Cloud. In order to use it we need to create a user token and import it into our local environment.

To follow the example in this section you would need a Terraform account on Terraform Cloud. Once logged in create a new organization by providing an organization name and an email.

Once you are done creating an organization, let's go back to our terminal and punch in this command:

$ terraform login
# output
Terraform will request an API token for app.terraform.io using your browser.

If login is successful, Terraform will store the token in plain text in
the following file for use by subsequent commands:
    /Users/andreyf/.terraform.d/credentials.tfrc.json

Do you want to proceed?
  Only 'yes' will be accepted to confirm.

  Enter a value:

Enter yes for the first prompt. It will open a browser window and print this output:

---------------------------------------------------------------------------------

Terraform must now open a web browser to the tokens page for app.terraform.io.

If a browser does not open this automatically, open the following URL to proceed:
    https://app.terraform.io/app/settings/tokens?source=terraform-login


---------------------------------------------------------------------------------

Generate a token using your browser, and copy-paste it into this prompt.

Terraform will store the token in plain text in the following file
for use by subsequent commands:
    /Users/andreyf/.terraform.d/credentials.tfrc.json

Token for app.terraform.io:
  Enter a value:

I named my token terraform login credentials:

Click Create API token and you will get the token.

Now we need to paste this token in our terminal to complete the setup process:

This is the output I got after I added the token:

----------------

Generate a token using your browser, and copy-paste it into this prompt.

Terraform will store the token in plain text in the following file
for use by subsequent commands:
    /Users/andreyf/.terraform.d/credentials.tfrc.json

Token for app.terraform.io:
  Enter a value: 


Retrieved token for user andreyfrol


---------------------------------------------------------------------------------

                                          -                                
                                          -----                           -
                                          ---------                      --
                                          ---------  -                -----
                                           ---------  ------        -------
                                             -------  ---------  ----------
                                                ----  ---------- ----------
                                                  --  ---------- ----------
   Welcome to Terraform Cloud!                     -  ---------- -------
                                                      ---  ----- ---
   Documentation: terraform.io/docs/cloud             --------   -
                                                      ----------
                                                      ----------
                                                       ---------
                                                           -----
                                                               -


   New to TFC? Follow these steps to instantly apply an example configuration:

   $ git clone https://github.com/hashicorp/tfc-getting-started.git
   $ cd tfc-getting-started
   $ scripts/setup.sh

I think this is a good point to wrap up this article. Terraform state is a big topic and it will likely require more than one article to cover the basics.

Thank you for reading and see you in the next article!

XPath vs CSS Selector: what is going on with these two?

AF uarabei — Mon, 20 Jun 2022 18:40:37 +0000

As I was learning scraping I have done many tutorials on it. Some tutorials used XPath and others used god ol' CSS Selectors. Until today I always resorted to CSS because it was a familiar choice. All I new about XPath is that Scrapy uses it by default and any CSS selectors are converted to XPath behind the scenes. Being a complete noob at the time I did not give it much thought. Alas, the time has come for me to sink my teeth into this topic and understand what is the difference between these two types of selectors.

XPath

What it is

XPath stands for XML Path. It uses XML document and queries it to identify elements within it. The path part of XPath means that we need to specify the path from the beginning to the desired element.

Advantages of XPath

Allows navigation up the DOM when looking for elements
More flexible than CSS Selectors
Allows searching for full or partial text in element names with contains keyword

CSS Selector

What it is

CSS Selector uses styles specified in Cascading Style Sheet (CSS) to select desired elements. Most of the web pages online are styled using CSS and that makes CSS Selector a popular choice for a lot of people.

CSS relies on tags, class names, and ids among other things to select what we want. This is in contrast with XPath which uses tree-like structure to select the element.

Advantages of CSS Selector

Simplicity because CSS is easy to pick up
Faster than XPath because we can specify the exact element and completely disregard everything else on the page
Allows attribute selection based on values assigned to them
Allows pseudo selectors for elements whose state is declared with CSS, such as on-hover attributes and checkboxes

Syntax for XPath and CSS Selector

This a great table that shows the differences between XPath and CSS Selector made by Slotix :

Terraform Workflow (write->plan->apply)

AF uarabei — Sun, 19 Jun 2022 22:36:40 +0000

Now that we are familiar with Terraform's building blocks we can start exploring how Terraform expects people to use it.

It may sound silly, but learning workflow can prevent common pitfalls and unexpected problems. I am sure all of us ended up in a situation when we were using something incorrectly. It happens to me very often because I want to use something as soon as possible hoping that I will figure things out as I go.

Since this blog doubles as my study notes, I believe I should not slack off and included this section because it is something that will be tested on the exam.

This photo illustrates basic workflow that Terraform wants its users to follow:

We touched on it during the practice and we followed this workflow without it being formally introduced. So here it is.

First we write our configuration and initialize our project.

Then we format and validate the code to tidy it up and check for syntax error.

After that we do a dry-run (terraform plan) to see what exactly Terraform will attempt to deploy and verify it.

Last step is an actual deploy with terraform apply.

One command that is used often is terraform destroy which destroys deployed resource from current configuration.

Terraform `init` command

This is a command that we used a lot and it is used to initialize terraform projects and update providers. This is the first command we would run after writing our configuration or after cloning existing configuration.

$ terraform init

That's also a command that needs to be run after we add/import new modules and checks if all versions are correct.

This command downloads Terraform backend and sets up things like lock file and other important internal files.

Rule of thumb is that we need to run init whenever we add new modules, change versions, add/remove providers, or change Terraform backend in some way. Luckily, Terraform will inform us if we forgot to initialize our configuration.

Terraform `validate` command

Validate command does exactly what its name suggests. It checks the code for syntax errors and ensures that it is internally consistent. It only looks at the configuration files (*.tf) in the current working directory

$ terraform validate

If you want validate to check files inside folders (eg you have modules/ directory), you need to set -recursive flag:

$ terraform validate -recursive

Terraform `plan` command

This command is often called a dry-run so make sure you remember it. When you hear the words "execution plan" that would be it as well.

It is used to determine the changes to apply to the existing (if any) resources. You will get a report of what is going to be created, modified, or destroyed. Terraform also allows for saving this plan in a file.

You can save the plan and execute that saved plan at a later time or use it for analysis and record keeping.

Execution plan is not a requirement for deployment, but it is always a good idea to see what will happen.

That's how you run it:

$ terraform plan

Terraform `apply` command

This is how you actually deploy your resources or applying changes to your infrastructure. As with plan command, you will also get a report identifying which resources are to be created, modified, or destroyed.

After running this command Terraform will also create a state file. This is a living record of all deployed resources. State warrants a whole articles on its own given how important it is.

One thing to note, this command only applies to the resources specified in your current configuration. It will not touch any existing resources that are not part of the configuration you are deploying.

That's how you deploy resource with Terraform:

$ terraform apply

Or if you don't want to type yes every time, you can set an auto-approve tag:

$ terraform apply -auto-approve

Terraform `destroy` command

Destroying resources is an integral part of Terraform. Deploying consistent and reproducible infrastructure implies that you will be creating and destroying resources when needed.

We used this command extensive in the practice section of this series because we do not want to leave any technical debt behind. It also ensures that we do not incur any unnecessary charges from AWS.

Just like with plan and apply commands, Terraform will show you what exactly it will attempt to destroy.

This is how you use it:

$ terraform destroy

It also supports auto-approve flag:

$ terraform destroy -auto-approve

Thank you for reading! At this point you are becoming somewhat knowledgeable about Terraform and its capabilities. We still have one big topic to cover. This topic is State.

See you in the next article!

Terraform Practice pt4: Module Inputs and Outputs

AF uarabei — Sun, 19 Jun 2022 07:44:53 +0000

To make out modules truly useful we need a way to pass input parameters to them and get output from them to use in our configuration.

Code for this example HERE

It is usually done by creating a varaibles.tf and outputs.tf. This file layout is the best practice and people working with Terraform would generally implement it this way.

varaibles.tf will store input variables and outputs.tf will store outputs from our module.

First, let's refactor out server module and create 3 files: main.tf, variables.tf, and outputs.tf.

Next we need to break down our code and put in inside the proper files:

# modules/server/variables.tf

variable "subnet_id" {}
variable "size" {
    default = "t2.micro"
}
variable "security_groups" {
  type = list(any)
}

# modules/server/main.tf

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  owners = ["099720109477"]
}

resource "aws_instance" "web_server" {
  ami = data.aws_ami.ubuntu.id
  instance_type = var.size
  subnet_id = var.subnet_id
  vpc_security_group_ids = var.security_groups

  tags = {
    Name = "Web Server from module"
    Terraform = "true"
  }
}

# modules/server/outputs.tf

output "public_ip" {
  value = aws_instance.web_server.public_ip
}
output "public_dns" {
  value = aws_instance.web_server.public_dns
}

We can now delete server.tf. Initialize, format, validate, and plan to check the new code.

This is the new project structure:

.
├── main.tf
├── modules
│   └── server
│       ├── main.tf
│       ├── outputs.tf
│       ├── server.tf
│       └── variables.tf
├── outputs.tf
├── terraform.tf
├── terraform.tfstate
├── terraform.tfstate.backup
└── variables.tf

Terrafrom input variables

As with many configurations out there Terraform provides us with ability to specify required and optional parameters. If you look into server's variable.tf you can see that some variables have default values and some do not.

Optional parameters will have a default value to fall back on in case it was not provided.

Required parameters do not have default meaning that it should be specified one way or the other.

Terraform outputs

Similar to variables, outputs serve the same purpose as inputs of providing data between different parts of the configuration. The difference lies in how they are accessed and the fact that outputs are read-only. In order to access outputs you must call them from the module where you intend to access them.

Outputs is the only way for us to access attributes from child modules.

Outputs can be accessed using dot notation (this is main.tf in the root dir):

# main.tf

# ... more code above

output "public_ip" {
  value = module.my_server_module.public_ip
}

Thank you for reading! See you in the next article!

DEV Community: AF uarabei

GCP CI/CD Pipeline: Build Docker images after commits to a repo branch (Google Cloud Source Repositories)

1. Creating a repository in Cloud Source Repositories

2. Source files

3. Creating a Cloud Build trigger

4. Verifying that Dockerimage is built automatically

GCP CI/CD Pipeline: Build Docker images after commits to a repo branch (Github)

1. Create a trigger

2. Run trigger manually

3. Run trigger automatically

Terraform: My experience taking the exam

Registration

Before the Exam

Exam

Thoughts about questions

Conclusion

Terraform Cloud with VCS Workflow(Github)

Terraform State Migration and State Refresh

Terraform state migration

Terraform state refresh

Terraform Enhanced Backend on Terraform Cloud with AWS access keys

Terraform Standard Backends: HTTP Backend

Terraform Standard Backends: S3 with versioning and state locking with DynamoDB

State locking on AWS S3

terraform.tf

Terraform State

Local backend

Viewing state

Terraform state locking

Terraform state backend authentication

Terraform S3 standard backend with environment variable authentication

Terraform Remote Enhanced Backed with user token authentication

XPath vs CSS Selector: what is going on with these two?

XPath

What it is

Advantages of XPath

CSS Selector

What it is

Advantages of CSS Selector

Syntax for XPath and CSS Selector

Terraform Workflow (write->plan->apply)

Terraform init command

Terraform validate command

Terraform plan command

Terraform apply command

Terraform destroy command

Terraform Practice pt4: Module Inputs and Outputs

Terrafrom input variables

Terraform outputs

Terraform `init` command

Terraform `validate` command

Terraform `plan` command

Terraform `apply` command

Terraform `destroy` command