You've already forked devops-exercises
Add k8s questions
Updated CKA page as well.
This commit is contained in:
abregman
@@ -6,13 +6,14 @@
|
||||
- [AWS](#aws)
|
||||
- [Questions](#questions)
|
||||
- [Terraform 101](#terraform-101-1)
|
||||
- [Terraform Hands-On Basics](#terraform-hands-on-basics)
|
||||
- [Providers](#providers)
|
||||
- [Provisioners](#provisioners)
|
||||
- [Modules](#modules)
|
||||
- [Variables](#variables)
|
||||
- [State](#state)
|
||||
- [Import](#import)
|
||||
- [Real Life Scenarios](#real-life-scenarios)
|
||||
- [AWS](#aws-1)
|
||||
|
||||
## Exercises
|
||||
|
||||
@@ -34,15 +35,22 @@
|
||||
|
||||
## Questions
|
||||
|
||||
<a name="questions-terraform-101"></a>
|
||||
### Terraform 101
|
||||
|
||||
<details>
|
||||
<summary>What is Terraform?</summary><br><b>
|
||||
|
||||
[Terraform](https://www.terraform.io/intro): "HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features."
|
||||
</b></details>
|
||||
|
||||
|
||||
<details>
|
||||
<summary>What are the advantages in using Terraform or IaC in general?</summary><br><b>
|
||||
|
||||
- Full automation: In the past, resource creation, modification and removal were handled manually or by using a set of tooling. With Terraform or other IaC technologies, you manage the full lifecycle in an automated fashion.<br>
|
||||
- Modular and Reusable: Code that you write for certain purposes can be used and assembled in different ways. You can write code to create resources on a public cloud and it can be shared with other teams who can also use it in their account on the same (or different) cloud><br>
|
||||
- Improved testing: Concepts like CI can be easily applied on IaC based projects and code snippets. This allow you to test and verify operations beforehand
|
||||
-
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@@ -51,27 +59,34 @@
|
||||
- Declarative: Terraform uses the declarative approach (rather than the procedural one) in order to define end-status of the resources
|
||||
- No agents: as opposed to other technologies (e.g. Puppet) where you use a model of agent and server, with Terraform you use the different APIs (of clouds, services, etc.) to perform the operations
|
||||
- Community: Terraform has strong community who constantly publishes modules and fixes when needed. This ensures there is good modules maintenance and users can get support quite quickly at any point
|
||||
-
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>In what language infrastructure in Terraform is defined?</summary><br><b>
|
||||
<summary>What language does Terraform uses?</summary><br><b>
|
||||
|
||||
A DSL called "HCL" (Hashiciorp Configuration Language). A declarative language for defining infrastructure.
|
||||
|
||||
HCL (Hashiciorp Configuration Language). A declarative language for defining infrastructure.
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What's a typical Terraform workflow?</summary><br><b>
|
||||
|
||||
1. Write Terraform definitions: `.tf` files written in HCL that described the desired infrastructure state
|
||||
1. Write Terraform definitions: `.tf` files written in HCL that described the desired infrastructure state (and run `terraform init` at the very beginning)
|
||||
2. Review: With command such as `terraform plan` you can get a glance at what Terraform will perform with the written definitions
|
||||
3. Apply definitions: With the command `terraform apply` Terraform will apply the given definitions, by adding, modifying or removing the resources
|
||||
|
||||
This is a manual process. Most of the time this is automated so user submits a PR/MR to propose terraform changes, there is a process to test these changes and once merged they are applied (`terraform apply`).
|
||||
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What are some use cases for using Terraform?</summary><br><b>
|
||||
|
||||
- Infra provisioning and management: You need to automated or code your infra so you are able to test it easily, apply it and make any changes necessary.
|
||||
- Multi-cloud environment: You manage infrastructure on different clouds, but looking for a consistent way to do it across the clouds
|
||||
- Consistent environments: You manage environments such as test, production, staging, ... and looking for a way to have them consistent so any modification in one of them, applies to other environments as well
|
||||
- Consistent environments: You manage environments such as test, production, staging, ... and looking for a way to have them consistent so any modification in one of them, applies to other environments as well
|
||||
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@@ -82,6 +97,15 @@ Terraform is considered to be an IaC technology. It's used for provisioning reso
|
||||
Ansible, Puppet and Chef are Configuration Management technologies. They are used once there is an instance running and you would like to apply some configuration on it like installing an application, applying security policy, etc.
|
||||
|
||||
To be clear, CM tools can be used to provision resources so in the end goal of having infrastructure, both Terraform and something like Ansible, can achieve the same result. The difference is in the how. Ansible doesn't saves the state of resources, it doesn't know how many instances there are in your environment as opposed to Terraform. At the same time while Terraform can perform configuration management tasks, it has less modules support for that specific goal and it doesn't track the task execution state as Ansible. The differences are there and it's most of the time recommended to mix the technologies, so Terraform used for managing infrastructure and CM technologies used for configuration on top of that infrastructure.
|
||||
|
||||
</b></details>
|
||||
|
||||
### Terraform Hands-On Basics
|
||||
|
||||
<details>
|
||||
<summary>How to reference other parts of your Terraform code?</summary><br><b>
|
||||
|
||||
Using the syntax <PROVIDER TYPE>.<NAME>.<ATTRIBUTE>
|
||||
</b></details>
|
||||
|
||||
### Providers
|
||||
@@ -534,8 +558,24 @@ It's does NOT create the definitions/configuration for creating such infrastruct
|
||||
2. You lost your tfstate file and need to rebuild it
|
||||
</b></details>
|
||||
|
||||
### Real Life Scenarios
|
||||
### AWS
|
||||
|
||||
<details>
|
||||
<summary></summary><br><b>
|
||||
</b></details>
|
||||
<summary>What happens if you update user_data in the following case apply the changes?
|
||||
|
||||
```
|
||||
resource "aws_instance" "example" {
|
||||
ami = "..."
|
||||
instance_type = "t2.micro"
|
||||
|
||||
user_data = <<-EOF
|
||||
#!/bin/bash
|
||||
echo "Hello, World" > index.xhtml
|
||||
EOF
|
||||
```
|
||||
</summary><br><b>
|
||||
|
||||
Nothing, because user_data is executed on boot so if an instance is already running, it won't change anything.
|
||||
|
||||
To make it effective you'll have to use `user_data_replace_on_change = true`.
|
||||
</b></details>
|
||||
Reference in New Issue
Block a user