Add initial Terraform documentation and setup guides
This commit is contained in:
16
Introductie/A. Infrastructure as code.md
Normal file
16
Introductie/A. Infrastructure as code.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# A. Infrastructure as code
|
||||
|
||||
Het beheren en provisioneren van infrastructuur door code in plaats van een handmatig proces.
|
||||
Waarom heb ik nog niets gezegd over de cloud, dat is omdat Terraform niet alleen voor cloud based systemen zijn. Maar je kunt het bijvoorbeeld ook voor Hyper-V of VM-Ware gebruiken.
|
||||
|
||||
Vandaag gaan we in de praktijk Azure gebruiken, maar alles wat ik hier uitleg is op alle cloud platformen etc. te gebruiken.
|
||||
|
||||
- Voordelen
|
||||
- Scalability: Het uitrollen van een grote hoeveelheid resources wordt veel makkelijker.
|
||||
- Voorbeeld: Je kunt veel gemakkelijker 100 virtual machines deployen wanneer je dat gewoon via een loopje kan doen.
|
||||
- Version control: Alle voordelen van version control systemen zoals GIT
|
||||
- Consistancy: Wat je deployed is altijd consistent
|
||||
- Nadelen
|
||||
- Feature lag: Infrastructure as code loopt altijd achter op de laatste features van cloud platforms.
|
||||
- Complexiteit: Het is toch een extra laag boven op wat er al is. En heeft extra kennis nodig om te kunnen worden gebruikt.
|
||||
- Configuration Drift: Als het gebruik binnen de organisatie niet goed is afgesproken is dit een probleem.
|
||||
20
Introductie/B. Wat kan Terraform voor jouw doen.md
Normal file
20
Introductie/B. Wat kan Terraform voor jouw doen.md
Normal file
@@ -0,0 +1,20 @@
|
||||
# B. Wat kan Terraform voor jouw doen
|
||||
|
||||
## Terraform State file
|
||||
|
||||
Waarschijnlijk de krachtigste feature die terraform heeft.
|
||||
In de terraform state, houd terraform bij welke resources het zelf heeft gedeployed.
|
||||
Bij elke apply checked terraform eerst of de state nog wel overeenkomt met de werkelijk gedeployde resources.
|
||||
Als iemand dus via de portal wijzigingen heeft gemaakt kan Terraform dat dus herkennen hier over rapporteren en weer terug wijzigen naar de deployment zoals deze in code is.
|
||||
|
||||
## Deployment volgorde en afhankelijkheden
|
||||
|
||||
Terraform controleert zelf of bepaalde resource afhankelijkheden hebben van elkaar. Jij hoeft dus zelf niet afhankelijkheden aan te geven.
|
||||
|
||||
## Error handeling
|
||||
|
||||
Terraforms error handeling is bijna altijd heel duidelijk, je krijg bijna nooit een "Something went wrong".
|
||||
|
||||
## Documentatie
|
||||
|
||||
In mijn mening is de documentatie van Terraform best in class, zeker als ik het vergelijk met Bicep van Microsoft.
|
||||
27
Introductie/C. Terraform CLI.md
Normal file
27
Introductie/C. Terraform CLI.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# C. Terraform CLI
|
||||
|
||||
## Init
|
||||
|
||||
Met Terraform init initialiseer je de working directory waar je Infrastructure as code staat.
|
||||
Het haalt eventuele modules binnen, het initialiseert de backend configuratie voor de terraform state, en het haalt de terraform provider binnen.
|
||||
|
||||
## Validate
|
||||
|
||||
Valideert je code op eventuele syntax fouten. Let op: Validate is niet volledig op de hoogte van providers, het kan je wel vertellen of je vereisten argumenten mist. Maar fouten in bijvoorbeeld namen kan het niet herkennen.
|
||||
|
||||
## fmt
|
||||
|
||||
fmt is een ingebouwde Linter om je code te formatteren zodat het er altijd strak uitziet.
|
||||
|
||||
## plan
|
||||
|
||||
Terraform plan geeft je een overzicht van alles wat je geschreven code gaat deployen in de geselecteerde omgeving.
|
||||
Als er al door terraform is gedeployed laat dit ook de wijzigingen zien die er eventueel worden toegepast.
|
||||
|
||||
## apply
|
||||
|
||||
Dit is waar het allemaal om draait. Terraform apply deployed jouw geschreven IAC. Onderdeel van een apply is dat het eerst een plan draait waar je vervolgens een goedkeuring op moet geven.
|
||||
|
||||
## destroy
|
||||
|
||||
Dit spreekt redelijk voor zich denk ik. Dit verwijdert alle resources die door middel van terraform gedeployed zijn.
|
||||
97
Introductie/D. Terraform language.md
Normal file
97
Introductie/D. Terraform language.md
Normal file
@@ -0,0 +1,97 @@
|
||||
# Terraform language
|
||||
|
||||
Voor dat je begint moet je weten in welke omgeving en/of cloud je wilt gaan deployen.
|
||||
Aan de hand hiervan kies je vervolgens 1 of meerdere providers. Je kunt dus met dezelfde code zowel resources in AWS als Azure en Google cloud deployen. Het is alleen niet zo dat je dan de bijvoorbeeld VM voor elke cloud apart moet definiëren.
|
||||
Naast dat de provider de authenticatie op het desbetreffende platform definieerd levert het ook de block syntax voor de rest van de code.
|
||||
De terraform taal voor het schrijven van de code bestaat uit wat we noemen blocks.
|
||||
De verschillende type blocks zijn:
|
||||
|
||||
- Resource blocks
|
||||
- Data blocks
|
||||
- module blocks
|
||||
|
||||
## Resource blocks
|
||||
|
||||
Elk resource block is een enkele resource binnen de geselecteerde provider. Hier definieer je vervolgens alle argumenten die de desbetreffendee resource nodig heeft.
|
||||
|
||||
```ad-example
|
||||
Binnen Azure bestaat een VM uit de werkelijke VM resource, een storage disk resource en een Network interface resource.
|
||||
Dit betekend dus dat om een Vm te deployen je minimaal 3 resource blocks nodig hebt voor al deze losse onderdelen.
|
||||
```
|
||||
|
||||
Benoem block name en resource type
|
||||
|
||||
### depends-on
|
||||
|
||||
Dit is voor de gevallen waar terraform het toch niet helemaal zelf kan uitvogelen wat de deployment volgorde is of omdat je een control freak bent en de tools die je gebruikt niet vertrouwd.
|
||||
|
||||
### count
|
||||
|
||||
Count is de eerste en oudste manier om een loop in je code te creëren, een count looped voor een set aantal keer door een resource block heen. Voor de meeste beter bekend als een for loop.
|
||||
|
||||
```ad-warning
|
||||
Het grote probleem met count is dat je heel weinig controle hebt over de specifieke resource.
|
||||
Stel je voor dat jij 6 VM's deployed met een count gebaseerd op een list.
|
||||
En jij wilt vervolgens VM 3 verwijderen en de rest laten staatn.
|
||||
Dan kan dat niet. Terraform zal namelijk altijd VM 6 verwijderen en de rest laten staan.
|
||||
```
|
||||
|
||||
Waar deze dagen count vooral voor wordt gebruikt is om makkelijk bepaalde resources niet te deployen afhankelijk van de environment in combinatie met een simpele expression.
|
||||
|
||||
### for-each
|
||||
|
||||
for-each is de andere manier om een loop in je code te bouwen, maar is een stuk slimmer. for-each kan namelijk omgaan met key-value pairs en dit geeft je dus wel de mogelijkheid om te doen wat ik net boven heb beschreven.
|
||||
|
||||
### dynamic blocks
|
||||
|
||||
Sommige resource blocks hebben een sub-block als een argument die meerdere keren mag voorkomen binnen het resource block.
|
||||
|
||||
```ad-example
|
||||
Een firewall policy rule collection group wat een groep firewall rules is heeft een argument application_rule_collection.
|
||||
Dit argument mag dus meerdere malen voorkomen in het resource block. Je kunt dit block dynamic maken en er een map variable als input voorgeven en nu heb je dus een loop binnen een resource block.
|
||||
```
|
||||
|
||||
Dit is ook de enige manier om nested loops te creëren in terraform.
|
||||
|
||||
## Data blocks
|
||||
|
||||
Met een data block kun je informatie over bestaande resources ophalen om vervolgens te gebruiken in andere blocks.
|
||||
|
||||
```ad-example
|
||||
Informatie ophalen over een bestaand network om vervolgens de VM en vrij ip-address te geven.
|
||||
```
|
||||
|
||||
## Module blocks
|
||||
|
||||
Modules zijn custom gemaakte collecties van resource blocks en data blocks. En module blocks gebruik je vervolgens om deze aan te roepen met input parameters.
|
||||
|
||||
```ad-example
|
||||
Binnen de business is er een standaard VM die altijd voor citrix wordt gebruikt. Je kunt dan een module maken die alle settings behalve de naam al hebt voor gedefineerd. Dan hoef jij zelf alleen maar een module block met de namen van de vm's te defineren. en deployen maar.
|
||||
```
|
||||
|
||||
## Backend configuration
|
||||
|
||||
In de backend configuration geeft je aan waar je de terraform state file wilt opslaan en met welke credentials.
|
||||
Een aantal opties zijn:
|
||||
|
||||
- Local
|
||||
- AWS S3
|
||||
- Azure storage accounts
|
||||
- Remote
|
||||
- Terraform cloud
|
||||
|
||||
## variablen
|
||||
|
||||
Je hebt hier twee opties je kunt locals gebruiken. Deze definieer je direct in je code.
|
||||
Of je gebruikt een variable file waar in je deze definieert. Deze variablen kun je ook als input variables meegeven wanneer je een run start. Of doormiddel van een tfvars file waar je vervolgens de waardes in defineert.
|
||||
|
||||
In de variable file kun je ook per variable descriptions meegeven, validations en aangeven of iets sensetive data is.
|
||||
Dan zijn er nog data en resource block variables, je kunt namelijk verwijzen naar resources en data blocks die je al eerder gedefineerd hebt.
|
||||
|
||||
## variable types
|
||||
|
||||
- string
|
||||
- number
|
||||
- bool
|
||||
- list (of tuple) is een lijst van waardes geidentificeerd als opeenvolgende getalen beginent met 0.
|
||||
- map (of object) een groep van key value pairs waarin de value's ook data types op zichzelf kunnen hebben. Dus nested maps zijn een mogelijkheid.
|
||||
30
Praktijk/A. Terraform dev omgeving opzetten.md
Normal file
30
Praktijk/A. Terraform dev omgeving opzetten.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# A. Terraform Dev omgeving opzetten
|
||||
|
||||
1. Azure CLI installeren ```winget install Microsoft.AzureCLI```
|
||||
2. Terraform installeren ```winget install Hashicorp.Terraform```
|
||||
3. Installeer je favoriete IDE.
|
||||
4. Reboot nu je computer.
|
||||
5. Installeer Terraform support in je IDE.
|
||||
6. Maak een folder aan.
|
||||
7. Voeg daar een main.tf aan toe.
|
||||
8. Vul deze met een basis terraform block en provider block:
|
||||
|
||||
```hcl
|
||||
terraform {
|
||||
backend "local" {}
|
||||
}
|
||||
|
||||
provider "azurerm" {
|
||||
features {}
|
||||
}
|
||||
```
|
||||
|
||||
1. Open een terminal via de IDE of browse met een terminal naar de folder die je net hebt aangemaakt.
|
||||
2. Voer de ```az login``` commando uit om in te loggen bij Azure.
|
||||
3. Na het inloggen wordt je geprompt om een subscription en tennant te kiezen. Zoek hier naar de naam van de subscription.
|
||||
4. Run terraform init
|
||||
|
||||
## Handige URL's
|
||||
|
||||
De Terraform language documentatie: <https://developer.hashicorp.com/terraform/language>
|
||||
De Azurerm Terraform provider documentatie <https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs>
|
||||
28
Praktijk/B. Webapp.md
Normal file
28
Praktijk/B. Webapp.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# B. Webapp
|
||||
|
||||
Je gaat nu wat resources deployen binnen je resource group.
|
||||
Dit gaan we doen doormiddel van webapps
|
||||
|
||||
Het eerste om te weten is dat een web app altijd een afhankelijkheid heeft naar een App service plan.
|
||||
Een app service plan kun je zien als een webserver waar je meerder web apps op kan draaien.
|
||||
Dus voor dit stuk moet je twee resources aanmaken.
|
||||
|
||||
## Tips
|
||||
|
||||
De naam van de webapp moet globaal uniek zijn. Dus niet binnen schiphol uniek maar over de hele wereld uniek!
|
||||
|
||||
Om het invullen van de location en resource group makkelijker te maken heb je een data block nodig om de info van de resource group op te halen.
|
||||
|
||||
Zorg dat sku_name "B1" is. Dit zorgt er voor dat je azurerm_service_plan op de basic tier komt te staan.
|
||||
|
||||
Zoek in de azurerm documentatie naar "azurerm_linux_web_app"
|
||||
|
||||
Houd er rekening mee dat je value's van andere resource blocks kunt gebruiken in je nieuwe resource blocks.
|
||||
|
||||
Als je het volgende output block toevoegt aan je code wordt de URL van je webapp naar de terminal geschreven na dat deze gedraaid is.
|
||||
|
||||
```hcl
|
||||
output "url" {
|
||||
value = azurerm_linux_web_app.<de naam van je webapp resource block>.default_hostname
|
||||
}
|
||||
```
|
||||
31
Praktijk/C. Variables.md
Normal file
31
Praktijk/C. Variables.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# C. Variables
|
||||
|
||||
Je gaat nu wat variabelen toevoegen om het makkelijker te maken om je code voor meerder omgevingen te gebruiken.
|
||||
|
||||
Hier voor moet je twee bestanden aanmaken:
|
||||
|
||||
- variables.tf - In deze file zetten wij de definitie van de variabelen.
|
||||
- dev.tfvars - in deze file defineren wij de waardes van de variabelen.
|
||||
|
||||
De namen zijn niet echt verplicht terraform kan namelijk door de syntax uitvogelen wat je wilt doen. Je zou het zelfs in je main.tf kunnen zetten. Maar dat is niet echt overzichtelijk.
|
||||
|
||||
Maak van de volgende value's variabelen:
|
||||
|
||||
- app service plan name
|
||||
- webapp name
|
||||
|
||||
## Tips
|
||||
|
||||
Een voorbeeld van een variabele definitie.
|
||||
|
||||
```hcl
|
||||
variable "variablename" {
|
||||
type = string
|
||||
description = "value"
|
||||
default = "value"
|
||||
}
|
||||
```
|
||||
|
||||
Om de tfvars file te gebruiken moet je ```terraform apply -var-file dev.tfvars``` gebruiken.
|
||||
|
||||
Als je de waarden precies hebt overgenomen van de vorige runs zouden er nu geen changes moeten zijn.
|
||||
22
Praktijk/D. Count.md
Normal file
22
Praktijk/D. Count.md
Normal file
@@ -0,0 +1,22 @@
|
||||
Zoals al eerder opgemerkt kunnen er meerdere web apps bestaan onder dezelfde app service plan.
|
||||
Je gaat nu met een simpele loop meerdere web apps aanmaken.
|
||||
We zullen dit op basis van een lijst van namen doen.
|
||||
|
||||
Maak 5 webapps aan door middel van een loop.
|
||||
|
||||
Wat moet je doen:
|
||||
- Verander de data type van de app naam variabelen naar list(string)
|
||||
- maak in je tfvars file een lijst van namen die je web apps moeten hebben.
|
||||
- Voeg de count meta-argument toe aan je web_app resource block.
|
||||
- Check de count documentatie voor details https://developer.hashicorp.com/terraform/language/meta-arguments/count
|
||||
- Als je een output block hebt zal die nu niet meer werken aanegzien er meer outputs zijn.
|
||||
- verander deze naar het volgende om het werkend te houden
|
||||
```hcl
|
||||
output "url" {
|
||||
value = azurerm_linux_web_app.<de naam van je webapp resource block>.*.default_hostname
|
||||
}
|
||||
```
|
||||
|
||||
## Experiment
|
||||
Verwijder web app 3 uit je lijst en run ```terraform apply -var-file dev.tfvars``` opnieuw.
|
||||
Kijk goed welke web app er is verwijderd. En welke niet.
|
||||
43
Praktijk/E. For_each.md
Normal file
43
Praktijk/E. For_each.md
Normal file
@@ -0,0 +1,43 @@
|
||||
Het is mooi dat je nu meerdere webapps kunt maken, maar de app service plan die we gebruiken heeft daar eigenlijk helemaal de resources niet voor. Dus we moeten nu toch een app service plan per webapp gaan maken.
|
||||
Daar kun je for_each goed voor gebruiken in combinatie met een map variabelen.
|
||||
|
||||
## Variabelen
|
||||
Als eerste ga je een map variabelen maken.
|
||||
- Voeg in je variables.tf een nieuwe variabelen toe met het type map(any)
|
||||
- Je kunt nu ook de app service plan naam en app naam variabelen verwijderen, die hebben we nu namelijk niet meer nodig.
|
||||
- Ga nu naar je dev.tfvars file, verwijder hier ook de app service plan naam en app naam variabelen.
|
||||
- Nu kun je de waardes van je map variabelen toe gaan voegen. Zie hieronder een voorbeeld:
|
||||
```hcl
|
||||
asps = {
|
||||
terraform101-asp1 = {
|
||||
asp_tier = "B1"
|
||||
app = {
|
||||
app_name = "asp1-webapp"
|
||||
https_only = true
|
||||
}
|
||||
}
|
||||
terraform101-asp2 = {
|
||||
asp_tier = "B1"
|
||||
app = {
|
||||
app_name = "asp2-webapp"
|
||||
https_only = true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Zoals je ziet hebben we de naam van de app service plan als de key en daaronder weer een map als value. Deze map heeft asp_tier en app als key-value pairs. De asp_tier variabelen geeft ons de mogelijkheid om dit per app service plan in te stellen. Voor nu houden we het gewoon op B1. App is zelf ook weer een map met twee key-value pairs. De naam van onze web app een https_only setting.
|
||||
|
||||
In het geval van een map variabelen is het dus alleen nodig om de eerste variabelen de definiëren.
|
||||
|
||||
## Code
|
||||
Check voor de code de documentatie ;P https://developer.hashicorp.com/terraform/language/meta-arguments/for_each
|
||||
|
||||
## Output block
|
||||
Als je een output block hebt moet je de volgende wijziging aan brengen:
|
||||
```hcl
|
||||
output "url" {
|
||||
value = {
|
||||
for r, wa in azurerm_linux_web_app.<de naam van je webapp resource block> : r => wa.default_hostname
|
||||
}
|
||||
}
|
||||
```
|
||||
0
Praktijk/F. Remote state.md
Normal file
0
Praktijk/F. Remote state.md
Normal file
Reference in New Issue
Block a user