script on Zwindler's Reflection

Avec Terragrunt, ne répétez plus vos variables Terraform 358 fois

Mon, 29 Aug 2022 06:45:00 +0200

Cet article a initialement été écrit avec ma collègue Chahrazed Yousfi (zed) en anglais. C’est donc une traduction pour mes copains francophiles ;-).

Mais pourquoi tu fais çaaaaaa ???

L’article qui suit parle d’un cas d’usage avancé de Terraform qui n’est probablement pas nécessaire d’aborder pour un débutant. Si jamais vous voulez un aperçu de ce qu’on peut faire avec Terraform, vous pouvez aller relire mon article Premiers pas avec Terraform.

Au travail, la majorité de notre infrastructure est hébergée sur site (hors d’un cloud) et dans la plupart des cas ça nous convient.

Mais maintenir un service en ligne avec des infras en propre c’est parfois compliqué et il arrive que les services proposés par les cloud providers soient plus adaptés à nos besoins que ce que nous, l’équipe SRE, pouvons apporter à nos utilisateurs (les développeurs).

Pour gérer de manière “DevOps” ces services “cloud”, nous utilisons un outil d’Infrastructure as Code (IaC) : Terraform de Hashicorp.

Terraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services. Terraform codifies cloud APIs into declarative configuration files. – Terraform website

Ce que nous aimons vraiment avec Terraform c’est que cet outil nous permet de construire une infrastructure “répétable” avec seulement quelques lignes de HCL (le domain-specific-langage de Hashicorp). L’état de l’infrastructure est stocké soit en local (dans un fichier) soit sur un système de stockage externe. Seule la différence entre ce qu’on écrit dans le code et ce qui est stocké dans ce state est appliquée/modifiée. Dernier point, l’outil est devenu un standard de-facto, ce qui est beaucoup à obtenir des services fiables et facilite l’onboarding des équipes de dev.

Pour donner une idée de notre usage de Terraform, le répository sur lequel nous stockons notre IaC représente :

Pratiquement 1000 fichiers “.tf” de Terraform, pour environ 35k lignes
Environ 4000 commits, 1500 pull-requests
Plus de 40 contributeurs venant de diverses équipes

Les limites de Terraform ?

Tant que vous avez peu d’objets dans Terraform, tout va bien.

Mais quand vous commencez à avoir des centaines de fichiers (comme nous), cela devient compliqué de travailler simultanément sur le même code Terraform. Le fichier qui stocke l’état de l’infrastructure doit être à jour et synchronisé entre tous les contributeurs.

Cela provoque des problématiques de “locking”, le calcul des “diffs” est de plus en plus long. En scalant, l’expérience utilisateur de Terraform se dégrade dans le temps.

Il y a plusieurs stratégies pour contourner cela, mais nous n’avons pas trouvé de solution qui éclipsait tous nos problèmes.

Par exemple, il est possible de découper le code Terraform dans différents dépôts git et avoir un état Terraform pour chacun d’entre eux. De cette manière, chaque équipe devient autonome est peut travailler de manière indépendante sur leur infrastructure. Cependant, le code Terraform tend à être dupliqué de projet en projet, puis d’équipe en équipe (même en utilisant les modules Terraform, on en parlera plus tard).

D’expérience, du code dupliqué conduit à des erreurs humaines et nous essayons donc d’éviter ça le plus possible.

Une autre solution pourrait être de créer un gros “monorepo” dans lequel on dépose tous les projets Terraform dans des répertoires différents (chacun avec son “state”). On peut utiliser des modules Terraform pour factoriser le code HCL commun de ses dossiers, soit directement dans le même monorepo, soit dans des dépôts distants.

Mais même comme ça, on se retrouve toujours à dupliquer toujours les mêmes variables (comme le “billing account” de votre cloud provider, par exemple, ou toute autre valeur que vous utilisez tout le temps).

Arrive alors Terragrunt !

Pour contourner certaines des limitations de Terraform, la société Gruntwork a créé un outil appelé Terragrunt, qui pour le dire simplement, est un wrapper de Terraform.

Note : vous connaissez peut-être déjà Gruntwork pour certains autres outils “cloud native”, notamment “Terratest” (qui permet de tester son code Terraform), “AWS Infrastructure as Code Library”, “Gruntwork Landing Zone for AWS”, etc.

L’idée principale mise en avant par Terragrunt est que le code Terraform devrait pouvoir être écrit de manière à ne jamais avoir à répéter quoique ce soit (philosophie DRY pour Don’t Repeat Yourself).

Dans ce post, je vous montrerai donc une façon (opinionated) d’utiliser les fonctions principales de Terragrunt, pour vous montrer qu’on peut éviter de se répéter 358 fois ;-).

On se prépare

La première chose à faire pour commencer à travailler avec Terragrunt est bien sûr de l’installer ;-). Le code source de Terragrunt est disponible ici et les binaires précompilés sont disponibles là.

Pour avoir une bonne idée des fonctionnalités offerts par Terragrunt, je vous propose d’utiliser un environnement cloud de démo avec la hiérarchie suivante :

Note : Pour cet exemple on a choisi Google Cloud Platform comme cloud provider, mais Terragrunt peut évidemment être utile dans bien d’autres contextes. L’avantage de GCP dans ce cas là, c’est qu’il existe des folders et des projects, qui nous permettent de gérer les droits par département, équipe, etc.

Dans cette démo, on va utiliser un dépôt git, qui contient initialement du code Terraform classique, et on va ensuite le dé-dupliquer étape par étape avec l’aide de Terragrunt.

github.com/deezer/terragrunt-example/

Pour des raisons de lisibilité, on va décrire les actions étapes par étapes mais pas afficher le code entier à chaque fois. Vous pouvez naviguer entre les commits pour voir le résultat.

Factoriser les variables

Avoir beaucoup de projets différents implique qu’on va avoir beaucoup de variables à déclarer. Et beaucoup de ces variables vont souvent être identiques ou similaires d’un projet à l’autre. Le souci, c’est que copier le code d’un projet devient alors source importante d’erreurs humaines. Si on oublie de changer une variable au milieu de celles qui doivent être copiées, le résultat peut être fâcheux.

C’est d’abord pour cette raison que nous avons cherché une solution pour factoriser nos variables Terraform (nous ne pouvions pas être les seuls à avoir ce problème).

Nous cherchions également une solution qui serait compatible avec un système d’héritage et nous avons trouvé Terragrunt !

La capture d’écran qui suit est un aperçu de ce qu’on a pu faire avec Terragrunt pour les variables d’un “projet” GCP. Nous disposons maintenant d’un moyen pour factoriser la quasi-totalité de nos variables à différents niveaux hiérarchiques, et je vais vous montrer comment ! 😉

Un fichier de configuration

La première chose qu’on va faire est de créer un fichier terragrunt.hcl qui va contenir les informations utilisées par Terragrunt pour fonctionner.

Ce fichier est écrit dans la même syntaxe que Terraform (c’est du HCL), avec en plus des fonctions supplémentaires. Pour plus de détails, vous pouvez aller voir la page officielle de documentation.

Pour notre démo, j’ai besoin de créer le fichier terragrunt.hcl à 2 niveaux dans mon repository :

