DÉPLOYER

Projets et environnements

Regroupez des applications liées, isolez la production de la préproduction, et donnez à chaque projet son réseau privé.

Un projet est un groupe d’applications et de bases qui vont ensemble. C’est l’unité que DockBoard utilise pour le placement, le réseau et le contrôle d’accès — presque tout ce que vous configurez s’y rattache.

Ses membres vivent sur un serveur — en mode multi-serveur, vous choisissez lequel.
Ils partagent un réseau Docker privé, donc ils se joignent par leur nom sans rien exposer publiquement.
Ils partagent le contrôle d’accès — qui est membre, et ce que chaque membre peut faire.

Créer un projet

01Allez dans Projets → Nouveau projet.
02Donnez-lui un nom. Le slug qui en dérive apparaît dans les noms de conteneurs et les noms d’hôtes internes : gardez-le court.
03En mode multi-serveur, choisissez le serveur cible. Il pourra changer plus tard — voir déplacer un projet.

Membres et rôles

Chaque membre d’un projet y détient un rôle. Voici les rôles fournis ; vous pouvez aussi définir les vôtres — voir rôles et permissions.

Rôle	Ce qu’il autorise
`OWNER`	Tout, y compris transférer la propriété et supprimer le projet.
`ADMIN`	Ajouter et retirer des membres, déployer, et déplacer le projet vers un autre serveur.
`DEVELOPER`	Déployer et éditer les applications. Aucun contrôle sur les membres.
`VIEWER`	Lecture seule.

Les rôles de projet sont distincts des droits au niveau de la plateforme. Être administrateur de l’instance DockBoard ne fait pas de vous, en silence, un membre de chaque projet — voir rôles et permissions pour la relation entre les deux catalogues.

Environnements

Un projet peut être divisé en environnements — typiquement préproduction et production, même si les noms et les couleurs vous appartiennent. Une application, une base ou une instance Linux est affectée à un environnement au plus, et c’est cette affectation qui permet à un même projet d’héberger deux copies du même service sans que leurs réglages se télescopent.

Le seul endroit où cela change le comportement plutôt que de simplement étiqueter, ce sont les jeux de variables : un jeu limité à un environnement l’emporte clé par clé sur le jeu valable pour tout le projet, si bien que DATABASE_URL peut désigner une chose en préproduction et une autre en production sous le même nom.

Promouvoir recopie un environnement sur un autre, en appariant les applications par leur nom. Une application déjà présente dans la destination est mise à jour sur place ; une application absente y est créée par copie. Deux interrupteurs indépendants décident de ce qui voyage :

Copier les variables: Les variables propres à l’application source écrasent celles de la destination. Décochez-le quand la production détient des identifiants que la préproduction ne doit jamais lui transmettre.
Mettre à jour la configuration de build: La branche Git voyage, et avec elle *ce qui en est construit* — le sous-dossier, le chemin du Dockerfile et le contexte de build. Ces éléments se déplacent ensemble à dessein : une destination restée pointée sur un ancien sous-dossier construirait un code différent depuis le même commit, précisément l’échec qu’une promotion existe pour écarter.

Promouvoir écrit des branches et des variables dans la destination : l’opération exige donc les mêmes droits que la modification directe de ces applications, et non le seul droit de déployer. Un membre dont la permission apps:env est refusée ne peut pas atteindre les secrets de production en y promouvant.

Une promotion rapporte ce qu’elle a modifié, ce qu’elle a créé, et ce qu’elle n’a pas pu transporter — un placement Swarm, par exemple, n’est délibérément pas recopié sur une nouvelle application. Lisez ces avertissements : une promotion qui annonce un succès n’est pas une promotion qui a tout transporté.

Un environnement ne se supprime qu’une fois vide. Si des applications, des bases ou des instances y sont encore affectées, le panneau refuse et indique combien de chaque — réaffectez-les ou supprimez-les d’abord. C’est la différence entre un environnement que vous avez retiré et un ensemble de ressources que plus rien ne désigne.

Les environnements servent aux copies que vous gardez. Pour une copie qui n’existe que le temps d’une pull request et disparaît à la fusion, utilisez plutôt les environnements de préview.

Le réseau du projet

Chaque projet possède un réseau Docker nommé dockboard_proj_<projectId>. Chaque application et chaque base placée dans le projet le rejoint automatiquement, et résout les autres par nom de conteneur via le DNS interne de Docker.

C’est ce qui fait fonctionner une application multi-services sans publier le moindre port. Les détails, avec un exemple complet, sont dans réseau de services.

Déplacer, exporter et supprimer

Déplacer un projet vers un autre serveur, volumes compris — déplacer et exporter des projets.
Exporter dans un fichier pour l’importer sur une autre instance DockBoard — même page.
Supprimer, ce qui démonte ses applications et ses bases. Faites une sauvegarde d’abord si quoi que ce soit compte.