0% found this document useful (0 votes)
11 views

CloudFoundation - Terraform and CICD

GCP CloudFoundation Teraform

Uploaded by

noxeyop637
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

CloudFoundation - Terraform and CICD

GCP CloudFoundation Teraform

Uploaded by

noxeyop637
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

Proprietary + Confidential

Terraform getting started


IaC fundamentals
Proprietary + Confidential
Proprietary + Confidential

Topics

1 IaC

2 Terraform Basics

3 CI/CD

4 Hands-on demo
Proprietary + Confidential

Infrastructure
as Code
Proprietary + Confidential

Benefits of IaC

Commit, version, trace, deploy, and collaborate,


Automate
just like source code

Declarative Specify the desired state of infrastructure, not updates

Roll back Roll out and roll back changes just like a regular application
No reinventing the
wheel, use software
Validate Assess desired state vs. current state infrastructure engineering practices
for infrastructure.

Scale Build reusable infrastructure blocks across an organization


Proprietary + Confidential

Terraform
Terraform is an infrastructure as code tool developed by HashiCorp that automates the building
and management of infrastructure using a declarative language

Multi-cloud Open core with


Large community
and multi-API enterprise support

Support for all major Cloud Three different editions Thousands of third-party
providers as well as many ranging from self-hosted to providers and modules
other services exposed fully managed with available from the Terraform
through an API (like GitHub, enterprise-level support Registry
Kubernetes)
Proprietary + Confidential

When to use Terraform


(or any IaC solution) and when not.

When to use IaC. When not.


● If you want a well-documented, homogenous environment ● Don’t necessarily use Terraform for playing around in sandbox
across stages, use IaC. Don’t let developers/administrators do environments.
manual changes on test/prod environments. This will help you
to understand and recover from outages faster.
● If you want to reduce operational toil, use automated
pipelines to push code to your environments, that are
triggered by code changes.
● If you want to provide solutions to others, you can do this
automated + establish automated monitoring and alerting for
infrastructure deployments
Service Catalog - Self Enablement
Proprietary + Confidential

Controlled Distribution
A product that surfaces curated, verified, Cloud admins manage visibility and deployment
access to curated templates and solutions at the
and approved deployment templates and organization, folder, and project levels.
cloud solutions defined by cloud
administrators to enable developers & Increased Discoverability
One-stop shop (catalog) for all pre-approved
operators to quickly and consistently product configs, templates, and solutions.
consume organization compliant and secured
solutions.
Ensured Compliance and
Governance
Cloud admins have full control over curated
templates and solutions ensuring that
deployments adhere to the organization policies.
Proprietary + Confidential

Terraform
basics
Proprietary + Confidential

Declarative Infrastructure

Declarative (statement) Imperative (command)

VS.
“I should have 5 servers” “Give me 5 servers”
Proprietary + Confidential

Key Concepts

01 02 03
Resource Configuration State Provider

Declarative configuration Terraform’s view of existing Implements API calls to


of the infrastructure setup infrastructure and desired create/update/delete
using HCL: Hashicorp outcome resources.
Configuration Language
Proprietary + Confidential

Providers

● Think of Terraform providers as "plugins" terraform {


that extend Terraform functionality, like required_providers {
google = {
mapping specific APIs to Terraform source = "hashicorp/google"
resources. version = "4.28.0"
● Each provider exposes specific resource }
}
types and implements its own
}
configuration.
● The Google Cloud Provider is jointly provider "google" {
# Configuration options
maintained by Google and Hashicorp
}
● Two sets of providers: google and
google-beta (you can use both together)
Proprietary + Confidential

State

● Maps your code to the actual resources


● Prior to any operation, Terraform does a terraform {
refresh to update the state with the real backend "gcs" {
bucket = "gcp-foundation-tfstate"
infrastructure prefix = "terraform/state/projects"
}
● Stores Terraform’s view of your
}
infrastructure as a large JSON file
● By default, stored locally in
terraform.tfstate
● Recommended to store with a GCS
backend
Proprietary + Confidential