un premier au niveau de mon projet (là où sont mes fichiers .tf), pour indiquer à Terragrunt qu’il peut s’éxecuter ici. Pour faire simple j’appelerai ça le “fichier de configuration local”
un second au niveau de la racine de mon dépôt git, où on mettra toute la configuration qui sera commune à tous les répertoires. Je l’appellerai “fichier de configuration global”

Le dépôt va avoir la structure suivante :

Au niveau du projet (dans le fichier de conf “local”), on va ajouter un bloc include, suivi par la fonction find_in_parent_folders(). Cette fonction recherche dans les répertoires parents jusqu’à trouver un autre fichier terragrunt.hcl. La fonction renvoie ensuite le chemin pour retrouver le fichier terragrunt.hcl “global” (situé à la racine), qui contient toute la configuration commune à tous les fichiers terragrunt.hcl.

Ce bloc nous permet donc de récupérer la configuration déclarée à la racine. Les projets ne contiennent donc pas de configuration spécifique, puisque vous est basé sur la configuration “globale”.

include "root" {
 path = find_in_parent_folders("terragrunt.hcl")
}

Variables globales

Admettons maintenant qu’on veut qu’un certain nombre de variables soient identiques pour tous les projets, comme pour le “billingID” par exemple. Pour le faire, on va ajouter des inputs dans le fichier de configuration globale :

inputs = {
 billing_account = "012345-ABCDEF-UVWXYZ"
 organization_id = "12345678"
 region = "europe-west1"
 zone = "europe-west1-b"
}

Les inputs permettent de remplacer des variables déclarées (mais vides) dans les projets. Souvent, on déclare ces variables dans un fichier variables.tf, au niveau du projet lui-même.

Une fois que vous déclarez la variable et son type, elle sera automatiquement remplacée par la valeur déclarée globalement (plus haut), par Terragrunt.

variable "billing_account" {
 type = string
}

De cette manière, on peut donc déclarer une seule fois les variables qui sont valables pour TOUS les projets.

Mais comment faire si jamais on a envie de mutualiser des valeurs qu’avec une partie de nos projets et pas tous ?

Variables intermédiaires

Contrairement aux fonctions, qui ne sont utilisables que dans le fichier de configuration terragrunt.hcl, il est possible de configurer des inputs dans d’autres fichiers “.hcl”. On peut donc les mettre où on veut dans notre dépôt, idéalement à un endroit intelligent dans notre hiérarchie de dossiers, histoire que tous les projets similaires héritent des mêmes variables.

Pour le faire, on va utiliser la fonction read_terragrunt_config dans la configuration globale pour tous les fichiers “.hcl” qu’on va vouloir inclure, puis fusionner tout ça ensemble.

Pour donner un exemple, si pour dossier et sous-dossiers donné on a un même tag “team leader” ou “point de contact”, on va positionner un fichier team.hcl dans le dossier qui les englobe tous.

inputs = merge(
 read_terragrunt_config(find_in_parent_folders("global.hcl")).inputs,
 read_terragrunt_config(find_in_parent_folders("team.hcl")).inputs,
)

Dans le cas de la team-a, ce fichier pourrait être placé ici : dept-datascience/team-a/team.hcl, avec les valeurs suivantes :

inputs = {
 tech_lead = "Freddie Mercury"
 contact = "fmercury@gmail.com"
}

Pour la team-b, dept-datascience/team-b/team.hcl et les valeurs :

inputs = {
 tech_lead = "Abel Tesfaye"
 contact = "atesfaye@gmail.com"
}

Notre arborescence d’exemple devrait ressembler à ça maintenant :

Variables non factorisables

On ne peut pas toujours factoriser toutes les variables pour tous les projets. Il arrive qu’il soit nécessaire de faire des exceptions, par exemple, un projet va être déployé dans une région inhabituelle.

Si jamais vous avez besoin d’écraser la valeur par défaut, déclarée dans un niveau supérieur, c’est possible. Il suffit de déclarer un inputs dans la configuration locale de Terragrunt en utilisant le même nom.

Allez plus haut

En tant que SREs, on cherche toujours à automatiser toujours plus de tâches manuelles.

Grâce aux fonctions de Terragrunt, nous avons trouvé comment automatiser la configuration de la variable “name” de nos projets GCP. Nous avons décidé que tous les projets (name + ID) devraient être définis directement par le nom du répertoire dans lequel le code Terraform/Terragrunt est stocké.

On peut le faire de la façon suivante dans le fichier de configuration global

inputs = {
 project_name = "basename(get_terragrunt_dir())"
}

De cette manière, nous n’avons plus à ne pas oublier de changer le project_name ou projet_id dans nos ressources Terraform ou notre variables.tf quand on copie du code. On se base simplement sur la variable project_name, qui est déduite automatiquement du dossier concerné.

Configuration du backend Terraform

Au travail, pour stocker nos états Terraform (les fameux fichiers de state), nous utilisons un bucket GCS. Tous les états des projets sont stockés dans des chemins différents et parfois dans des buckets GCS différents. Mais ce chemin doit toujours contenir le nom du projet et le nom du bucket concerné.

terraform {
 backend "gcs"{
 bucket = "tfstate-team-a"
 prefix = "team-a-proj-product1"
 }
}

Avec Terraform, il est impossible de variabiliser cette partie backend.

a backend block cannot refer to named values (like input variables, locals, or data source attributes).

Heureusement, Terragrunt propose lui la possibilité de le faire, dans un bloc remote_state à ajouter dans le fichier de configuration global.

Dans notre exemple, nous avons décidé de créer des buckets qui seraient mutualisés pour quelques projets chacun.

On les définit donc dans un fichier backend.hcl placé au plus haut des sous dossiers que le bucket va gérer. On réutilise la même technique que précédemment (inputs + find_in_parent_folders() + read_terragrunt_config())

Par exemple, tous les projets de la team-a utilisent le même “tfstate-teamA”, on va donc créer le backend.hcl à la racine du dossier team-a.

Pour ce qui est du préfixe (le chemin du state dans le bucket), on utilise ensuite une fonction path_relative_to_include() qui renvoie le chemin relatif depuis la racine du dépôt.

Dans l’exemple, le path pour team-a-proj-product1 ça serait dept-datascience/team-a/product1/team-a-proj-product1. Ca nous permet de nous assurer que le state est toujours stocké dans un endroit unique.

remote_state {
 backend = "gcs"
 config = {
 bucket = read_terragrunt_config(find_in_parent_folders("backend.hcl")).inputs.bucket
 prefix = path_relative_to_include()
 }
}

Note : dans cet exemple particulier, on voit bien que la façon dont on nomme nos dossiers ainsi que la hiérarchie des dossiers est très importante pour faciliter la façon dont on décrit notre configuration. Pour autant, ce n’est qu’un exemple et on peut tout à fait gérer cela différemment tout en profitant des fonctions de Terragrunt.

Dans notre projet, on devra remplacer la configuration du backend par l’extrait suivant. La configuration du backend sera automatiquement remplie par terragrunt à partir de la configuration globale.

terraform {
 backend "gcs" {}
}

Une commande pour les contrôler toutes…

Une commande que nous n’attendions pas et que nous avons découverte avec Terragrunt est l’ajout d’un run-all.

run-all est une commande de la CLI Terragrunt qui permet de lancer de manière terragrunt dans tous les sous-dossiers contenant un terragrunt.hcl.

