Infrastructure as code is also sometimes referred to as software defined infrastructure.
AWS CloudFormation makes it easy to use programming languages or even a text file to securely model and provision the resources you need to run your application.
One potential drawback of opting for AWS CloudFormation is that it effectively locks you into AWS as a cloud provider, unless you want to start over.
Learn more about CloudFormation:
You will need to consult the AWS CLI Command Reference for RDS to determine the CLI commands you will need to use to create and delete a database with these parameters:
aws rds create-db-instance \ --allocated-storage 20 --db-instance-class db.t2.micro \ --db-instance-identifier myinstancename \ --engine postgres \ --master-username myname \ --master-user-password secret99 --no-publicly-accessible
on't forget to return to the CLI to delete your database!
aws rds delete-db-instance \ --db-instance-identifier myinstancename \ --skip-final-snapshot
Learn more about Terraform here:
Terraform has its own configuration language,Hashicorp Configuration Language (HCL), that it uses primarily to declare resources.
HCL is declarative, meaning you use it to describe your desired infrastructure and Terraform will figure out how to create what you requested in the code
The set of files used to describe infrastructure in Terraform is referred to as a Terraform configuration
Terraform configuration files are named with the .tf file extension. A JSON-based varian of Terraform language uses the .tf.json file extension
A Terraform configuration can be as simple as a single root module (folder) containing one .tf file.
To get help or view information about a specific command, pass the -h
flag after the command. For example, to learn more about the ‘show’ command, type:
terraform show -h
Try it out with a simple terraform file like the example shown below. Name the file terraform.tf
and run it from a working directory in your terraform root folder.
provider "aws" { access_key = "<Your Access Key>" secret_key = "<Your Secret Key>" region = "us-east-1" } resource "aws_instance" "example" { ami = "ami-0742b4e673072066f" instance_type = "t2.micro" }
Run terraform init
, terraform plan
, terraform apply
, and terraform destroy
and observe the results in the AWS EC2 Management console.
Read more about Terraform here:
Terraform variables are commonly stored in either a variables.tf
or .tfvars
file in a Terraform configuration
Input variables are used to make your code more configurable by allowing you to SEND values into Terraform
Output variables output or print an expression from Terraform.
Terraform modules ensure that the configurations in your lifecycle environments are the same.
Terraform modules abstract your infrastructure descriptions by describing it as architecture and not actual objects.
Terraform modules are a set of Terraform configuration files in a folder.
Terraform modules can be reused in different environments, so that the code in the environments is the exact same.
A Terraform module best practice is to have separate git repositories for reusable modules and live infrastructure and specify a versioned module git URL in the source parameter instead of your local filesystem.
Terraform modules can be created and shared among Terraform users on Terraform Registry or in private registries. Using premade modules is a good way to get started.
Terraform is a declarative language that describes infrastructure in terms of the end goal as opposed to a series of steps it would take to get there.
An example of how declarative code differs from procedural code would be changing the number of servers in a .tf file to increase the number of running servers from 2 to 4. Terraform would recognize that two servers have already been created based on the .tfstate, and add two more because the end goal is 4 servers. In procedural language such as an AWS CLI command, increasing the server count to 4 would result in 4 additional servers.
https://www.cnblogs.com/Answer1215/p/15350900.html
Learn more about Terraform Modules
The Terraform state file, terraform.tfstate
, is how Terraform is able to keep track of the elements of your infrastructure it is responsible for. The state file allows Terraform to find the resources it has previously created or updated and proceed to carry out the current instruction
terraform.tfstate
is a JSON file that maps the instructions in your configuration files to the actual resource in the real world and maintains all of the metadata about the resource so it can keep track of its status.
Instead of using version control for your terraform.tfstate
file, the terraform best practice is to use a remote backend to store the file.
If you are already using Terraform with AWS, your best bet would be to use AWS S3 as your remote backend.
AWS S3 is extremely durable, so losing your state file is nearly impossible
AWS S3 supports encryption in transit and at rest, and it supports versioning, so if you ever need to roll back your changes, all of your older versions are available
Storing a terraform.tfstate
file in S3 would cost almost nothing.
https://www.cnblogs.com/Answer1215/p/15350921.html
Read more about Terraform State
What do you think is the worst thing that can happen if Terraform isn’t implemented correctly?
In my opinion, the #1 worst thing that can happen is having your secrets accidentally exposed in your tfstate file or even worse your AWS config file in a public repo. Even though you are learners, you should start implementing the best practice of strong single-use passwords and multi-factor authentication. Once someone with bad intentions has your password, they will be off to the races trying to use it to get into other parts of your infrastructure.
AWS does scan public repos for secrets and notifies users when they have made such a mistake, but by that time, anything could have happened, and by anything, I mean a person may have provisioned quantum computers to mine bitcoin on your AWS account. Which brings me to another reminder to always set a billing alarm when you create an AWS account!
Best practices are subjective and what works best for one company won’t work for another, These practices will generally keep you aware of the power of Terraform and the risks and rewards of running infrastructure as code
Ultimately, the implementation of a best practices culture at your company will lay the foundation for effective team communication, rapid issue resolution, and predictable deployments.
Terraform implementation should be done incrementally with all members of the team on board.
Terraform is not the answer for every company, especially a company that doesn’t want to use it. The risk of using it improperly is too great
Terraform has the best chance of succeeding at your company when it is used to address a specific pain point, and it performs that function well
More Best Practies
Tips & Tricks
Please follow the links below to learn more about Terraform. Terraform is the industry-leading IaC tool, and learning more about how to manage infrastructure using Terraform will be great for your cloud architecture career.