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.
174 lines
8.2 KiB
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.
|
|
|