Regroupe la documentation ainsi que les fichiers communs du projet collaborateur-EPA, notamment le docker-compose.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Collaborateur_Epa_Compose_Doc/README.md

174 lines
8.2 KiB

# Application Collaborateur-EPA
**Ce git contient la documentation de l'application Collaborateur-EPA de l'agence Tours-Orléans-Poitiers d'Apside. Il
contient également le docker-compose permettant de rapidement build le front et le back, ainsi que le script permettant
d'initialiser la base de données.**
## Mise en préproduction
Cette documentation contient les informations nécessaires pour déployer le front et le back de l'application
Collaborateur-EPA.
Assurez-vous d'avoir bien cloné les 3 repositories du Git à la racine d'un dossier commun.Vous devez donc avoir un
dossier racine contenant ces dossiers :
- Collaborateur_Epa_Compose_Doc
- Collaborateur_Epa_Back
- Collaborateur_Epa_Front
:warning: **Il est très important de respecter le nommage ci-dessus, car docker-compose va naviguer entre vos fichiers
afin de build l'application. Si vos dossiers ne respectent pas ce nommage, docker-compose ne pourra pas build les image
sans être modifié** :warning:
Sélectionnez bien les branches que vous souhaitez déployer dans les Git Front & Back
Avant de commencer le déploiement, nous allons vérifiez que les routes utilisées dans l'application front sont bien
celles de la préproduction, et que le back utilise bien la base de données de la préproduction.
Ensuite, nous verrons comment accéder à la base données. Enfin, vous verrez la procédure pour build, push et déployer
votre nouvelle version sur la préproduction d'Apside.
## Vérification des configurations
Il y a plusieurs façons de savoir si le front et bien lié au back de la préproduction :
- si les données que vous récupérez sont identiques à la préproduction,
- si les routes dans les services de l'application sont bien celles de la préproduction,
- l'application doit pouvoir démarrer sans avoir un back local en route.
Il est possible de voir si le back est lié à la BDD de préproduction en vérifiant le fichier appsettings.json. Dans ce
fichier, il y aura 2 lignes "ConnectionString", dont 1 commentée. A la fin de chaque ligne, vous verrez un commentaire
indiquant à quoi correspond celle-ci. Pour build en préproduction, dé-commentez la ligne de la préproduction et
commentez celle du déploiement local.
Les images des applications front et back sont maintenant prêtes à être build.
## Changements dans la base de données (optionnel)
Avant de déployer une nouvelle version, il faut effectuer les changements **si nécessaire** dans la base de données de
la préproduction. L'accès à la base de données se fait sur Rancher, dans le cluster "Collaborateur-EPA", dans le
conteneur "database" du namespace "dev-collaborateur-epa" à l'aide de l'option "Execute Shell". Ensuite, la connection à
MySQL se fait avec :
```
mysql -uroot -proot collaborateur_epa
```
"collaborateur_epa" étant la base de données utilisée, il n'est pas obligatoire de l'ajouter à la commande, vous pouvez
choisir cette base dans un second temps.
Il ne vous reste plus qu'à faire les modifications souhaitées afin que cette base corresponde à la nouvelle version.
Passons maintenant au build des images front et back
## Build les images
Vous l'avez compris, nous utiliserons docker et surtout docker-compose dans la phase de build. Ceci est très fortement
recommandé, car divers problèmes auront lieu si vous tentez de build les images sans docker-compose, notamment pour
l'image du back.
À partir d'un terminal, rendez-vous dans le dossier "Collaborateur_Epa_Compose_Doc". Lancez ensuite la commande :
```docker-compose up --build```
Les images vont se build et vont se lancer selon la configuration du docker-compose. Vous pouvez bien entendu tester les
applications lancées individuellement, mais elles sont normalement configurées pour fonctionner avec la préproduction.
Maintenant, couper les conteneurs (ctrl+c dans le terminal), une fois fait, entrez la commande :
```docker-compose down```
Ceci détruira les conteneurs afin de vous éviter une surconsommation de ressource inutile, puisque nous nous intéressons
ici aux images, pas aux conteneurs.
Nous allons voir comment push vos images sur le registry d'Apside, Harbor.
## Push les images
### Authentification sur Harbor
:warning: Votre compte devra être autorisé sur le projet "collaborateur-epa" avant de pouvoir vous y connecter.
Renseignez-vous auprès de la DSI et des responsables du projet pour obtenir les accès.:warning:
Afin de vous authentifier à Harbor, entrez la commande suivante :
```
docker login harbor.apsdigit.lan
```
Vous devrez ensuite entrer vos identifiants apsdigit (première lettre du prénom suivi du nom de famille en général),
puis votre mot de passe apsdigit correspondant. Pour rappel, il s'agit généralement du même mot de passe que celui de
votre poste.
### Publication sur Harbor
[Lien vers Harbor](https://harbor.apsdigit.lan/harbor/projects)
Une fois authentifié, vous pouvez uploadez vos images sur Harbor en entrant la commande suivante :
*Image Front*
```
docker push harbor.apsdigit.lan/collaborateur-epa/preprod/front:beta
```
*Image Back*
```
docker push harbor.apsdigit.lan/collaborateur-epa/preprod/api:beta
```
Si vous souhaitez changer le tag des images (ici "beta"), assurez-vous de le faire dans le docker-compose, et de le
faire également lors du push des images, vous aurez sinon des erreurs.
Si une erreur d'authentification vous est retournée, assurez-vous que vos credentials ne soient pas expirés en
réeffectuant l'étape d'authentification expliquée plus tôt.
Maintenant que les images sont sur Harbor, nous devons indiquer au namespace Kubernetes d'utiliser cette image.
:warning: Sur Harbor il est possible de vérifier les vulnérabilités de chaque image du repository. Il est fortement
recommandé de ne déployer sur Kubernetes que des versions dont les vulnérabilités ont été reparées au maximum possible.
Il s'agit souvent de mises à jour de dépendances des packages utilisés par les applications.:warning:
## Déploiement Kurbernetes sur Rancher
[Lien vers le cluster Kubernetes sur Rancher](https://rancher.apsdigit.lan/p/c-cxs28:p-f7tpc/workloads)
[Lien vers la préproduction](https://collaborateur-epa.apsdigit.lan/)
Il y a deux cas à différencier sur Kubernetes lorsque l'on veut déployer une nouvelle version de l'application.
Placez-vous dans Rancher dans le cluster Collaborateur-EPA pour suivre la procédure suivante.
### Cas 1 : Tags identiques
Si les tags de vos images sont identiques, alors la manipulation est si simple qu'on a pas besoin d'utiliser notre
cerveau, la moelle épinière suffit !
- Cliquez sur les 3 petits points verticaux sur la ligne de l'application que vous voulez mettre à jour,
- Cliquez sur "Redeploy",
- C'est terminé, attendez quelques minutes, puis rafraichissez le site dans votre navigateur pour vérifier que tout
s'est bien passé.
### Cas 2 : Tags différents
Si les tags de vos images sont différents, alors la manipulation est à peine plus complexe :
- Cliquez sur les 3 petits points verticaux sur la ligne de l'application que vous voulez mettre à jour,
- Cliquez sur "Edit",
- Dans le champs de texte sous "Docker Image" modifiez le tag pour qu'il corresponde à celui de votre image,
- En bas de la page cliquez sur le bouton "Save",
- C'est terminé, attendez quelques minutes, puis rafraichissez le site dans votre navigateur pour vérifier que tout
s'est bien passé.
Pour rappel, le tag d'une image docker est la partie **après** les ":" .
Il n'est pas recommandé de modifier le nom complet de l'image, puisque tout est déjà configuré pour fonctionner tel
quel. Le tag peut être modifié pour indiquer différentes versions, et peut s'avérer utile en cas d'audit ou de
déploiement versionné.
A l'instant où votre manipulation est terminée, vous devriez voir deux pods sur le conteneur que vous avez mis à jour,
un en cours de fermeture (removing) et un en déploiement. Kubernetes gère automatiquement les redéploiements afin que le
service ne soit pas ou peu interrompu. Par exemple, si le front n'arrive pas à compiler sur votre nouvelle version, le
conteneur gardera l'ancienne version et vous pourrez accéder aux logs du pod n'ayant pas réussi à se lancer afin
d'identifier le problème.
En cas de problème avec Rancher ou Harbor, vous pouvez contacter la DSI d'Apside afin d'obtenir de l'aide.