Terraform training 🎒 - Basic

Editor's Notes

• #2: Thanks everyone for joining us today. As usual we’ll be waiting for 5 min. Put music https://open.spotify.com/playlist/4idpO55zNoCMNTtuqP0rlB?si=56914a0f6fd94054&nd=1#login For future training, webinars and use cases, follow our LinkedIn page. CTA like the Linkedin page -> share the LinkedIn page: https://www.linkedin.com/company/brainboard-co
• #4: Quick introduction about what we are working on at Brainboard. Bidirectional way from code to design and vice versa.
• #5: We will not be talking about the history of infrastructure as code, neither its benefits and why it is useful. There are hundreds of articles and information that you can find online. Our goal today is to: Understand clearly how terraform works How you can use it in real life to manage cloud infrastructures, not just in theory We’ll be using Brainboard today to save time as it generates the Terraform code and also helps on the explanation or how IaC works. I suggest if you want to do it in a hands on way that you either login or create an account in Brainboard. You can also use your vscode editor and terminal if you want. I highly recommend that you follow us this way and not just listen to it as literature. Tarak shares https://app.brainboard.co/register Stephane & Tarak are with us today, they’ll be your host and managing your questions
• #6: Explain the different topics quickly We’ll be taking questions regularly, so if you have any questions ask in the chat and the team will handle it
• #7: Versioning Testing Code review Automatic deployment Change management
• #8: 2 lives: before and after the code All the tools we see now are mainly focused on deployments: … -> once you are the code The big part is now emerging - push button deploy We will see every part of that Life - Before the code
• #9: Talk about the installation of Terraform, download the binary. At the end they can import code and learn from public repos. HCL is like YAML with JSON capabilities. Like comments… In the how talk about architecture: so you design your architecture which is the state you want to achieve and Terraform handles the interactions with the cloud providers and their APIs. Terraform the project that compiles to the binary hosted at https://github.com/hashicorp/terraform Cloud providers that contains the resources for eg: https://github.com/hashicorp/terraform-provider-aws you usually interact with that through the documentation only https://registry.terraform.io/providers/hashicorp/aws/latest/docs unless you hit an issue or you look for a new missing feature Tarak sends all the link of this page + link from the slides
• #10: Talk about the installation of Terraform, download the binary. At the end they can import code and learn from public repos. HCL is like YAML with JSON capabilities. Like comments… In the how talk about architecture: so you design your architecture which is the state you want to achieve and Terraform handles the interactions with the cloud providers and their APIs. Terraform the project that compiles to the binary hosted at https://github.com/hashicorp/terraform Cloud providers that contains the resources for eg: https://github.com/hashicorp/terraform-provider-aws you usually interact with that through the documentation only https://registry.terraform.io/providers/hashicorp/aws/latest/docs unless you hit an issue or you look for a new missing feature Tarak sends all the link of this page + link from the slides
• #11: Preflight checks: Checks the binary if it matches the configuration Check if you want a specific version of the provider or use latest version Download modules Compare configuration files (can .tf files or a saved plan) against the state to know what to do, that’s why it’s extremely important to save this file in a safe place This is a global picture, we’ll zoom a bit on the supported actions on resources later on This is a the first training and we’ll be doing deep dives in every section, modules, remote backend configuration, secure connection, create workflows.... State files Matching the state with the conf files to create, destroy/destroy & recreate and update Cloud providers, are distributed separately API Versions
• #12: Give examples of var, terraform conf block Blocks are optional in some situations here are some examples: in BB Terraform conf Variable Resource Give example of expressions Identifiers can contain letters, digits, underscores (_), and hyphens (-). The first character of an identifier must not be a digit, to avoid ambiguity with literal numbers. It’s a good practice to use fmt or tflint project https://github.com/terraform-linters/tflint as part of your CI
• #16: Infrastructure should be considered in its entirety not just provisioning part. You need to care about all the points around the infrastructure for costs, security and maintenaibility
• #18: https://registry.terraform.io/browse/providers
• #19: For the version and source give an example of cloudflare
• #20: Create resources that exist in the configuration but are not associated with a real infrastructure object in the state. Destroy resources that exist in the state but no longer exist in the configuration. Update in-place resources whose arguments have changed. Destroy and re-create resources whose arguments have changed but which cannot be updated in-place due to remote API limitations. The ID card with the generated code
• #21: Give example of attribute accessible Give examples of dependency When to use count = identical resources and for_each for specific information For_each values should be known for_each = { a_group = "eastus" another_group = "westus2" } name = each.key location = each.value Chain for_each variable "vpcs" { type = map(object({ cidr_block = string })) } resource "aws_vpc" "example" { # One VPC for each element of var.vpcs for_each = var.vpcs # each.value here is a value from var.vpcs cidr_block = each.value.cidr_block } resource "aws_internet_gateway" "example" { # One Internet Gateway per VPC for_each = aws_vpc.example # each.value here is a full aws_vpc object vpc_id = each.value.id }
• #22: data "aws_ami" "example" { most_recent = true owners = ["self"] tags = { Name = "app-server" Tested = "true" } } data "local_file" "foo" { filename = "${path.module}/foo.bar" } resource "aws_s3_bucket_object" "shared_zip" { bucket = "my-bucket" key = "my-key" content = data.local_file.foo.content }
• #24: Source accept registry, git, s3…. For_each added in v0.13
• #26: Thanks everyone for joining us today. As usual we’ll be waiting for 5 min. Put music https://open.spotify.com/playlist/4idpO55zNoCMNTtuqP0rlB?si=56914a0f6fd94054&nd=1#login For future training, webinars and use cases, follow our LinkedIn page. CTA like the Linkedin page -> share the LinkedIn page: https://www.linkedin.com/company/brainboard-co
• #27: Especially in the CI/CD and automation in general but also cross environments It means we may have errors that we debug together, we may simulate errors to better understand how it works….
• #28: Explain the different topics quickly We’ll be taking questions regularly, so if you have any questions ask in the chat and the team will handle it
• #29: How variables are defined and used in the CI/CD pipeline: variables.tf vs *.tfvars To show case the different argument create a vpc + subnet + instance -> this is a real use case The purpose here is also to see the thinking process, start with the simplest form you can and add organically constraints Input = variables & locals Let’s start with variables as they slightly differ from locals Arguments, type: list(string) Map List of map or object list(object({ internal = number external = number protocol = string })) Map or map(string) If default and type are present, the default should be in the specified type. Show an example In validation you can use Terraform functions like. Show an example: length(var.toto) > 4 Sensitive: show an example of a resource containing a sensitive information sensitive in TF is week, it’s better to treat sensitive as secrets and hide them with your vault because if it’s part of the id it will be printed even if it’s sensitive Use random_pet Error messages
• #31: I know the value of my variable, so where do I put it’s value? tfvars: this is how tf passes vars in their cloud offering and this how bb also do it Show bb separation between variables.tf and variables.tfvars Space around = are not tolerated…. In command line vars TF_VAR_varname=”toto” difference between env vars and files is with env var there are no warnings or error messages
• #34: How variables are defined and used in the CI/CD pipeline: variables.tf vs *.tfvars To show case the different argument create a vpc + subnet + instance -> this is a real use case The purpose here is also to see the thinking process, start with the simplest form you can and add organically constraints Input = variables & locals Let’s start with variables as they slightly differ from locals Arguments, type: list(string) Map List of map or object list(object({ internal = number external = number protocol = string })) Map or map(string) If default and type are present, the default should be in the specified type. Show an example In validation you can use Terraform functions like. Show an example: length(var.toto) > 4 Sensitive: show an example of a resource containing a sensitive information sensitive in TF is week, it’s better to treat sensitive as secrets and hide them with your vault because if it’s part of the id it will be printed even if it’s sensitive Use random_pet Error messages
• #37: Quick introduction about what we are working on at Brainboard. Bidirectional way from code to design and vice versa.