VMware on Zwindler's Reflection

Déployer un hyperviseur VMware ESXi avec MAAS

Mon, 08 Jan 2024 18:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical
Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical
Déployer un hyperviseur VMware ESXi avec MAAS

Résumé des épisodes précédents

Dans les deux derniers épisodes, on a vu comment déployer MAAS sur un lab perso, comment déployer ensuite nos premiers OS sur des machines baremetal de manière automatisée, comment les customiser en changeant de version d’Ubuntu ou avec cloud-init.

Mais dans les promesses de MAAS, il y a plus que ça. En théorie, on doit pouvoir démarrer “out of the box” (ouais pas tout à fait, mais je ne spoil pas plus) des serveurs d’autres OS, comme Windows (beurk) ou des hyperviseurs VMware ESXi. Et même plus (mais ça n’est pas le but de cet article pour l’instant).

ESXi ?

Vous l’avez compris, point de Windows Server dans ce tutoriel, cependant sachez qu’avec les deux liens que j’ai déjà donnés dans l’article précédent, vous devriez pouvoir vous en sortir :

Même si c’est un hyperviseur propriétaire, j’ai quand même passé pas mal de temps à travailler avec VMware et j’ai toujours été relativement content d’ESXi (no comment sur le reste de la “suite” par contre).

Note : vous pouvez d’ailleurs retrouver tous les articles qui parlent de VMware sur ce blog, ça date un peu, mais il reste peut-être des trucs utiles.

On va donc voir si c’est si facile que ça…

Ubuntu Pro ?

La première chose qu’on apprend dans la doc, c’est qu’il existe 2 manières de customiser des OS non Ubuntu pour les faire marcher dans MAAS :

Packer MAAS
MAAS Image Builder

MAAS Image Builder nécessitant une souscription Ubuntu Pro, je vais évidemment me rabattre uniquement sur Packer MAAS…

Heureusement, le projet est relativement bien fourni, avec des CentOS (8 ou 9 stream), des Debian jusqu’à la 12, et donc… VMware ESXi, de la 6 à la 8.

Pour cet article, je me suis d’abord basé sur le tutoriel officiel, mais il est sévèrement “pas à jour” (on a un petit doute dès la première étape qui demande d’utiliser Ubuntu 18.04) et pointe vers des versions obsolètes…

Installer Packer

Comme son nom le laisse deviner, on va avoir besoin de Packer, un tool de mes copain⋅es de chez Hashicorp. Pour l’instant personne n’a forké Packer, donc :

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install packer

On vérifie que ça a bien marché

packer --version
 Packer v1.10.0

Récupérer un ISO chez VMware

Alors, là, c’est la partie pénible. Si on n’est pas client VMware, il n’est pas possible de télécharger d’ISO de VMware ESXi sans :

se créer un compte
demander un trial sur une version (idéalement la dernière) d’ESXi

C’est pénible, ça demande plein d’infos personnelles et ça pourri les BAL, mais bon… c’est ça aussi, d’utiliser des logiciels privateurs. Avant, l’usage de l’ESXi était gratuit, mais visiblement, c’est de l’histoire ancienne…

Pas de bol, j’avais fait mes premiers tests sur VMware ESXi 8.0u1, et j’ai voulu récupérer la u2, mais voici ce que me dit VMware

Your evaluation has expired on August 29, 2023

Pour paraphraser un certain Linus T., F… YOU VMware! Tant pis, je vais donc faire avec l’ISO que j’ai…

VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso

Récupérer packer-maas

Si vous suivez le tuto que je vous ai donné en début d’article, il y a un moment où on va vous demander un Nom/Prénom/Email pour avoir le droit de télécharger un script pour transformer notre ISO VMware en image MAAS.

maas.io/vmware-images

Sauf que :

l’archive que vous allez télécharger est obsolète et ne fonctionnera pas
les sources et les releases sont dispos et à jour sur le github du projet

Rant: Je suis éventuellement OK pour donner mes informations personnelles en échange de l’outil, mais s’il vous plait, gardez vos tutos à jour !?!

On va donc plutôt télécharger directement la dernière version de packer-maas qui supporte les Debian et des variantes de RHEL supplémentaires :) et est disponible ici (page de la release / archive tgz)

wget https://github.com/canonical/packer-maas/archive/refs/tags/v1.1.0.tar.gz
tar xzf v1.1.0.tar.gz
cd packer-maas-1.1.0/vmware-esxi/

Construire l’image VMware ESXi pour MAAS

On commence par charger le driver nbd. Si comme moi, vous ne savez pas ce que c’est, sachez que c’est Network Block Devices.

sudo modprobe nbd
# si ça ne renvoie rien, c'est bon

Ensuite, on lance Packer avec les arguments suivants :

sudo packer init .
sudo PACKER_LOG=1 packer build -var 'vmware_esxi_iso_path=../../VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso' .

Note: packer-maas fourni aussi un Makefile pour vous simplifier encore plus la vie… Vous pouvez juste lancer make ISO=/path/to/VMware-VMvisor-Installer.iso

À ce moment-là, les scripts de packer-maas vont booter une VM avec notre ISO et réaliser des actions pour “l’installer” en envoyant des caractères dans une session VNC !

Quand on y réfléchit, c’est à la fois un peu bourrin et awesome à la fois.

Si tout se passe bien, vous devriez vous retrouver avec un fichier vmware-esxi.dd.gz au bout de quelques minutes.

ESXi dans MAAS

Maintenant qu’on a notre image, on va l’envoyer dans MAAS !

Sur l’UI, récupérer une clé pour API (sinon on ne pourra pas pousser l’image) sur votre utilisateur (il doit être avec des privilèges admin) :

Je n’ai pas trouvé de menu dans la GUI pour le faire, mais on peut loguer notre terminal avec la commande suivante (en n’oubliant pas de renseigner l’API key) :

maas login admin http://192.168.x.y:5240/MAAS/
API key (leave empty for anonymous access):

Puis envoyer l’image en CLI

maas admin boot-resources create name='esxi/8.0u1' title='VMware ESXi 8.0u1' architecture='amd64/generic' filetype='ddgz' content@=vmware-esxi.dd.gz

Note 1 : ne faites pas de Packer sur une partition Windows montée sous Linux (fuse + packer = KK) Note 2 : si vous avez installé MAAS en tant que snap sur votre poste, vous ne pouvez accéder aux fichiers que dans votre /home (vous vous prendrez un “no such file or directory”)

À partir de là, elle devrait apparaitre dans la liste des “Images” disponibles !

Let’s go la déployer sur une machine du lab… Et au bout de quelques minutes…

Victoire !

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.

Sécurité des mots de passes ESXi 5.X et 6.X

Mon, 06 Apr 2020 06:50:00 +0000

