Skip to main content

Déploiement

ArgoCD installation app-of-apps​

Mettre en place la igor-app-of-apps dans argocd, appliquer le fichier root-app.yaml du repo

GitLab

https://gitlab.com/olicy/igor/infra/applications

Architecture DevOps IGOR​

.
├── argocd-definitions/
│   ├── .argocd-source-geiq-laon-zd20hafy.yaml
│   └── .argocd-source-ge-epe-sivzrgob.yaml
│
└── application-manifests/
    ├── geiq-laon-zd20hafy/
    │   ├── values.yaml
    │   └── sealedsecret.yaml
    │
    └── ge-epe-sivzrgob/
        ├── values.yaml
        └── sealedsecret.yaml

Explication de cette structure :

  • argocd-definitions/ : Ce dossier contient uniquement les fichiers qui définissent vos Application Argo CD. C'est la "configuration pour Argo CD". C'est dans ce dossier que vous créerez tous vos fichiers .argocd-source-*.yaml.

  • application-manifests/ : Ce dossier contient la configuration spécifique à chaque application :

    • values.yaml pour le chart Helm.
    • secret.yaml et tout autre manifeste Kubernetes brut que vous souhaitez appliquer en plus du chart Helm.

1. Nouvelle instance IGOR custom​

1. Repo Git​

GitLab

https://gitlab.com/olicy/igor/igor

2. Créé un utilisateur AWS IAM​

Sur le compte AWS Olicy dans AWS IAM

PROD et REC​

PROD​
  • préfixé l'utiliisateur igor- (ex: igor-ge-epe-sivzrgob)
  • ajouter l'utilisateur dans le groupe IgorProd
  • ajouter un tag (Balise) à l'utilisateur, ajouter le tag username avec en valeur le nom de l'utilisateur sans le préfix igor- (ex : ge-epe-sivzrgob )
  • Bucket S3 igor-media-prod
REC​
  • préfixé l'utiliisateur igor- (ex: igor-ge-epe-sivzrgob)
  • ajouter l'utilisateur dans le groupe IgorRec
  • ajouter un tag (Balise) à l'utilisateur, ajouter le tag username avec en valeur le nom de l'utilisateur sans le préfix igor- (ex : rec2-sivzrgob )
  • Bucket S3 igor-media-rec

Tag username

3. DevOps définition​

La définition de l'application doit être dans le dossier /argocd-definitions/<projet>,

La définition de l'Application Argo CD dans le dossier /application-manifests et créé le fichier .argocd-source-<nomprojet-id>.yaml

1. Application Argo CD​

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: geiq-laon-zd20hafy
  namespace: nexylan-argocd
  annotations:
spec:
  project: igor

  # --- CONFIGURATION MULTI-SOURCE ---
  sources:
    # Source n°1 : Le chart Helm depuis le registre de packages GitLab
    - repoURL: https://gitlab.com/api/v4/projects/67043871/packages/helm/stable
      chart: igor
      targetRevision: "*.*.*"
      helm:
        # Fait référence au fichier values.yaml d'une autre source via 'ref'
        valueFiles:
          - $values/application-manifests/geiq-laon-zd20hafy/values.yaml

    # Source n°2 : Les fichiers de valeurs depuis le dépôt Git
    - repoURL: https://gitlab.com/olicy/igor/infra/applications.git
      targetRevision: main
      # On donne une référence à cette source pour que la source n°1 puisse l'utiliser
      ref: values

    # Source n°3 : Uniquement le secret.yaml et autres manifestes bruts
    - repoURL: https://gitlab.com/olicy/igor/infra/applications.git
      targetRevision: main
      path: application-manifests/geiq-laon-zd20hafy
      # On exclut le values.yaml pour ne pas l'appliquer deux fois
      directory:
        exclude: '{values.yaml,Chart.yaml,templates/}'

  destination:
    server: https://kubernetes.default.svc
    namespace: igor
  
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2. Secret application​

