Merge pull request #60 from dmattia/dmattia/tf_qs
Added some terraform questions and answers
This commit is contained in:
commit
ee6c25e006
37
README.md
37
README.md
@ -2359,6 +2359,12 @@ The benefits of Terraform over the other tools:
|
|||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>Explain what is "Terraform configuration"</summary><br><b>
|
<summary>Explain what is "Terraform configuration"</summary><br><b>
|
||||||
|
A configuration is a root module along with a tree of child modules that are called as dependencies from the root module.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>What is HCL?</summary><br><b>
|
||||||
|
HCL stands for Hashicorp Conviguration Language. It is the language Hashicorp made to use as the configuration language for a number of its tools, including terraform.
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -2390,6 +2396,7 @@ It keeps track of the IDs of created resources so that Terraform knows what it i
|
|||||||
|
|
||||||
<code>terraform init</code> scans your code to figure which providers are you using and download them.
|
<code>terraform init</code> scans your code to figure which providers are you using and download them.
|
||||||
<code>terraform plan</code> will let you see what terraform is about to do before actually doing it.
|
<code>terraform plan</code> will let you see what terraform is about to do before actually doing it.
|
||||||
|
<code>terraform validate</code> checks if configuration is syntactically valid and internally consistent within a directory.
|
||||||
<code>terraform apply</code> will provision the resources specified in the .tf files.
|
<code>terraform apply</code> will provision the resources specified in the .tf files.
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
@ -2424,18 +2431,29 @@ It's a resource which was successfully created but failed during provisioning. T
|
|||||||
<details>
|
<details>
|
||||||
<summary>What types of variables are supported in Terraform?</summary><br><b>
|
<summary>What types of variables are supported in Terraform?</summary><br><b>
|
||||||
|
|
||||||
String
|
string
|
||||||
Integer
|
number
|
||||||
Map
|
bool
|
||||||
List
|
list(<TYPE>)
|
||||||
|
set(<TYPE>)
|
||||||
|
map(<TYPE>)
|
||||||
|
object({<ATTR_NAME> = <TYPE>, ... })
|
||||||
|
tuple([<TYPE>, ...])
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>What is a data source? In what scenarios for example would need to use it?</summary><br><b>
|
<summary>What is a data source? In what scenarios for example would need to use it?</summary><br><b>
|
||||||
|
Data sources lookup or compute values that can be used elsewhere in terraform configuration.
|
||||||
|
|
||||||
|
There are quite a few cases you might need to use them:
|
||||||
|
* you want to reference resources not managed through terraform
|
||||||
|
* you want to reference resources managed by a different terraform module
|
||||||
|
* you want to cleanly compute a value with typechecking, such as with <code>aws_iam_policy_document</code>
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
<summary>What are output variables and what <code>terraform output</code> does?</summary><br><b>
|
<summary>What are output variables and what <code>terraform output</code> does?</summary><br><b>
|
||||||
|
Output variables are named values that are sourced from the attributes of a module. They are stored in terraform state, and can be used by other modules through <code>remote_state</code>
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
@ -2472,6 +2490,17 @@ List
|
|||||||
The random provider aids in generating numeric or alphabetic characters to use as a prefix or suffix for a desired named identifier.
|
The random provider aids in generating numeric or alphabetic characters to use as a prefix or suffix for a desired named identifier.
|
||||||
</b></details>
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>How do you test a terraform module?</summary><br><b>
|
||||||
|
Many examples are acceptable, but the most common answer would likely to be using the tool <code>terratest</code>, and to test that a module can be initialized, can create resources, and can destroy those resources cleanly.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary>Aside from <code>.tfvars</code> files or CLI arguments, how can you inject dependencies from other modules?</summary><br><b>
|
||||||
|
The built-in terraform way would be to use <code>remote-state</code> to lookup the outputs from other modules.
|
||||||
|
It is also common in the community to use a tool called <code>terragrunt</code> to explicitly inject variables between modules.
|
||||||
|
</b></details>
|
||||||
|
|
||||||
## Docker
|
## Docker
|
||||||
|
|
||||||
<a name="docker-beginner"></a>
|
<a name="docker-beginner"></a>
|
||||||
|
Loading…
Reference in New Issue
Block a user