Pourquoi tu nous parles d’ESXi 5 ?

En voilà une bonne question ! Comme la majorité des blogueurs tech, j’ai dans mes brouillons une bonne 30aines d’articles en attente depuis plus ou moins longtemps (demandez à Seboss666 ce qu’il en pense).

Ca fait presque deux ans que je n’ai pas touché à un serveur VMware et pourtant, cette doc était pratiquement “prête à poster”. Tout comme “Intégrer un RHEL 7 dans un Active Directory avec Ansible” et “Mise en place de DRBD 8.4 sous CentOS 6.3”, mais c’est une autre histoire…

Et comme je n’aime pas gâcher, je “profite” du confinement pour déconfiner des vieilles docs avant qu’elles ne soient plus définitivement plus d’actualité (trop tard, vSphere 7 vient de sortir).

Les mots de passe dans vSphere

Un truc que je n’ai pas trouvé très très clair et qu’il est possible dans VMware d’avoir des comptes utilisateurs internes à l’ESXi avec des mots de passe plutôt bof complexes. En effet, il est tout à fait possible d’avoir un mot de passe avec que des lettres minuscules (voire même des chiffres ??) ce qui -nous sommes d’accord- est absolument catastrophique.

Lorsqu’on sait qu’on a parfois besoin de se loguer sur la console à distance et que l’émulation des terminaux KVM des constructeurs est une bouse intergalactique qui vous transforme votre AZERTY en un gloubiboulga à mis chemin entre le QWERTY et DVORAK, c’est parfois tentant…

Bref, j’ai voulu comprendre la logique de VMware pour l’acceptation de la longueur des mots de passe.

En fait, tout est expliqué, en fonction des versions, dans ce KB (lien mort, comme tout chez VMware).

Password quality-control PAM module

Je ne savais pas, mais VMware utilise tout simplement le module PAM Password quality-control PAM. Il permet de réaliser des contrôles simples sur la qualité des mots de passe choisi pour les utilisateurs Linux.

Globalement, on dispose, via ce module, de différents flags pour valider une politique simple de gestion de mot de passe sur un système Linux (car oui, ESXi c’est un Linux).

Les arguments retenus par VMware sont uniquement basés sur une taille minimale de mots de passe en fonction du nombre de type de caractères différents dont dispose ce mot de passe. Voilà à quoi ça ressemble :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4

Par défaut, voici ce que vous allez trouver dans vSphere 6 :

retry=3 : Un utilisateur a droit à trois tentatives pour entrer un mot de passe suffisant.
N0=12 : Le mot de passe comportant des caractères d’une seule classe doit contenir au moins 12 caractères.
N1=9 : Le mot de passe comportant des caractères de deux classes doit contenir au moins neuf caractères, mais qui n’est pas éligibles aux conditions des passphrases.
N2=8 : Le mot de passe respecte les conditions des passphrases. Il comporte des caractères de deux classes et doit contenir au moins huit caractères.
N3=7 : Le mot de passe comportant des caractères de trois classes doit contenir au moins sept caractères.
N4=6 : Le mot de passe comportant des caractères des quatre classes doit contenir au moins six caractères.

Procédure pour modifier la politique de sécurité

Si pour une raison ou pour une autre, vous souhaitez modifier ces paramètres (pour les durcir, hein !), voici la marche à suivre :

Connectez-vous au Shell ESXi et obtenez les privilèges root.
Ouvrez le fichier passwd avec un éditeur de texte.

vi /etc/pam.d/passwd

Modifiez la ligne suivante :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=disabled,20,20,15,10

Cette commande vous permettra de désactiver la possibilité d’ajouter des utilisateurs dans ESXi dont les mots de passe n’ont qu’une classe de caractères et de complexifier fortement les autres types de mots de passe.

Il existe de nombreux autres paramètres. Je vous invite à aller lire la page man de ce module pour améliorer encore la sécurité des mots de passe dans vos ESXi.

Bonus GUI pour ESXi 6.0

Si vous êtes allergique à la console jaune et noire d’ESXi (ou que vous n’avez pas la main sur un KVM), sachez que depuis ESXi 6.0, il est possible de modifier directement les valeurs du module PAM depuis la console vSphere. Ça se passe dans les options avancées de l’hôte (cf cet article de Vladan).

Password Complexity Rules – change here where In previous versions of ESXi, password complexity changes had to be made by hand-editing the /etc/pam.d/passwd file on each ESXi host. In vSphere 6.0 now this can be done by adding an entry in Host Advanced System Settings, enabling centrally managed setting changes for all hosts in a cluster.

Ouah, cébo !

Sources

VMware KB 1012033 (lien mort, comme tout chez VMware)
Doc vSphere 5, en français (lien mort, comme tout chez VMware)
Page man de pam_passwdqc
Vladan : ESXi 6.0 Security and Password Complexity Changes

Harbor : la registry Docker open source de VMware – part 2

Tue, 26 Jun 2018 11:45:04 +0000

Harbor, la registry Docker de VMware

Il y a quelques mois, j’avais écris un article à propos d’une bonne surprise de la part de VMware : Harbor. Pour ceux qui n’ont pas lu mon article sur le sujet, j’ai développé dans la première partie ce qu’était Harbor et ce que cette solution apporte par rapport aux autres outils du marché, puis j’ai expliqué pas à pas comment l’installer et la configurer (vous pouvez vous rattraper ici).

Rapidement, Harbor est un des produits open sourcé par VMware. C’est un serveur permettant de stocker « on premise » ou dans le cloud des images Docker, au même titre que le produit historiquement appelé Docker Registry (maintenant Docker Distribution), mais avec des fonctionnalités supplémentaires, notamment :

Gestion de la sécurités, des comptes, rôles, habilitation (RBAC)
Réplication des images entre plusieurs instances de Harbor
Portail web
Logging de toutes les opérations à des fins d’audit
API RESTful
Scan de vulnérabilité intégré
Nettoyage automatique des images inutiles (garbage collection)
Intégration native avec Notary pour la signature des images

Dans cette deuxième partie, j’ai voulu explorer un peu plus l’utilisation et l’administration de la plateforme que nous venons d’installer.

Administration de base

Dans l’article précédent, on a installé Harbor à l’aide d’un Docker Compose et d’Ansible pour faciliter la récupération de certains prérequis et la configuration des différents composants.

Démarrer/arrêter Harbor

Du coup, comme tout est configuré avec docker compose, l’arrêt et le redémarrage de la plateforme se limite à un simple docker-compose up ou down.

