Skip to main content

Helm Charts

Déploiement​

La définition de l'application doit être dans le git https://gitlab.com/olicy/bedigital/infra/applications

Voir documentation

Values​

Configuration du chart Helm — values.yaml​

1. Réplicas​

CléDescriptionValeur
replicaCountNombre de pods déployés1

2. Image​

CléDescriptionValeur
image.repositoryRepository de l’imageregistry.gitlab.com/olicy/igor/igor/
image.pullPolicyPolitique de récupérationIfNotPresent
image.tagTag de l’image2.3.8.1-1

3. Application​

CléDescriptionValeur
app.nameNom de l’applicationIgor
app.mail.from_nameNom utilisé pour l’envoi d'emailsIgor
app.session.driverDriver de sessiondatabase
app.session.lifetimeDurée de session (minutes)10080
app.queue_connectionMode queuesync
app.worker.enabledActivation du workertrue

4. Paramètres PHP​

CléDescriptionValeur
php.memoryMémoire PHP512M
php.uploadTaille max upload50M

5. Gotenberg​

CléDescriptionValeur
gotenberg.urlURL du service Gotenberghttp://igor-gotenberg.igor.svc.cluster.local:3000

6. Environnement​

CléDescriptionValeur
env.appEnvironnement applicatifproduction

7. Secrets & Overrides​

CléDescriptionValeur
imagePullSecretsSecret d’accès registregitlab-registry-igor
nameOverrideNom personnalisé""
fullnameOverrideNom complet personnalisé""

8. Sécurité Pods & Conteneurs​

CléDescriptionValeur
podSecurityContextContexte sécurité du pod{}
securityContextContexte sécurité conteneur{}

9. Service​

CléDescriptionValeur
service.typeType de serviceClusterIP
service.portPort HTTP80

10. Ingress​

Configuration principale​

CléDescriptionValeur
ingress.classClasse Ingress (Traefik)traefik
ingress.enabledActivationtrue
ingress.entryPointsEntrypoint Traefikwebsecure

TLS​

CléDescriptionValeur
ingress.tls.enabledActivation TLStrue
ingress.tls.secretNameSecret TLSwildcard-igor-cert

Ingress personnalisé​

CléDescriptionValeur
ingress.custom.enabledIngress customfalse
ingress.custom.entryPointsEntrypoint customwebsecure
ingress.custom.tls.enabledTLS customtrue

DNS​

CléDescriptionValeur
ingress.dns.ttlTTL DNS"3600"

11. Autoscaling​

CléDescriptionValeur
autoscaling.enabledActivation HPAfalse
autoscaling.minReplicasMinimum1
autoscaling.maxReplicasMaximum3
autoscaling.averageUtilizationCible CPU85

12. Cronjob​

CléDescriptionValeur
cronjob.scheduleExpression CRON"*/5 * * * *"

13. Base de données​

CléDescriptionValeur
db.portPort MySQL"3306"

14. Resources​

HTTP​

CléDescriptionValeur
resources.http.requests.memoryMemory request64Mi
resources.http.requests.cpuCPU request50m
resources.http.limits.memoryMemory limit256Mi
resources.http.limits.cpuCPU limit1

PHP​

CléDescriptionValeur
resources.php.requests.memoryMemory request128Mi
resources.php.requests.cpuCPU request50m
resources.php.limits.memoryMemory limit2048Mi
resources.php.limits.cpuCPU limit1

15. Scheduling​

CléDescriptionValeur
nodeSelectorCiblage de nœud{}
tolerationsTolerations[]
affinityAffinité pods{}

16. PodDisruptionBudget​

CléDescriptionValeur
poddisruptionbudget.enabledActivationfalse
poddisruptionbudget.minMin pods1

17. Identifiants registre​

CléDescriptionValeur
imageCredentials.registryRegistreregistry.gitlab.com
imageCredentials.usernameUsernameCommenté
imageCredentials.passwordPasswordCommenté

Pipeline et mise à jour​

1. Quel est l'objectif ?​

Ce pipeline gère un chart Helm nommé igor. Ses fonctions sont :

  1. Valider la syntaxe du chart.
  2. Mettre à jour la version du chart (manuellement ou en synchronisation avec l'application).
  3. Publier le chart dans le registre de paquets Helm de GitLab.

2. Comment ça marche ?​

Le pipeline est divisé en plusieurs étapes et s'exécute principalement sur la branche main et pour les tags Git.

Étape 1 : lint (Validation)​

  • Job : helm:lint
  • Quoi ? Ce job vérifie que la structure et la syntaxe de votre chart Helm sont correctes et ne contiennent pas d'erreurs.
  • Quand ? Automatiquement, à chaque fois qu'une modification est poussée sur la branche main.
  • Comment ? Il utilise la commande helm lint. Si une erreur est trouvée, le pipeline s'arrête.

Étape 2 : chart-versioning (Gestion des versions du Chart)​

Cette étape contient deux jobs différents pour la gestion des versions :

Job 1 : bump:version (Mise à jour Manuelle de la Version du Chart)​
  • Quoi ? Ce job vous permet d'augmenter manuellement le numéro de version du chart lui-même (ex: de 1.2.3 à 1.2.4 ou 2.0.0).
  • Quand ? Manuellement uniquement. Vous devez le déclencher depuis l'interface de GitLab.
  • Comment ?
    1. Il clone le dépôt des charts.
    2. Il lit la version actuelle du chart dans igor/Chart.yaml.
    3. Il augmente la version (par défaut, il incrémente le dernier chiffre).
    4. Il crée un commit Git avec la nouvelle version et le pousse sur la branche main.
Job 2 : update:helm-chart (Synchronisation de la Version de l'Application)​
  • Quoi ? Ce job met à jour la version de l'application que votre chart va déployer. Il synchronise l'appVersion dans Chart.yaml et l'image.tag dans values.yaml avec le tag de l'application Docker fraîchement construite (ex: v1.2.0).
  • Quand ? Automatiquement, à chaque fois qu'un tag est poussé pour l'application, après que l'image Docker de l'application a été construite et poussée.
  • Comment ?
    1. Il clone le dépôt des charts.
    2. Il met à jour les fichiers igor/values.yaml et igor/Chart.yaml pour refléter la nouvelle version de l'application.
    3. Il crée un commit avec ces modifications et le pousse sur la branche main.
    4. Il inclut une logique de re-tentative (retry) en cas d'échec de push initial.

Étape 3 : publish (Publication du Chart)​

  • Job : helm:publish
  • Quoi ? Ce job prépare et publie le chart Helm.
  • Quand ? Automatiquement, après l'étape lint (et donc après toute mise à jour de version effectuée par bump:version ou update:helm-chart), à chaque fois qu'une modification est poussée sur main.
  • Où est-il publié ? Dans le Registre de Paquets Helm du projet GitLab, accessible via "Deploy > Package Registry".
  • Comment ? Il met à jour les dépendances du chart, compresse le chart dans une archive (.tgz) et l'envoie au registre GitLab.