Créer le Secret à partir du serveur nc3413 pour chiffrer les secrets avec kubeseal

  1. Créez un secret Kubernetes SealedSecret en YAML, par exemple :
kubectl create secret generic projets-xxxx-igor -n igor --dry-run=client --from-literal=APP_KEY="base64:vfb6VQXZT5Bqm35PSdf7LJuO3lhbHfO2iE4eoBioMKo=" --from-literal=DB_HOST="185.x.x.x" --from-literal=DB_DATABASE="bd-projets-xxxx-stg-0bxl99js_prod" --from-literal=DB_USERNAME="bd-projets-xxxx-stg-0bxl99js_prod_user" --from-literal=DB_PASSWORD="xxxxxXXXxx" --from-literal=AWS_ACCESS_KEY_ID="AKIAXXXXX" --from-literal=AWS_SECRET_ACCESS_KEY=xxxxxxx -o yaml | kubeseal --controller-name=sealed-secrets --controller-namespace=kube-system --format yaml > sealedsecret.yaml
  1. Le fichier sealedsecret.yaml chiffré peut être stocké en toute sécurité, par exemple dans un dépôt Git, et partagé sans risque.
  2. Le contrôleur SealedSecrets dans le cluster déchiffrera le secret et créera un Secret Kubernetes déchiffré classique.

Push le fichier sealedsecret.yaml dans https://gitlab.com/olicy/igor/infra/applications/dzdzdz-dzdzdzd/

3. Values de l'application​

Exemple de values.yaml

ingress:
  enabled: false
  class: nginx
  custom:
    enabled: true
    hosts:
      - host: geiq-laon.igor-pro.app
image:
  tag: "2.3.18"
resources:
  php:
    requests:
      memory: "512Mi"
      cpu: "250m"

2. Mise à jour d'une instance​

Pour mettre à jour une application il faut modifier manuellement le fichier values.yaml de l'application dans le dossier /argocd-definitions/<projet> du repo DevOps et changer le tag.

Exemple :

image:
  tag: "2.3.18"

3. Pipeline CI/CD​

Variables globales​

  • Configuration pour Docker-in-Docker.
  • APP_NAME = nom de l'application backend.
  • DOCKER_TLS_CERTDIR: "" est requis pour éviter les erreurs de connexion Docker.

Stages​

  1. run : installation des dépendances.
  2. build : build du front.
  3. package : build + push des images Docker.

Docker-in-Docker​

  • Image principale : docker:dind.
  • Service : docker:dind sans TLS.
  • Permet l'exécution de docker build et docker push dans les jobs.

Backend (PHP)​

1. app:composer (run)​

  • Installe les dépendances PHP.
  • Met en cache vendor/.
  • Exécuté uniquement sur les tags.

2. app:package (run)​

  • Récupère le cache Composer.
  • Se connecte au registry Docker.
  • Build l’image backend via .docker/php.Dockerfile.
  • Tags créés :
    • app:<tag>
    • app:latest
  • Push des images.
  • Exécuté uniquement sur les tags.

Frontend (Node)​

1. front:assemble (run)​

  • npm install.
  • Cache de node_modules/.
  • Exécuté uniquement sur les tags.

2. front:build (build)​

  • Dépend de front:assemble.
  • npm run production.
  • Génère les assets dans public/ (artifacts).
  • Exécuté uniquement sur les tags.

3. front:package (package)​

  • Dépend de front:build et front:assemble.
  • Build l’image Nginx via .docker/nginx.Dockerfile.
  • Tags créés :
    • http:<tag>
    • http:latest
  • Push des images.
  • Exécuté uniquement sur les tags.

Résultat final​

Lors de chaque tag :

  • Build + push du backend Docker :
    registry/app:<tag> et app:latest
  • Build + push du frontend Docker :
    registry/http:<tag> et http:latest
  • Pipeline complet uniquement sur les tags.

Schéma image Docker​

Schéma image Docker