docker-compose up
[...]
docker-compose down
Stopping nginx ... done
Stopping harbor-jobservice ... done
Stopping harbor-ui ... done
Stopping harbor-db ... done
Stopping registry ... done
Stopping harbor-adminserver ... done
Stopping harbor-log ... done
WARNING: Found orphan containers (notary-server, notary-signer, notary-db) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Removing nginx ... done
Removing harbor-jobservice ... done
Removing harbor-ui ... done
Removing harbor-db ... done
Removing registry ... done
Removing harbor-adminserver ... done
Removing harbor-log ... done
Removing network harbor_harbor

Supprimer / Réinstaller Harbor

Contrairement à ce qu’on pourrait penser naïvement, un simple docker-compose down ne suffit pas. Si les containers sont bien supprimé (cf. le « Removing… » pour chaque composants plus haut), il reste encore les fichiers de configurations et les données des différents containers, toujours présents sur disques et persistés à l’aide de volumes Docker.

Il est nécessaire de supprimer ces fichiers créés par l’installation précédente, notamment le contenu de common/config et le fichier secretkey. Par défaut, l’emplacement de ces fichiers est configuré par le playbook Ansible que je vous ai proposé. common/config est par défaut dans /usr/local/harbor, et la secretkey dans dans /data (configurable dans le fichier /usr/local/harhor/harbor.cfg).

cd /usr/local/harbor
ll common/config/
total 0
drwxr-xr-x 2 root root 16 20 oct. 11:38 adminserver
drwxr-xr-x 2 root root 16 20 oct. 11:38 db
drwxr-xr-x 2 root root 31 20 oct. 11:38 jobservice
drwxr-xr-x 9 root root 139 20 oct. 11:38 nginx
drwxr-xr-x 3 root root 27 20 oct. 11:38 notary
drwxr-xr-x 2 root root 38 20 oct. 11:38 registry
drwxr-xr-x 2 root root 53 20 oct. 11:38 ui
cat harbor.cfg
[...]
secretkey_path /data
[...]

Voilà donc la bonne méthode pour tout supprimer (maintenant qu’on a vérifié que les chemins configurés correspondent).

docker-compose down
rm -rf /usr/local/harbor/common/config/
rm -rf /data/secretkey

Pousser (push) une image depuis un client configuré vers la Registry

Pour vous permettre d’organiser un peu vos images et donner des droits plus fins aux utilisateurs, les accès aux images sont découpés via des « projet » dans Harbor.

Du coup, avant de pousser un image sur la registry, il est nécessaire de « taguer » l’image avec le nom du serveur registry ET son projet associé, au lieu de simplement taguer un nom d’image comme on l’aurait fait normalement avec la Docker Registry.

REGISTRY=[hostname_de_la_registry]
DOCKER_IMAGE=[your-docker-image]
HARBOR_PROJET=library
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded
docker tag $DOCKER_IMAGE $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE
docker push $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE
The push refers to a repository [xxx/library/xwiki-tomcat8]
ac33aaa78bac: Pushed
[...]
fe40aaa9465f: Pushed
cf4aaa492384: Pushed
latest: digest: sha256:81b3a60d6936a07e9zzzzzzccb29ead8a1d1035fa5042297ac54f71a6c1e95bb size: 4504

L’image apparaît sur la console :

Tirer (pull) une image depuis un client configuré

Même principe que pour le push, il faut être authentifié et sélectionner le projet dans lequel est située l’image

REGISTRY=[hostname_de_la_registry]
DOCKER_IMAGE=[your-docker-image]
HARBOR_PROJET=library
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded
docker pull $REGISTRY/$HARBOR_PROJECT/$DOCKER_IMAGE

Tout simplement !

Interface web : Projects

La vue Projects a vocation a permettre la segmentation de la plateforme en plusieurs projets distincts.

Chaque projet peut être privé ou public, disposer d’habilitations et règles de réplications qui lui sont propres.

Interface web : Logs

La vue Logs permet aux administrateurs d’avoir une vue d’ensemble des logs (pull, push, etc) de TOUS les projets de manière centralisée.

Chaque projet peut également voir ses propres logs dans la vue du projet.

Clairement, ce n’est pas transcendant en terme de logging (à des fins d’audit par exemple) mais c’est mieux que rien (Docker Registry…) et relativement intuitif.

Interface web, partie Administration

Le sous-menu Users permet d’avoir une liste des utilisateurs et de les administrer.

Le sous-menu Replication permet de gérer les endpoints de réplication et la réplication des projets (Replication Rule) de manière globale.

Le sous-menu Configuration permet de visualiser et modifier une partie des paramètres généraux de la plateforme. Une partie des ces paramètres proviennent de la configuration harbor.cfg renseignée lors de l’instanciation (via Ansible dans notre cas). Certains ne peuvent pas être changés depuis l’interface (comme la méthode d’authentification par exemple, mais je ne le testerai pas si j’étais vous…).

Par défaut, la création de projets est permis pour tout le monte et l’enregistrement d’utilisateurs est possible. Pour des raisons de sécurité, il est préférable de le désactiver si ce n’est pas nécessaire.

Erreurs rencontrées

Dans l’ensemble, Harbor est un produit sympa et plutôt bien fini, qui étend avec des fonctionnalités vitales en entreprise la bête Docker Registry.

Pour autant, le produit étant récent, il n’était pas exempt de quelques bugs à sa sortie (en grande partie corrigés depuis). Voilà ceux que j’ai rencontré au moment où j’ai rédigé le premier article (il y a quelques mois maintenant)

Modification du secretkey_path

Si on modifie le paramètre secretkey_path, le container harbor-adminserver part en crash loop. Le problème est référencé sur ce ticket

github.com/vmware/harbor/issues/2208

docker ps
[...]
7dcd18a310bc vmware/harbor-adminserver:v1.2.0 "/harbor/harbor_ad..." 19 seconds ago Restarting (1) 3 seconds ago harbor-adminserver
docker-compose up
[...]
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] initializing system configurations...
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] the path of json configuration storage: /etc/adminserver/config/config.json
harbor-adminserver | 2017-10-20T09:56:16Z [DEBUG] [driver_json.go:46: path of configuration file: /etc/adminserver/config/config.json]
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] the path of key used by key provider: /etc/adminserver/key
harbor-adminserver | 2017-10-20T09:56:16Z [INFO] configurations read from storage driver are null, will load them from environment variables
harbor-adminserver | 2017-10-20T09:56:16Z [FATAL] [main.go:46: failed to initialize the system: read /etc/adminserver/key: is a directory]

A priori il n’y a pas encore de correctif, la seule solution est de remttre le paramètre secretkey_path à la valeur par défaut

secretkey_path /data

Crash loop sur nginx lorsqu’on utilise Notary

En cas d’installation avec Notary, le container frontend nginx (reverse proxy) part en crashloop

nginx | 2017/10/20 10:05:40 [emerg] 1#0: host not found in upstream "notary-server:4443" in /etc/nginx/conf.d/notary.upstream.conf:3
nginx | nginx: [emerg] host not found in upstream "notary-server:4443" in /etc/nginx/conf.d/notary.upstream.conf:3
nginx exited with code 1

