Skip to main content

Déploiement

ArgoCD installation app-of-apps​

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

GitLab

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

Architecture DevOps Bedigital​

.
├── argocd-definitions/
│   ├── .argocd-source-maisondubonze-38xknku2.yaml
│   └── .argocd-source-autre-application.yaml
│
└── application-manifests/
    ├── maisondubonze-38xknku2/
    │   ├── values.yaml
    │   └── secret.yaml
    │
    └── autre-application/
        ├── values.yaml
        └── secret.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 BeDigital custom​

1. Repo git projet custom​

Les projets custom doivent être créé dans le git olicy/bedigital-projects et porter le nom du projet sans le préfix bd- et sans id (ex: maisondubonze)

2. Créé un utilisateur AWS IAM​

Sur le compte AWS Olicy dans AWS IAM

STAGING !

ajouter le suffix -staging pour une instance de recette (ex : maisondubonze-38xknku2-staging)

PROD et STAGING​

  • préfixé l'utiliisateur bd- (ex: bd-hubscrm-jsaf3545)
  • ajouter l'utilisateur dans le groupe BeDigitalProd
  • ajouter un tag (Balise) à l'utilisateur, ajouter le tag username avec en valeur le nom de l'utilisateur sans le préfix bd- (ex : hubscrm-jsaf3545 )

Tag username

info

La PROD et la STAGING utilise le même bucket S3

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

Pour une STAGING .argocd-source-<nomprojet-id-staging>.yaml

1. Application Argo CD​

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: <nomprojet-id>
  namespace: nexylan-argocd
spec:
  project: bedigital

  # --- CONFIGURATION MULTI-SOURCE ---
  sources:
    # Source n°1 : Le chart Helm depuis le registre de packages GitLab
    - repoURL: https://gitlab.com/api/v4/projects/61954451/packages/helm/stable
      chart: bedigital
      targetRevision: "^2.0.0"
      helm:
        # Fait référence au fichier values.yaml d'une autre source via 'ref'
        valueFiles:
          - $values/application-manifests/<nomprojet-id>/values.yaml

    # Source n°2 : Les fichiers de valeurs depuis le dépôt Git
    - repoURL: https://gitlab.com/olicy/bedigital/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/bedigital/infra/applications.git
      targetRevision: main
      path: application-manifests/<nomprojet-id>
      # 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: bedigital-app
  
  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-**staging**-bedigital -n bedigital-app --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/bedigital/infra/applications/dzdzdz-dzdzdzd/

3. Values de l'application​

Exemple de values.yaml

image:
  repository: registry.gitlab.com/olicy/bedigital-projects/maisondubonze
  tag: v0.2.13
ingress:
  enabled: true
  class: nginx
resources:
  php:
    requests:
      memory: "256Mi"
      cpu: "250m"
  worker:
    requests:
      memory: "256Mi"
    limits:
      memory: "512Mi"

5. Déployement CI/CD automatique n8n​

Sur la plateforme n8n https://workflow.olicy.fr/, copier le worflow de TEMPLATE BeDigital afin de mettre en place le déploiement continue. n8n va détecter une nouvelle pipeline et commit le nouveau tag de l'application dans le values.yaml dans le repo DevOps.

Configuration​

Changer les valeurs des nodes Git en fonction du projet.

n8n node

n8n

2. Nouvelle instance BeDigital standard​

Sans repo git custom, il utilise BeCore

1. Créé un utilisateur AWS IAM​

Sur le compte AWS Olicy dans AWS IAM

STAGING !

ajouter le suffix -staging pour une instance de recette (ex : maisondubonze-38xknku2-staging)

PROD et STAGING​

  • préfixé l'utiliisateur bd- (ex: bd-hubscrm-jsaf3545)
  • ajouter l'utilisateur dans le groupe BeDigitalProd
  • ajouter un tag (Balise) à l'utilisateur, ajouter le tag username avec en valeur le nom de l'utilisateur sans le préfix bd- (ex : hubscrm-jsaf3545 )

Tag username

info

La PROD et la STAGING utilise le même bucket S3

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

Pour une STAGING .argocd-source-<nomprojet-id-staging>.yaml

1. Application Argo CD​

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: <nomprojet-id>
  namespace: nexylan-argocd
