book

Terraform in Action

by Scott Winkler

July 2021

Intermediate to advanced

408 pages

9h 51m

English

Manning Publications

Read now

Unlock full access

forewordprefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: A roadmapAbout the codeliveBook discussion forumabout the authorabout the cover illustration
1.1 What makes Terraform so great?1.1.1 Provisioning tool1.1.2 Easy to use1.1.3 Free and open source software1.1.4 Declarative programming1.1.5 Cloud-agnostic1.1.6 Richly expressive and highly extensible1.2 “Hello Terraform!”1.2.1 Writing the Terraform configuration1.2.2 Configuring the AWS provider1.2.3 Initializing Terraform1.2.4 Deploying the EC2 instance1.2.5 Destroying the EC2 instance1.3 Brave new “Hello Terraform!”1.3.1 Modifying the Terraform configuration1.3.2 Applying changes1.3.3 Destroying the infrastructure1.4 Fireside chatSummary
2.1 Process overview2.1.1 Life cycle function hooks2.2 Declaring a local file resource2.3 Initializing the workspace2.4 Generating an execution plan2.4.1 Inspecting the plan2.5 Creating the local file resource2.6 Performing No-Op2.7 Updating the local file resource2.7.1 Detecting configuration drift2.7.2 Terraform refresh2.8 Deleting the local file resource2.9 Fireside chatSummary
3.1 Fun with Mad Libs3.1.1 Input variables3.1.2 Assigning values with a variable definition file3.1.3 Validating variables3.1.4 Shuffling lists3.1.5 Functions3.1.6 Output values3.1.7 Templates3.1.8 Printing output3.2 Generating many Mad Libs stories3.2.1 for expressions3.2.2 Local values3.2.3 Implicit dependencies3.2.4 count parameter3.2.5 Conditional expressions3.2.6 More templates3.2.7 Local file3.2.8 Zipping files3.2.9 Applying changes3.3 Fireside chatSummary
4.1 Architecture4.2 Terraform modules4.2.1 Module syntax4.2.2 What is the root module?4.2.3 Standard module structure4.3 Root module4.3.1 Code4.4 Networking module4.5 Database module4.5.1 Passing data from the networking module4.5.2 Generating a random password4.6 Autoscaling module4.6.1 Trickling down data4.6.2 Templating a cloudinit_config4.7 Deploying the web application4.8 Fireside chatSummary

