Adding a New Provider to Your Configuration

Provider plugins are Terraform’s superpower

• a provider is a terraform plugin which allows user manage an external API

• these plugins are available in public and private registries or even local file system

• three types of plugins available
  • Official: written by Terraform
  • Verified: written by third-part org, verified as Hashicorp Technology Partner
  • Community: written by community, not verified

• All providers are open-source

• Providers are a collection of resources and data sources

• They are versioned, by semantic numbering
  • in case an update breaks your deployment

• Can call multiple instances of same provider
  • e.g. as each AWS instance is linked to one region and account, call two instances for multi-region

Provider Syntax

• Provider information is provided in the Terraform configuration block, nested within a required_providers block
  • NOTE: not in the provider block

• Terraform configuration block configures general settings like
  • terraform version
  • back end settings for state data
  • required provider plugins
  • provider metadata
  • experimental language features

    

• each key is the name reference for a provider plugin
  • use standard provider name unless using multiple instances of same provider

• the value is a map defining source of plugin and its version
  • terraform registry has shorthand notation
  • alternate locations require an expanded form

    

• the ~> before 3.0 indicate to terraform we are happy to use the latest plugin in the form 3.x

• deployment breaks normally occur on major releases (going from 3.0 to 4.0) so staying within same major release should keep things stable. Should, depending on provider

• Once required providers have been defined, they can be referenced in a provider block

  

• We did some housekeeping with our configuration

• we defined the required providers and removed the access key variables as we will define them as Env Variables

• because we have added new providers, we need to run terraform init again before updating because we will need to download these new plugins, which is done during the init stage

• there is a Official Random provider which added randomness to terraform configuration files
  • one use case would be adding a unique identifier to ensure a S3 bucket’s name is globally unique

Planning and Dependencies

• when terraform is running deployment to match config, it needs to plan

• happens during a plan, apply or destroy

• to create the plan of action, Terraform
  • first, refreshes and inspects the state data
  • second, parse config and build a dependency graph based on the data sources and resources in code
  • then compares graph with state data and makes the list of additions, updates and deletions
  • tries to make as many changes at the same time as others, except those that are dependent on others completing first
    • makes decision about the order of changes by checking for references within a resource block to other resources
    • this is automatically done by terraform in most cases
    • when it’s not worked out by terraform, using the depends_on ensures a resource will wait till another has been successfully created

  Post Deployment Configuration

• sometimes configuration needs to be performed after deployment
  • such as, loading application onto a virtual machine
  • configuring a database cluster
  • generating files on an NFS share

• if you want to stay in Terraform env, there are many providers and resources that can help
  • File resource
  • mySQL provider

• another option is to pass data to servers and their OS specifically when they startup
  • all major cloud providers offer this
  • downside is terraform cannot track if successfully passed or not

• can also leverage configuration management software
  • e.g Ansible, Puppet, Chef
  • these can bake the config management software into an image for a machine and get terraform use that image when it creates instance

• Last option is Terraform Provisioners
  • last option

• Provisioners are defined as part of resource

• executed during resource creation or destruction

• each resource can have multiple provisioners

• to run a provisioner without a resource, run within a null_resource

• if provisioner fails, can tell terraform to fail all resource or continue on

• Provisioner is a last result because Terraform can’t fully understand or manage them

• You need to check for errors, idempotence and consistency

• Three types of Provisioners
  1. File: create files and directories on remote system
  2. Local-exec: run a script on the local machine executing terraform run
     1. used for functionality which may not yet be in a provider
     2. most common provisioner
  3. Remote-exec: run a script on a remote system

• In most cases, a file provisioner or remote-exec provisioner can be replaced by passing data to instance on creation through user data in aws or similar for other cloud providers

Formatting of terraform files can be done using

which automatically makes the changes to the files to bring them in line with Hashicorp standard for HC configuration files

Summary

• We learnt how to add a new provider

• how to specify proper version and source in provider’s block

• learnt about Terraform’s dependency graph

• learnt how to perform post deployment configuration