Historial de página
Contenido
| Tabla de contenidos | ||||||
|---|---|---|---|---|---|---|
|
Resumen
| Sugerencia |
|---|
|
Cumplimiento normativo
| Advertencia | ||
|---|---|---|
| ||
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC. La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabeceras de la tablas dónde se indican las fechas de entrada en vigor y versión.
| Expandir | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
| ||||||||||||||||||
1. Introducción
1.1 ¿Qué es Helm?
Helm es un gestor de paquetes basado en plantillas para Kubernetes y su principal función es definir, instalar y actualizar aplicaciones complejas de Kubernetes
1.2 ¿Qué nos aporta HELM?
- Sencillez: El procedmiento de instalación se simplifica, quedando en la ejecución de un comando "helm install".
- Versionado: En el desarrollo permite realizar iteraciones rápidas sobre cambios estructurales, añadir o quitar tipos de bases de datos, caches, servicios extra, configuraciones, etc...
- Pilotable: Como esta basado en plantillas, se puede personalizar y configurar para que la instalación tenga comportamientos diferentes según entorno.
- Homegeneización: Permite tener una forma unificada de instalación en el SAS, simplificando las instalaciones al equipo de Sistemas y replicación en los entornos de desarrollo.
- Simplicidad: La gestión de actualización, rollback y configuración se simplifica.
- Heterogeneidad: Permite realizar el despliegue en cualquier cluster de kubernetes sin tener que modificar la plantilla.
2. Instalación
Helm 3 es un cliente local, por lo que no será necesario realizar ninguna instalación en el cluster de destino, simplemente tendremos que descargar a local el CLI de Helm y cumplir una serie de requisitos.
2.1 Requisitos previos
- Acceso a un Cluster de Kubernetes de desarrollo
- Cli de HELM en local
- kubectl en local
2.2 Instalación local
La mejor forma de realizar la instalación es seguir la documentación oficial: https://helm.sh/es/docs/intro/install/
4. Consejos y recomendaciones
4.1 Crear dependencia entre configMap y deployment
Helm detecta los cambios en los recursos que han cambiado y redespliega solo los necesarios. Pero por defecto no detecta si ha cambiado la configuracion de un recurso que este en un configMap o una secret.
Para que Helm entienda que tiene que realizar un redespliegue de un recurso que depende de otro, lo mas facil es incluir una anotacion que apunte al hash de el fichero del que depende.
Por ejemplo:
| Bloque de código | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
kind: Deployment
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
... |
En este ejemplo de Deployment, estamos incluyendo una nueva anotación que contiene el checksum o hash del fichero del que depende este deployment, de esta manera cada vez que la configuración cambien, la anotación también, y esto provocara que Helm detecte el cambio del deployment y lo redespliegue.
5. Recursos adicionales
En el SAS disponemos de una pequeña colección de recursos útiles para el desarrollo.
5.1 Plantilla básica de Ejemplo
Se ha creado una plantilla sencilla para los proyectos que no tengan mucha complejidad en sus servicios, donde con mínimas adaptaciones y configuración se podría tener lista para entregar.
La plantilla esta alojada en el repositorio de código del SAS: http://git.sas.junta-andalucia.es/gobernanza/ArchivosDeDesarrollo/basic-helm
Si no se tuvieran permisos para acceder, solicitar a la OCA que incluyan a vuestro usuario en el grupo "team-publico" de Gitlab
En el Readme.md de este repositorio se amplia la documentación de como debe de ser usuada.
Terminología
- Release: Una [Release] es una instancia de un Chart que se ejecuta en un clúster de Kubernetes. A menudo, un Chart se puede instalar muchas veces en el mismo clúster. Y cada vez que se instala, se crea un nuevo release. Considere un Chart MySQL. Si desea que se ejecuten dos bases de datos en su clúster, puede instalar ese Chart dos veces. Cada uno tendrá su propio release, que a su vez tendrá su propio nombre de release.
- Chart: La plantilla Helm es el conjunto especifico de plantillas y otros recursos que se usa para instalar el producto.
Referencias
| Info | ||
|---|---|---|
| ||
En esta sección se presentará un listado de bibliografia o documentos externos que sean de ayuda para la compresión de la normativa expuesta. Si no se expone información en esta sección eliminese. Esta nota informativa debe ser eliminada en el documento normativo definitivo. |
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2