Si vous avez changé une des globales variables, vous pouvez appliquer le changement à tous vos projets d’un seul coup avec la commande suivante :

$ terragrunt run-all apply

On peut également utiliser cette fonction dans une CI/CD pour s’assurer que l’infrastructure est toujours à jour et qu’il n’y a pas eu de “drift”.

Conclusion

J’espère vous avoir convaincu que Terragrunt peut réellement être utile lorsque vous travaillez avec un grand nombre de fichiers Terraform.

Cela nécessite un peu de rigueur et de réflexion pour créer une hiérarchie de dossiers, de manière à mutualiser de manière intelligente les variables dans l’arborescence.

Même si Terragrunt ajoute un peu de complexité, il permet également d’obtenir de nouvelles fonctions et facilite l’automatisation et la factorisation du code.

Tout ceci permet ensuite d’avoir du code plus propre, plus maintenable, moins dupliqué.

Je ne conseille pas de commencer directement avec Terragrunt si vous débutez dans Terraform (ça ajoute quand même un peu de complexité pour peu de gain). Cependant, si vous commencez à avoir beaucoup de fichier, de contributeurs, vous devriez clairement le tester.

D’autres ressources externes sur le sujet

Récupérer les informations sur la distribution avec les facts Ansible

Wed, 21 Nov 2018 12:45:40 +0000

Les facts d’Ansible

Si vous suivez le blog, vous savez que j’utilise énormément Ansible. J’ai même été faire un talk sur le sujet à BDX I/O 2018, à l’ENSEIRB.

Aujourd’hui, plutôt que de vous donner un playbook tout fait pour installer sans effort une des multiples applications dont j’ai automatisé le déploiement avec Ansible, je vous propose d’explorer une des features les plus importantes et utiles d’Ansible, les facts, par le biais d’un petit exemple.

C’est quoi les facts dans Ansible

Si vous avez déjà lancé un playbook, vous avez sûrement remarqué lors de son exécution, que la première tâche qui est réalisée n’est pas une tâche que vous avez demandée explicitement.

ansible-playbook -i inventory/prod/blop -u blop --private-key=blop.key configure-blop.yml
[...]]
TASK [Gathering Facts] *********************************************************
ok: [blop-vm1]

Cette tâche [Gathering Facts], qui ne fait à première vue rien, correspond en fait à la connexion à la ou les machines sur lesquelles seront exécutées les playbooks. Si la connexion échoue, le playbook échouera sur cette cible, et continuera éventuellement sur les autres (s’il en reste). Si l’hôte répond, alors Ansible en profite pour récupérer moult informations en rapport avec cette machines et les stockent dans une variable ansible_facts.

A quoi ça ressemble ?

Comme je ne disais, à première vue, cette commande de fait rien. Si on ne sait pas qu’elle stocke des informations dans une variables, on ne peut rien en faire.

Un bon moyen d’avoir un premier aperçu de ce qu’on peut en faire est de les afficher. On peut faire ça avec le module « setup », qui est en réalité le même module qui est appelé lors de l’étape [Gathering facts].

Le retour se fera au format JSON, ce qui est certes peu digeste, mais facilitera grandement les manipulations de type « filtre » (via le flag filter intégré ou via l’utilitaire jq par exemple).

ansible blop-vm1 i inventory/prod/blop -m setup
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"10.1.1.10"
],
"ansible_apparmor": {
"status": "enabled"
},
[...]

Je ne vous copie-colle pas tout, rien que pour cette machine, j’ai 719 lignes… La quantité d’informations disponible est impressionnante, et on peut même en venir à se demander à quoi ça va bien pouvoir nous servir.

Ok, on en fait quoi ?

Du coup je profite de cet article pour faire un tuto tout simple et qui peut être utile dans de nombreux cas, réaliser des opérations différentes en fonction de la distribution de la machine concernée.

L’information qui va nous intéresser ici concerne donc les remontées en tant que « nom » ou « version » d’une distribution. Je vais vous économiser la lecture de nos 700+ lignes, et vous indiquer que vous pouvez trouver ces informations en filtrant sur les mots clés « ansible_distribution… » et « ansible_os… »

Voilà ce qu’on pourrait obtenir sur une machine CentOS :

ansible blop-vm1 -m setup -a 'filter=ansible_distribution*'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
"ansible_distribution_release": "Core",
"ansible_distribution_version": "7.2.1511"
},
"changed": false
}
ansible blop-vm1 -m setup -a 'filter=ansible_os_family'
blop-vm1 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "RedHat"
},
"changed": false
}

Et sur une machine Ubuntu :

ansible blop-vm2 -m setup -a 'filter=ansible_distribution*'
ansible blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "Ubuntu",
"ansible_distribution_file_parsed": true,
"ansible_distribution_file_path": "/etc/os-release",
"ansible_distribution_file_variety": "Debian",
"ansible_distribution_major_version": "16",
"ansible_distribution_release": "xenial",
"ansible_distribution_version": "16.04"
},
"changed": false
}
ansible blop-vm2 -m setup -a 'filter=ansible_os*'
blop-vm2 | SUCCESS => {
"ansible_facts": {
"ansible_os_family": "Debian"
},
"changed": false
}

Utiliser les facts dans un playbook

Pour continuer dans l’exemple, on va faire une chose qu’il ne faut jamais faire : désactiver le firewall et SELinux.

Imaginons que vous souhaitiez quand même le faire. Si vous lancez ce playbook sur tout votre parc et qu’il n’est pas homogène, vous allez tomber sur des groupes de machines Ubuntu, CentOS 5, 6, 7…

Un moyen de gérer les cas particuliers pourrait être de les classer tous vos hosts dans des groupes, et de créer un playbook pour chaque OS/version, restreint à un groupe de machines uniquement.

---
- hosts: rhelcentos6only
tasks:
[…]

Ce n’est d’ailleurs pas une mauvaise idée, surtout pour gérer les distrib aussi différentes que RHEL et Ubuntu par exemple.

En revanche, dans le cas de RHEL, on a des différences qui apparaissent à partir de la RHEL 7, notamment la gestion du Firewall qui passe de IPtables à firewalld.

On va donc faire appel à la clause when: de ansible, qui conditionne l’exécution d’une tâche (ou d’un rôle ou d’un block) à une validation. Et ça donnerait quelque chose comme ça :

---
- hosts: rhelcentos6only
tasks:
- name: "shutdown and disable IPtables for RHEL <= 6"
service:
name=iptables
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version <= "6")
- name: "shutdown and disable firewalld for RHEL >= 7"
service:
name=firewalld
state=stopped
enabled=no
when: (ansible_distribution == "CentOS" or ansible_distribution == "RedHat") and
(ansible_distribution_major_version >= "7")
- name: "disable selinux"
selinux:
state=disabled

Dans cet exemple, lors de l’exécution du playbook, on aura donc, pour chaque VM CentOS ou RHEL, une tâche qui sera exécutée, et l’autre qui sera marquée « skipping » (en bleu clair) et le playbook marchera pour toutes les RHEL, quelque soit leur version.

Aller plus loin

Il existe une page spécifique sur la documentation d’Ansible pour parler des conditions dans les playbooks, accessible à l’adresse suivante : https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_conditionals.html

Vous pouvez aussi utiliser les facts dans les options des tasks, et dans les templates, en encadrant le nom de la variable souhaitée avec des « doubles curly braces » : {{ xxx }}