A priori, il s’agit d’un problème d’ordonnancement du démarrage des containers dans le Docker Compose (notary n’est pas accessible au moment du démarrage du nginx). Un redémarrage du container nginx (uniquement )après le « docker compose up » règle la plupart du temps le problème.

Sortie de Proxmox VE 5.2.1, les nouveautés

Tue, 22 May 2018 14:45:57 +0000

Proxmox VE 5.2.1

La semaine dernière, Proxmox Server Solutions GmbH, l’équipe derrière Proxmox VE a sortie la version 5.2 de son hyperviseur libre & clé en main.

J’ai déjà écris de nombreux articles sur cette distribution car c’est un très beau projet, à mon sens une des seuls distributions clés en main pour faire de la virtualisation aussi bien pour des besoins perso que des besoins pros. Pour ceux qui ne connaissent pas, je vous conseille de commencer par les tutos de M4vr0x sur Proxmox VE 5.x (part1) (part2) (part3).

Dans le rétroviseur, Proxmox VE 5.0 et Proxmox VE 5.1

Sortie l’été dernier, le changement de la branche 4 vers la branche 5 de Proxmox VE a surtout marqué une évolution de l’OS à la base de Proxmox VE (Debian 8 vers Debian 9), même si quelques features sympa avaient quand même été ajoutées.

Dans les points marquants, il y avait tout de même eu :

le renforcement de l’intégration avec Ceph, via l’intégration de la version Luminous (Ceph 12.1, preview) et des améliorations dans le Dashboard Ceph dans l’UI (apparue en 4.4)
l’introduction de la fonctionnalité de Storage Replication, basée sur des mécanismes built-in de ZFS
la migration à chaud de VMs, même s’il s’agit de stockages locaux
un effort particulier pour importer des VMs provenant d’autres hyperviseurs

Clairement, l’équipe de Proxmox a fait un focus sur le stockage, dans le but de rattraper les « grands » hyperviseurs sur ces aspects (i.e. des alternatives à VSAN, vSphere Replication et storage vMotion). Voir ce genre de features dans un hyperviseur (qui peut être) gratuit et sans pour autant être une usine à gaz comme RHEV/oVirt est très appréciable.

Sortie fin Octobre, la version 5.1 était passée relativement inaperçue (au moins de moi) puisqu’elle apporte surtout un passage à l’état « production ready » du stockage Ceph (v12.2) dans PVE ainsi qu’une mise à jour de ZFS apportant des gains de performance (en plus des mises à jour de kernel/packages habituelles).

Et Proxmox VE 5.2 alors ?

Là, en revanche, ya du lourd !

Déjà, on est passé sur une Debian 9.4, avec un kernel 4.15.17 (assez récent puisqu’on est en est au 4.16). LXC passe de la 2.0.0 à la 3.0.0, la LTS sortie en mars du container runtime disponible dans PVE. Ceph passe en Luminous LTS stable, ce qui rassurera les plus frileux qui attendaient avant de tester Ceph sous Proxmox VE.

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester =>

Support de Cloudinit dans la GUI. Pour ceux qui ne connaissent pas, c’est un mécanisme universel sous Linux permettant de configurer votre VM dès son instanciation (voir doc officielle)
La possibilité de gérer les nœuds des clusters Proxmox VE
Gestion des certificats Let’s encrypt directement depuis la GUI; ce point va faire l’objet d’un petit article très vite ;-)
Ajout des partages SMB/CIFS comme support de stockage officiel (backups, images, templates, iso et containers)
Affichage de l’adresse IP de la VM dans l’UI (première intégration de l’agent qemu-guest-agent, on peut espérer plus de fonctionnalités à l’avenir)
Possibilité de limiter la bande passante lors des opérations de restauration des backups
Intégration de xterm.js comme console en plus de noVNC et SPICE

Il y en a d’autre mais qui m’intéressent moins. Vous pouvez néanmoins consulter la liste complète sur le changelog de la version.

Concrètement ça donne quoi ?

Je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je ne souhaite pas en dire plus pour le moment, car je vais (en cours d’écriture) publier des articles dans les jours qui viennent sur ces nouvelles fonctionnalités. Un petit teasing tout de même :

cloud-init dans l’UI de PVE

Génération d’un certificat Let’s Encrypt pour un nœud PVE

L’ajout de xterm.js dans l’UI

La gestion des clusters dans l’UI de PVE

Limites en MiB/s lors d’une restauration

Récap’ du premier jour de KubeCon Europe 2018

Wed, 02 May 2018 22:09:43 +0000

Premier jour de KubeCon aujourd’hui !

Hier soir, je suis arrivé à Copenhague pour participer à la KubeCon + CloudNativeCon Europe 2018. Vous ne savez pas de quoi il s’agit ? C’est LA conférence sur 3 jours, organisée par la CNCF, qui parle de Kubernetes et tout ce qui gravite autour.

Ce n’est pas la première conf que je couvre sur le blog, j’avais déjà fais un récapitulatif de la Hack-It-N 2018.

On est environ 4300…

La journée a commencée par des Keynotes, ponctuées par des petites interventions de Liz Rice et Kesley Hightower. La plupart étaient un peu humoristiques, mais j’ai retenu ceci parmis les keynotes du matin :

Où en sont les projets de la CNCF ?

Keynote: CNCF Project Update - Liz Rice, Technology Evangelist, Aqua Security; Sugu Sougoumarane, CTO, PlanetScale Data; Colin Sullivan, Product Manager, Synadia Communications, Inc. & Andrew Jessup, Co-founder…

Cette année, le moins que l’on puisse dire est que la CNCF a réellement pris de l’ampleur, en terme de projets notamment.

L’ajout de plusieurs projets à l’état « Sandbox » :

Rook (abstraction du stockage), One Policy Agent (politiques de sécurité pour l’ensemble de la stack), SPIFFE (langage de spec) & SPIRE (runtime env) qui a pour but d’établir un lien de confiance entre l’infrastructure et les workloads.

Plusieurs projets sont à l’état « Incubator » :

CoreDNS, Linkerd (service mesh), Envoy (distributed proxy), Prometheus, OpenTracing, Jaeger (distributed tracing), Fluentd (Splunk Entreprise connector + fluentd daemonset for kubernetes), Fluent bit (client lightweight un peu comme Beats d’Elastic), NATS (messaging), Container Network Interface (CNI), gRPC (client/server), Container runtime (Containerd / Kubernetes CRI), TUF (The Update Framework), Notary, Vitess (distribution de données sur MySQL avec Sharding/resharding automatic)

La liste est vertigineuse.

