- Okay so to begin with, we're gonna talk about
the Terraform block and provider blocks
in your Terraform config.
The Terraform block is used to configure Terraform itself.
So one common thing to put here is the required version.
So especially since version 12,
it's pretty important to specify
that you're using configuration that's compatible
with 0.12 or above.
But it's always a good idea to include this block
just so that you know that somebody doesn't try and run
your configuration with some older version.
And you can see that this works really simply.
Okay so I've told it that we're gonna require
Terraform version 13, which doesn't exist currently.
But if we do Terraform 12, 0.12,
it should tell us that infrastructure's up to date.
So that's a simple thing.
The other thing that is commonly configured
in the Terraform block are remote back ends.
And we're gonna talk about that
in the collaboration section.
So we're not gonna cover that right now,
but just know that it's pretty typical,
and it's best practice, to include a Terraform block
even though it may be completely optional, right?
Your Terraform might work perfectly fine
without your Terraform block,
but it does serve as a good way of documenting
what version of Terraform was used
to create the configuration.
Provider blocks are also optional.
If your provider doesn't require any configuration,
then Terraform doesn't actually need
a provider block to be present.
But it's always best practice to specify
at least the version of the provider that you're using.
This is how you can ensure that you have
reproducible builds in Terraform.
If you don't specify the version,
it will actually give you a warning when you are on plan.
So just as a best practice,
always put in a provider block,
even if you don't require it.
For the main cloud providers,
it's usually required because you have to give it
some configuration for most of them.
So for example, this is a configuration
for the AWS provider.
The region is a required configuration.
And then also often times you'll need to give it
some sort of a credential.
Now you can see that I have these commented out.
The AWS provider will accept access key and secret key
as configuration options to the provider.
Hopefully it's obvious to everybody
that that's a really bad idea.
Those are sensitive and secrets.
They're essentially passwords.
So it's best not to store those in your Terraform code
that gets checked in to a source code repository
and may be readable by a lot of people.
Okay so if it's not stored in here,
then how do we store it?
Well in the case of AWS,
it can use the AWS command line tool configuration files
that are stored in your home directory.
Or it will read environment variables.
So I've set up my environment
with my AWS access and secret keys.
I can't show you those for obvious reasons.
Those are secrets.
But that's the recommended way to do it.
And then most continuous deployment services
have a way to manage secrets and environment variables.
So all the cloud providers are different
in what they require.
Google, for example, requires a service account file.
It's a JSON file with some encryption keys in it.
AWS requires the secret key and the access key.
So if you have to consult the documentation
on what exactly it is that the different providers require
in terms of authentication.