
## Table of Contents

1. [Introduction](#introduction)
2. [Switch to the Correct Workspace Environment](#switch-to-the-correct-workspace-environment)
3. [Pull Latest State File](#pull-latest-state-file)
4. [Test by Running Terraform Plan](#test-by-running-terraform-plan)
5. [Run Import to Update State File](#run-import-to-update-state-file)
6. [Conclusion](#conclusion)

## Introduction

When working with Terraform and existing cloud resources, you may need to import those resources into your Terraform state file. This blog shows how to do that.

## Switch to the Correct Workspace Environment

For example, you can run the following command to create a QA workspace environment:

```
terraform workspace new qa
or
terraform workspace select qa
```

## Pull Latest State File

Run this command to get the latest state file for the environment from storage:

```
terraform state pull
```

This is what you get when you run `terraform state pull` — basically nothing is saved to the current workspace state:

```
{
  "version": 4,
  "terraform_version": "1.4.6",
  "serial": 1,
  "lineage": "59eb4435-e702-29bf-71de-1231231",
  "outputs": {},
  "resources": [],
  "check_results": null
}

```

## Test by Running Terraform Plan

If at this point you run `terraform plan`, you'll see some changes if you have active resources in your local files. This is incorrect if the same resource already exists in GCP, and you don't want to run `terraform apply`, which would end up creating duplicate resources or throwing errors.

## Run Import to Update State File

For instance, if you have an existing GCP BigQuery schedule query, you can run the following command to sync the state file:

```
terraform import google_bigquery_data_transfer_config.job projects/1233/locations/us/transferConfigs/12312312
```

The above command should update the state file, and if you run `terraform plan` again, you should not see any changes.

## Conclusion

Importing existing resources into your Terraform state file ensures that Terraform is aware of your current infrastructure. This prevents duplicate resource creation and keeps your state file in sync with your actual cloud resources.


This blog shows how to run Terraform to create a state file from existing resources.

How to Create Terraform State File for Current Resources


## Table of Contents

1. [About Terraform with GCP](#about-terraform-with-gcp)
2. [Preparation](#preparation)
3. [Create Terraform Files](#create-terraform-files)
4. [Start Deployment](#start-deployment)
5. [Conclusion](#conclusion)

## About Terraform with GCP

Terraform provides infrastructure automation to provision resources to many cloud providers. GCP is one of them. This article shows how to use Terraform to deploy a simple BigQuery Schedule Job to GCP.

## Preparation

Before getting started, ensure you have Terraform installed and a GCP account with the necessary permissions.

## Create Terraform Files

### Create `provider.tf` File

Start with the Terraform provider, Google credentials, and the GCP project.

```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "5.15.0"
    }
  }
}

provider "google" {
  credentials = file("{this is option but your can create GCP service account with BigQuery.job.create role}")
  project = "{your gcp project id}"
}
```

### Create Service Account

For the above credentials, below are a few steps to create a service account with the minimal role to perform the GCP operation.

- Go to the GCP Roles page and create a new custom role with `bigquery.job.create` permission.
- Go to the IAM Service Account page, create a new service account, and then assign the custom role you created.
- Once the service account is created, go to the KEYS tab and click `ADD KEY` to create a new JSON key. Save it locally so the above credentials can reference it.

### Create `backend.tf` File

Here, we're using a GCP Cloud Storage bucket to store the Terraform state file. This is similar to sharing the code within the team so that the same infrastructure is deployed no matter who runs it.

```
terraform {
 backend "gcs" {
   bucket  = "{create a GCP cloud bucket}"
   prefix = "test"
 }
}
```

### Create `schedule-job.tf`

Finally, here is the main code. We're writing a simple query and deploying it to a GCP BigQuery Schedule Job that runs every Sunday.

```
resource "google_bigquery_data_transfer_config" "job" {
    display_name = "test-query"
    project = "{your gcp project}"
    location = "us"
    data_source_id = "scheduled_query"
    schedule = "first sunday of quarter 00:00"
    params = {
      query = "select 1 as ID;"
    }
}
```

## Start Deployment

First, go to the folder containing the above Terraform files and run this command to initialize Terraform and download state files from the GCP Cloud Storage bucket:

```
terraform init
```

This command will create a new workspace called `test`. If it does not exist, the state will be saved to the cloud bucket:

```
terraform workspace new test
```

Run the plan command to check what resources will be created in GCP:

```
terraform plan
```

If you have confirmed the resources, run this command to deploy the changes to GCP:

```
terraform apply
```

## Conclusion

Using Terraform is a great way to deploy infrastructure resources to GCP for production environments. It provides reproducible, version-controlled infrastructure management.


This article demonstrates how to use Terraform to deploy a GCP Schedule Job.

How to Create GCP Schedule Job with Terraform


## Table of Contents

1. [Introduction](#introduction)
2. [Sample Terraform Code](#sample-terraform-code)
3. [Run the Sample Terraform](#run-the-sample-terraform)
4. [Use Variables](#use-variables)
5. [Different Values for Each Environment](#different-values-for-each-environment)
6. [Conclusion](#conclusion)

## Introduction

This blog shows how to use Terraform variables to move environment-specific values out of the code, so you can run the same Terraform configuration for different environments and inject the appropriate variables for each one.

## Sample Terraform Code

This blog uses the following Terraform code to get started.

**_provider.tf_**

```
terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "5.15.0"
    }
  }
}

provider "google" {
  # Configuration options
  credentials = file("your google credential file path")
  project = "{gcp project id}"
}
```

**_backend.tf_**

```
terraform {
 backend "gcs" {
   bucket  = "{gcp bucket for terraform}"
   prefix = "test"
 }
}
```

**_schedule-job.tf_**

```
resource "google_bigquery_data_transfer_config" "job" {
    display_name = "my_test_sj"
    project = "{your project id}"
    location = "us"
    data_source_id = "scheduled_query"
    schedule = "first sunday of quarter 00:00"
    params = {
      query = "call spTest();"
    }
}
```

## Run the Sample Terraform

Running the above sample Terraform should create a scheduled job.

## Use Variables

Now, let's say we want to move the **_display_name_** to a variable, because we want to reuse the same name later.

Let's create a new **_variable.tf_**. If you run `terraform plan`, you can see the display name as **_my_test_sj_**.

### Variable with Default

```
variable "bq_name" {
  type = string
  nullable = false
  default = "my_test_sj"
}
```

### Without Default Variable

Let's say we want to enter the name every time we run Terraform. We can remove the default so that every time we run **_terraform plan_**, it will ask for input for the variable. The example here might not be ideal, but there may be some areas where this approach is useful.

```
variable "bq_name" {
  type = string
  nullable = false
}
```

## Different Values for Each Environment

Assume we have 2 different workspaces: **_dev_** and **_qa_**.

For this case, we define the variables as below.

### variable.tf

```
variable "bq_name" {
  type = string
  nullable = false
}
```

### dev.tfvars

Create a **_dev.tfvars_** file and add the following key-value pairs.

```
name = "dev_job"
```

### qa.tfvars

Create a **_qa.tfvars_** file and add the following key-value pairs.

```
name = "qa_job"
```

At this point, nothing needs to be modified in the schedule job Terraform file. We'll run **_terraform plan_** with the option **_--var-file=dev.tfvars_**. This will run Terraform with the key/value environment variables defined in **_dev.tfvars_**.

```
terraform plan --var-file=dev.tfvars
```

## Conclusion

Using Terraform **_workspaces_** with **_var-file_** allows you to write Terraform configurations for different environments, keeping environment-specific values separate from your infrastructure code.


This blog shows how to use Terraform variables to move environment variables out of the code, so you can run Terraform for different environments and inject the variables for each one.

How to Run Terraform with Input Variables


## Table of Contents

1. [Introduction](#introduction)
2. [Configure AWS](#configure-aws)
3. [Visual Studio Code Extension for HashiCorp Terraform](#visual-studio-code-extension-for-hashicorp-terraform)
4. [Terraform Commands](#terraform-commands)
5. [Other](#other)
6. [Conclusion](#conclusion)

## Introduction

Prerequisites:

- Terraform CLI
- AWS CLI
- AWS Account
- VS Code Extension: HashiCorp Terraform

## Configure AWS

This will be the first step for this tutorial. You'll need to have an AWS account, create a user, and have the access key and secret configured so we can run Terraform with the correctly configured AWS credentials later.

### Install AWS CLI

This blog skips how to install AWS CLI on your local machine, but you can reference [how to get started with AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

### Verify AWS CLI

Check that AWS CLI is working by typing the below command.

```
aws --version
```

### Retrieve AWS Access Keys

If you don't have an AWS user created, you can log in to AWS and create a new user. Once you create a new user, go to the Security Credentials section and retrieve the access key and secret key.

- Create an AWS user
- Create Security Credentials by retrieving the AWS access keys
- Add a role to the AWS user (to make it simple for this blog, we're adding the **_AmazonEC2FullAccess_** permission for testing)

Once you have the access and secret keys, use `aws configure` to set them.

Now, for the below steps, once you run Terraform, it will create resources under this AWS account.

## Visual Studio Code Extension for HashiCorp Terraform

This blog uses VS Code to modify Terraform files and the VS Code extension `HashiCorp Terraform` for Terraform editing. It is a great tool that provides IntelliSense for editing Terraform.

- VS Code Extension: HashiCorp Terraform

## Terraform Commands

List all the available commands for executing Terraform.

```
terraform -help
```

Prepare the local directory for other commands.

```
terraform init
```

```
terraform validate
```

```
terraform fmt
```

```
terraform apply
```

```
terraform destroy
```

```
terraform show
```

```
terraform state list
```

## Other

Get the public key by key pair name:

```
aws ec2 describe-key-pairs --key-names test --include-public-key
```

## Conclusion

With Terraform and the AWS CLI configured, you can easily create and manage AWS EC2 instances as infrastructure as code. Use `terraform init`, `terraform apply`, and `terraform destroy` to manage the lifecycle of your resources.


This blog demonstrates how to set up AWS EC2 with Terraform locally.

How to Create AWS EC2 by Terraform


## Table of Contents

1. [Introduction](#introduction)
2. [Download Binary from HashiCorp](#download-binary-from-hashicorp)
3. [Install the HashiCorp Binary at macOS](#install-the-hashicorp-binary-at-macos)
4. [Conclusion](#conclusion)

## Introduction

The goal here is to be able to run the below command in your local terminal.

```
terraform -help
```

## Download Binary from HashiCorp

After downloading the binary for macOS (for instance, after the download you should see **_terraform_1.4.6_darwin_amd64_**), once you unzip the binary you should see the terraform binary file.

## Install the HashiCorp Binary at macOS

If you're getting an error like **_"terraform" cannot be opened because the developer cannot be verified_**, you can try the below setting to avoid this error:

- System Preferences
- Security & Privacy
- Choose General

Once the terraform binary file is allowed on your local machine, run the below code in the terminal to include the **_terraform_** file in the path.

Type this to check the current **_PATH_**:

```
echo $PATH
```

Type this to move the terraform file to the user's PATH folder:

```
mv ~/Downloads/terraform /usr/local/bin/
```

Now, if you type the below command and it works, you should see a list of help commands.

```
terraform -help
```

## Conclusion

Installing Terraform on macOS is straightforward — download the binary from HashiCorp, allow it in your security settings, and move it to a directory in your PATH. You can then verify the installation by running `terraform -help`.


A quick guide on how to download and install the Terraform binary on macOS.

Terraform

How to Create Terraform State File for Current Resources

How to Create GCP Schedule Job with Terraform

How to Run Terraform with Input Variables

How to Create AWS EC2 by Terraform

Install Terraform at macOS