Kubernetes est également passé à l’état « Graduated » (premier projet CNCF a passé à l’état « production ready » pour la plupart des projets informatiques, pas seulement pour les tech enthousiasts et les early adopters.

Si j’ai tout listé, c’est que l’ensemble de ces projets ont par la suite droit à une ou plusieurs confs et j’aurai l’occasion de revenir dessus si je participe aux confs en question.

Re-thinking Networking for Microservices

Keynote: Re-thinking Networking for Microservices - Lew Tucker, VP/CTO Cloud Computing, Cisco Systems, Inc.

Le CTO Cloud Computing de Cisco est venu nous expliquer que maintenir l’ensemble des services permettant au microservice d’échanger avec le monde extérieur, c’est compliqué, et qu’il vaut mieux utiliser du service mesh (découpler tous les services de communication et externes aux services comme logging, api, auth, …).

REX du CERN

Keynote: CERN Experiences with Multi-Cloud Federated Kubernetes

On ne présente pas le CERN (mais en fait on a quand même eu droit à une présentation ;-p ), mais au delà des travaux scientifiques, il faut des ops pour faire tourner la puissance de calcul brute.

10000 hyperviseurs, des quantités de données très importantes (1 Po/s généré, 10 Go/s enregistré).

Malgré cette force de frappe plus qu’honnête, lors de grosses campagnes de calculs scientifiques, il faut tirer parti de ressources externes (clouds, universités), ce qui induit la nécessité d’un outils permettant de fédérer des machines provenant de tous horizons.

Le CERN utilise la fédération de cluster de Kubernetes, avec en plus l’outil HTCondor qui étend l’API de Kubernetes et leur permet de lancer les jobs sur les machines (distantes ou pas) en fonction du job demandé.

Mini talk du VP & Chief Open Source Officer de VMware

Keynote: From Innovation to Production - Dirk Hohndel, VP & Chief Open Source Officer, VMware

Au delà du présentation plus que rapide des produits opensource sur lesquels contribue VMware, (Harbor, pivotal, BOSH), Dirk Hohndel a surtout utilisé les 5 minutes qu’il avait pour nous faire remarquer que les gens de l’audience sont en grande majorité des hommes blancs et qu’il y a un vrai problème de mixité dans nos métiers. J’ai regardé autour de moi, difficile de lui donner tort.

Et les vraies conférences ont pu commencer !

Pourquoi y a-t-il autant de runtimes ?

Whats Up With All The Different Container Runtimes? - Ricardo Aravena, Branch Metrics

Ricardo Aravena a brossé un tableau de l’évolution des containers runtimes sous Linux, puis a listé leurs avantages et leurs inconvénients. Un talk plutôt sympa en mode comparaisons et Pros/Cons sur les différents runtimes du marché.

Créer et gérer une communauté open source

Building an Open Source Community to Achieve Innovation-Through-Openness - Jonas Rosland, {code}

Un talk « non technique » auquel j’avais vraiment envie d’aller. J’avais été assez surpris de remarquer l’ouverture de Dell EMC en 2015 avec l’équipe {code}, alors forcément, un REX sur comment gérer une communauté open source et le erreurs qui ont pu être faites m’intéressait forcément.

Au final, le talk, même s’il est resté très haut niveau, a donné de bons conseils (planification de la roadmap, transparences, SIGs, focus sur les individus plus que les projets) et des ressources complémentaires (opensource.com guides, codeofconducts), qui n’existaient pas à l’époque où {code} s’est mise en place.

REX de Turbine labs a propos de leur migration de nginx vers envoy

Replacing NGINX with Envoy in a Traffic Control System - Mark McBride, Turbine Labs, Inc

Le CEO de Turbine Labs nous a fait un REX sur un changement majeur qu’ils ont eu à réaliser sur leur produit : le changement de nginx (limité pour leurs besoins spécifiques) pour Envoy. Ce changement impliquait (1) d’écrire une partie des features manquantes dans Envoy (extensions maisons spécifiques à Turbine Labs pour leurs besoins propres) et la façon la plus progressives de migrer ce composant central dans leur architecture.

Si le talk était intéressant en soit (et permet d’avoir un premier aperçu de Envoy), c’était aussi l’occasion de se poser les bonnes questions pour tout migration, qu’elle qu’elle soit.

REX Zalando, la mise à jour des clusters Kubernetes

Continuously Deliver your Kubernetes Infrastructure - Mikkel Larsen, Zalando SE

Le site de e-commerce Zalando est quelque chose d’assez énorme. On ne s’en rend pas forcément compte, mais ce sont des dizaines de clusters Kubernetes qui sont nécessaires pour gérer la partie développement des nouvelles applications.

Zalando est connue comme faisant partie des sociétés qui communiquent beaucoup sur leurs (bonnes) pratiques en terme d’IT. D’ailleurs l’amphi était plein à craquer :

Mikkel Larsen n’y a pas coupé et nous a méthodiquement expliqué pas à pas tout ce qui était mis en place pour assurer (1) des mises à jours des clusters Kubernetes complètement transparentes et quasi automatiques, et (2) des test ends to ends complet permettant de repérer des régressions mêmes subtiles.

Côté technique, Zalando travaille sur AWS, sur plusieurs availability zones, avec des Stack Cloud Formations, 1 seule AMI pour toutes les VMs, des clusters etcd externalisés des nœuds Kubernetes (rendant les masters stateless, et donc plus facile à mettre à jour), …

The Route to rootless container

The Route To Rootless Containers - Ed King, Pivotal & Julz Friedman, IBM

Je ne vais pas le cacher, je suis allé pour le titre de la conf et je n’ai pas été déçus côté clins d’œils / memes (ni par le contenu, mais c’est toujours plus agréables quand les speakers sont bons).

Si Ed King et Julz Friedman ont commencé par dire qu’ils étaient contents qu’autant de gens soient présents pour un « sujet aussi basique », le talk n’était clairement pas à destination de débutants !

Point par point, ils ont expliqué quels technologies et couches de sécurités étaient disponibles, contre quoi elle protégeaient et ne protégeaient pas. Dans une seconde partie, ils ont ensuite expliqués comment réussir à faire fonctionner des containers exécutés côté hôte par un utilisateurs non privilégié mais privilégié au sein du container. Mais surtout, pourquoi ça fonctionne et pourquoi ça n’était pas grave.

Une vraie surprise car j’avais mal compris la conf (je pensais qu’on allait expliquer comment faire pour que les applications ne soient pas root DANS le container).

Améliorer la sécurité des workloads Kubernetes avec la virtualisation matérielle

Improving your Kubernetes Workload Security with Hardware Virtualization - Fabian Deutsch, Red Hat & Samuel Ortiz, Intel

Une conf’ amusante où deux projets dont le but est de faire tourner des workloads Kubernetes dans des machines virtuelles (Kata et KubeVirt), soit disant non concurrents, ont été présentés en même temps.

La subtilité, selon eux, c’est que :

Kata containers est plutôt à destination des personnes qui souhaitent :
- ajouter une couche de sécurité/ségrégation supplémentaire à la conteneurisation simple en ajoutant l’isolation via la virtualisation matérielle
- utiliser des kernels différents pour des containers différents sur un même groupe d’hôtes Kubernetes
Kubevirt permet l’adoption plus rapide de Kubernetes en permettant l’ajout des workload de type legacy « non containerisables » dans un cluster Kubernetes. Ces workloads deviennent des Pods qui tournent dans Kubernetes, ce qui a l’immense avantage d’ajouter toutes les fonctionnalités de Kubernetes sur les Pods, mais aussi la gestion de réseau et du stockage.

A vous de me dire si vous êtes convaincus qu’il faut absolument 2 projets ;-).

