Principes du déploiement

Principes de base #

Ces principes sont communs à tous les déploiements.

• Le déploiement se fait depuis un serveur Gitlab dédié au projet et infogéré par Bearstech.
• Un projet Gitlab est associé à un compte Unix qui correspond au nom de votre projet comme il apparaît dans l’url Gitlab: https://GITLAB_URL/GROUP/PROJECT sous la forme GROUP-PROJECT
• Sur le serveur de destination, votre repository Gitlab se trouve dans le dossier root à la racine de ce compte
• Tout déploiement correspond à un commit Git, le repository présent sur le serveur est mis-à-jour vers ce commit au début de chaque déploiement. Attention : Toute modification faite localement sur un serveur pourra être écrasée par un déploiement
• Les variables de CI définies dans Gitlab commençant par DEPLOY_ sont transmises au serveur et accessibles dans le fichier $HOME/root/.env

Déploiement natif #

Nous avons prévu une méthode déploiement qui s’appliquera aux projets qui n’ont pas besoin de builder une application dans une image Docker.

Cette méthode est valable pour tous types d’applications instanciées directement sur l’hôte, ou la génération de pages statiques.

A partir des sources disponibles d’un projet Gitlab (depuis le dépôt, et/ou à partir de la registry qui stocke les artefacts issus du build d’une application), le service de déploiement va correctement instancier votre application vers un serveur de destination, infogéré par Bearstech.

Exemple de workflow pour le déploiement d’une application instanciée nativement sur l’hôte. Les sources sont récupérées depuis le dépôt Git et les assets depuis la registry Gitlab (package-manager). L’avantage est de pouvoir définir un paramétrage fin de l’application et de garantir une sécurité optimale de l’hôte.

Déploiement de conteneurs #

Cette méthode est valable pour des applications exécutées dans un environnement Docker.

Dans le cas du déploiement d’applications conteneurisées, un reverse-proxy HTTP, expose publiquement l’application. Le proxy va se charger du routage HTTP, de la terminaison TLS, ainsi que de la répartition de charge quand il y a plusieurs instances d’un même service avec les mêmes règles.

Workflow de déploiement d’une application conteneurisée. Ici les sources sont dans l’image construite lors de l’intégration continue. L’avantage est de pouvoir déployer plusieurs applications issues de technologies ou de versions différentes sur un même hôte.

Afin d’instancier correctement les services de votre application sur les environnements infogérés, le déploiement va vérifier :

• que l’image Docker est basée sur une image maintenue par Bearstech
• qu’elle n’a pas d’utilisateur root
• que le conteneur ne s’exécute pas en mode privilégié
• que les volumes se trouvent tous dans le compte utilisateur