Resource configuration (HCL language)


● Configuration language, not a variable “parent_folder” {
default = “123456789”
programming language }
resource "google_storage_bucket" "my_bucket" {
● Block types: // this is a single-line comment
○ variable count = 2
display_name = "my-bucket-${count.index}"
○ resource }
data "google_active_folder" "common" {
○ data display_name = "${var.parent_folder}-common"
○ output parent = var.parent_folder
}
○ module output "folder_id" {
value = data.google_active_folder.common.name
○ locals description = "The name of the bucket being
○ backend/ providers created"
}
● Functions, conditional expressions,
operators, comments…
Proprietary + Confidential

Code layout

Terraform code is structured in modules: the


top-level folder is your "root module". ├── terraform.tfvars
├── logging.tf
● All .tf files are parsed together ├── backend.tf
├── iam.tf
● File names and ordering don't matter ├── cloud-function.tf
● Minimal best practices ├── main.tf
├── outputs.tf
○ main.tf for resources ├── providers.tf
├── variables.tf
○ outputs.tf for outputs └── versions.tf
○ variables.tf for variables
○ backend.tf for backend
○ Same for providers, versions
● terraform.tfvars for defining variables
Proprietary + Confidential

Terraform CLI commands


Main commands you'll be using: Advanced commands:
● init - initializes the Terraform working ● output - shows outputs from state (can output
directory, pulls providers JSON)

● plan - computes and shows execution ● fmt - formats your .tf files
plan to converge existing to described
● destroy - destroys all resources managed by
● apply - applies the computed plan to current state
converge infrastructure
● state - examines and manipulates state (list, show,
mv, rm, push, pull)

● taint / untaint - (un)marks a resource for recreation


on next apply

● show - shows human-readable state or saved plan


(can output JSON)

● refresh - reconcile the state Terraform knows about


with real-world infrastructure
Proprietary + Confidential

The Terraform Workflow


Separation of Duties

Write Plan Apply Evolve

The “terraform plan” stage


After validating the plan, the
compares the defined Terraform managed
“terraform apply” stage
Declaratively define desired infrastructure as code infrastructure is
executes the plan and
infrastructure as code in against the existing continuously evolved over
either creates, modifies, or
either HCL or JSON environment, and outputs a time using the same
deletes infrastructure within
proposed “plan” of all declarative code base
the environment
changes that will be made
Proprietary + Confidential

CI/CD: Terraform
Automation
Proprietary + Confidential

Evolve
CI/CD Pipeline
Git Repositories Google Cloud

Team / Product 1 @ Folder


Triggers a
pipeline
Dev @ Project
branch @
CI/CD
Product 1
pipeline Prod @ Project
… (for ex.
Cloud
branch @ Build)
DevOps Product N Team / Product N @ Folder
Engineer(s)

IaC commands Dev @ Project


Pushing code ran by the
pipeline (for ex.
‘Terraform Prod @ Project
apply’)
Proprietary + Confidential

CICD: Automated Terraform Workflow

When running Terraform in automation, the basic path is broadly the same as the familiar Terraform CLI
commands, with some additional options:

● terraform init -input=false to initialize the working directory.


● terraform plan -out=tfplan -input=false to create a plan and save it to the local file tfplan.
● terraform apply -input=false tfplan to apply the plan stored in the file tfplan.

The -input=false option indicates that Terraform should not attempt to prompt for input, and instead
expect all necessary values to be provided by either configuration files or the command line.

image: hashicorp/terraform:full
pipelines:
default:
- step:
script:
- terraform init
- terraform plan -out=tfplan -input=false
- if [ $BITBUCKET_BRANCH == main ];
then terraform apply -input=false tfplan; fi
Proprietary + Confidential

Demo

You might also like