- command: "echo {{ ma_super_variable }}"

Sources

Sortie d’Ansible 2.7 et ma première contribution

Wed, 10 Oct 2018 12:15:12 +0000

Sortie d’Ansible 2.7

Hier soir, la dernière version d’Ansible (2.7) est sortie. Cette release s’est concentrée sur une amélioration de la performance et de la stabilité, même si de très nombreux modules ont fait leur apparition, comme à chaque nouvelle version.

Python

Le support de Python 2.6 est abandonné, au profit de Python 2.7. Cela signifie que l’hôte qui exécutera le playbook devra disposer de Python 2.7 au minimum (même si Python 2.6 est toujours supporté sur la machine cible).

Écritures concurrentes

Un problème auquel j’ai déjà eu affaire est la gestion des écritures concurrentes sur un même fichier (par exemple si plusieurs hôtes écrivent sur un même fichier distant ou alors un delegate_to). A priori il existe maintenant un « lock » pour éviter d’écraser les modifications. Il faudra que je teste pour voir si ça marche bien.

Performances accrues, généralisation du SSH pipelining ?

La plus grosse modification, qui va nécessiter des tests approfondis, est la modification de la manière dont sont déclenchées les actions/modules sur les serveurs distants. Précédemment, les tasks nécessitaient 2 commandes SSH au lieu d’une maintenant. Effectivement, le temps d’exécution de playbooks contenant des actions simple mais très nombreuses pouvait être très long.

Ansible-2.7 changes the Ansiballz strategy for running modules remotely so that invoking a module only needs to invoke python once per module on the remote machine instead of twice.

Un gain de performance dans ce genre de cas où on passe plus de temps à lancer des commandes que les exécuter est forcément une bonne nouvelle. Je me demande si ce n’est pas simplement une activation « par défaut » de la variable d’environnement ANSIBLE_SSH_PIPELINING=1 (que j’utilise déjà dans ce genre de cas).

A priori non si j’en crois cette issue, mais pour l’instant je n’ai pas remarqué de différence significative sur mes playbooks les plus gourmands en temps d’exécution.

Module reboot

A noter, la plupart des gens remontent l’arrivée d’un module « reboot » (et son équivalent « win_reboot ») qui redémarre une machine et ré-initie une connexion une fois que la machine a refait surface. Personnellement je n’utilise pas ce genre de fonctionnalité mais j’imagine que c’est une feature « nice to have » plutôt que d’utiliser le module « pause » ou la fonctionnalité « retry » en attendant que l’hôte refasse surface.

Les nouveaux modules

Je ne vais pas en faire la liste complète (disponible dans le changelog), mais cette version a visiblement été l’occasion pour les équipes de plusieurs cloud providers de se mettre en avant.

On peut noter les équipes de Google Cloud comme grands vainqueurs avec 39 nouveaux modules. Ils sont suivi par Azure (+21, avec l’apport des bases de données et des webapps), Vultr (13), et 8 pour Scaleway.

Tout ça m’intéresse beaucoup car, notamment pour Scaleway, de nombreux objets étaient encore indisponibles et il a fallut que j’écrive des scripts à la main pour curler l’API, ne serait ce que pour récupérer les IDs des templates de VMs que je voulais utiliser (impossible à lister autrement).

Avant :

curl -X GET -H "X-Auth-Token: $SCW_API_KEY" -H 'Content-Type: application/json' https://cp-par1.scaleway.com/images | jq -r '.images[] | select(.name|contains("CentOS")) | .id,.name,.arch,.modification_date'
37832f54-c18f-4338-a552-113e4302a236
CentOS 7.4
x86_64
2018-09-06T10:40:08.145552+00:00
[...]

Maintenant, je peux sois l’exécuter à la main directement depuis Ansible, soit requêter le serveur Scaleway pour avoir une liste des images disponible directement dans mes playbooks :