5.1 The “two-penny website”5.2 Architecture and planning5.2.1 Sorting by group and then by size5.3 Writing the code5.3.1 Resource group5.3.2 Storage container5.3.3 Storage blob5.3.4 Function app5.3.5 Final touches5.4 Deploying to Azure5.5 Combining Azure Resource Manager (ARM) with Terraform5.5.1 Deploying unsupported resources5.5.2 Migrating from legacy code5.5.3 Generating configuration code5.6 Fireside chatSummary
6.1 Standard and enhanced backends6.2 Developing an S3 backend module6.2.1 Architecture6.2.2 Flat modules6.2.3 Writing the code6.3 Sharing modules6.3.1 GitHub6.3.2 Terraform Registry6.4 Everyone gets an S3 backend6.4.1 Deploying the S3 backend6.4.2 Storing state in the S3 backend6.5 Reusing configuration code with workspaces6.5.1 Deploying multiple environments6.5.2 Cleaning up6.6 Introducing Terraform Cloud6.7 Fireside chatSummary
7.1 A tale of two deployments7.2 CI/CD for Docker containers on GCP7.2.1 Designing the pipeline7.2.2 Detailed engineering7.3 Initial workspace setup7.3.1 Organizing the directory structure7.4 Dynamic configurations and provisioners7.4.1 for_each vs. count7.4.2 Executing scripts with provisioners7.4.3 Null resource with a local-exec provisioner7.4.4 Dealing with repeating configuration blocks7.4.5 Dynamic blocks: Rare boys7.5 Configuring a serverless container7.6 Deploying static infrastructure7.7 CI/CD of a Docker container7.7.1 Kicking off the CI/CD pipeline7.8 Fireside chatSummary
8.1 Hybrid-cloud load balancing8.1.1 Architectural overview8.1.2 Code8.1.3 Deploy8.2 Deploying an MMORPG on a federated Nomad cluster8.2.1 Cluster federation 1018.2.2 Architecture8.2.3 Stage 1: Static infrastructure8.2.4 Stage 2: Dynamic infrastructure8.2.5 Ready player one8.3 Re-architecting the MMORPG to use managed services8.3.1 Code8.3.2 Ready player two8.4 Fireside chatSummary
9.1 Lifecycle customizations9.1.1 Zero-downtime deployments with create_before_destroy9.1.2 Additional considerations9.2 Blue/Green deployments9.2.1 Architecture9.2.2 Code9.2.3 Deploy9.2.4 Blue/Green cutover9.2.5 Additional considerations9.3 Configuration management9.3.1 Combining Terraform with Ansible9.3.2 Code9.3.3 Infrastructure deployment9.3.4 Application deployment9.4 Fireside chatSummary
10.1 Self-service infrastructure provisioning10.1.1 Architecture10.1.2 Code10.1.3 Preliminary deployment10.1.4 Tainting and rotating access keys10.2 Refactoring Terraform configuration10.2.1 Modularizing code10.2.2 Module expansions10.2.3 Replacing multi-line strings with local values10.2.4 Looping through multiple module instances10.2.5 New IAM module10.3 Migrating Terraform state10.3.1 State file structure10.3.2 Moving resources10.3.3 Redeploying10.3.4 Importing resources10.4 Testing infrastructure as code10.4.1 Writing a basic Terraform test10.4.2 Test fixtures10.4.3 Running the test10.5 Fireside chatSummary
11.1 Blueprints for a Terraform provider11.1.1 Terraform provider basics11.1.2 Petstore provider architecture11.2 Writing the Petstore provider11.2.1 Setting up the Go project11.2.2 Configuring the provider schema11.3 Creating a pet resource11.3.1 Defining Create()11.3.2 Defining Read()11.3.3 Defining Update()11.3.4 Defining Delete()11.4 Writing acceptance tests11.4.1 Testing the provider schema11.4.2 Testing the pet resource11.5 Build, test, deploy11.5.1 Deploying the Petstore API11.5.2 Testing and building the provider11.5.3 Installing the provider11.5.4 Pets as code11.6 Fireside chatSummary
12.1 Poor person’s Terraform Enterprise12.1.1 Reverse-engineering Terraform Enterprise12.1.2 Design details12.2 Beginning at the root12.3 Developing a Terraform CI/CD pipeline12.3.1 Declaring input variables12.3.2 IAM roles and policies12.3.3 Building the Plan and Apply stages12.3.4 Configuring environment variables12.3.5 Declaring the pipeline as code12.3.6 Touching base12.4 Deploying the Terraform CI/CD pipeline12.4.1 Creating a source repository12.4.2 Creating a least-privileged deployment policy12.4.3 Configuring Terraform variables12.4.4 Deploying to AWS12.4.5 Connecting to GitHub12.5 Deploying “Hello World!” with the pipeline12.5.1 Queuing a destroy run12.6 Fireside chat12.6.1 FAQSummary
13.1 Securing Terraform state13.1.1 Removing unnecessary secrets from Terraform state13.1.2 Least-privileged access control13.1.3 Encryption at rest13.2 Securing logs13.2.1 What sensitive information?13.2.2 Dangers of local-exec provisioners13.2.3 Dangers of external data sources13.2.4 Dangers of the HTTP provider13.2.5 Restricting access to logs13.3 Managing static secrets13.3.1 Environment variables13.3.2 Terraform variables13.3.3 Redirecting sensitive Terraform variables13.4 Using dynamic secrets13.4.1 HashiCorp Vault13.4.2 AWS Secrets Manager13.5 Sentinel and policy as code13.5.1 Writing a basic Sentinel policy13.5.2 Blocking local-exec provisioners13.6 Final wordsSummary
A.1 Creating an AWS accountA.2 Creating an IAM userA.3 Installing the AWS CLI (optional)A.4 Configuring the credentials fileA.5 Configuring the AWS provider in Terraform
B.1 Creating an Azure accountB.2 Installing the Azure CLIB.3 Obtaining credentials via the CLIB.4 Configuring Azure CLI authentication in Terraform
C.1 Creating a GCP accountC.2 Creating a new projectC.3 Installing the Google Cloud SDKC.4 Authenticating with the Google Cloud SDKC.5 Configuring the GCP provider in Terraform
D.1 Installing the providerD.2 Using the providerD.3 Final thoughts
E.1 Registering the data sourceE.2 Creating the data sourceE.3 Writing acceptance testsE.3.1 Running acceptance testsE.4 Using the data source

Content preview from Terraform in Action

7 CI/CD pipelines as code

This chapter covers

Designing a CI/CD pipeline as code on GCP
Two-stage deployments for separating static and dynamic infrastructure
Iterating over complex types with for_each expressions and dynamic blocks
Implicit vs. explicit providers
Creating custom resources with local-exec provisioners

CI/CD stands for continuous integration (CI) / continuous deployment (CD). It refers to the DevOps practice of enforcing automation in every step of software delivery. Teams that practice a culture of CI/CD are proven to be more agile and able to deploy code changes more quickly than teams who do not practice a culture of CI/CD. There is also the ancillary benefit of improving software quality, as faster code delivery tends ...