spec:
  project: bedigital

  # --- CONFIGURATION MULTI-SOURCE ---
  sources:
    # Source n°1 : Le chart Helm depuis le registre de packages GitLab
    - repoURL: https://gitlab.com/api/v4/projects/61954451/packages/helm/stable
      chart: bedigital
      targetRevision: "^2.0.0"
      helm:
        # Fait référence au fichier values.yaml d'une autre source via 'ref'
        valueFiles:
          - $values/application-manifests/<nomprojet-id>/values.yaml

    # Source n°2 : Les fichiers de valeurs depuis le dépôt Git
    - repoURL: https://gitlab.com/olicy/bedigital/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/bedigital/infra/applications.git
      targetRevision: main
      path: application-manifests/<nomprojet-id>
      # 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: bedigital-app
  
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2. Secret application​

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

Usage de base avec YAML

  1. Créez un secret Kubernetes non chiffré localement en YAML, par exemple :
kubectl create secret generic projets-xxxx-**staging**-bedigital -n bedigital-app --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. Utilisez kubeseal pour chiffrer ce secret en un SealedSecret au format YAML :
kubeseal --controller-name=sealed-secrets --controller-namespace=kube-system -f secrets.yaml -o 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 code secret dans https://gitlab.com/olicy/bedigital/infra/applications/nomprojet-id

3. Values de l'application​

Exemple de values.yaml

ingress:
  enabled: true
  class: nginx
resources:
  php:
    requests:
      memory: "256Mi"
      cpu: "250m"
  worker:
    requests:
      memory: "256Mi"
    limits:
      memory: "512Mi"

5. Déployement CI/CD automatique n8n​

Sur la plateforme n8n https://workflow.olicy.fr/, copier le worflow de TEMPLATE BeDigital afin de mettre en place le déploiement continue. n8n va détecter une nouvelle pipeline et commit le nouveau tag de l'application dans le values.yaml dans le repo DevOps.

Configuration​

Changer les valeurs des nodes Git en fonction du projet.

n8n node

n8n

3. Mise à jour d'une instance​

Pour mettre à jour une application il faut créer un tag de l'application, n8n va détecter une nouvelle pipeline et commit le nouveau tag de l'application dans le values.yaml dans le repo DevOps.

Voir la documentation

4. Pipeline CI/CD​

CI

1. Quel est l'objectif ?​

Ce pipeline automatise la création et la publication d'images Docker pour l'application BeDigital Custom.

Il est conçu pour être efficace : il évite de reconstruire une image pour une version de production si une version "Release Candidate" (RC) correspondante existe déjà.

2. Comment ça marche ?​

Le pipeline fonctionne selon deux scénarios principaux, en fonction du nom du tag Git que vous poussez.

Scénario 1 : Vous publiez une version de test (un tag "RC")​

Exemple de tag : v1.2.0-rc.1

  1. Build complet : Le pipeline installe les dépendances (composer install et npm install).
  2. Compilation : Il compile les fichiers front-end (npm run build).
  3. Packaging : Il crée une nouvelle image Docker et la tague avec la version RC (ex: be-digital:v1.2.0-rc.1).
  4. Publication : Il pousse cette nouvelle image sur le registre Docker.
Scénario 2 : Vous publiez une version finale (un tag de "Production")​

Exemple de tag : v1.2.0

  1. Vérification : Le pipeline cherche d'abord s'il existe déjà un tag RC pour cette version (ex: v1.2.0-rc.1).

  2. Deux cas possibles :

    • A) Oui, une RC existe :

      • Le pipeline saute les étapes de build et de compilation. C'est plus rapide !
      • Il récupère l'image Docker de la RC.
      • Il lui ajoute simplement les tags de production : be-digital:v1.2.0 et be-digital:latest.
      • Il publie ces nouveaux tags. On appelle ça une promotion.

    • B) Non, aucune RC n'existe :

      • Le pipeline exécute un build complet, exactement comme pour une RC.
      • Il crée une nouvelle image et la publie avec les tags be-digital:v1.2.0 et be-digital:latest.

3. Résumé des Étapes​

  1. prepare : Décide si un build est nécessaire (uniquement pour les tags de production).
  2. run : Installe les dépendances (si nécessaire).
  3. build : Compile les assets (si nécessaire).
  4. package : Crée l'image Docker (pour les RCs) ou promeut/crée l'image (pour la production).

Schéma image Docker​

Schéma image Docker