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.
|
||||
Reference in New Issue
Block a user