Azure on Zwindler's Reflection

Sauvegarder son Kubernetes avec Velero (ex Ark)

Mon, 02 Aug 2021 06:15:00 +0000

Contexte

J’ai écris cet article / tuto en janvier 2019 sans jamais le terminer / mettre en forme. A l’époque, Heptio était en train de se faire racheter par VMware. Au moment où j’allais le poster, VMware a fait quelques modifications dans le tool, notamment en changeant le nom de Ark vers Velero et en l’intégrant à Tanzu (le Kubernetes de VMware).

Idéalement, j’aurais donc aimé réécrire l’article en remettant tout à jour, les noms, les lignes de commandes, etc. Sauf que je ne l’ai jamais fait. Et aujourd’hui, je ne travaille plus sur des clusters Kubernetes avec des workloads majoritairement Stateful et préfère l’approche Déclarative (type FluxCD) dans l’hypothèse où j’aurais un énorme crash à gérer plutôt que de tenter une restauration, avec tous les effets de bords et les risques que ça implique.

Cependant, plutôt que de mettre cet article « presque fini » à la corbeille, je prend donc le parti de le poster « tel quel », avec tous les défauts qu’il pourra avoir (notamment si certaines parties sont outdated). Le concept général lui, restera le même.

Pour illustrer le propos, j’avais déployé un cluster AKS mais ça marche bien évidemment avec n’importe quel cluster Kubernetes.

Générer le cluster K8s AKS

az login
az group create --name myownkubernetescluster --location westeurope \
--subscription "Visual Studio Professional"
az aks create --resource-group myownkubernetescluster --name myawesomeakscluster \
--node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s \
--kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/dgermain_never_expire_rsa_openssl2.pub \
--subscription "Visual Studio Professional"
az aks get-credentials --resource-group myownkubernetescluster --name myawesomeakscluster \
--subscription "Visual Studio Professional"

Éventuellement ajouter les droits pour le dashboard

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard
az aks browse --resource-group myownkubernetescluster --name myawesomecluster

Sauvegarde / restauration avec Velero

Information sur Velero (Ark Heptio) github.com/vmware-tanzu/velero

Comme on est sur Azure dans mon exemple :

github.com/vmware-tanzu/velero-plugin-for-microsoft-azure#setup

On commencer par créer un ressource group spécifique aux backups (pour ne pas tout perdre si le ressource group est supprimé)

AZURE_BACKUP_RESOURCE_GROUP=arkbackups
az group create -n $AZURE_BACKUP_RESOURCE_GROUP --location westeurope \
--subscription "Visual Studio Professional"
AZURE_STORAGE_ACCOUNT_ID="ark$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
az storage account create \
--name $AZURE_STORAGE_ACCOUNT_ID \
--resource-group $AZURE_BACKUP_RESOURCE_GROUP \
--sku Standard_GRS \
--encryption-services blob \
--https-only true \
--kind BlobStorage \
--access-tier Hot \
--location westeurope \
--subscription "Visual Studio Professional"
az storage container create -n arkblob --public-access off \
--account-name $AZURE_STORAGE_ACCOUNT_ID --subscription "Visual Studio Professional"

Récupérer le groupe de ressource du cluster K8s

az group list --query '[].{ ResourceGroup: name, Location:location }' --subscription "Visual Studio Professional"
[...]
{
"Location": "westeurope",
"ResourceGroup": "MC_myownkubernetescluster_myawesomeakscluster_westeurope"
},
{
"Location": "westeurope",
"ResourceGroup": "myownkubernetescluster"
}

Dans le cas d’AKS, il s’agit bien de choisir le groupe qui contient les VMs (MC_myownkubernetescluster_myawesomeakscluster_westeurope), et pas celui que vous avez créé en début de procédure (myownkubernetescluster) qui ne contient que l’objet « Kubernetes service ».

AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope

Créer un « Service principal » (compte de service dans Azure). Ne pas oublier de stocker le secret (contenu de la variable AZURE_CLIENT_SECRET) car on y aura plus accès a posteriori.

AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "myarkserviceprincipal" --role "Contributor" --query 'password' -o tsv`
AZURE_CLIENT_ID=`az ad sp list --display-name "myarkserviceprincipal" --query '[0].appId' -o tsv`

Récupérer les sources

Dans mon cas, la dernière version disponible est la v1.6.2, et j’ai besoin des la version linux amd64

mkdir velero && cd velero
wget https://github.com/vmware-tanzu/velero/releases/download/v1.6.2/velero-v1.6.2-linux-amd64.tar.gz
tar -xzf velero-v1.6.2-linux-amd64.tar.gz

Créer un namespace et un service provider (différents de ceux par défaut)

Quelque soit le cloud provider, il faut modifier le fichier config/common/00-prereqs.yaml

Comme indiqué dans la documentation dédiée, ce fichier contient la plupart des informations génériques, notamment, les définitions (CRD pour les backups/restores Ark), le namespace, le service account et les rôles (RBAC).

Dans notre cas, on doit donc modifier le fichier config/common/00-prereqs.yaml pour qu’il créé un autre namespace, qu’on appellera « backup » pour faire original;
On va aussi modifier le nom du service account pour qu’il colle à celui du Service Principal azure (pas obligatoire, mais c’est pour rester cohérent) et surtout son namespace.

vi config/common/00-prereqs.yaml
[...]
---
apiVersion: v1
kind: Namespace
metadata:
name: backup
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: myarkserviceprincipal
namespace: backup
labels:
component: ark
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: ark
labels:
component: ark
subjects:
- kind: ServiceAccount
namespace: backup
name: myarkserviceprincipal
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io

Ensuite, il faut également modifier les spécifiques à notre cloud provider (ici Azure), en particulier le namespace, mais aussi nos informations de connexion à notre blob

Dans le déploiement, changer le namespace et le serviceAccountName

vi config/azure/00-ark-deployment.yaml
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
namespace: backup
name: ark
[...]
spec:
restartPolicy: Always
serviceAccountName: myarkserviceprincipal
[...]

vi config/azure/05-ark-backupstoragelocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: BackupStorageLocation
metadata:
name: default
namespace: backup
spec:
provider: azure
objectStorage:
bucket: arkblob
config:
resourceGroup: arkbackups
storageAccount: arkANDTHEUUID
vi config/azure/06-ark-volumesnapshotlocation.yaml
---
apiVersion: ark.heptio.com/v1
kind: VolumeSnapshotLocation
metadata:
name: azure-default
namespace: backup
spec:
provider: azure
config:
apiTimeout: 30s
resourceGroup: ark-EUW-sandbox-RG

Créer les objets sur le cluster Kubernetes sur Azure

kubectl --context=myawesomeakscluster apply -f config/common/00-prereqs.yaml
customresourcedefinition.apiextensions.k8s.io/backups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/schedules.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/restores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/downloadrequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/deletebackuprequests.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumebackups.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/podvolumerestores.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/resticrepositories.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/backupstoragelocations.ark.heptio.com created
customresourcedefinition.apiextensions.k8s.io/volumesnapshotlocations.ark.heptio.com created
namespace/backup created
serviceaccount/arkeuwsandboxsp created
clusterrolebinding.rbac.authorization.k8s.io/ark created
kubectl --context=myawesomeakscluster apply -f config/azure/
deployment.apps/ark created
backupstoragelocation.ark.heptio.com/default created
volumesnapshotlocation.ark.heptio.com/azure-default created
daemonset.apps/restic created

A noter : avant le premier appel de ark, sur chaque machine, il faudra spécifier dans quel namespace est ark sur notre cluster K8s.

./ark client config set namespace=backup

Créer le secret du service provider

#AZURE_RESOURCE_GROUP=MC_myownkubernetescluster_myawesomeakscluster_westeurope
AZURE_SUBSCRIPTION_ID=d717105a-ac1d-457c-8ef8-7467aa90df5c
AZURE_TENANT_ID=15eb2494-5298-4347-81a3-e2d3c08a0f82
AZURE_CLIENT_ID=f44ae340-97a2-4d54-bdc5-c4d7b2a49a2a
AZURE_CLIENT_SECRET=r+VGoBqOwraH9uVdk/sED3Ezdb7bIZI1xjvZyyvmnzM=
kubectl --context=myawesomeakscluster --namespace=backup create secret generic ark-azure-credentials \
--from-literal AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID} \
--from-literal AZURE_TENANT_ID=${AZURE_TENANT_ID} \
--from-literal AZURE_CLIENT_ID=${AZURE_CLIENT_ID} \
--from-literal AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET} \
--from-literal AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
secret/ark-azure-credentials created

Créer des données dans le cluster pour vérifier le fonctionnement

kubectl create ns testrestore
namespace/testrestore created
kubectl run pod ubuntu --image=ubuntu --namespace=testrestore
deployment.apps/pod created
kubectl --namespace=testrestore get all
NAME READY STATUS RESTARTS AGE
pod/pod-5945cc9b88-sq8c8 0/1 RunContainerError 1 14s
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/pod 1 1 1 0 14s
NAME DESIRED CURRENT READY AGE
replicaset.apps/pod-5945cc9b88 1 1 0 14s

Créer une backup

./ark backup create $(date +"%Y%m%d-%H%M")
Backup request "20190109-1553" submitted successfully.
Run `ark backup describe 20190109-1553` or `ark backup logs 20190109-1553` for more details.
./ark backup describe 09-01-2019
Name: 09-01-2019
Namespace: backup
Labels:
Annotations:
Phase: New
Namespaces:
Included: *
Excluded:
Resources:
Included: *
Excluded:
Cluster-scoped: auto
Label selector:
Storage Location:
Snapshot PVs: auto
TTL: 720h0m0s
Hooks:
Backup Format Version: 0
Started: <n/a>
Completed: <n/a>
Expiration: 0001-01-01 00:00:00 +0000 UTC
Validation errors:
Persistent Volumes:

Restaurer une backup

kubectl --namespace=testrestore delete ns testrestore
namespace "testrestore" deleted
./ark backup get
NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTOR
20190109-1553 Completed 2019-01-02 14:30:17 +0100 CET 23d default
./ark restore create restore-01 --from-backup 20190109-1553
Restore request "restore-01" submitted successfully.
Run `ark restore describe restore-01` or `ark restore logs restore-01` for more details.

CIVO : du kubernetes managé à partir de 4$/mois, vraiment ?

Fri, 16 Jul 2021 07:00:00 +0000

Pendant la Kubecon EU 2021, un provider que je ne connaissais pas a mis le paquet pour s’assurer de la visibilité : CIVO. Et avec une promesse plus qu’alléchante : un Kubernetes managé basé sur k3s (que j’adore) et avec un tarif à partir de 4$/mois !

Chez les concurrents, on a rien sous les 15€ / mois (Scaleway), quand ce n’est pas 30 voire 80… De quoi piquer ma curiosité donc.

Un de plus ?

J’ai donc pris un compte d’essai proposé par l’entreprise aux participants de la Kubecon et j’ai créé un compte.

La première chose que j’ai testé, c’est l’interface (il y a aussi une CLI). Forcément, chez un pure player, c’est simple et efficace, on s’y retrouve et l’interface est léchée. On est loin du gloubiboulga visuel de chez Azure (cf mon test d’AKS). Après, c’est un minimum… c’est forcément plus simple quand on commence de zéro et qu’on a pas des centaines de produits ;-p.

On a un dashboard avec les opérations réalisées chronologiquement, un menu pour créer des clusters kube, un menu pour créer du compute et des LB « nus ». Rien de bien révolutionnaire, ça fait le job.

La partie « KubeQuest », c’est de la bête gamification (« Créez un cluster pour passer niveau 2!!! »), je ne m’y attarderai même pas.

Bon, on le créé ce cluster à 4$ ?

Bon, ne vous enflammez pas, l’offre « à partir de 4$/mois » ne sera pas utilisable en prod, pas de miracle. Mais c’est déjà un tour de force qu’ils arrivent à le proposer, notamment grâce à k3s.

Pas de surprise, le pricing des nodes est immédiatement affiché, et voilà à quoi ça ressemble :

Pour 4$ par mois, on vous propose un « cluster » d’un seul node, avec seulement 1 vCPU et 1 Go de RAM. Pas de quoi faire tourner grand chose d’autre que quelques containers nginx… Si ça jamais ça fonctionne ?! (on y reviendra)

Au delà, les prix sont similaires à ce que l’on trouve sur le marché « bon marché » (Scaleway notamment). Si on veut être un peu sérieux et comparer ce qui est comparable, on peut booter des machines avec 2vCPU et 4 Go de RAM à16$/mois l’unité (moins de ~13,5€ en ce moment).

Kubernetes easy to install

La plupart des offres managées de Kubernetes (si ce n’est toutes) viennent avec une certaine quantité de personnalisation préinstallée. Chez Azure, vous pouvez choisir parti 2 CNIs et le dashboard (ou pas). Chez Scaleway si c’est Calico qui est préinstallé ou pas.

Chez CIVO, ils ont poussé le concept beaucoup plus loin, en reprenant l’idée de Rancher ou d’Openshift du « marketplace ».

Avant de boostraper votre cluster, vous avez accès à tout un magasin d’applications (ni plus ni moins que des charts helm avec une icône pour cliquer dessus) et éventuellement une très petite personnalisation avec un dropdown menu (mais vraiment trivial, très peu de choix).

Et là, pour le coup en terme d’UX je trouve ça très très malin. En quelques clics, j’ai (dé)sélectionné les composants qui m’intéressent et ils ont été préinstallés pour moi avec mon cluster.

On peut même préinstaller des produits de sécurité, notamment Kyverno avec un ensemble de règles de sécurité préconfigurées.

Et c’est pas fini !

Pour ce qui est des composants d’infrastructure, je comprend l’incentive. Pour certains devs, l’infra c’est ch***t.

Mon cluster je le veux up and running sans perte de temps, sans pour autant que mes données soient à poil sur Internet

Mais comme tout ce qui « cache » la complexité du métier d’Ops (cf mon article « Au secours, le métier d’Ops va disparaître »), la difficulté n’est pas tant le déploiement que le « day 2 operations ». Et si vous voulez modifier un paramètre, vous êtes marrons.

Tout de même, préconfigurer cette partie dès le bootstrap du cluster est malin. Et ce qui est encore plus malin, c’est qu’ils ont open sourcé leur marketplace.

Qu’est ce qu’ils y gagnent, me direz vous ?

Et bien, s’il y a un nouveau « shiny composant » qui fait rêver tout le monde, vous pouvez aller faire une PR pour ajouter une tuile dans l’UI de CIVO. Comme ça vous bossez pour eux. Elle est pas belle la vie ? ;-p (je troll, mais je trouve ça cool, en vrai).

Et le cluster, il boote vite ?

C’est un peu la guéguerre entre Kubernetes managés à qui bootstrappera le control plane et les workers le plus vite. Azure met plus de 20 minutes. OVH bootstrappe le control plane en une minute mais met des plombes à sortir les VMs à cause de leur OpenStack. Exoscale fait le tout (control plane + workers) en moins de 2 minutes.

CIVO nous promet 90 secondes et c’était pas loin d’être vrai. Je ne dirai pas que c’est les plus rapides mais ils sont dans le top 3 de tous les kubes managés que j’ai pu tester, sans hésiter.

Une fois le cluster opérationnel, on vous propose évidemment de télécharger votre kubeconfig et roule ma poule

Mais qu’est ce qu’on peut faire tourner dans Kube avec 1 (ou 4) Go de RAM ?

Le souci avec ce genre de « petites machines », c’est que si vous n’avez pas OS et kubernetes optimisés, une part non négligeable de la VM ne sera pas utilisable pour vos workloads et vous n’aurez que (dans le pire des cas) 2 Go de libre.

Et c’est là toute la « malinerie » d’utiliser k3s plutôt qu’un k8s vanilla. k3s est spécialement pensé pour tourner sur des petites machines (en edge notamment). J’avais pu installer un master kubernetes sur un raspberry pi 1 (model B, 1 CPU ridicule et 512 Mo de RAM) tellement l’empreinte mémoire demandée est faible.

Associé à un magasin d’applications maison pré-tuné pour consommer peu (très petites requests pour fit les petites machines sans tout bloquer), on arrive avec des nodes quasiment sans overhead. Dans cet exemple, j’ai cliqué sur plusieurs composants (cert-manager, kyverno, ha-proxy, prometheus+alertmanager+grafana, metrics-server, falco). Je me retrouve avec des nodes (4vCPU 8Go) quasiment vides !

kubectl --kubeconfig civo-zwindler-kubeconfig top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
k3s-zwindler-deadbeef-node-pool-31af 230m 5% 945Mi 12%
k3s-zwindler-deadbeef-node-pool-6609 97m 2% 471Mi 6%
k3s-zwindler-deadbeef-node-pool-e07c 141m 3% 874Mi 11%

Du coup, pour du lab perso ou des workloads qui nécessitent très peu de puissance, l’offre de CIVO est plutôt bien positionnée. Je ne suis pas complètement convaincu de l’intérêt de l’offre extra small à 4$ qui est plus là pour la prouesse technique qu’une réelle utilisation. Mais dès small ou medium, on a un service qui fonctionne, moins cher que de nombreux concurrents et surtout bien plus optimisé en terme de ratio overhead/puissance totale.

Au delà de kubernetes, l’offre est quasiment inexistante. Des VMs (plus chères que les workers kubes !!! wtf) et des loadbalancer à 10$/mois (Scaleway le fait à 8€, on est dans les prix « pas cher ») et c’est tout…

Autant dire que c’est kubernetes ou rien. Du coup, est ce qu’il y a un marché pour ce besoin, je ne suis pas certain… mais pourquoi pas ? En tout cas, bonne surprise !

J’ai testé pour vous : l’offre Kubernetes as a service d’OVH

Tue, 09 Jul 2019 11:30:50 +0000

OVH sort son offre Kubernetes managée

Vous avez peut être vu passer l’actualité début février, OVH a lancé (comme d’autres cloud providers) son offre Kubernetes as a service (KaaS).

Cette blague hilarante vous est offerte par zwindler !

Comme beaucoup de techno non triviales, une offre managée, c’est un bon moyen de mettre le pied à l’étrier si vous ne connaissez pas encore Kubernetes. C’est aussi un bon moyen pour OVH pour ne pas trop se laisser distancer par les géants américains.

En avril dernier, j’ai pu participer à un meetup dans les locaux d’OVH et de rencontrer les personnes qui avaient mis en place cette technologie. Du coup, je vous propose un petit article dans lequel on va voir ensemble à quoi ça ressemble.

Côté tarif

C’est le nerf de la guerre. Comme tous les autres (à l’exception notable d’EKS d’Amazon), vous ne payez que pour les workers, pas pour les masters (le control plane donc). Niveau tarif pour les workers, c’est simple, ce sont les tarifs applicables sur l’offre cloud public d’OVH.

La plus petite machine que vous pouvez sélectionner est un machine Linux de type B2-7, avec 2 vCPUs, 7 Go de RAM et 50 Go de SSD local.

C’est suffisant pour faire des tests, mais en production on en voudra au minimum 3, ce qui à 22€HT/mois pièce vous fera quand même environ 75€ / mois.

Au final, on est objectivement moins cher que ce que j’avais pu tester sur AKS. Car pour rappel, j’avais monté un cluster de machines de type B2ms avec 2 vCPU et 8 Go de RAM pour 30€ / mois, donc identique. SAUF que ces machines sont des machines dites “burstable” (vous n’avez qu’une portion d’un vCPU, que vous ne pouvez dépasser que pour une durée réduite avant de subir un throttling). Des machines équivalentes reviendraient sur Azure à utiliser des D2, pour un tarif de 83€TTC / mois… par machine !!!

Le fait que le control plane (les masters) ne soient pas payant est à la fois un avantage et un inconvénient. Pour OVH, je n’ai pas encore la réponse, mais lorsque j’avais testé AKS d’Azure, j’avais demandé au commercial ce qui se passait si mon control plane était HS (vu que c’est eux qui gèrent, je ne peux pas prendre la main pour le fixer). Il m’avait répondu texto : “comme c’est un produit gratuit, on ne s’engage sur aucune SLA (seulement un SLO de 2h)”. De quoi refroidir quand on est habitué à avoir la main sur son cluster Kubernetes.

Et si on testait ?

Assez parlé ! Dans mon manager d’OVH, j’ai créé un nouveau projet, que j’ai nommé de manière originale “Kubernetes Project”. Puis, j’ai créé un cluster Kubernetes en cliquant sur “Créer un cluster Kubernetes”

Actuellement, seul le DC “Graveline 5” semble capable d’accueillir l’offre KaaS d’OVH. Un point qu’il faudra améliorer dans le futur pour pouvoir se construire une infrastructure réellement résiliente.

Edit: Une deuxième région sera disponible dans le mois (cf Maxime Hurtrel, PM K8s chez OVH)

Niveau version de Kubernetes, bonne nouvelle, OVH s’est donné les moyens de proposer des versions très à jour de Kubernetes. Toutes les versions depuis la 1.11 jusqu’à la version 1.14 sont disponibles. La 1.14, qui n’a que quelques mois, est devenue dispo chez OVH assez rapidement. On peut imaginer que la 1.15 de Kubernetes qui vient tout juste de sortir (mi juin) sera probablement assez vite disponible aussi.

A titre de comparaison, chez Azure, ils sont assez bons dans ce domaine, et pourtant ils n’ont la 1.14 qu’en preview. Le mauvais élève Amazon est à la traîne avec seulement la 1.12 (pourtant sortie en septembre 2018).

“Ca va trop vite”

Cette partie là est relativement impressionnante. La création d’un nouveau cluster est extrêmement rapide.

Au total, l’instanciation d’un cluster met moins d’une minute, là où AKS en nécessite une 20aine (en comptant les workers certes, mais bon la moitié du temps le portal ou l’appel à l’API plante !).

Ceci est du à la façon dont le control plane a été créé et conçu par les équipes d’OVH (j’y reviendrais juste après) et est clairement une réussite. Pour avoir déployé à la main Kubernetes un paquet de fois et avec de nombreuses méthodes différentes (cf mes divers articles sur le sujet), c’est la méthode la plus rapide d’installer Kubernetes, et de loin.

L’architecture du control plane

Un des trucs sympas avec OVH, c’est qu’ils n’hésitent pas à communiquer sur les détails techniques. Certes, ils ne sont pas les seuls, mais c’est toujours agréables.

Lors du CNCF Meetup, Kevin Georges, Pierre Peronnet et Sébastien Jardin nous ont donc présenté les entrailles de leur Kubernetes as a service.

L’idée principale est que le control plane doit être le plus léger possible, pour coûter le moins cher possible à OVH (vu que c’est gratuit), tout en restant résilient.

La solution qui a été retenue pour arriver à une solution acceptable a été de déployer les services nécessaires au control plane de Kubernetes (control malanger, api server, scheduler) dans … un Kubernetes ! La seule brique non containerisée est etcd, et il s’agit ici d’un cluster dédié sur des machines physiques (ce qui explique probablement la limitation au DC Graveline).

Dans tous les cas, ça explique probablement aussi la vitesse de démarrage d’un nouveau cluster : il faut juste lancer 3 containers et zou, un nouveau cluster.

Source : OVH https://www.ovh.com/fr/blog/kubinception-using-kubernetes-to-run-kubernetes/

L’article technique détaillant tout ça est dispo sur le site d’OVH, je n’en dis pas plus, ils l’expliquent mieux que moi.

Les workers

Pour la partie Workers, plutôt que de développer sa propre API et l’intégrer comme module du projet Kubernetes (comme les autres gros cloud providers, qui ont leur code embarqué dans celui de Kubernetes), la team chez OVH en charge du projet s’est appuyée sur de l’existant : leurs propres services OpenStack fournissent déjà l’ensemble des briques dont ils ont besoin pour créer des VMs à la volées et les intégrer à des clusters Kubernetes.

Quand j’ai demandé au Meetup combien de temps il fallait pour “poper” un nouveau worker, un des trois speakers m’a dit, tout désolé “on ne fait pas de miracles, il faut quelques minutes”. Il n’a pas compris le pauvre quand j’ai éclaté de rire (parce que sur Azure, ça prend des plombes).

Ajouter des workers

La procédure est assez simple, mais se fait au travers de l’interface (comme la création du cluster). Je suis quasiment certain que tout doit pouvoir se piloter par API (je vois mal pourquoi ils auraient fait autrement pour un service tout neuf), pour autant, je n’en ai pas trouvé de trace dans la documentation officielle (pas à jour avec la nouvelle interface et encore un peu light)

Bon, alors je suis peut être mal tombé, mais quand j’ai cliqué dans l’interface pour ajouter des nodes, ça a quand même pris énormément de temps (facile 20-30 minutes). Du coup j’étais un peu (très) déçu…

Après investigation, en fait… c’est l’interface qui déconne ! En réalité, mon nœud était UP depuis longtemps déjà.

Je m’en suis rendu compte en faisant un petit kubectl get nodes et j’ai vu que mon node “Ready” depuis 28 minutes était encore marqué “En cours d’installation” …

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
vm1.12-1 Ready <none> 28m v1.12.7 51.77.204.236 <none> Container Linux by CoreOS 2135.4.0 (Rhyolite) 4.19.50-coreos-r1 docker://18.6.3

Se connecter au cluster

D’ailleurs, comment on s’y connecte ? Pas de souci de ce côté, OVH vous simplifie la vie en vous proposant de télécharger directement votre fichier kubeconfig préconfiguré, prêt à utiliser.

Si vous en avez plusieurs, pour rappel, vous pouvez utiliser le flag “–kubeconfig=kubeconfig.yml”

En vrai, un node ne met que 3 minutes à poper

Du coup, j’ai voulu retester le démarrage d’une nouvelle VM, en sachant que le temps indiqué sur l’interface web n’est pas bon.

Après quelques tests, en 3 minutes, le node apparait en “Not Ready”, puis passe “Ready” au bout de quelques secondes. On est donc très proche de ce dont j’avais pu parler avec les gens d’OVH du coup, c’est très bon comme temps de boot.

Ouf, on est rassurés !

Mise à jour

Un point sympa que permettent les solutions de type KaaS est la gestion des mises à jour depuis votre interface de gestion. Mettre à jour Kubernetes, c’est pénible. La moitié du temps, on a peur de tout casser.

Alors je ne dis pas que rien ne va casser avec le Kubernetes d’OVH, mais comme l’infra est cadrée et gérée par eux, j’imagine que c’est suffisamment bien testé dans des conditions similaires aux vôtres pour être un peu plus serein le jour où ça arrive.

A noter, contrairement à AKS, vous n’avez que peu la main sur les mises à jour. Cela se limite à ça, et je n’ai pas trouver comment monter de la 1.12 à la 1.13 par exemple…

Edit: Toujours selon Maxime Hurtrel, ça devrait arriver bientôt

Conclusion : au delà du compute, l’UI

Dans les points qui déchirent : OVH sait fournir un control plane à une vitesse à faire pâlir d’envie tous les concurrents.

Cependant, cela se fait sur un cluster Kubernetes mono DC (DC5 Graveline), avec la partie etcd externalisée à part, sur un cluster mutualisé. Je ne fais pas de jugement de valeur car, contrairement à OVH qui est transparent, je n’ai pas d’info technique sur les versions proposées par la concurrence.

En revanche, je peux comparer avec un cluster que j’installe moi même, et là clairement, je suis un cran en dessous en terme de ce qui peut être fait en terme de sécurisation de mon cluster.

Pour ce qui est de l’interface, elle souffre un peu de sa jeunesse. Il n’y a rien de plus que les onglets pour créer un cluster et pour ajouter ou supprimer des nœuds (et encore, pas plus d’info sur ces nœuds que leur nom et leur taille !).

Un dernier onglet existe pour “visualiser” ses containers et ses services, mais il est pour l’instant vide et sera de toute façon probablement moins utile que le dashboard ou tout autre outil existant (sauf à fournir un énorme effort de dev sur ce point).

Encore un exemple de la jeunesse de la solution et particulièrement de son interface : OVH pope des VMs (workers) très vite, ce qui devrait être super cool et soulever les foules… mais si on teste la solution rapidement, comme l’interface ne l’indique pas, on pourrait penser que ce n’est pas le cas ! Dommage !

Edit: Le problème est connu et en cours de fix

[Le tweet n’est plus disponible]

Et pour ce qui est des mises à jour, c’est le flou total. On vous explique que tout est maintenu à jour, mais les montées de versions majeurs sur un cluster ne semble pas disponible pour l’instant.

Dans les points pas glop : aucune trace dans la doc d’API pour créer des clusters à la volée ou les gérer de manière automatisée via Ansible ou autre…

Edit: l’API est là

[Le tweet n’est plus disponible]

Bref, vous l’aurez compris, techniquement c’est une réussite. Chez OVH, ils savent gérer des VMs et des containers et ça se voit. Mais l’offre KaaS d’OVH manque peut être encore d’un petit coup de polish pour qu’on se sente bien chez soi, et pleinement en confiance. Et c’est d’autant plus rageant que la solution a plein de bons points, que le travail abattu (en peu de temps) est colossal.

Je voudrais donc tenter de terminer sur une note positive, car c’est mon ressenti au global. Pour avoir rencontré des membres de l’équipes (de vrais passionnés), j’ai envie de croire que ce produit est amené à grandir, et ses petits défauts de jeunesse à disparaître.

A suivre donc !

Bonus GPU

Dans les petits “trucs” qui m’ont fait sourire, j’ai vu passer un tweet indiquant qu’OVH se lançait également (en alpha par contre pour l’instant) dans Kubernetes managé avec des instances baremetal avec GPU.

Je n’ai pas forcément de workload en tête, mais pour ceux qui veulent lancer des containers avec des calculs GPU, c’est une option qui peut faire sens.

Si vous voulez en savoir plus, c’est par ici :

Labs OVH GPU baremetal k8s nodes

Déléguer l’authentification Gitlab à Azure AD avec OAuth2

Tue, 14 May 2019 11:45:56 +0000

Gérer les comptes internes à Gitlab, c’est bof, le SSO, c’est mieux !

Dans le cadre de l’hébergement d’un nouveau serveur Gitlab, j’ai voulu intégrer notre base de compte existante, synchronisée dans Azure à l’aide de l’outil Azure AD, qui est le pendant « cloud » de l’Active Directory, bien connus de mes amis Windowiens (oui, il y en a). La plupart des applications savent aujourd’hui déléguer l’authentification à des fournisseurs tiers, généralement de type LDAP, via des protocoles tels que SAML(2) ou OAuth(2).

Cependant, bien que ces protocoles soient standards, leur implémentation dépend fortement du logiciel en question et il n’est pas toujours facile de s’y retrouver.

Pour faciliter cette opération, Azure a mis à disposition, directement dans Azure AD, des objets préconfigurés pour des milliers d’applications tierces. C’est comme ça qu’on peut implémenter, de manière simple et rapide, le SSO Active Directory avec les produits Atlassian (JIRA + Confluence), par exemple.

Tout commence dans Azure

Dans le portail Azure, ouvrir « Entreprise applications », puis cliquer sur « New Application »

Malheureusement pour nous, il n’y a pas de template pour Gitlab ! Il va falloir le faire à la main.

A noter, le principe déroulé dans ce tutoriel est valable pour n’importe quelle autre application supportant des mécanismes similaire. Il est possible de réutiliser un template utilisé pour un soft et le réadapter pour d’autres logiciels qui fonctionnent de la même façon. C’est juste une histoire de paramètres.

Le menu nous conseille donc de choisir « Non-gallery application », puisque nous ne trouvons pas Gitlab. Sauf que, bizarrement, il faut un compte Premium pour utiliser cette feature.

On se rabat donc sur « Application you’re developing ». C’est d’ailleurs ce que conseille d’utiliser la documentation de Gitlab. Sauf que, pas de chance non plus, ça ne marche plus comme ça, maintenant ;)

Créer une App registration pour Gitlab

Pour toutes les applications qui ne sont pas dans le store, on ne peut donc plus passer par les « Entreprise Applications ». On va donc créer une « App registration », qui n’est ni plus ni moins qu’un compte de service avec un ID et un (ou plusieurs) secrets.

Cliquer sur « New registration », puis lui donner un nom.

Sélectionner le type de comptes qui pourront accéder à cette application. Dans mon cas, il s’agit uniquement d’autoriser les comptes provenant de mon AD, mais on peut imaginer le cas d’une application ouverte en BtoB ou carrément ouverte à tout Internet.

Enfin, renseigner l’URL de callback, qui permettra à Azure de rediriger l’utilisateur qui s’est authentifié avec succès vers notre Gitlab.

We’ll return the authentication response to this URI after successfully authenticating the user. Providing this now is optional and it can be changed later, but a value is required for most authentication scenarios.

Dans le cas précis de Gitlab, cette URL aura la forme : mongitlab.example.org/users/auth/azure_oauth2/callback

Récupérer des valeurs qui intéressent Gitlab

Retourner ensuite dans l’overview de notre nouvelle « App registration ». Dans les détails, elle dispose d’un Application ID, aussi appelé Client ID et d’un Tenant ID :

On va maintenant créer un Secret. Pour les secrets, on peut choisir soit d’uploader un certificat (conseillé car plus sécurisé), ou de lui générer un mot de passe. Pour la simplicité de ce tutoriel, je vais créer un mot de passe pour notre application, mais je le répète, mieux vaut uploader un certificat.

On dispose maintenant de notre CLIENT_ID, notre TENANT_ID et de notre CLIENT_SECRET. Notez les bien, car une fois que la fenêtre sera fermée, il ne sera plus possible de relire à nouveau le secret et il faudra en générer un nouveau…

Ajouter des restrictions ou des fonctionnalités complémentaires

En fonction de votre niveau de licence pour Azure AD, vous aurez accès à plus ou moins de choses. Moi, je n’ai accès à pratiquement aucune feature, mais si vous avez mieux, vous aller pouvoir ajouter des options très pratiques telles que le self service (les utilisateurs peuvent demander eux même à avoir accès à l’application, et si c’est validé, ils sont ajouté dans le bon groupe) et aux autorisations/restrictions par groupes Azure AD.

Pour se faire, il faut RETOURNER dans les Entreprises Applications (#RollingEyes), puis chercher notre « App registration » qui y apparaît maintenant dans la liste (avec le filtre All applications).

Configuration de Gitlab

Gitlab ayant été installé avec les packages, la configuration se situe dans le fichier /etc/gitlab/gitlab.rb.

Dans le fichier de configuration, ajouter le bloc suivant en remplaçant les valeurs en majuscules par celles qu’on vient de récupérer :

gitlab_rails['omniauth_providers'] = [
{
"name" => "azure_oauth2",
"args" => {
"client_id" => "CLIENT_ID",
"client_secret" => "CLIENT_SECRET",
"tenant_id" => "TENANT_ID",
}
}
]

Rechargez ensuite Gitlab pour prise en compte de ce nouveau paramètre

sudo gitlab-ctl reconfigure
[...]
Running handlers complete
Chef Client finished, 13/637 resources updated in 26 seconds
gitlab Reconfigured!

Une boite d’authentification Azure Oauth2 devrait apparaître sous le login classique !! Youpi :)

Et voilà c’est fini… ou presque…

Vous avez maintenant ajouté du SSO et l’authentification via Azure AD pour l’accès à votre Gitlab ! On essaye de se connecter ?

Et Paf !!

Signing in using your Azure Oaut2 account without a pre-existing gitLab account is not allowed

En fait, c’est normal.

Par défaut, il n’est pas possible de s’authentifier avec Azure Oauth2 si un compte n’existe pas préalablement dans Gitlab, ce qui est quand même bien dommage si vous avez beaucoup de comptes à créer.

Deux cas de figure.

Soit vous ne souhaitez pas que n’importe qui dans votre AD puisse se connecter sans votre accord préalable

Dans ce cas là, ce cas vous est finalement assez favorable, puisque vous allez pouvoir explicitement dire qui peut ou ne peut pas se connecter. Si vous ne disposez pas des bonnes licences et que vous avez pas pu restreindre l’accès à un groupe d’utilisateurs, c’est une « solution » de contournement acceptable.

Cependant, pour éviter de créer à la main tous les comptes, il sera probablement préférable de les créer de manière automatique à l’aide de l’API Gitlab et même du très bon module Ansible gitlab_user :

- name: "Create Gitlab User"
gitlab_user:
server_url: "{{gitlab_api}}"
login_token: "{{token}}"
validate_certs: True
name: "Zwindler"
username: "zwindler"
password: "{{ 99999999 | random | to_uuid }}"
confirm: no
email: "zwindler@zwindler.fr"
state: present

Soit, à l’inverse, vous souhaitez que tous les utilisateurs de votre AD puissent avoir accès, sans pour autant devoir les ajouter uns par uns

Il existe alors des lignes sont à ajouter dans la configuration gitlab pour autoriser cette option :

gitlab_rails['omniauth_allow_single_sign_on'] = ['azure_oauth2']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['sync_profile_from_provider'] = ['azure_oauth2']
gitlab_rails['sync_profile_attributes'] = ['name', 'email']

D’un point de vue sécurité, c’est un peu moins bien puisque n’importe qui avec un compte pourra se connecter, sans que vous le sachiez.

Cependant, ce problème est un peu moins grave qu’il n’y parait puisque l’utilisateur sera logué mais n’aura accès à rien (ou juste ce qui est « public »).

Dans le cas d’un Gitlab d’entreprise, où tous les développeurs doivent pouvoir se connecter, cette seconde option me parait quasi obligatoire. C’est encore plus acceptable si vous avez pu restreindre l’accès au SSO par groupe dans Azure AD, comme indiqué plus haut.

Have fun :)

Sources

J’ai testé pour vous AKS, la plateforme Kubernetes managée d’Azure

Tue, 18 Dec 2018 12:45:33 +0000

AKS = Azure Kubernetes Service

Après EKS (Amazon) et GKE (Google) (et plein d’autres en fait), Azure a fini par lancer aussi son service managé de Kubernetes (preview en octobre 2017).

Ce service ne doit pas être confondu avec ACI (Azure Container Instances) qui est le service d’Azure CaaS, où vous pouvez instancier les containers à la demande sur les Kubernetes d’Azure, où Kubernetes vous est complètement caché.

Vous verrez aussi peut être dans la littérature des références à ACS (l’ancien nom d’AKS) ou alors de ACS-engine, qui est le projet utilisé par Azure pour déployer des clusters Kubernetes (sur du IaaS) pour leur besoins propres et qu’ils ont open sourcé.

Il s’agit donc bien d’un service fourni par Azure, qui masque toute la complexité du déploiement des machines et des composants de Kubernetes. Vous n’aurez pas accès aux VMs, on n’est donc pas sur du IaaS. Mais contrairement à ACI, vous aurez les pleins pouvoir sur le control plane de Kubernetes, et vous pourrez l’administrer comme bon vous semble.

C’est vraiment facile à installer ?

Oui, c’est vraiment simple. L’installation peut se faire depuis le portail ou en quelques commandes « az cli »

Pour tout vous dire, Microsoft a même pousser le vice jusqu’à faciliter l’installation du binaire kubectl, ainsi que la configuration de votre cluster dans les contextes (via des commandes « az cli »). Dans l’absolu, les commandes qu’on va faire ci dessous sont équivalentes à celles que j’ai décrites dans l’article Installer kubectl et Configurer kubectl.

Nice to have

C’est parti !!

Depuis le portail, cherchez « Kubernetes services », puis cliquez sur « Add ».

Et si vous préférez comme moi le faire en lignes de commande, ça donne quelque chose comme ça :

az group create --name myownkubernetescluster --location westeurope --subscription "mysubscription"
az aks create --resource-group myownkubernetescluster --name myawesomeclsuter --node-count 3 --enable-addons monitoring --node-vm-size Standard_B2s --kubernetes-version 1.10.9 --ssh-key-value ~/.ssh/mypublicsshkey.pub --subscription "mysubscription"

Si vous l’avez fait depuis le portail, vous verrez également une popup sur la droite pour vous aider à configurer kubectl (mais vous pouvez aussi les utiliser si vous avez monté le cluster avec les commandes précédentes aussi).

Les commandes à lancer après avoir déployé le cluster sont les suivantes :

az aks install-cli
Downloading client to /usr/local/bin/kubectl from https://storage.googleapis.com/kubernetes-release/release/v1.12.0/bin/linux/amd64/kubectl
Please ensure that /usr/local/bin is in your search PATH, so the `kubectl` command can be found.

Si vous essayez de les lancer sans avoir fait votre az login, vous aurez l’erreur suivante

az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
Resource group 'test_AKS' could not be found.

On se logue, donc

az login
Note, we have launched a browser for you to login. For old experience with device code, use "az login --use-device-code"

Comme l’indique la commande, az cli à récemment changé de méthode d’authentification par défaut.

Si vous lancez ces commandes et que vous n’avez pas d’environnement graphique (dans une petite VM par exemple), vous pouvez toujours utiliser l’ancienne méthode avec un code à recopier dans une page web avec la commande suivante :

az login --use-device-code
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code TOTOTOTOTO to authenticate.

Dans mon cas, j’ai accès à un abonnement Visual Studio en plus de mes souscriptions habituelles.

Par défaut, cette souscription est filtrée, donc az cli continuera à ne pas « voir » le ressource group que j’aurai créé pour l’occasion. L’idéal est de l’indiquer explicitement en ajoutant un « –subscription ». Une autre solution, plus simple, pour éviter le problème est de positionner cette souscription comme « par défaut »

az account set --subscription "Visual Studio"

Maintenant ça devrait marcher. On récupère les crédentials et les informations du contexte.

Par défaut, az cli va merger ces informations avec votre .kube/config existant s’il existe. Si vous avez peur qu’il fasse des bêtises, pensez à le sauvegarder avant.

az aks get-credentials --resource-group myownkubernetescluster --name myawesomeclsuter
/root/.kube/config has permissions "644".
It should be readable and writable only by its owner.
Merged "testaksdge" as current context in /root/.kube/config

Maintenant que l’outil az cli a configuré notre contexte pour nous, on peut interagir avec le cluster normalement :

kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-nodepool1-36034183-0 Ready agent 26m v1.10.9
aks-nodepool1-36034183-1 Ready agent 26m v1.10.9
aks-nodepool1-36034183-2 Ready agent 26m v1.10.9

Lancer le « proxy » (pour afficher le dashboard et accéder à l’API)

az aks browse --resource-group myownkubernetescluster --name myawesomeclsuter
[...]
Proxy running on http://127.0.0.1:8001/
Press CTRL+C to close the tunnel...
[...]

Etape supplémentaire si vous avez activé le RBAC

Si vous avez activé le RBAC, ce que je vous conseille fortement et qui devrait être le choix par défaut, votre dashboard n’aura pratiquement accès à rien !

Il faut lui ajouter des droits sur le cluster. La procédure complète d’Azure vous indique la marche à suivre ici. Ce que eux conseillent, qui est effectivement le plus simple (mais pas le plus sage), est de donner les droits cluster-admin au service account kubernetes-dashboard…

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Mais attention aux conséquences ! De très nombreuses personnes laissent le dashboard ouvert sur Internet et si EN PLUS votre dashboard est admin du cluster, vous allez rapidement miner des cryptocurrencies et lancer des mails de SPAM à votre insu…

N’autorisez donc pas le portail depuis l’extérieur.

Et après ?

Dans le cycle de vie d’un cluster Kubernetes, deux tâches vont très vite vous intéresser. Sauvegarder vos objets (ce qu’on peut faire avec Ark de Heptio) et mettre à jour votre cluster (ce qu’on peut faire avec AKS).

Ces deux points seront le focus d’articles futurs ;-)

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 !!

Votre première VM dans Azure… déployée avec Ansible bien sûr !

Tue, 07 Aug 2018 11:45:22 +0000

Mais tu n’as pas déjà fais un article sur Ansible et des VMs ?

Si vous me suivez depuis quelques temps, vous savez que j’apprécie particulièrement Ansible. J’ai déjà écris plusieurs articles sur le sujet, ainsi que de nombreux playbooks que j’ai mis à votre disposition sur mon compte github.

Un des articles qui intéresse le plus les lecteurs du blogs est un article en deux parties (part1 part2) qui détaille comment déployer des machines virtuelles sur une architecture VMware vSphere avec Ansible. J’en ai d’ailleurs fait une version en anglais également qui attire pas mal de monde aussi ;-).

Du coup, maintenant que je me suis attaqué aux principaux clouds providers (AWS, GCP et Azure), il était grand temps de faire un article sur cette partie également !

Comme d’autres outils d’automatisation, Ansible fait la part belle aux intégrations cloud. Je vous laisse jeter un oeil à la liste des modules Ansible disponibles pour le cloud :

docs.ansible.com/ansible/2.9/modules/list_of_cloud_modules.html

Et c’est particulièrement vrai pour Azure, dont l’équipe dédiée chez Microsoft est assez réactive et ajoute des features de manière très régulière (on aura l’occasion d’y revenir dans un prochain article, #teasing).

Les prérequis

Finalement, déployer un VM dans Azure, c’est presque pareil que comme déployer une VM dans VMware. On a des prérequis, une liste de paramètres à renseigner et pouf, on va poper une VM.

Bon, en vrai, ce n’est pas aussi trivial : si pour VMware, on se contentait d’une API python relativement simple à installer avec pip et d’un mot de passe, sur Azure, il va falloir trimer un poil plus.

Deux ressources nous donnent la marche à suivre pour configurer notre poste :

Installer

Sur une machine mint/debian/ubuntu, récupérer les modules python nécessaires :

apt install python-pip ansible
pip install setuptools wheel
pip install ansible[azure]

Configurer

Pour déployer des VMs sur Azure, il faut… un compte sur Azure !

Thanks, captain obvious.

Bon, si jamais vous voulez essayer, sachez que vous pouvez vous créer un compte gratuit avec 200$ de crédit offert, mais seulement valable 30 jours. C’est hyper radin de leur part, là où un GCP offre 300$ pendant 1 an, ce qui offre largement plus de temps pour tester.

Pour ouvrir le compte, il faut simplement aller à cette URL et renseigner une carte bancaire. Oui je sais, j’ai flippé moi aussi.

Normalement, ils ne vous prélèveront pas sans vous prévenir, c’est simplement pour éviter les bots. Personnellement je n’ai pas eu de problèmes mais je ne peux rien garantir (même si je pense que ça se saurait s’il y avait eu des soucis de ce côté là).

Une fois le compte créé, on va générer les fichiers de configuration pour Azure. Le plus simple pour le faire, c’est d’utiliser la commande « az login » (mais du coup il faut installer az cli en plus).

az login
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code CCHMTROLL to authenticate.

Vous devriez avoir un dossier .azure dans votre homedir

ll .azure
total 8
drwxrwxrwx 1 zwindler zwindler 512 Aug 4 17:00 ./
drwxr-xr-x 1 zwindler zwindler 512 Aug 4 16:56 ../
-rw------- 1 zwindler zwindler 7124 Aug 4 17:00 accessTokens.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.json
-rw-rw-rw- 1 zwindler zwindler 5 Aug 4 16:56 az.sess
-rw-rw-rw- 1 zwindler zwindler 333 Aug 4 17:00 azureProfile.json
-rw-rw-rw- 1 zwindler zwindler 66 Aug 4 17:00 clouds.config
-rw------- 1 zwindler zwindler 27 Aug 4 16:56 config

Et donc, on la déploie sur Azure, cette VM ?

Maintenant que notre poste est configuré, ça redeviens simple. Ouf !

Le module à invoquer dans notre playbook est azure_rm_virtualmachine, dont la documentation est disponible à l’adresse suivante :

https://docs.ansible.com/ansible/latest/modules/azure_rm_virtualmachine_module.html#azure-rm-virtualmachine-module

Voici un des exemples donnés dans la documentation du module :

- name: Create a VM with managed disk
azure_rm_virtualmachine:
resource_group: Testing
name: testvm001
vm_size: Standard_D4
managed_disk_type: Standard_LRS
admin_username: adminUser
ssh_public_keys:
- path: /home/adminUser/.ssh/authorized_keys
key_data: < insert your ssh public key here... >
image:
offer: CoreOS
publisher: CoreOS
sku: Stable
version: latest

La plupart des options que je vous met plus haut sont obligatoires. Il y en a beaucoup d’autre, mais celles ci sont un minimum. Pour expliquer un peu de quoi il s’agit, voici une petite traduction :

resource_group
Sur Azure, il existe plusieurs entités logiques permettant de segmenter les ressources entre elles. La souscription (plus haut niveau de segmentation, utile au niveau billing) et les resources groups. On peut donc avoir plusieurs resource groups dans une souscription.

name
Le nom de la ressource, telle qu’elle apparaîtra dans votre portail Azure. Pas plus important que ça.

vm_size
Là on rentre dans le vif du sujet ; il s’agit de la taille de la VM (en terme de nombre de CPU et de Go de RAM) que va avoir votre VM. Un guide des tailles (sans le billing) est disponible à l’adresse suivante

managed_disk_type

Pour faire simple, est ce que votre disque sera sur des baies SSD ou sur des baies mixant SSD et HDD classiques. On a assez peu d’information sur la façon dont sont stockées les données, au delà d’un nombre d’IOPS qui sera d’autant plus important que vous aurez réservé d’espace disque. Par exemple, un disque Premium de 128 Go, on aura droit à 500 IOPS et 100Mo/s max. Si vous passez au delà (de 129 à 256), vous aurez droit à 1100 IOPS et 125 Mo/s.

Quelques infos quand même :

Je vois vos petits yeux pétiller de malice.

Vous vous dites « ahah, je vais les feinter, me payer un disque de 129 Go pour avoir les perfs d’un disque de 256 pour à peine plus qu’un disque de 128 Go ».

Et bien non, ils ne sont pas fous, vous payerez pour un disque de 256 même si vous ne demandez que 129 (et même si vous n’utilisez 1 Go dedans).

admin_username & ssh_public_keys

Je ne vais pas vous faire l’affront de détailler ça. Il faut rentrer un utilisateur, un path pour la clé SSH et le contenu de votre clé publique.

image

Sur azure, vous avez accès à un magasin pré configuré d’images de VMs.

Si on veut un Ubuntu 16.04, on mettra :

image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest

Pour un CentOS 7.4 :

image:
offer: CentOS
publisher: OpenLogic
sku: '7.4'
version: latest

Toujours plus

Alors OK, avoir un bout de doc qui explique comment déployer une VM sur Azure, c’est chouette. Mais est ce qu’on pourrait pas faire mieux ?

Et oui, bien sûr ! Car en fait, dans Azure, on ne va pas simplement pouvoir déployer notre VM comme ça et espérer que ça marche.

Je l’ai déjà dis, il existe des ressources groups, dans lequel toutes vos ressources doivent être. On va devoir le créer. Mais il va aussi nous falloir une carte réseau, qui aura une adresse IP qui elle même proviendra d’un réseau virtuel, qui auront leur propres règles de sécurité (genre de firewalling basique). Et bien sûr, tout ça, c’est des objets à créer (à la main :-( … ou pas) !

Mais comme je suis sympa, je vais vous donner un playbook clé en main qui fait tout ça pour vous ;)

---
- name: "Create Azure resources"
connection: local
hosts: all
vars_prompt:
- name: "location"
prompt: "Choose region to deploy VMs"
private: no
default: "westeurope"
- name: "project_prefix"
prompt: "Choose a prefix for all the resources"
private: no
default: "test"
- name: "instances_number"
prompt: "Choose a number of virtual machines to create"
private: no
default: 1
- name: "vm_size"
prompt: "Choose a size for azure virtual machines"
private: no
default: "Standard_B2s"
- name: "managed_disk_type"
prompt: "Choose a type for azure virtual disks"
private: no
default: "Standard_LRS"
- name: "admin_username"
prompt: "Choose an admin username"
private: no
default: "zwindler"
- name: "admin_pub_path"
prompt: "Where can I find the admin public key ?"
private: no
default: "~/.ssh/id_rsa.pub"
- name: "local_ip"
prompt: "your local IP address (skip if you don't want to add 22 port to NSG)"
private: no
default: "skip"
- name: "virtualnetwork_cidr"
prompt: "Give a network CIDR for virtual network (large)"
private: no
default: "172.16.0.0/18"
- name: "subnet_cidr"
prompt: "Give a subnet of that network"
private: no
default: "172.16.1.0/24"
vars:
- resourcegroup_name: "{{project_prefix}}-rg"
- availabilityset_name: "{{project_prefix}}-avset"
- virtualnetwork_name: "{{project_prefix}}-vnet"
- subnet_name: "{{project_prefix}}-subnet"
- securitygroup_name: "{{project_prefix}}-nsg"
- vm_root_name: "{{project_prefix}}-vm"
- public_ip_name: "{{project_prefix}}-ip"
- nic_root_name: "{{project_prefix}}-nic"
tasks:
- name: "Create {{project_prefix}}-rg Resource Group"
azure_rm_resourcegroup:
name: "{{resourcegroup_name}}"
location: "{{location}}"
- name: "Create {{availabilityset_name}} Availability Set"
azure_rm_availabilityset:
name: "{{availabilityset_name}}"
location: "{{location}}"
resource_group: "{{resourcegroup_name}}"
sku: Aligned
- name: "Create {{virtualnetwork_name}} Virtual Network"
azure_rm_virtualnetwork:
name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefixes_cidr:
- "{{virtualnetwork_cidr}}"
- name: "create {{subnet_name}} Subnet in {{virtualnetwork_name}} for VMs"
azure_rm_subnet:
name: "{{subnet_name}}"
virtual_network_name: "{{virtualnetwork_name}}"
resource_group: "{{resourcegroup_name}}"
address_prefix_cidr: "{{subnet_cidr}}"
register: subnet
- name: "Create {{securitygroup_name}} security rules (if local IP address was given)"
azure_rm_securitygroup:
name: "{{securitygroup_name}}"
resource_group: "{{resourcegroup_name}}"
purge_rules: yes
rules:
- name: 'AllowSSHFromYourOwnInternetIP'
protocol: 'Tcp'
source_address_prefix: "{{local_ip}}"
destination_port_range: 22
access: Allow
priority: 1000
direction: Inbound
when: local_ip | ipaddr
- name: "Create a {{nic_root_name}}X network interface for each VM"
azure_rm_networkinterface:
name: "{{nic_root_name}}{{item}}"
resource_group: "{{resourcegroup_name}}"
virtual_network: "{{virtualnetwork_name}}"
subnet_name: "{{subnet_name}}"
security_group: "{{securitygroup_name}}"
ip_configurations:
- name: "ipconfig"
public_ip_address_name: "{{public_ip_name}}"
primary: True
with_sequence: count="{{instances_number}}"
- name: "Create {{vm_root_name}}X VM with existing NIC"
azure_rm_virtualmachine:
resource_group: "{{resourcegroup_name}}"
name: "{{vm_root_name}}{{item}}"
vm_size: "{{vm_size}}"
managed_disk_type: "{{managed_disk_type}}"
admin_username: "{{admin_username}}"
availability_set: "{{availabilityset_name}}"
ssh_password_enabled: false
ssh_public_keys:
- path: "/home/{{admin_username}}/.ssh/authorized_keys"
key_data: "{{lookup('file', '{{admin_pub_path}}') }}"
network_interface_names: "{{nic_root_name}}{{item}}"
image:
offer: UbuntuServer
publisher: Canonical
sku: '16.04.0-LTS'
version: latest
with_sequence: count="{{instances_number}}"

Pour ceux qui veulent d’économiser un copier coller, j’ai mis à disposition ce playbook à l’adresse suivante :

github.com/zwindler/ansible-deploy-azure

Et il ne reste plus qu’à l’exécuter :

pip install --user netaddr
echo localhost > hosts
ansible-playbook -i hosts azure-deploy.yml
[...]
TASK [Create test-vmX VM with existing NIC] *****************************************
changed: [localhost] => (item=1)
PLAY RECAP **************************************************************************
localhost : ok=1 changed=7 unreachable=0 failed=0

Le mot de la fin

Bon, on en est où maintenant ?

Et bien maintenant, vous avez un playbook qui vous permet de déployer des VMs à tour de bras dans Azure certes, mais aussi de les préconfigurer avec votre clé SSH et votre utilisateur administrateur, et seul votre IP (ou celle que vous aurez donné ou un subnet) pourra y accéder en SSH.
Vous avez toutes vos VMs dans un même sous réseau, lui même dans un réseau virtuel.
Vous avez également un AVSET qui vous permet de ne pas avoir toutes vos VMs sur les mêmes hyperviseurs et augmenter la disponibilité de votre application.
Et tout ça, sans rien avoir eu à faire à la main.

Badass non ?

Et encore! J’en ai gardé un peu sous le coude, pour d’autres articles ;-)

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…