Contexte : Déploiement d’application & besoins des développeurs¶

Type de code¶

SI développés en interne ou par des prestataires, architecture type : multi-niveaux (front/back) avec JAVA (Springboot) et JS (VueJS), une base de données Postgres est hébergée par ailleurs et le développeur ne s’en préoccupe pas.

workspace { model { proprietaire = person "Propriétaire d'étude" "Un propriétaire d'étude ou qqn qui le représente" "Utilisateur" consommateur = person "Utilisateur" "Un utilisateur qui veut obtenir des informations sur les études" "Utilisateur" dw4System = softwareSystem "Donesolweb 4" { proxy = container "Proxy" "Gère le routage des requêtes" "Nginx" frontApplication = container "Frontend" "Application VueJS" "JS" "frontend" { technology = technology "VueJS" } frontendServer = container "Sert statiquement le code du frontend" backend = container "Backend" "Application Springboot" "Java" database = container "Base de données" "Stockage des données" "Postgres" } forge = softwareSystem "Dépôts Git (forgemia)" { frontendRepo = container "Dépôt Git Frontend" "Contient le code source VueJS" "Git" backendRepo = container "Dépôt Git Backend" "Contient le code source Springboot" "Git" infraRepo = container "Dépôt Git de l'infrastructure" "Git" } proprietaire -> dw4System "Gère les données des études de sol" consommateur -> dw4System "Récupère des données d'études de sol" // proprietaire -> proxy "va sur https://dw4.gissol.fr" "HTTPS" // consommateur -> proxy "va sur https://dw4.gissol.fr" "HTTPS" proprietaire -> frontApplication "Modifie une étude" proxy -> frontendServer "Route les requêtes vers" "/" proxy -> backend "Route les requêtes API vers" "/api/" frontApplication -> proxy "Appels API" "HTTPS/REST" backend -> database "Requêtes" "PostgreSQL" frontApplication -> frontendRepo "Versionné" "Git" backend -> backendRepo "Versionné" "Git" // Déploiement Docker dockerEnv = deploymentEnvironment "Docker" { deploymentNode "Infrastructure Docker" { deploymentNode "Conteneur Proxy" { containerInstance proxy } deploymentNode "Conteneur Frontend" { containerInstance frontendServer } deploymentNode "Conteneur Backend" { containerInstance backend } } deploymentNode "Serveur BDD" { deploymentNode "Serveur Base de Données" { containerInstance database } } } } views { systemContext dw4System systemContexte { include * autolayout lr title "Contexte DW4" } container dw4System containerView { include * autolayout title "Diagramme de Conteneurs" } deployment * dockerEnv vueDocker { include * autolayout title "Diagramme de Déploiement" } styles { element "Container" { shape roundedbox } element "Proxy" { background "LightGray" color "Gray" } element "frontend" { shape WebBrowser } element "Backend" { background "Orange" color "DarkRed" } element "Base de données" { background "Yellow" color "DarkGreen" } element "Person" { shape Person } } } } — Contexte système¶

Avec docker¶

Administration d’une VM « coquille vide » + Gestion des certificats
Dépôt « deploiement » contenant un docker-compose.yaml

version: '3.7'
services:
  reverse_proxy:
    image: haproxy:vXX
    volumes:
       - haproxy.conf:/etc/haproxy.conf # règles proxy vers back/front
       - cert.pem:/etc/ssl/certs/cert.pem #certificat ssl

    ports:
       - "443:443"
  frontend:
    image: registry.forgemia.inra.fr/monappli/front:v2023-05-14

  backend:
    image: registry.forgemia.inra.fr/monappli/back:v2023-05-14
    environment:
      - POSTGRES_SERVER=${POSTGRES_SERVER}
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

Lancement et mise à jour : docker compose up.

Remarque : les images docker sont soit directement compilées (votre DockerFile est dans le dépot contenant les règles de déploiement) soit déposées sur la forgemia. Le dépot sur la forgemia peut être manuel (docker push), ou intégré au CI avec un Dockerfile dans le dépot de votre code et un gitlabci adapté.

Avec K8S - En pratique¶

Dépôt « déploiement »
Contient un « helm chart » (équivalent docker-compose, généré semi-automatiquement) :
- des templates pour chaque objet k8s
- un fichier values.yaml avec les paramètres

.
└── charts
    ├── back
    │   ├── templates
    │   │   ├── deployment.yaml # responsable du conteneur back
    │   │   ├── ingress.yaml # règles "proxy" back (monappli.inrae.fr/api/)
    │   │   └── service.yaml
    │   └── values.yaml # paramétrage
    └── front
        ├── templates
        │   ├── deployment.yaml # responsable du conteneur front
        │   ├── ingress.yaml # règles "proxy" front (monappli.inrae.fr/)
        │   └── service.yaml
        └── values.yaml

# Value.yaml du back
replicaCount: 1
image:
  repository: registry.forgemia.inra.fr/monappli/back
  tag: "v2023-05-17"
ingress:
  hosts:
    - host: monappli.inrae.fr
      paths:
        - path: /api/(.*)

Démonstration¶

Une fois ce helm chart déposé sur la forge:

argocd pour l’installer sur notre cluster (démonstration avec dw4-dev)
synchronisation automatique
rollback / suivi basique des logs / debuggage k8s / via argocd

Petit shéma du cluster¶

Intérêt par rapport à Docker¶

Gestion des certificats
Regles de proxy simplifiées
Outil de suivi argocd
Intégration CI/CD
Scalabilité