Aller au contenu

Déploiement et CI/CD Mis à jour le 2026-05-27

Déploiement applicatif

Comment le code applicatif est déployé sur Stack Harbor PaaS à travers les sources de déploiement supportées — archive, VCS, registre de conteneur — et les surfaces tableau de bord, CLI et API qui pilotent chacune d'elles.

Cette page couvre le déploiement applicatif sur Stack Harbor PaaS — l’action de déposer un artefact de build sur un serveur applicatif en exécution dans un environnement. La plateforme supporte trois sources de déploiement et trois surfaces de pilotage, toutes appuyées sur le même mécanisme sous-jacent.

Sources de déploiement

  • Archive — un build empaqueté (.zip, .tar.gz, .tar.bz2, .tar, .war, .jar) fourni comme fichier local ou récupéré depuis une URL. L’archive est téléversée dans le gestionnaire de déploiement de la plateforme et peut être déployée vers n’importe quel environnement compatible.
  • VCS — un dépôt Git ou SVN enregistré avec ses identifiants dans le gestionnaire de déploiement. La plateforme clone le dépôt dans le serveur applicatif. Les mises à jour suivantes peuvent être déclenchées manuellement, interrogées sur calendrier ou poussées via webhook.
  • Registre de conteneur — pour les serveurs applicatifs basés sur Docker, une image est tirée depuis un registre public ou privé, incluant les registres privés requérant des identifiants.

Comment chaque source est traitée

Le flux dépend du runtime :

  • Java — les déploiements basés sur VCS passent par un nœud de build Maven. Le nœud de build clone le dépôt, exécute le build Maven et pousse l’artefact résultant vers le serveur applicatif. Les déploiements par archive sautent l’étape de build et déploient l’artefact directement.
  • PHP, Ruby, Python, Node.js, Go — les déploiements basés sur VCS exécutent les sources du projet directement sur le serveur applicatif. Les déploiements par archive décompactent l’archive dans le chemin de déploiement.
  • .NET sur IIS — pris en charge via un flux de déploiement spécifique à Windows qui diffère du pipeline standardisé ci-dessus.

Configuration du déploiement

Chaque déploiement est configuré via une boîte de dialogue. Paramètres communs :

  • Source — fichier local, URL, dépôt Git/SVN enregistré, ou image Docker.
  • Environnement — l’environnement cible contenant le serveur applicatif.
  • Chemin — le chemin de contexte (p. ex. ROOT, /myapp). Python et Node.js utilisent un seul chemin prédéfini.
  • Hooks — scripts pré- et post-déploiement à exécuter dans le cadre de l’opération.
  • Stratégie de déploiement — pour les paliers à l’échelle, soit Simultaneous (plus rapide, brève interruption) soit Sequential with delay (sans interruption, plus lent).
  • Déploiement zéro interruption — pour les serveurs applicatifs PHP, bascule la racine documentaire de façon atomique.

Pour les sources VCS, des paramètres additionnels s’appliquent :

  • Branch — la branche à déployer (master par défaut).
  • Build — pour Java, le nœud de build Maven à utiliser.
  • Check and auto-deploy updates — active l’interrogation périodique à un intervalle configurable.
  • Auto-resolve conflicts — écarte les modifications locales sur le serveur applicatif au profit de la version du dépôt.

Déploiement applicatif Kubernetes

Pour les environnements basés sur Kubernetes, les applications sont déployées via les méthodes natives Kubernetes : manifestes YAML, charts Helm, ou appels à l’API Kubernetes. Le réseau interne, l’exposition de service et la configuration d’ingress sont couverts séparément dans la documentation Kubernetes.

Surfaces de pilotage

Trois façons d’initier un déploiement :

  • Tableau de bord — la ligne Deployments sur chaque serveur applicatif ouvre la boîte de dialogue de déploiement. Le panneau gestionnaire de déploiement au bas du tableau de bord stocke les archives réutilisables et les projets VCS.
  • CLI — ~/jelastic/environment/vcs/createproject, ~/jelastic/environment/file/upload et les commandes associées couvrent chaque action de déploiement.
  • API — les mêmes opérations sont accessibles via des appels REST API avec un jeton de session.

Automatiser les déploiements

Deux modèles d’automatisation :

  • Auto-déploiement par interrogation — pour tout dépôt Git ou SVN enregistré dans le gestionnaire de déploiement. Activez Check and auto-deploy updates, réglez l’intervalle d’interrogation, et la plateforme redéploie quand de nouveaux commits apparaissent.
  • Déploiement déclenché par push — pour GitHub et GitLab, l’add-on Git-Push-Deploy configure un webhook sur le dépôt. Chaque push déclenche un redéploiement. Pas de délai d’interrogation.

Pour les pipelines CI (Jenkins, GitLab CI, GitHub Actions), appelez le CLI ou l’API pour déployer un artefact construit directement.

Voir aussi