InSpec-Iggy permet de générer des règles de compliances InSpec pour les cloud AWS, Azure et GCP à partir de tfstate
Terraform.
Il est possible de générer des règles de compliances incluant le tfstate
Terraform ou l'excluant. Ce derniers cas est intéressant pour vérifier que rien n'est provisionné dans le cloud en dehors de Terraform.
Le getting started officiel Hashicorp pour déployer un cluster EKS avec Terraform.
Le code est ici: https://github.com/terraform-providers/terraform-provider-aws/tree/master/examples/eks-getting-started
EDIT:
NOTE: The usage of the specific kubernetes.io/cluster/ resource tags below are required for EKS and Kubernetes to discover and manage networking resources.
NOTE: The usage of the specific kubernetes.io/cluster/ resource tag below is required for EKS and Kubernetes to discover and manage compute resources.
voir également: https://github.com/kubernetes/cloud-provider-aws/blob/8f6e1e3d2cfa20a0deac088b9c4022d433500369/pkg/cloudprovider/providers/aws/tags.go#L30-L52
Je n'ai pas trouvé de doc officielle claire indiquant les tags à mettre en place sur les ressources AWS, mais après avoir passé 2 jours à débugguer pourquoi mes ELB ne se provisionnaient pas, puis pourquoi mes Nodes n'arrivaient pas à joindre le cluster EKS, je confirme que ces tags sont très importants à ajouter sur les ressources suivantes:
Une bonne introduction au déploiement d'infra sur Azure avec Ansible et Terraform. A noter l'utilisation du module Ansible pour Terraform.
Terratest est un framework de test en Go pour automatiser les tests d'infrastructure Terraform, mais aussi Packer et Docker build.
Atlantis permet d'orchestrer la planification et l'application topologies Terraform depuis des pull requests GitHub, GitLab où BitBucket.
Atlantis fait désormais partie d'Hashicorm (cf. https://medium.com/runatlantis/joining-hashicorp-200ee9572dc5)
Un tuto pour provisioner des ressources sur GCP avec Terraform
Terraform propose désormais une registry de modules Terraform prêts à l'emploi (ex: vpc, autoscaling, rds, elb, ...)
Depuis Terragrunt v0.10.0, la configuration S3 et DynamoDB permettant de gérer les states et lock Terraform se trouve dans terraform.tfvars
au lieu de .terragrunt
.
Exemple de configuration avec un repo de configuration et un repos module:
* terraform-configuration-repo
|- dev
|- test
|- prod
|- application
| |- terraform.tfvars
| |- main.tfvars (symlink -> ../main.tfvars)
|- terraform.tfvars
|- main.tfvars
* terraform-module-application-repo
|- main.tf
|- vars.tf
|- ...
application
:# terraform-configuration/prod/application/terraform.tfvars
terragrunt = {
terraform {
source = "git@github.com:myuser/tf-modules-application-repo.git///ref=1.0.0"
extra_arguments "main" {
arguments = [
"-var-file=main.tfvars",
"-var-file=terraform.tfvars"
]
commands = [
"plan",
"apply"
]
}
}
include {
path = "${find_in_parent_folders()}"
}
}
# variables specifics to application module
var1 = "XXX"
var2 = "YYY"
# var3 can override var3 from main.tfvars environment variables
var3 = "BBB"
...
prod
environnement:# terraform-configuration/prod/terraform.tfvars
terragrunt = {
# Configure Terragrunt to use DynamoDB for locking
lock = {
backend = "dynamodb"
config {
state_file_id = "prod"
}
}
# Configure Terragrunt to automatically store tfstate files in an S3 bucket
remote_state = {
backend = "s3"
config {
encrypt = "true"
bucket = "s3-terraform-states"
key = "prod/${path_relative_to_include()}/terraform.tfstate"
}
}
}
prod
environment:# terraform-configuration/prod/main.tfvars
# variables specifics to prod environment
var3 = "ZZZ"
var4 = "AAA"
Les slides de Gruntwork qui résument toutes les bonnes pratiques Terraform présentés dans leur série d'article
Cf. liens précédents:
Workflow proposé par Gruntwork pour les changements d'infrastructure avec Terraform:
terraform plan
terraform apply
terraform apply
Des astuces pour utiliser des boucles et des conditions avec Terraform en utilisant le paramètre count
au sein des ressources:
On peut ensuite utiliser la fonction element
pour récupérer l'élément d'une liste correspondant à l'indice de count
ou utiliser la fonction replace
pour remplacer 0 ou 1 par des valeurs différentes par exemple.
C'est plutôt tricky mais ça à l'air de faire le job.
Best practices pour Terraform:
ex:
- infrastructure-live-repo
| - dev
| | - app1
| | - app2
| | - db1
| | - vpc
| - test
| | - ...
| - prod
| | - ...
| - mgmt
| | - bastion
| | - ...
| - global
| | - iam
| | - route53
| | - ...
- infrastructure-modules-repo (tags v0.0.1, v0.0.2, ...)
| - app1
| - app2
| - db1
| - vpc
| - bastion
| - ...
Terraform 0.8 est sorti.
Au menu:
Attention, certains changements provoquent des incompatibilités avec les versions précédentes. Lire la partie upgrade de la release note pour vérifier les changements nécessaires.
Des bonnes pratiques pour gérer son infrastructure avec terraform:
(via: https://jeekajoo.eu/links/?XvEgyg)
Une explication du concept SRE (Site Reliability Engineering) qui est utilisée pour gérer la production chez Google.
Parmi les points marquant par rapport à DevOps:
EDIT: en complément, l'interview du Vice President Engineering de Google qui donne plus de détails sur le fonctionnement chez Google
https://landing.google.com/sre/interview/ben-treynor.html
Alternative à Cloudformation et Terraform pour gérer le provisioning sur AWS
- Do the simple thing first. This is the secret of supporting exponential growth. There's no need to future proof everything you do. That leads to paralysis. For each new challenge find the fastest, simplest fix for each.
- Do fewer things better. Focus on a single platform. This allows you to iterate faster because not everything has to be done twice. When you have to expand create a team explicitly for each platform.
- Upfront work but can pay huge dividends. Create an automated scriptable infrastructure implementing a repeatable server provisioning process. This makes it easier to bring on new hires and handle disasters. Hire engineers with the right stuff who aren't afraid to work through a disaster.
- Don’t reinvent the wheel. Instagram moved to Facebook's infrastructure because it allowed them to stay small and leverage a treasure trove of capabilities.
- Nothing lasts forever. Be open to evolve your product. Don't be afraid of creating special teams to tackle features and adapt to a rapidly scaling community.
Otto automatise l'environnement de développement et de déploiement en production d'une application en se basant sur les autres outils d'Hashicorp (Vagrant, Packer, Terraform & Nomad)
(via https://github.com/jeekajoo?tab=activity)