@@ -55,7 +55,8 @@ Ainsi, chaque service versionné sur ce dépôt contiendra :
* Un fichier `docker-compose.yml` permettant de lancer le service,
* Si possible, un ou des fichiers de configuration permettant de personnaliser le service selon nos besoins,
* Un fichier d'exemple de secrets (mot de passe...) nécessaire au lancement du service,
* Un `README` résumant les paramètres modifiables sur le dépôt, les mécanismes pour en rajouter, etc.
* Un `README.md` résumant les paramètres modifiables sur le dépôt, les mécanismes pour en rajouter, etc,
* Pour les images maison, un `CHANGELOG.md` résumant les modifications faites au fil des version.
Il n'y a pas de Docker Compose global : chaque service a son propre Docker Compose.
...
...
@@ -111,6 +112,9 @@ Modifier peut vouloir dire :
Il suffit de récupérer ce dépôt, de faire les mises à jour, de commit les changements et de les pousser.
On n'oublie pas de correctement versionner l'image dans le `docker-compose.yml`, via le tag de l'image.
Le cas échéant, pour des services "maisons", il est de bon ton de mettre à jour un fichier `CHANGELOG.md` pour résumer les modifications.
*Attention, la CI se déclenche en regardant les modifications apportées lors du dernier commit. Si vous modifiez le `Dockerfile` dans un commit, puis le `README` dans un autre, et que vous poussez le tout, la construction ne se déclenchera pas automatiquement.*
Vous pouvez suivre les différentes étapes de la CI dans la section [Pipelines](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines), et il est **recommandé** de lire les logs des différentes étapes en cliquant sur chacune d'entre elles. Si la construction et les analyses de sécurité se passent bien, tous les voyants sont au vert (sauf la dernière étape, qui doit être déclenchée manuellement). Sinon, référez-vous à la section [En cas d'erreur](#en-cas-derreur).
...
...
@@ -156,6 +160,8 @@ Une fois les premières étapes de la CI passées, il est temps de déployer le
À ce stade, l'image est construite, saine, et poussée sur le registre de test. Avant de la mettre en production, il faut vérifier que le service se lance bien comme prévu. Pour ce faire, on se rend sur une machine virtuelle de test (exemple : `pica01-test.picasoft.net`) et on se rend dans `/DATA/docker/dockerfiles`.
Il faut être connecté au registre de test pour la suite : on s'assure de bien avoir exécuté la commande `docker login registry.test.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
Pour que le service réponde à nos critères, il faut s'assurer qu'il démarre **indépendamment** de ce qui existe sur la machine. Le script [`docker_test.sh`](./docker_test.sh) s'occupe de tout cela pour vous.
Il suffit de lancer la commande `$ ./docker_test.sh <nom du dossier, e.g. pica-mattermost>` pour effectuer les opérations suivantes :
* Mise à jour du dépôt dans sa dernière version,
...
...
@@ -173,6 +179,8 @@ Lorsque tout est bon, on retourne sur la page [Pipelines](https://gitlab.utc.fr/
On se rend enfin sur la machine de production, dans le dossier `/DATA/docker/dockerfiles`. On s'assure que les fichiers de secrets existent et contiennent bien des valeurs **secrètes**, pas celles du fichier d'exemple !
Il faut être connecté au registre de production pour la suite : on s'assure de bien avoir exécuté la commande `docker login registry.picasoft.net`. Les identifiants sont sur le [pass](https://gitlab.utc.fr/picasoft/interne/pass).
On peut alors utiliser le script [`docker_prod.sh`](./docker_prod.sh), qui automatise quelques étapes.
Il suffit de lancer la commande `$ ./docker_prod.sh <nom du dossier>` pour effectuer les opérations suivantes :