Et vous reprendrez bien quelques keynotes

Anatomy of a Production Kubernetes Outage

Keynote: Anatomy of a Production Kubernetes Outage - Oliver Beattie, Head of Engineering, Monzo Bank

Un postmortem d’un incident qui a bloqué la prod d’une banque « digital native ». Très bien présenté et d’autant plus intéressant que les « erreurs » qui ont été faites tendent plus de la malchance et de fausses bonnes idées que de l’erreur a proprement parler; il était très facile de m’imaginer à la place des équipes qui ont géré cet incident.

Container Native Dev and ops Experience

Keynote: Container-Native Dev-and-ops Experience: It’s Getting Easier, Fast. - Ralph Squillace, Principal PM – Azure Container Platform, Microsoft

Je ne vais pas mentir, je suis un peu passé à côté de cette keynote. Ralph Squillace nous a fait une démo en live de code qui se déploie, se débugue et tourne sur Kubernetes pour nous prouver à quel point c’est simple. Moui, ok.

Au delà de ça, j’ai surtout remarqué que son PC était sous Ubuntu. Venant de quelqu’un qui bosse chez Microsoft (même si c’est une team Kubernetes), c’est quand même quelque chose qui aurait été impensable il y a quelques années ;-p

Cloud native observability & security

Keynote: CNCF End User Awards - Presented by Chris Aniszczyk, COO, Cloud Native Computing Foundation

Un résumé des annonces faites aujourd’hui par Google à l’occasion de la Kubecon.

gVisor, un système révolutionnaire qui va résoudre tous les pb de sécurité des containers
stackdriver, un outil de monitoring (observability) génial, qui rendre nos vies géniales

Peut être que le format était mal choisi, mais je suis extrêmement sceptique et je vais attendre d’en savoir plus ;)

Prometheus 2.0

Keynote: Prometheus 2.0 – The Next Scale of Cloud Native Monitoring - Fabian Reinartz, Software Engineer, Google

Une tonne de slides pour nous brosser l’historique de Prometheus dans un premier temps, puis nous expliquer qu’un gros problème est arrivé, la TSDB de Prometheus était trop lente sur de très gros workloads. Déluge de slides pour nous montrer à quel point Prometheus 2 est bien meilleur.

Maintenant c’est mieux.

Et demain ?

Et bien demain rebelote (enfin si je poste pas très vite, on va déjà être demain…).

Si ça vous intéresse, vous pouvez suivre les confs que je vais voir sur kccnceu18.sched.com/d.germain.

Hack : diminuer la taille du VMDK d’une VM Linux LVM

Wed, 14 Mar 2018 12:45:43 +0000

Réduire un VMDK

Note : cet article n’est pas écrit par moi mais par mon ami et ancien collègue Steve aka ventreachoux85 (ahahah faut assumer maintenant Steve), que j’héberge avec grand plaisir sur le blog :-)

Note 2: Comme toute opération sur des disques, des partitions, des filesystems, elles sont à faire avec des backups préalables. Cette opération est dangereuse et est à vos risques et périls => vous voilà prévenus.

Sur un serveur Linux (CentOS 6.9 pour la petite histoire) hébergé sur un serveur VMware, je souhaite réduire la taille de mon disque virtuel de 75 Go car la volumétrie ne va pas bouger. S’il est simple d’agrandir un disque virtuel sous VMware, le réduire est une autre paire de manches !

Si la machine avait été un serveur Windows, voilà ce que j’aurai fais :

Réduction du volume depuis l’utilitaire de gestion de disques
Modification de l’extent description directement sur le fichier .vmdk depuis l’ESXi (en SSH)
Migration de la VM sur un autre datastore => elle aurait eu la taille voulue à l’issue de l’opération

Je ne détaille volontairement pas cette procédure car celle qui suit est similaire et nous allons prendre le temps de tout voir.

Et donc du coup, là c’était pas pour des windows, mais pour des machines sous Linux ! J’ai demandé son avis à zwindler, qui m’a demandé en échange de rédiger une petite procédure pour le blog ;-)

Réduction du FS

Voilà donc à quoi ressemble les disques de mon serveur avant l’opération :

Dans mon cas, je n’ai pas besoin de réduire les Filesystems, j’ai déjà beaucoup de PE de disponibles. S’il avait fallut le faire, on aurait été obligé de réduire les FS à froid (dans le cas ext*), voire même de passer par un liveCD si on avait du redimensionner « / » ou un autre FS vital pour l’OS.

Réduire un VMDK partitionné pour du LVM

Le problème avec la commande pvs est que la taille utilisée et la taille disponible est arrondie pour être au format « human readable » d’Unix. Idéalement, il nous faut une mesure exacte pour redimensionner au plus juste.

Une des manières simples de le faire est d’utiliser l’unité « secteur » de la commande pvs (512 octets). Il faut faire la différence entre le PSize et le PFree pour avoir la taille définitive du disque :

Après un rapide calcul, si je veux réduire le disque de tous les PE disponibles :

209453056 – 164757504 = 44695552

La nouvelle taille du PV sera de 44965552 secteurs

Note de zwindler : Personnellement j’aurai laissé quelques PE, par habitude (limitations de LVM1 pénibles quand il n’y a plus de PE) et parce que je suis un froussard, mais a priori « ça marche ».

On redimensionne le disque

A noter, malgré le fait qu’on ait spécifié qu’il ne devait pas rester de PE de libre, a priori il en reste quand même quelques uns. Je ne sais pas si c’est une sécurité du pvresize ou si c’est lié aux arrondis et à la taille d’un PE sur ce PV. C’était une erreur de calcul (cf voir les commentaires).

Pour vérifier que tout va bien, un petit pvscan/vgscan.

Réduire la partition

A partir de là, ça se corse. On a réduit sans trop de difficulté le PV qui héberge nos LV, mais il nous reste maintenant à réduire la partition qui héberge ce PV. Même si théoriquement on peut le faire à chaud, zwindler m’a conseillé de faire ça à froid.