ansible localhost -m scaleway_image_facts -a region=par1
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
localhost | SUCCESS => {
"ansible_facts": {
"scaleway_image_facts": [
{
"arch": "x86_64",
"creation_date": "2018-09-14T10:01:24.268850+00:00",
"default_bootscript": {
"architecture": "x86_64",
"bootcmdargs": "LINUX_COMMON scaleway boot=local nbd.max_part=16",
"default": false,
"dtb": "",
"id": "15fbd2f7-a0f9-412b-8502-6a44da8d98b8",
[...]
- name: Gather Scaleway images facts 
scaleway_image_facts: 
region: par1
register: images_facts

Et tant qu’on est dans le genre module qui vient remplacer des trucs que je faisais à la mimine, on peut aussi citer docker_swarm + docker_swarm_service pour gérer un cluster docker Swarm (comme son nom l’indique), ou k8s_facts pour récupérer des objets dans Kubernetes.

Et ma première contribution !

Même si j’ai déjà contribué sur plusieurs projets open source (traductions du site de Shinken, petites contributions à plusieurs plugins Nagios et à XWiki, ouverture d’issues dans de nombreux projects open source), j’ai également résolu ma première issue sur un gros projet grâce à Ansible et l’équipe d’Azure.

Il y a peu, Microsoft a mis à disposition sur Azure de machine virtuelle disposant gratuitement d’interface physique dédiées (non virtualisées donc) à 30 Gbps et avec une latence moindre (plus d’info sur la documentation officielle).

Comme il s’agissait d’un simple flag à ajouter dans l’API et que l’issue avait été taguée en « easy fix » par les maintainer, j’ai sauté sur l’occasion et j’ai pris l’issue à mon compte.

Au final, sur les 70 lignes de mon commit, il n’y a que 10 lignes de codes (le reste étant des tests et de la documentation, obligatoires pour toute soumission), mais je suis quand même content car ça marche bien ;)

Champomy !!

Minikube sur Hyper-V part 2 : troubleshooting de l’installation

Tue, 02 Oct 2018 11:45:54 +0000

Minikube, le retour

Il y a deux semaines, j’ai fais un article sur l’installation de Minikube sur un poste Windows 10. Petite subtilité, l’article en question explique comment installer Minikube sur Hyper-V, nativement présent avec Windows 10, plutôt qu’avec Virtual Box, le choix par défaut mais qui nécessite un téléchargement et une installation complémentaire. Si vous l’avez loupé, c’est par ici.

Option 2 : Expectations meet life

On s’était arrêté dans l’article précédent à un monde merveilleux ou tout marche du premier coup.
Mais, vous vous en doutez, dans la vie (et particulièrement dans l’IT), rien ne se passe jamais comme prévu.

Voilà donc un petit florilège des problèmes que vous pourriez (ou avez) rencontrer (et leur résolution !)

VBoxManage not found

Si vous en venez à vous demander comment l’installer sur Hyper-V, c’est probablement que vous avez commencé par lancer la commande « minikube start » sans arguments… L’installeur a donc bêtement assumé que vous utilisiez Virtual Box (pourquoi ?) et vous vous retrouvez avec l’erreur suivante :

Error getting state for host: VBoxManage not found. Make sure VirtualBox is installed and VBoxManage is in the path.

Pourtant, vous avez beau forcer le start avec le flag suivant, rien y fait, ce n’est pas pris en compte.

--vm-driver hyperv

Pour trouver comment résoudre ce problème, vous pouvez jeter à œil à cette issue sur github

En réalité, une fois le premier « start » lancé, les fichiers de configuration sont générés dans C:\users[votrelogin].minikube (et en particulier dans profiles\minikube\config.json).

Impossible d’expliquer à l’installeur que vous avez changé d’avis (oui oui…), il faut donc de supprimer tout le dossier .minikube et recommencer avec les bons paramètres la prochaine fois (enfin c’est le plus simple, on va dire).

minikube-v0.xx.x.iso: Le chemin d’accès spécifié est introuvable…

minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable...

Ok, ça ne marche toujours pas. On passe en mode verbose pour avoir l’erreur exacte :

PS C:\windows\system32> minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch" -v=7
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
[...]
[stderr =====>] :
Downloading D:\Users\zwindler\.minikub\cache\boot2docker.iso from file://D:/Users/zwindler/.minikub/cache/iso/minikube-v0.28.1.iso...
E0906 15:10:27.568262 14484 start.go:174] Error starting host: Error creating host: Error executing step: Creating VM.: open /Users/zwindler/.minikub/cache/iso/minikub-v0.28.1.iso: Le chemin d’accès spécifié est introuvable..
Retrying.
E0906 15:10:27.873612 14484 start.go:180] Error starting host: Error creating host: Error executing step: Creating VM.
: open /Users/zwindler/.minikube/cache/iso/minikube-v0.28.1.iso: Le chemin d’accès spécifié est introuvable.

Pourtant le fichier existe. Et c’est reparti pour un tour sur Github pour avoir plus de détails !

Ici, c’est donc tout simplement le script Minikube qui ne sait pas que vous avez un disque **D:**… Alors qu’il vient de le déposer lui même dans *D:* une ligne plus haut !!! La solution donc :

you can specify the path for the .minikub directory by setting the MINIKUBE_HOME env variable

Bon en vrai la bonne syntaxe sous Windows (dans Powershell en tout cas) c’est :

$MINIKUBE_HOME="D:\Users\[votrelogin]\"

On oublie pas de nettoyer la tentative précédente avec un :

minikube delete

FLMNH : « Error deleting machine profile config »

Si jamais en essayant de nettoyer votre environnement (pour recommencez, vous essayez un « minikube delete » et que vous vous prenez une erreur).

minikube delete
Deleting local Kubernetes cluster...
Machine deleted.
Error deleting machine profile config

Rebelotte, on supprime le dossier D:\Users[votrelogin].minikube à la main.

Error starting host: Error starting stopped host: exit status 1

Tout à l’air de fonctionner. Vous croyez que vous vous en êtes sortis ? Pauvres fous ;)

Au moment où tout se termine, le script vérifie que le cluster est opérationnel. Et après avoir boucler un moment : PAF !

Error starting host: Error starting stopped host: exit status 1

L’erreur n’est pas très explicite. En gros, vous êtes dans le cas où tout est bien installé, mais le curl pour vérifier que le cluster est UP échoue, pour un souci réseau. La plupart du temps, il s’agit de l’erreur suivante :

After some troubleshooting and head banging, it became apparent that the external network adapter had an ethernet adapter selected that was not connected to a network. (ethernet selected, instead of the wireless adapter). Of course an IP wont be allocated on an external network if none is connected.

Vérifiez donc dans les paramètres d’Hyper-V que vous ne vous êtes pas trompé d’adaptateur réseau lors de la configuration du réseau virtuel (cf l’article précédent) !

unable to authenticate, attempted methods [publickey none]

Ok, cette fois ci tout est censé être bon. Pourtant, à la fin, ça plante encore (désespoir).

Error dialing TCP: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain

Là je ne suis pas sûr à 100% ni de la cause, ni du fix, mais a priori, c’était un problème lié au client/serveur OpenSSH fourni par Microsoft, qui serait pourri. L’installation d’une autre version via Chocolatey semble avoir résolu le problème.

github.com/kubernetes/minikube/issues/2329

PS D:\> minikube ip
172.16.25.217

choco install openssh
Chocolatey v0.10.11
Installing the following packages:
openssh

Installer Minikube sur Windows 10 et Hyper-V – part 1

Wed, 12 Sep 2018 11:45:26 +0000

Minikube sur Hyper-V, c’est facile ?

Un bon moyen de commencer à bidouiller avec Kubernetes, c’est d’utiliser Minikube.

Pour ceux qui ne connaissent pas, il s’agit d’un script qui va récupérer une machine virtuelle préconfigurée avec tous les composants nécessaires à Kubernetes, et l’installer sur votre machine. Ce script est disponible sur Windows, Mac et Linux, et vous trouverez de nombreux tutos pour l’installer via le logiciel de virtualisation Virtual Box (à installer préalablement, en prérequis donc).

Mais admettons que vous ayez commencés à bidouiller avec Docker avec « Docker for Windows ». Quoi de plus normal de passer sur K8s (le petit nom de Kubernetes, plus court) après avoir joué avec Docker.

Et paf ! vous n’arrivez pas à installer, à cause d’un obscur message qui vous parle de Virtual Box (alors que vous ne l’utilisez pas). On coince dès les prérequis, ça commence mal.

Et oui… « Docker for Windows » active Hyper-V… et si Hyper-V est activé, impossible d’installer Virtual Box !

Si la plupart des tutoriels mettent en avant Virtual Box justement (car c’est l’option par défaut), vous n’avez peut être pas envie de désinstaller Docker for Windows pour autant !

Ou peut être que vous n’avez pas envie d’installer Virtual Box alors que votre Windows 10 vous fourni déjà « out of the box » un logiciel de virtualisation parfaitement valide (attention, je dis ça uniquement pour Windows 10, sur un PC client… Pour un serveur, c’est juste une grosse blague cette plateforme de virtu…).

On va quand même s’en sortir

En gros, on est censé dérouler simplement les prérequis : avoir VT-x/AMD-v d’activés dans le BIOS. Là je ne vais pas vous faire l’explication car ça dépend grandement de votre machine.

Ensuite, on ajoute la fonctionnalité Hyper-V sur votre Windows 10. Pour se faire, on ouvre le menu des « fonctionnalités Windows ».

Si ce n’est pas déjà fait cocher « Hyper-V », validez, et on vous demandera très probablement de redémarrer. Attention, à partir de là vous ne pourrez plus utiliser Virtual Box (c’est tout le but de cet article, mais bon) ou VMware player ou autre.

Et enfin, pour éviter des conflits avec Docker pour Windows, on va créer un réseau virtuel dédié dans notre console Hyper-V. Lancer le gestionnaire Hyper-V :

Sur le menu tout à droite, on créé un Commutateur virtuel dédié. Pour réaliser cette opération, on clique sur Gestionnaire de commutateur virtuel, puis dans la fenêtre qui s’ouvre, en haut à gauche dans la liste des Commutateurs virtuels, on clique sur Nouveau commutateur réseau virtuel.

Dans les propriétés, on lui donne un petit nom (minikube par exemple) et on oublie pas de cocher « Réseau externe » (pour utiliser une des cartes physiques comme un bridge) et de cocher ensuite « Autoriser le système d’exploitation de gestion à partager cette carte réseau (surtout si c’est votre seule carte réseau !).

Pour finir, on récupère Minikube ici et on lance la commande suivante depuis un Powershell :

minikube start --vm-driver hyperv --hyperv-virtual-switch "minikube"

Option 1 : « J’ai de la chance »

Si tout se passe bien, tant mieux pour vous !

Vous avez de la chance, tout se passe bien et vous avez Minikube d’installé sur votre poste. C’est la fête, vous allez pouvoir déployer des containers à Gogo !

PS D:\> minikube status
minikube: Running
cluster: Running
kubectl: Correctly Configured: pointing to minikube-vm at 172.16.25.173

Protips : Et maintenant ?

Pour aller plus loin, vous pouvez commencer par jeter un oeil sur mes autres articles qui parlent de Kubernetes, notamment le tutoriel pas à pas où j’explique comment déployer une application complète et Statefull sur Kubernetes.

Mais voici quelques protips supplémentaires spécialement dédiées aux spécificités de minikube.

Les Ingress !

Pour le fun, on va certainement vouloir ajouter le support des Ingress (pas activés par défaut) :

PS D:\> minikube addons enable ingress
ingress was successfully enabled

Accéder au dashboard

On peut accéder au Dashboard (l’interface web qui permet de contrôler k8s sans passer par kubectl ou les API) n’est pas directement accessible avec un kubectl proxy comme sur un Kubernetes standard.

Elle est cependant bien disponible sans ajout supplémentaire, à l’aide de la commande suivante :

minikube dashboard

Se loguer sur la machine virtuelle K8s

Si pour une raison ou pour une autre, vous voulez vous connecter en SSH sur la VM qui contient votre environnement Kubernetes, c’est possible ! Récupérez l’IP affectée à la VM (afficher avec un minikube status ou un kubectl config view).

Il existe un user « docker » avec pour mot de passe « tcuser » (mot de passe ultrasecure, s’il en est). A noter, ce compte à un accès sudo à la machine en NOPASSWD.

Ca peut être utile par exemple pour vérifier que les Adminission Controllers sont bien actifs (on en aura besoin dans un prochain article)

ps -ef | grep api
kube-apiserver --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota --requestheader-allowed-names=front-proxy-client --service-account-key-file=/var/lib/localkube/certs/sa.pub --tls-private-key-file=/var/lib/localkube/certs/apiserver.key --kubelet-client-key=/var/lib/localkube/certs/apiserver-kubelet-client.key --proxy-client-cert-file=/var/lib/localkube/certs/front-proxy-client.crt --requestheader-group-headers=X-Remote-Group --enable-bootstrap-token-auth=true --allow-privileged=true --requestheader-username-headers=X-Remote-User --requestheader-extra-headers-prefix=X-Remote-Extra- --client-ca-file=/var/lib/localkube/certs/ca.crt --proxy-client-key-file=/var/lib/localkube/certs/front-proxy-client.key --insecure-port=0 --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --advertise-address=172.16.25.173 --service-cluster-ip-range=10.96.0.0/12 --tls-cert-file=/var/lib/localkube/certs/apiserver.crt --kubelet-client-certificate=/var/lib/localkube/certs/apiserver-kubelet-client.crt --requestheader-client-ca-file=/var/lib/localkube/certs/front-proxy-ca.crt --secure-port=8443 --authorization-mode=Node,RBAC --etcd-servers=https://127.0.0.1:2379 --etcd-cafile=/var/lib/localkube/certs/etcd/ca.crt --etcd-certfile=/var/lib/localkube/certs/apiserver-etcd-client.crt --etcd-keyfile=/var/lib/localkube/certs/apiserver-etcd-client.key

kubectl api-versions | findstr "admissionregistration.k8s.io/v1beta1"
admissionregistration.k8s.io/v1beta1

Option 2

Rien ne marche !

Et pour être parfaitement honnête, c’est ce qui m’est arrivé ! Du coup, je vous prépare un nouvel article avec toutes les astuces de troubleshooting. La suite - dans le prochain épisode, donc ;-)

