L'un des grands avantages de la compréhension du fonctionnement de l'écosystème des conteneurs est que vous pouvez utiliser le même modèle pour plusieurs spécifications.
Il n'y a pas longtemps, Helm a annoncé qu'il prendrait en charge les artefacts OCI, qui ne sont rien de plus qu'une spécification ouverte OCI pour la distribution d'images de conteneurs et d'autres types de données, appelés artefacts.
Cette spécification, comme toutes les autres spécifications OCI, est indépendante du cloud, ce qui en fait un outil fantastique avec lequel travailler.
Enregistrements de conteneur
Un enregistrement de conteneur (CR), ou un registre, est quelque chose que tous ceux qui ont déjà eu à s'occuper de conteneurs ont dû utiliser. Le CR est l'endroit où nous stockons nos images de conteneurs, afin que nous puissions les récupérer de n'importe où et quand nous le voulons.
Essentiellement, une image est essentiellement un ensemble de fichiers qui suit une structure plus ou moins comme celle-ci :
├── blobs
│ └── sha256
│ ├── 1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db3...
│ ├── 31fb454efb3c69fafe53672598006790122269a1b3b458607dbe106...
│ └── 8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690f...
├── index.json
└── oci-layout
Le fichier index.json est la liste de tous les manifestes disponibles, c'est-à-dire qu'il s'agit de la liste de toutes les images disponibles dans un emplacement. Dans notre cas, il s'agit d'une liste de tous les graphiques de barre.
Chaque fichier à l'intérieur de blobs/sha256 est un JSON qui identifie un artefact, qu'il s'agisse d'une image ou d'un graphique. Ce JSON est conforme à la spécification OCI pour les fichiers SHA.
En bref, il s'agit d'une liste de paramètres décrivant les caractéristiques du blob, ses paramètres, ses propriétés, les couches du système de fichiers, ainsi que les commandes initiales.
Dans le cas d'un Helm Chart, nous avons le fichier suivant :
{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.cncf.helm.config.v1+json",
"digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111",
"size": 117
},
"layers": [
{
"mediaType": "application/tar+gzip",
"digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617",
"size": 2487
}
]
}
Notez que nous avons une différenciation de mediaType , alors qu'une image Docker commune a un type application/vnd.oci.image.config.v1+json .
Ici, nous avons un type application/vnd.cncf.helm.config , idem pour les calques, chaque calque d'une image OCI est de type application/vnd.oci.image.layer.v1.tar+gzip , alors qu'ici nous n'avons que le format .tar.gz .
Hébergement de graphiques dans Azure Container Registry
L'hébergement de graphiques Helm sur Azure CR est assez similaire à leur stockage local. Vous devez avoir accès à Azure via Azure CLI. Je suppose que vous avez déjà Azure CLI, alors créons notre ACR.
Nous devons d'abord créer notre groupe de ressources puis l'ACR avec les commandes :
az group create -n helm-reg -l eastus
az acr create -n chartregistry$RANDOM -g helm-reg --sku Basic -o tsv --query loginServerUne astuce consiste à stocker le nom du dépôt dans une variable :
export ACR=$(az acr create -n chartregistry$RANDOM -g helm-reg --sku Basic -o tsv --query loginServer)
Nous allons maintenant nous connecter à notre registre à l'aide de clés gérées par Azure, mais nous devons activer le contrôle administratif avec az acr update -n $ACR --admin-enabled true .
Ensuite, exécutez les deux commandes suivantes pour récupérer les identifiants de connexion et les enregistrer dans le shell :
export ACRUSER=$(az acr credential show -n $ACR --query username -o tsv)
export ACRPASS=$(az acr credential show -n $ACR --query 'passwords[0].value' -o tsv)
Nous pouvons maintenant nous connecter à notre registre avec Helm en utilisant helm registry login $ACR --username $ACRUSER --password $ACRPASS , et à partir de là, notre registre est déjà configuré.
Créons un autre artefact avec helm chart save hrepo $ACR/hrepo:2.1.3 (à titre d'exemple, j'utiliserai un graphique provenant d'un référentiel vide nommé hrepo). Ensuite, nous le pousserons avec helm chart push $ACR/hrepo:3.8.0 .
Une fois qu'il sera là, nous pourrons tout lister dans le référentiel avec une commande Azure CLI :
az acr repository show -n $ACR --repository hrepo
Notez que nous allons avoir une sortie qui correspond exactement à ce que nous avons envoyé :
{
"changeableAttributes": {
"deleteEnabled": true,
"listEnabled": true,
"readEnabled": true,
"writeEnabled": true
},
"createdTime": "2022-03-05T20:56:49.6118202Z",
"imageName": "hrepo",
"lastUpdateTime": "2022-03-05T20:56:49.7812323Z",
"manifestCount": 1,
"registry": "chartregistry23657.azurecr.io",
"tagCount": 1
}
On peut aussi obtenir plus de détails avec la commande show-manifests en ajoutant un --detail :
az acr repository show-manifests -n $ACR --repository hrepo --detail
Cela nous donnera exactement la définition d'un artefact OCI :
[
{
"changeableAttributes": {
"deleteEnabled": true,
"listEnabled": true,
"quarantineState": "Passed",
"readEnabled": true,
"writeEnabled": true
},
"configMediaType": "application/vnd.cncf.helm.config.v1+json",
"createdTime": "2022-03-05T20:56:49.7213057Z",
"digest": "sha256:4780713fa23d7144d356c353795b5b84e66ad2b8bbd47c7118b4b85435d50bbc",
"imageSize": 1378,
"lastUpdateTime": "2022-03-05T20:56:49.7213057Z",
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"tags": [
"2.1.3"
]
}
]
Pour le stocker, nous devons simplement :
helm chart pull $ACR/hrepo:3.8.0
helm chart export $ACR/hrepo:3.8.0 -d ./destination
helm install hrepo-acr ./destinationConclusion
Bien que l'utilisation de Helm soit facile, il n'existe pas de moyen "simple" d'héberger un graphique Helm comme une sorte d'enregistrement privé.
Bien que Helm dispose d'excellents outils comme le Chart Museum, ils ne sont toujours pas complètement standard et pour un développement distribué facile, il est essentiel que nous disposions de normes ouvertes que tout le monde peut suivre dans son ensemble.
Helm a récemment fait passer la prise en charge du registre OCI d'une fonctionnalité expérimentale à une fonctionnalité générale, ce qui indique clairement que l'écosystème des conteneurs s'améliore de plus en plus.
Informations sur l'auteur :Talha Khalid est développeur Web indépendant et rédacteur technique.