Pour autant, si vous vous sentez l’âme d’un aventurier et/ou avec un OS récent et/ou que vous n’avez pas le choix, vous pouvez toujours aller lire ce post sur Ask Ubuntu.

Le plus safe est quand même d’arrêter la VM puis booter sur un liveCD avec GParted.

Clic droit sur la partition à modifier – désactiver (sinon impossible de la redimensionner)

Sélectionner la partition puis Redimensionner / Déplacer

Attention : lors du premier redimensionnement, GParted ne prend ne réduit pas au maximum la partition. Il reste 2 Go qui sont inutilisés.

On lance un nouveau redimensionnement pour récupérer la place disponible !!

Note de zwindler : moi j’aurai laissé comme ça ;-)

ATTENTION

On voit que /dev/sda2 fait 21.44 Go après le pvresize (cf. screenshot précédent). En essayant de réduire au maximum la place utilisée, on peut tout casser (expérience vécue !!!). Pour plus de sécurité, je conseille de resizer à l’entier supérieur (donc dans notre exemple 22 Gio soit 22528 Mio)

Redimensionner le VMDK

Maintenant que le disque est modifié au niveau de l’OS, il faut le redimensionner au niveau de VMware.

Et là, rebelote : c’est pas « simple » à faire. En effet, VMware ne supporte pas la réduction des VMDK (que ce soit à chaud ou à froid).

Note: You cannot shrink virtual disks using vmkfstools in ESXi as the hypervisor is not aware of the file system layout and cannot ensure a safe shrink operation.

Heureusement, des petits malins ont trouvés la technique depuis bien longtemps :

Se connecter en SSH sur l’ESX qui héberge la VM, se rendre dans le dossier de la VM et faire un vi sur le fichier NomVM.vmdk, qui est un fichier texte (configuration), contrairement au fichier NomVM-flat.vmdk qui contient les données réelles.
Modifier la valeur suivante :

# Extent description
RW 209715200 VMFS "testsba-flat.vmdk"

La nouvelle valeur du paramètre extent description sera « 22 GB = 22 x 1024 x 1024 x 1024 / 512 (octets/secteur) = 46137344 secteurs »

# Extent description
RW 46137344 VMFS "testsba-flat.vmdk"

Déplacer la VM vers un autre Datastore

A partir de là, vous vous dites : « cool ! j’ai récupéré l’espace disque ». Et vous êtes déçus car rien ne se passe.

En effet, ce paramètre n’est pris en compte que lors de la création du disque, lorsque le fichier contenant réellement les données (le fameux NomVM-flat.vmdk dont je vous ai parlé plus tôt) est créé. Vous pouvez mettre n’importe quoi, ça ne changera rien du tout.

Cependant, si vous avez la licence qui va bien sur votre cluster, vous pouvez feinter le cluster pour lui faire recréer un disque à chaud de la bonne taille avec un simple Storage vMotion.

Avant le Storage vMotion :

Après le Storage vMotion :

Pourquoi ça marche ?

Petit aparté de zwindler : Pour bien comprendre ce qu’il se passe, il faut comprendre comment marche un Storage vMotion. Au moment où vous demandez à VMware de déplacer un disque d’un datastore à l’autre, voici l’enchaînement des opérations :

Prise d’un snapshot du disque initial
Création d’un disque sur le datastore cible. Ce disque est identique au disque initial au moment du snapshot via la commande vmkfstools. Cette commande relis la valeur contenu dans extent description pour savoir quelle taille le fichier doit faire physiquement, ce qui nous permet de feinter VMware et d’avoir un disque à la bonne taille._
_
L’ensemble des IO depuis le snapshot sont écrites simultanément sur les deux datastores, ce qui permet d’avoir 2 copies identiques au moment de la fin de la copie du snapshot
Migration de la VM sur le nouveau disque
Suppression de l’ancien disque hébergé par l’ancien datastore

Note de zwindler : j’étais persuadé d’avoir fais un article là dessus (et en fait pas du tout) mais il est évidemment possible de faire la même chose à la main sans Storage vMotion, simplement avec vmkfstools à la main.

Boot de la machine

Pour finir, une fois la VM bootée, il reste encore une petite opération de maintenance à réaliser. Il y a une petite différence de nombre de secteurs suite au redimensionnement.

Il suffit de faire un pvresize avec le nombre de secteurs indiqué par la commande pvs précédente :

Tout est dorénavant OK :

Harbor : la docker registry d’entreprise open source de VMware – part 1

Tue, 27 Feb 2018 12:45:35 +0000

Harbor ?

Rien à voir avec l’île dans le Pacifique ou l’accord entre les Etats Unis et l’Union Européenne dans les années 90. Le Harbor dont je vais vous parler, c’est la registry Docker d’entreprise et Open Source de VMware !

Harbor est un des produits open sourcé par VMware. C’est un serveur permettant de stocker « on premise » ou dans le cloud des images Docker, au même titre que le produit historiquement appelé Docker Registry (maintenant Docker Distribution), mais avec des fonctionnalités supplémentaires, notamment :

Gestion de la sécurités, des comptes, rôles, habilitation (RBAC)
Réplication des images entre plusieurs instances de Harbor
Portail web
Logging de toutes les opérations à des fins d’audit
API RESTful
Scan de vulnérabilité intégré
Nettoyage automatique des images inutiles (garbage collection)
Intégration native avec Notary pour la signature des images

Rien que ça ;)

Pour ceux que ça intéressent et qui ne savaient pas (comme moi) que VMware met à disposition des logiciels open source, les autres sont disponibles sur la page Github de VMware.

Petite étude du marché

Je ne vais pas vous faire une analyse poussée du marché de la registry privée, mais si jamais vous cherchez des produits similaires, vous pouvez aller jeter un œil aux produits suivants qui ont attirés mon attention :

Docker Trusted Registry (version entreprise de Docker Distribution)
Gitlab Container Registry, fortement intégré à Gitlab CI
Artifactory supporte maintenant les containers
Quay de CoreOS, Inc. (maintenant racheté par Redhat)

Et je vous met aussi quelques articles sympas qui parlent de ces différentes solutions :

Méthode choisie

Ok ! Maintenant qu’on connaît un peu l’écosystème, on peut s’attaquer à la bête. Il existe plusieurs méthodes pour installer Harbor sur une infrastructure « on premise » :

Installer Harbor sur un serveur Docker via
- l’installeur « online » (qui télécharge les images nécessaires sur Dockerhub)
- l’installeur « offline » (qui dispose déjà des images nécessaires)
Déployer une VM VMware via un OVA VIC (VMware vSphere Integated Containers) qui contient entre autre un serveur Harbor préinstallé et préconfiguré
Déployer Harbor directement sur un cluster Kubernetes via YAML (option communautaire)