Sources

Installation xwiki 10.6.1 via un playbook Ansible

Wed, 05 Sep 2018 11:45:00 +0000

Ansible + XWiki

Je sais ce que vous vous dites :

Ça fait longtemps que zwindler n’a pas écrit un article sur Ansible ou XWiki !

Non ? Vous ne vous dites pas ça ? Bon tant pis c’est pas grave. Aujourd’hui, je rédige ENFIN l’article pour parler d’un playbook que j’ai déjà rédigé il y a presque un an déjà (et mis à jour et déployé de nombreuses fois). C’est dire si j’ai du retard dans les articles du blog…

Petit rappel des épisodes précédents

J’ai déjà rédigé de manière extensive sur XWiki qui est un belle solution open source de gestion de la connaissance. Parmi les articles les plus susceptibles d’intéresser, il y a déjà :

Il y en a plein d’autre (voir ici).

Et Ansible ?

Et bien oui. Je vous rabâche aussi les oreilles avec Ansible, l’Infrastructure as Code, et l’Idempotence. (Là encore, il y en a plein)

Alors pourquoi pas un playbook Ansible pour automatiser l’installation de XWiki, si vous n’avez pas de cluster Kubernetes sous la main et que vous êtes un Gaulois réfractaire à Docker ?

Ya quoi dans ton playbook ?

Trêve de suspense, les sources sont disponibles sur Github à cette adresse.

Ce playbook a été testé pour des RHEL/CentOS 7, en particulier de la version 7.2 jusqu’à 7.4. Une installation de RHEL/CentOS en mode minimale, même sans environnement graphique, devrait être suffisante. Je l’ai faite tourner en production sur des environnements Desktop dans des VMs, mais aussi en Minimal sur un container LXC dans Proxmox VE sans aucun souci.

L’installation n’utilise pas les serveurs web et de bases de données par « défaut » (MySQL), mais Tomcat 8 et PostgreSQL. Pour la version de Tomcat, c’est une version très particulière qu’il faut utiliser car des bugs ont étés introduits dans une version, puis RE-introduits quelques mois plus tard. Vous pouvez modifier la version par défaut qui est une variables de mon playbook (8.5.32) si elle ne vous convient pas. Les instructions d’installation se basent sur la documentation officielle.

- tomcat_version: 8.5.32

Vous pouvez également modifier la version de XWiki directement dans le playbook (c’est une variable là aussi) :

- xwiki_version: "10.6.1"

A noter, les vielles versions de XWiki n’étaient pas hébergées sur le même dépôt, qui a changé récemment, d’où les deux URLs dans le playbook.

Prérequis

On va utiliser git pour récupérer le playbook et ansible (version de l’OS, rien d’exotique).

yum install ansible git
git clone https://github.com/zwindler/ansible-deploy-xwiki-tomcat-postgresql
cd ansible-deploy-xwiki-tomcat-postgresql

Quand est ce qu’on installe XWiki ?

Maintenant !

Sur un poste qui dispose de git et Ansible :

ansible-playbook -l localhost ansible-deploy-xwiki-tomcat-postgresql.yml

Le playbook devrait vous prompter pour un mot de passe pour l’utilisateur de base de données PostgreSQL, n’hésitez pas à mettre quelque chose de complexe. Vous ne devriez pas en avoir besoin.

Si vous avez une erreur qui vous dit que localhost est ignoré, vous pouvez l’ajouter à votre fichier d’inventaire global : /etc/ansible/hosts

