Déployer un projet

Principe

Le déploiement sur votre environnement de développement se fait via l'outil Helm

Lors de la création de votre groupe, 4 pré-requis vous seront fourni :

  • un projet Deploiement initialisé avec un projet exemple
  • un projet Cluster agent vous permettant de déployer (à ne pas modifier)
  • un namespace dédié dans l'environnement de développement de l'usine logicielle
  • Un Tableau de bord pour votre environnement

Le projet de déploiement

Par défaut, le projet Déploiement vous permettra de déployer un projet exemple respectant le squelette suivant :

  • Un chart parent ne contenant que des dépendences vers les charts des services à déployer
  • Un chart enfant (subchart)

Le chart contenu dans ce projet servira également à déployer les environnements de qualification/préproduction et production. Il sera défini en collabaration avec le gestionnaire de l'usine logicielle.

Limitation de l'environnement de développement

L'environnement de développement ne possède pas de service managés. Si vous avez besoin de service "externes" comme du stockage ou base de donnée, il vous faudra ajouter les dépendances adéquates.

Des exemples de services externes recommandés sont indiqué dans la rubrique Support -> Charts Helm

Deployer mon environnement

Par défaut, le déploiement se fait par un déclenchement de la CI/CD de votre projet déploiement :

  • Dans le menu gauche de gitlab : CI/CD -> pipeline
  • Cliquer sur "Run pipeline"
  • Choisir la branche "main" et valider

Gérer mon environnement

Pour visualiser votre environnement, un tableau de bord vous est mis à disposition. Depuis ce tableau de bord, vous pourrez :

  • visualiser le contenu de votre environnement
  • accéder aux logs des pods
  • accéder via terminal à l'intérieur d'un pod

Détruire mon environnement

La destruction d'un environnement peut se faire :

  • Directement via l'interface :
  • Menu Gauche -> Deployments -> Environnements
  • Cliquer sur "Stop" -> déclenche un job spécial sur la pipeline qui supprimera le job
  • Par déclenchement du job adéquat :
  • Menu Gauche -> Ci/CD -> pipeline
  • Cliquer sur la puce "Stages"
  • Cliquer sur le bouton ">" du job stop_review

Ecrire un sous-chart

Où commencer ?

Si vous avez l'outil "Helm" sur votre poste, il suffit de faire :

helm create <nom du chart>

Sinon, vous pouvez partir d'un projet existant.

Arborescence type

 | charts/ -> contient les éventuels sous-charts
 | templates -> contient les templates de déploiement
    | _helpers.tpl -> outil pour les templates
    | deployement.yaml -> template contenant les instructions de déploiement du service à proprement parlé
    | hpa.yaml -> template pour la gestion du scaling horizontal (désactivé par défaut)
    | ingress.yaml -> template pour la déclaration de l'ingress (désactivé par défaut)
    | service.yaml -> template pour la déclaration du service
  | Chart.yaml -> fichier principal.
  | values.yaml -> fichier contenant la valorisation des attendus

Autoriser l'accès aux registres

Dans le fichier values.yaml, vérifier que les lignes suivantes sont présentes :

imagePullSecrets:
  - name: regcred

Ce secret est déclaré lors du process d'enrollement

Indiquer l'image docker à utiliser

Dans le fichier values.yaml:

image:
  repository: registry.gpf-tech.ign.fr/<nom groupe>/<nom projet>
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: <tag de l'image>

Déclarer un ingress

Par convention, les noms à donner dans les ingress des services doit respecter la norme : <nom service>-<namespace>.dev.gpf-tech.ign.fr

La déclaration type d'un ingress dans le fichier values.yaml ressemble à ça :

...
ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-manager-cert
  hosts:
    - host: <nom service>-<namespace>.dev.gpf-tech.ign.fr
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: <nom service>-<namespace>-tls
      hosts:
        - <nom service>-<namespace>.dev.gpf-tech.ign.fr
...

Déclarer un service

La déclaration type d'un service dans le fichier values.yaml ressemble à ça :

...
service:
  type: ClusterIP
  port: 80 -> port d'accès au conteneur. Le mapping port accès <-> port conteneur est dans le template "deployment.yaml"
...

Ajouter des variables d'environnement au conteneur

Dans le fichier deployment.yaml, ajouter le code suivant :

  ...
  containers:
    - name: {{ .Chart.Name }}
      ...
      env:
      {{- if .Values.serverEnvs }}
        {{- .Values.serverEnvs | toYaml | nindent 12 }}
      {{- end }}

Puis dans le fichier values.yaml :

...
# Variable d'environnement pour le serveur
serverEnvs:
  - name: VALUE_1
    value: value1
  ...
  - name : VALUE_N
    value: valueN