Les releases sont disponibles depuis la page « release » sur le dépôt Github. L’OVA est lui disponible sur myvmware (lien mort, comme tout chez VMware, j’utilise Internet Archive), le site de téléchargement habituel de VMware.

Dans le cadre de cette article, la méthode d’installation que j’ai choisie est l’installation via les sources en mode « offline » car il m’arrive souvent dans les datacenters de ne pas avoir accès à Internet facilement (pour des raisons de sécurité).

Récupération des sources

Depuis un poste qui a accès à Internet, on va donc télécharger l’ensemble des fichiers dont nous aurons besoins : le fichier d’installation ainsi que sa signature md5.

curl -L https://github.com/vmware/harbor/releases/download/v1.2.0/harbor-offline-installer-v1.2.0.md5.txt -o harbor-offline-installer-v1.2.0.md5.txt
curl -L https://github.com/vmware/harbor/releases/download/v1.2.0/harbor-offline-installer-v1.2.0.tgz -o harbor-offline-installer-v1.2.0.tgz

C’est super d’avoir mis un fichier MD5… mais la comparaison avec la signature ne peut pas être faite telle quelle car un fichier de signature MD5 « valide » doit avoir le nom du fichier indiqué APRÈS la signature en elle même. Ce n’est pas le cas dans le fichier mis à disposition par VMware.

cat harbor-offline-installer-v1.2.0.md5.txt
235fcfb9fe00ad61f6cbc2de4920b477
#Un fichier MD5 valide doit contenir "235fcfb9fe00ad61f6cbc2de4920b477 harbor-offline-installer-v1.2.0.tgz"

Pour pouvoir le comparer sous Linux avec md5sum, on doit recréer un fichier correct avec la commande suivante :

file="harbor-offline-installer-v1.2.0"
md5sum -c <(echo $(<${file}.md5.txt) ${file}.tgz)
harbor-offline-installer-v1.2.0.tgz: Réussi

Source : Most practical way to compare MD5 checksums sur StackExchange

Installation des prérequis

La documentation d’installation officielle nous indique les dépendances suivantes :

python 2.7+
docker 1.10+
docker-compose 1.6+

Depuis un serveur qui a accès à Internet, on va donc récupérer les sources de Docker compose

curl -L https://github.com/docker/compose/releases/download/1.16.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

Vous ne trouvez pas que ça commence à être un peu relou toutes ces étapes ?

Vous le voyez venir ? Quoi donc ?

Et bien le playbook Ansible pardi !! Pour faciliter cette installation, j’ai écris des rôles Ansible pour automatiser ça ;-)

Pourquoi ? Parce que je kiffe Ansible.

Ansible à la rescousse

Tout est sur mon Github, sauf docker compose et l’installeur d’Harbor évidemment (que vous aurez récupéré lors des étapes précédentes)

cd /etc/ansible
git clone https://github.com/zwindler/ansible-deploy-harbor
cp /usr/local/bin/docker-compose /etc/ansible/roles/prereqs_harbor/files
cp harbor-offline-installer-v1.2.0.tgz /etc/ansible/roles/install_harbor/files

Et si vous voulez un coup d’œil rapide au fichier principal qui appelle les rôles, voici ce qu’il contient (et les variables qu’il convient de renseigner) :

cat deploy_harbor.yml
---
# Playbook pour installer Harbor
- name: "Install harbor prerequisites"
hosts: zwindler_linux
vars_prompt:
- name: "db_password"
prompt: "Harbor Database Password"
default: "HarborPassword"
- name: "clair_db_password"
promt: "ClairDB password"
default: "HarborPassword"
- name: "harbor_admin_password"
promt: "Harbor Admin password"
default: "HarborPassword"
vars:
- add_notary: false
- use_https : true
- generate_ssl: true
- harbor_install_path : "/usr/local/"
roles:
- prereqs_harbor
- install_harbor

Dans le cas où l’on ne souhaite pas utiliser Notary, la configuration d’Harbor est plus simple et la configuration se fait en HTTP simple. Il est nécessaire de modifier la variable add_notary à False dans le playbook dans ce cas particulier.

Dans le cas où l’on souhaite utiliser Notary, il est obligatoire de passer en HTTPS et d’avoir un certificat. Si tel est le cas, vous l’avez compris, il faut laisser le paramètre add_notary à True ce qui permettra de gérer ce cas particulier. Pour être honnête, je n’ai pas testé la partie Notary, je ne peux donc pas certifier à 100% que cette partie fonctionne convenablement.

Enfin, le script Ansible peut générer un certificat autosigné en laissant la variable generate_ssl à True. Il est aussi possible d’en générer un à la main en suivant la documentation sur le site de Harbor. Auquel cas il ne faudra pas oublier de passer le paramètre generate_ssl à False.

Configuration

Le playbook déploie Harbor avec une authentification login/mdp stockés dans une base de données interne. Pour tester, c’est pas mal mais évidemment, dans un second temps, il sera opportun de déporter cette authentification à une source de type LDAP ou Active Directory par exemple.

La première connexion se fait donc avec le login admin et le mot de passe tel que défini lors du déploiement du playbook.

Une fois connecté, le portail permet d’explorer les projets et de réaliser les configurations complémentaires, telle que la création d’utilisateurs (si on est en mode de stockage « base de données »), la gestion des habilitations, ou la réplication des registries entre elles.

Configurer un client

Comme le playbook est très bien fait (enfin normalement, hahaha), tout s’est bien passé et on peut maintenant configurer son poste client pour qu’il s’authentifie sur la Registry et commence à pousser/tirer des images Docker.

Si vous êtes en HTTPS, vous aurez besoin sur le poste client du CA autosigné généré lors du déploiement d’Harbor, car la registry est du coup sécurisée. Il devrait être disponible dans /etc/ssl/ca/ et dans /etc/docker/certs.d/[hostname_de_la_registry]/ et doit être déposé dans /etc/docker/certs.d/ du client depuis lequel on souhaite se connecter :

scp /etc/docker/certs.d/ca.crt [machine_cliente]:/etc/docker/certs.d/[hostname_de_la_registry]/

Une fois fait, on peut tenter de se connecter sur la registry avec la commande suivante :

REGISTRY=[hostname_de_la_registry]
docker login https://$REGISTRY
Username: admin
Password:
Login Succeeded

Tadam !

Et la suite ?

Et ben c’est déjà pas mal pour un premier article sur Harbor, non ? Vous venez, sans effort, de déployer une registry privée d’entreprise pour vos images Docker ;-)

Mais comme vous l’avez sûrement vu dans le titre, ce n’est que la partie 1. J’ai encore plein de choses à vous raconter sur Harbor. La suite au prochain épisode !