sudo vim /etc/ansible/hosts
[local]
localhost ansible_connection=local

Et Paf ! Vous avez un XWiki installé, disponible à l’adresse http://@IP:8080/. Il n’y a plus qu’à le configurer :)

Utiliser kubectx/kubens pour changer facilement de context et de namespace dans Kubernetes

Tue, 28 Aug 2018 11:45:26 +0000

Vous avez plusieurs clusters Kubernetes et de nombreux namespaces

Si vous avez la main sur plusieurs clusters Kubernetes, vous utilisez très probablement la commande kubectl à tour de bras. Et le moins qu’on puisse dire, c’est que switcher d’un cluster à l’autre est parfois pénible, surtout si vous avez en plus de nombreux namespaces dans chacun d’entre eux.

Pour ceux qui voudraient en savoir plus sur Kubernetes et qui voudraient monter un petit cluster rapidement, je vous renvoie sur mes autres articles sur le sujet; en particulier celui sur Kubespray, qui a l’avantage incommensurable d’utiliser Ansible pour déployer k8s ;-).

Avec kubectl

Voilà ce qu’il faut faire si vous voulez naviguer de cluster en cluster et de namespace en namespace, simplement avec kubectl (en partant du principe que vos contexts sont déjà configurés).

On commence par lister les contexts. Oui je ne connais pas par coeur leur nom alors j’ai besoin de regarder comment ils s’appellent et lequel est sélectionné en ce moment.

kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
k8s-par-prod k8s-par-prod k8s-par-prod-zwindler
k8s-dub-dev k8s-dub-dev k8s-dub-dev-zwindler
* k8s-par-test k8s-par-test k8s-par-test-zwindler

Ici, la petite étoile nous dit que c’est k8s-par-test qui est sélectionné. Pas de bol, c’est en prod que je veux faire mes modifications.

kubectl config use-context k8s-par-prod
Switched to context "k8s-par-prod".

Si je ne veux pas que le context prod soit celui par défaut (pour éviter de supprimer par erreur des pods en prod alors que je pense être en dev), il est plus prudent de spécifier explicitement à chaque fois dans quel context je me trouve

kubectl --context k8s-par-prod get nodes
[...]

Maintenant que j’ai sélectionné mon contexte, je veux lister des pods d’un namespace en particulier. Bon, le souci c’est que j’en ai beaucoup des namespaces et je ne me souviens pas toujours comment ils s’appellent. Rebelotte, je liste une nouvelle fois les objets disponibles :

kubectl get ns
NAME STATUS AGE
kube-public Active 361d
kube-system Active 361d
[...]
zwindler Active 126d

Ok, je me souviens que mes pods sont dans le namespace « zwindler ». Comme pour le context, je peux maintenant soit configurer un namespace par defaut, soit le nommer explicitement :

kubectl -n zwindler get pods
NAME READY STATUS RESTARTS AGE
ubuntu-1111111111-aaaaa 1/1 Running 0 31d

A noter, si je veux spécifier le context explicitement aussi, ça commence à faire long comme lignes de commandes, juste pour un « get pods » :

kubectl --context k8s-par-prod -n zwindler get pods
NAME READY STATUS RESTARTS AGE
ubuntu-1111111111-aaaaa 1/1 Running 0 31d

Contourner la difficulté

Si je suis un peu bourrin, j’aurai pu afficher les pods de TOUS les namespaces avec l’option « –all-namespaces ». C’est une bonne idée si on a pas beaucoup de containers et si on ne sait plus trop dans quel namespace est notre pod. Mais clairement, au delà de 50 pods, ça devient totalement illisible.

kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
toto ubuntu-1111111111-aaaaa 1/1 Running 0 4h
[... et c'est parti pour des centaines de lignes !!!]

Pour se gagner du temps, il existe aussi des fichiers d’autocomplétion pour kubectl. Vous n’avez plus qu’à appuyer sur la touche [tab] une fois que vous avez écris « kubectl –context » pour éviter de faire un get préalable et des copier coller le nom du contexte souhaité.

Vous trouverez des infos sur l’autocomplétion de kubectl sur le site officiel de Kubernetes : kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion

echo "source <(kubectl completion bash)" >> ~/.bashrc

Mais ça ne vous évite pas les lignes de commande à rallonge avec contexts et namespaces explicitement indiqués.

Un petit hack simple pour se simplifier la vie

Si l’autocomplétion ne vous suffit pas, vous pouvez utiliser deux petits binaires très pratiques, disponibles sur le dépôt Github de ahmedb.

Vu sur Twitter (comme quoi des fois ça sert), ces deux petits binaires kubectx et kubens permettent de configurer respectivement le contexte et le namespace par défaut. Le projet fourni même l’autocomplétion pour les shells les plus utilisés.

Installation rapide de kubectx et kubens

Ici, rien de bien compliqué. On copie le dépôt sur son poste et on link les binaires dans un dossier du PATH, et on colle l’autocomplétion dans notre shell :

sudo git clone https://github.com/ahmetb/kubectx /opt/kubectx
sudo ln -s /opt/kubectx/kubectx /usr/local/bin/kubectx
sudo ln -s /opt/kubectx/kubens /usr/local/bin/kubens
echo "source /opt/kubectx/completion/kubectx.bash" >> ~/.bashrc
echo "source /opt/kubectx/completion/kubens.bash" >> ~/.bashrc

Simple, non ?

Utilisation de kubectx et kubens

kubectx [tab]
- k8s-par-prod k8s-dub-dev k8s-par-test
kubectx k8s-par-prod
Switched to context "k8s-par-prod".
kubens
- default blip blup
kube-public kube-system blop [...]

Pour le fun le développeur a simplifié la liste des objets et a ajouté un peu de couleur (jaune) pour indiquer quel context/namespace est sélectionné par défaut (plutôt qu’un tableau et une étoile). Peut être un peu gadget mais je ne dis pas non.

Et c’est tout ?

Et enfin, kubectx ne sert pas qu’à sélectionner le context par défaut. On peut également réaliser la plupart des commandes sur les contexts avec :

kubectx --help
USAGE:
kubectx : list the contexts
kubectx : switch to context
kubectx - : switch to the previous context
kubectx = : rename context to
kubectx =. : rename current-context to
kubectx -d [] : delete context ('.' for current-context)
(this command won't delete the user/cluster entry
that is used by the context)
kubectx -h,--help : show this message

Alors certes, ça ne va pas révolutionner votre vie, mais ça peut vous faire gagner quelques secondes dans la journée. Et si vous êtes comme moi, vous n’êtes jamais contre quelques secondes de gagnées ;)

Sécuriser l’émission de vos certificats avec un CAA (Azure)

Tue, 12 Jun 2018 11:45:10 +0000

CAA ? Azure ?!?

Et oui, je travaille sur Azure ! Je crois bien que c’est le premier article que je vais faire à ce sujet donc je commence par quelque chose de léger, créer un CAA.

Au-delà de toute considération purement dogmatique, le cloud de Microsoft fait quand même partie des plus grands, avec une richesse fonctionnelle et une API aussi riche que ce qu’on trouve chez les autres. J’aurai l’occasion de faire d’autres articles sur Azure car j’utilise énormément les modules Ansible développés par les équipes de Microsoft (qui s’appuient sur l’API d’Azure).

