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

⚠️ 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é ⚠️

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

⚠️ 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.⚠️

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

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.

⚠️ 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.⚠️

Déploiement Kurbernetes sur Rancher

Lien vers le cluster Kubernetes sur Rancher Lien vers la préproduction

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.