Una de las grandes ventajas de entender cómo funciona el ecosistema de contenedores es que puedes usar el mismo patrón para varias especificaciones.
No ha pasado mucho tiempo desde que Helm anunció que admitiría OCI Artifacts, que no son más que una especificación abierta de OCI para distribuir imágenes de contenedores y otros tipos de datos, llamados artefactos.
Esta especificación, como todas las demás especificaciones de OCI, es independiente de la nube, lo que la convierte en una herramienta fantástica para trabajar.
Registros de contenedores
Un registro de contenedor (CR), o un registro, es algo que todos los que alguna vez han tenido que estar involucrados con contenedores han tenido que usar. El CR es donde almacenamos las imágenes de nuestro contenedor, por lo que podemos obtenerlas desde cualquier lugar y cuando queramos.
En esencia, una imagen es básicamente un conjunto de archivos que sigue una estructura más o menos como esta:
├── blobs
│ └── sha256
│ ├── 1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db3...
│ ├── 31fb454efb3c69fafe53672598006790122269a1b3b458607dbe106...
│ └── 8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690f...
├── index.json
└── oci-layout
El archivo index.json es la lista de todos los manifiestos disponibles, es decir, es la lista de todas las imágenes disponibles en una ubicación. En nuestro caso, es una lista de todos los gráficos de timón.
Cada archivo dentro de blobs/sha256 es un JSON que identifica un artefacto, ya sea una imagen o un gráfico. Este JSON cumple con la especificación OCI para archivos SHA.
En resumen, son una lista de configuraciones que describen las características del blob, su configuración, propiedades, capas del sistema de archivos y también los comandos iniciales.
En el caso de un Helm Chart, tenemos el siguiente archivo:
{
"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
}
]
}
Observe que tenemos una diferenciación de mediaType , mientras que una imagen común de Docker tiene un tipo application/vnd.oci.image.config.v1+json .
Aquí, tenemos un tipo application/vnd.cncf.helm.config , lo mismo ocurre con las capas, cada capa de una imagen OCI es de tipo application/vnd.oci.image.layer.v1.tar+gzip , mientras que aquí solo tenemos el formato .tar.gz .
Hospedaje de gráficos en Azure Container Registry
Hospedar gráficos de Helm en Azure CR es bastante similar a almacenarlos localmente. Debe tener acceso a Azure a través de la CLI de Azure. Asumiré que ya tiene la CLI de Azure, así que creemos nuestro ACR.
Primero tenemos que crear nuestro grupo de recursos y luego el ACR con los comandos:
az group create -n helm-reg -l eastus
az acr create -n chartregistry$RANDOM -g helm-reg --sku Basic -o tsv --query loginServerUn consejo es almacenar el nombre del repositorio en una variable:
export ACR=$(az acr create -n chartregistry$RANDOM -g helm-reg --sku Basic -o tsv --query loginServer)
Ahora vamos a iniciar sesión en nuestro registro con claves administradas de Azure, pero debemos habilitar el control administrativo con az acr update -n $ACR --admin-enabled true .
A continuación, ejecute los siguientes dos comandos para obtener las credenciales de inicio de sesión y guardarlas en el 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)
Ahora podemos iniciar sesión en nuestro registro con Helm usando helm registry login $ACR --username $ACRUSER --password $ACRPASS , y a partir de aquí ya tenemos nuestro registro configurado.
Vamos a crear otro artefacto con helm chart save hrepo $ACR/hrepo:2.1.3 (como ejemplo, usaré un gráfico de un depósito voluminoso llamado hrepo). Luego lo empujaremos con helm chart push $ACR/hrepo:3.8.0 .
Una vez que esté allí, podremos enumerar todo en el repositorio con un comando de la CLI de Azure:
az acr repository show -n $ACR --repository hrepo
Note que vamos a tener una salida que es exactamente lo que enviamos:
{
"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
}
También podemos obtener más detalles con el comando show-manifests agregando un --detail :
az acr repository show-manifests -n $ACR --repository hrepo --detail
Esto nos dará exactamente la definición de un artefacto 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"
]
}
]
Para almacenarlo, simplemente tenemos que:
helm chart pull $ACR/hrepo:3.8.0
helm chart export $ACR/hrepo:3.8.0 -d ./destination
helm install hrepo-acr ./destinationConclusión
Aunque usar Helm es fácil, no existe una forma "simple" de alojar un gráfico de Helm como una especie de registro privado.
Si bien Helm tiene excelentes herramientas como Chart Museum, todavía no son completamente estándar y para un desarrollo distribuido fácil es esencial que tengamos estándares abiertos que todos puedan seguir.
Helm ha cambiado recientemente la compatibilidad con OCI Registry de una característica experimental a una característica general, lo que es un fuerte indicio de que el ecosistema de contenedores está mejorando cada vez más.
Información del autor:Talha Khalid es desarrolladora web independiente y escritora técnica.