Et donc, le CAA ?

Mais cet article parle de CAA. Pour ceux qui ne connaitraient pas, un CAA est un « nouveau » (2017) type d’enregistrement DNS :

La CAA est une mesure de sécurité qui permet aux propriétaires d’un nom de domaine de préciser dans leur DNS (Domain Name System) les autorités de certification (AC) qui sont autorisées à émettre des certificats pour leur nom de domaine.

Global Sign (lien mort, pas disponible sur Internet Archive)

Concrètement, si je possède un domaine avec un grand nombre de sites web signés, que je n’utilise qu’une ou deux (ou un nombre fini) autorités de certifications, je peux maintenant spécifier lesquelles (parmi la centaine des AC existantes) sont autorisées à émettre un certificat pour mon domaine. Cela permettra d’éviter que des personnes mal intentionnées génèrent un certificat pour une URL dans un de vos sous domaines.

Comment ça fonctionne ?

Il existe donc un nouveau type d’entrée dans votre DNS qui devrait ressembler à ça :

Name	Type	Value
zwindler.fr.	CAA	0 issue « letsencrypt.org »
zwindler.fr.	CAA	0 iodef « mailto:zwindler@zwindler.fr »

Pour l’entrée zwindler.fr., j’ai donc un CAA qui dispose de 2 variables (issue et iodef) :

La première indiquant que seul letsencrypt.org peut générer des certificats pour mon domaine. On peut en avoir plusieurs si on a plusieurs autorités de certification.
La seconde indiquant qu’il faut m’envoyer un email si jamais quelqu’un qui n’a pas les droits essaye de générer un certificat.

A noter : iodef n’est pas respecté par toutes les autorités de certifications, donc vous n’aurez potentiellement pas d’emails en cas de tentative de génération de certificat chez une AC non autorisé.

Ok, comment je créé un CAA ?

Normalement, c’est trivial. Il s’agit d’un enregistrement DNS comme un autre. Par exemple chez OVH, vous pouvez directement le créer depuis l’interface :

Et sur Azure ?

Il faut bien que ce soit rigolo. Dans le portail d’Azure, il n’est pas possible de créer (ni même de voir !!!) les champs de types CAA, pourtant disponibles depuis mi 2017.

La seule solution est d’utiliser l’API REST, la CLI azure, ou Powershell :

Page de documentation azure cli (record-set)
Gérer les enregistrements DNS avec Powershell

Avec Azure cli

Du coup je suis parti de la doc pour faire ça :

En partant du principe que vous avez un compte sur Azure, que vous gérez les DNS de la zone zwindler.fr depuis Azure DNS (dans un resource group appelé dns-rg), voilà ce qu’il faut faire pour créer une protection pour le sous domaine *.test.zwindler.fr.

az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "issue" --value "letsencrypt.org"
az network dns record-set caa add-record --resource-group dns-rg --zone-name zwindler.fr --record-set-name test --flags 0 --tag "iodef" --value "zwindl3r@zwindler.fr"
az network dns record-set caa list --resource-group dns-rg --zone-name zwindler.fr
{
"caaRecords": [
{
"flags": 0,
"tag": "iodef",
"value": "zwindl3r@zwindler.fr"
},
{
"flags": 0,
"tag": "issue",
"value": "letsencrypt.org"
}
],
"etag": "aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa",
"fqdn": "test.zwindler.fr.",
"id": "/subscriptions/aaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa/resourceGroups/dns-rg/providers/Microsoft.Network/dnszones/zwindler.fr/CAA/test",
"metadata": null,
"name": "test",
"resourceGroup": "dns-rg",
"ttl": 3600,
"type": "Microsoft.Network/dnszones/CAA"
}

Et si je veux le domaine entier ?

Et là c’est la blague !

Si vous créez un record-set « test« , il va vous créer un CAA pour test.zwindler.fr (voire le champ fqdn dans la réponse du list). Vous n’avez pas la main sur le fqdn directement (que ce soit en création ou en mise à jour), il est créé à partir du nom.

Or, vous avez très probablement envie de protéger zwindler.fr, pas seulement test.zwindler.fr, car ça n’aurait pas vraiment de sens (on rappelle que le but de la manœuvre et d’empêcher des gens de générer des certificats pour des sous domaine de votre domaine) sinon.

Créer une liste exhaustive de tous les sous domaines possibles me semble complexe ;-).

L’astuce, que vous ne trouverez pas dans la documentation (en tout cas dans les pages que j’ai lues), est de créer un recordset avec comme nom « @ » (j’avais testé, vide, « * », « . », mais pas « @ »…).

Et là, un recordset sera créé pour l’ensemble de votre zone DNS (zwindler.fr dans mon exemple).

Magie-magie…

script on Zwindler's Reflection

Avec Terragrunt, ne répétez plus vos variables Terraform 358 fois

Mais pourquoi tu fais çaaaaaa ???

Les limites de Terraform ?

Arrive alors Terragrunt !

On se prépare

Factoriser les variables

Un fichier de configuration

Variables globales

Variables intermédiaires

Variables non factorisables

Allez plus haut

Configuration du backend Terraform

Une commande pour les contrôler toutes…

Conclusion

D’autres ressources externes sur le sujet

Récupérer les informations sur la distribution avec les facts Ansible

Les facts d’Ansible

C’est quoi les facts dans Ansible

A quoi ça ressemble ?

Ok, on en fait quoi ?

Utiliser les facts dans un playbook

Aller plus loin

Sources

Sortie d’Ansible 2.7 et ma première contribution

Sortie d’Ansible 2.7

Python

Écritures concurrentes

Performances accrues, généralisation du SSH pipelining ?

Module reboot

Les nouveaux modules

Et ma première contribution !

Minikube sur Hyper-V part 2 : troubleshooting de l’installation

Minikube, le retour

Option 2 : Expectations meet life

VBoxManage not found

minikube-v0.xx.x.iso: Le chemin d’accès spécifié est introuvable…

FLMNH : « Error deleting machine profile config »

Error starting host: Error starting stopped host: exit status 1

unable to authenticate, attempted methods [publickey none]

Installer Minikube sur Windows 10 et Hyper-V – part 1

Minikube sur Hyper-V, c’est facile ?

On va quand même s’en sortir

Option 1 : « J’ai de la chance »

Protips : Et maintenant ?

Les Ingress !

Accéder au dashboard

Se loguer sur la machine virtuelle K8s

Option 2

Sources

Installation xwiki 10.6.1 via un playbook Ansible

Ansible + XWiki

Petit rappel des épisodes précédents

Et Ansible ?

Ya quoi dans ton playbook ?

Prérequis

Quand est ce qu’on installe XWiki ?

Utiliser kubectx/kubens pour changer facilement de context et de namespace dans Kubernetes

Vous avez plusieurs clusters Kubernetes et de nombreux namespaces

Avec kubectl

Contourner la difficulté

Un petit hack simple pour se simplifier la vie

Installation rapide de kubectx et kubens

Utilisation de kubectx et kubens

Et c’est tout ?

Sécuriser l’émission de vos certificats avec un CAA (Azure)

CAA ? Azure ?!?

Et donc, le CAA ?

Comment ça fonctionne ?

Ok, comment je créé un CAA ?

Et sur Azure ?

Avec Azure cli

Et si je veux le domaine entier ?

Liens utiles