Merge pull request #34 from cloud-pi-native/fix/issues

Fix/issues
cloud-pi-native · Jun 17, 2024 · 490429a · 490429a
2 parents 993bb05 + d458db2
commit 490429a
Show file tree

Hide file tree

Showing 11 changed files with 34 additions and 31 deletions.
diff --git a/docs/agreement/faq.md b/docs/agreement/faq.md
@@ -14,13 +14,13 @@ La description de l'utilisation de ces bouchons est détaillée [ici](/agreement
 ### Comment puis-je lancer la pipeline de synchronisation de mes repos depuis mes repos externes ?
 
 Pour synchroniser le code tu peux suivre la procédure suivante.
-Sur Gitlab:
+Sur GitLab:
 
 - Aller sur ton projet
 - Aller sur le dépôt mirror
 - Dans la barre latérale gauche Build > Pipelines
 - Cliquer en haut à droite de l'écran sur Run pipeline
-- Ajouter comme valeur pour la variable PROJECT_NAME le nom du dépôt (dans le Gitlab) que tu souhaites synchroniser
+- Ajouter comme valeur pour la variable PROJECT_NAME le nom du dépôt (dans le GitLab) que tu souhaites synchroniser
 - Ajouter la variable GIT_BRANCH_DEPLOY avec comme valeur la branche que tu souhaites synchroniser
 - Cliquer sur Run pipeline
 

diff --git a/docs/guide/get-started.md b/docs/guide/get-started.md
@@ -69,7 +69,7 @@ Remplir le formulaire de synchronisation des dépôts:
 <img src="/img/tuto/3tuto-depots-ajouter.png" alt="Dépôts synchronisés" width="75%" title="Dépôts synchronisés">
 
 
-Dans le cas d'un dépôt de code applicatif, générer les fichiers de *gitlab-ci* en cliquant sur le bouton *Fichiers de Gitlab CI*. Le fichier `.gitlab-ci-dso.yml` est à placer à la racine de votre dépôt externe et les `includes` (les autres fichiers `.yml`) sont à placer dans un dossier `includes/` à la racine de votre dépôt externe. Ces fichiers seront utilisés par le Gitlab de Cloud π Native pour effectuer les divers tests, scans et déploiements du projet.
+Dans le cas d'un dépôt de code applicatif, générer les fichiers de *gitlab-ci* en cliquant sur le bouton *Fichiers de GitLab CI*. Le fichier `.gitlab-ci-dso.yml` est à placer à la racine de votre dépôt externe et les `includes` (les autres fichiers `.yml`) sont à placer dans un dossier `includes/` à la racine de votre dépôt externe. Ces fichiers seront utilisés par le GitLab de Cloud π Native pour effectuer les divers tests, scans et déploiements du projet.
 
 <img src="/img/tuto/3tuto-depots-ajouter-gitlab-ci.png" alt="Gitlab-CI" width="75%" title="Gitlab-CI">
 
@@ -180,11 +180,11 @@ Une fois le dépôt interne à la plateforme créé et lié à un dépôt extern
 
 Pour paramétrer la synchronisation d'un dépôt :
 
-<!-- - Un dépôt nommé `<nom_de_votre_project>/<nom_de_votre_project>-mirror` a été créé dans le groupe Gitlab du projet. Dans ce dernier se trouve un script `script-mirror.sh` à copier dans votre dépôt externe.
+<!-- - Un dépôt nommé `<nom_de_votre_project>/<nom_de_votre_project>-mirror` a été créé dans le groupe GitLab du projet. Dans ce dernier se trouve un script `script-mirror.sh` à copier dans votre dépôt externe.
   > Ce script a pour but de demander à la plateforme de synchroniser le dépôt en effectuant un appel api (avec authentification auprès de l'api gateway).
   > Il faut donc lancer ce script dans la CI/CD du dépôt source selon les évènements sur lesquels on souhaite déclencher une synchronisation (ex: lors d'un push sur la branche main).
 
-- Dans le Gitlab de la plateforme, récupérer dans le dépôt `<nom_de_votre_project>/<nom_de_votre_project>-mirror` le token `GITLAB_TRIGGER_TOKEN` (`Settings > CI/CD > Pipeline triggers`, au besoin en créer un).
+- Dans le GitLab de la plateforme, récupérer dans le dépôt `<nom_de_votre_project>/<nom_de_votre_project>-mirror` le token `GITLAB_TRIGGER_TOKEN` (`Settings > CI/CD > Pipeline triggers`, au besoin en créer un).
 
 - Ajouter les variables d'environnements suivantes dans les __*secrets*__ de la CI/CD externe avec les valeurs fournies par l'équipe DSO ou précédemment récupérées (ces secrets seront utilisés par le script `script-mirror.sh`)
 
@@ -229,20 +229,20 @@ Pour paramétrer la synchronisation d'un dépôt :
 
 La synchronisation est maintenant en place et chaque appel API effectué avec le script `script-mirror.sh` entrainera le déclenchement de la chaine DevSecOps. -->
 
-- Un dépôt nommé `<nom_de_votre_project>/mirror` a été créé dans le groupe Gitlab du projet. Dans ce dernier se trouve un script `mirror.sh` à copier dans votre dépôt externe.
+- Un dépôt nommé `<nom_de_votre_project>/mirror` a été créé dans le groupe GitLab du projet. Dans ce dernier se trouve un script `mirror.sh` à copier dans votre dépôt externe.
   > Ce script a pour but de demander à la plateforme de synchroniser le dépôt en effectuant un appel api (avec authentification un trigger_token).
   > Il faut donc lancer ce script dans la CI/CD du dépôt source selon les évènements sur lesquels on souhaite déclencher une synchronisation (ex: lors d'un push sur la branche main).
 
-- Dans le Gitlab de la plateforme, récupérer dans le dépôt `<nom_de_votre_project>/mirror` le token `GITLAB_TRIGGER_TOKEN` (`Settings > CI/CD > Pipeline triggers`, au besoin en créer un).
+- Dans le GitLab de la plateforme, récupérer dans le dépôt `<nom_de_votre_project>/mirror` le token `GITLAB_TRIGGER_TOKEN` (`Settings > CI/CD > Pipeline triggers`, au besoin en créer un).
 
 - Ajouter les variables d'environnements suivantes dans les __*secrets*__ de la CI/CD externe avec les valeurs fournies par l'équipe DSO ou précédemment récupérées (ces secrets seront utilisés par le script `mirror.sh`)
 
   | Nom de variable          | Description                                                                  |
   | ------------------------ | ---------------------------------------------------------------------------- |
-  | API_URL                  | Url de GITLAB                                                                |
+  | API_URL                  | Url de GitLab                                                                |
   | BRANCH_TO_SYNC           | Branche ou tag a synchroniser                                                |
-  | GITLAB_MIRROR_PROJECT_ID | ID du projet mirror dans gitlab                                              |
-  | REPOSITORY_NAME          | Nom du repo a synchronisé dans le Gitlab DSO                                 |
+  | GITLAB_MIRROR_PROJECT_ID | ID du projet mirror dans GitLab                                              |
+  | REPOSITORY_NAME          | Nom du repo a synchronisé dans le GitLab DSO                                 |
   | GITLAB_TRIGGER_TOKEN     | Token de déclenchement du pipeline de synchronisation dans le GitLab interne |
 
 - Ajouter dans la CI/CD l'exécution de ce script pour déclencher la synchronisation automatiquement.

diff --git a/docs/guide/metrics.md b/docs/guide/metrics.md
@@ -82,6 +82,9 @@ Remplir les informations et cliquer sur `Save`
 Votre dashboard est maintenant disponible dans la liste des dashbords
 ![dashboard_list](/img/guide/grafana_list_dashboard_final.png)
 
+>[!WARNING]
+> Les dashboards personnels ne sont pas sauvegardés, penser à faire un backup du code yaml nécessaire à sa mise en place
+
 ## Aller plus loin
 La communauté propose des dashboards pré-définis pour la plupart des outils.
 

diff --git a/docs/guide/secrets-management.md b/docs/guide/secrets-management.md
@@ -4,7 +4,7 @@ Le déploiement applicatif suit le principe gitOps et donc de "pousser" l'ensemb
 
 La solution que nous proposons aujourd'hui est [SOPS](https://github.com/mozilla/sops). Avec SOPS, vos secrets applicatifs sont poussés chiffrés sur vos dépôts git. Une clé asymétrique est utilisée dont la clé privée n'est connue que du cluster Kubernetes hébergeant votre application et la clé publique accessible à tous les projets.
 
-Dans le cas ou vous choisissez l'offre de services de la plateforme SecNumCloud MIOM pour déployer vos applicatifs dans les clusters kubernetes gérés par les équipes Cloud π Native, des paires de clés au format age ont été générées sur les différents clusters et les clés publiques ont été déposées par les admins dans le dépôt `documentation-dso-projets-interne` du Gitlab de la plateforme.
+Dans le cas ou vous choisissez l'offre de services de la plateforme SecNumCloud MIOM pour déployer vos applicatifs dans les clusters kubernetes gérés par les équipes Cloud π Native, des paires de clés au format age ont été générées sur les différents clusters et les clés publiques ont été déposées par les admins dans le dépôt `documentation-dso-projets-interne` du GitLab de la plateforme.
 
 Exportez la variable `AGE_KEY` avec la valeur du cluster souhaité, exemple :
 

diff --git a/docs/installation/versions.md b/docs/installation/versions.md
@@ -101,7 +101,7 @@ https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/tags
 
 Dans le même ordre d'idée, une version de chart GitLab correspond à une version d'instance GitLab.
 
-La correspondance entre versions de charts GitLab et versions d'instances Gitlab est fournie par la page de documentation suivante :
+La correspondance entre versions de charts GitLab et versions d'instances GitLab est fournie par la page de documentation suivante :
 
 https://docs.gitlab.com/charts/installation/version_mappings.html
 

diff --git a/docs/platform/glossary.md b/docs/platform/glossary.md
@@ -7,7 +7,7 @@
 | Dépôt externe | Dépôt de code sur lequel travaillent les utilisateurs au quotidien                                             |
 | Dépôt interne | Dépôt de code interne de la plateforme vers lequel est cloné le dépôt externe                                  |
 | DSO           | DSO pour DevSecOps est le nom communément utilisé par les équipes Cloud Pi Native pour parler de la plateforme |
-| Gitlab        | Service d'hébergement de code source et service de CI/CD                                                       |
+| GitLab        | Service d'hébergement de code source et service de CI/CD                                                       |
 | Gitops        | Système de déploiement via l'observation de code source dans un dépôt                                          |
 | Harbor        | Service d'hébergement d'image de conteneur                                                                     |
 | Nexus         | Service d'hébergement d'artefacts (ex: lib npm)                                                                |

diff --git a/docs/platform/introduction.md b/docs/platform/introduction.md
@@ -25,7 +25,7 @@ Liste des services de la plateforme :
 | -------------- | ------------------------------------------ | ----------- |
 | Argocd         | Outil de déploiement automatique (GitOps)  | Oui         |
 | Harbor / Trivy | Hébergement / analyse d'image de conteneur | Oui         |
-| Gitlab         | Hébergement de code et pipeline CI/CD      | Oui         |
+| GitLab         | Hébergement de code et pipeline CI/CD      | Oui         |
 | Kubernetes     | Création des ressources kubernetes         | Oui         |
 | Nexus          | Hébergement d'artefacts                    | Oui [1]     |
 | Sonarqube      | Analyse de qualité de code                 | Oui         |
@@ -37,13 +37,13 @@ Liste des services de la plateforme :
 
 L'ambition de cette plateforme est de proposer aux équipes projets une offre de services large, complète déployée au sein d'un cloud souverain et permettant d'automatiser la construction et le déploiement de vos projets en assurant les standards de qualité et sécurité. 
 
-Pour pouvoir manipuler les services de cette plateforme, la première étape consister à synchroniser le code applicatif depuis un repo externe accéssible depuis la plateforme. 
+Pour pouvoir manipuler les services de cette plateforme, la première étape consister à synchroniser le code applicatif depuis un repo externe accéssible depuis la plateforme.
 
-La chaine de CI/CD sur le Gitlab de la plateforme permet:
+La chaine de CI/CD sur le GitLab de la plateforme permet:
 
 - Lancer vos jeux de tests applicatif (unitaires, de bout en bout, ...).
 - Effectuer une analyse de la qualité de votre code source à l'aide du service [Sonarqube](https://www.sonarqube.org/).
-- Construire vos images de conteneur de l'application dans la CI/CD du service [Gitlab](https://about.gitlab.com/).
+- Construire vos images de conteneur de l'application dans la CI/CD du service [GitLab](https://about.gitlab.com/).
 - Scanner vos images et le code source à l'aide de [Trivy](https://aquasecurity.github.io/trivy).
 - Stocker vos images dans un registry de conteneurs dans la plateforme: [Harbor](https://goharbor.io/).
 

diff --git a/docs/platform/skills-matrix.md b/docs/platform/skills-matrix.md
@@ -8,7 +8,7 @@ Cette page liste les technologies nécessaires à maitriser avant d'utiliser la
 | ---------------- | ---------------------------------------------------------------------------------------------------------------- |
 | Conteneurisation | **Obligatoire** Connaitre les principes de construction et de lancement d'images Docker                          |
 | Kubernetes       | **Obligatoire** Connaître et comprendre les principes et objets principaux de k8s et les manifest de déploiement |
-| Gitlab-CI        | **Obligatoire** Connaître les pipelines de déploiements gitlab-ci                                                |
+| GitLab-CI        | **Obligatoire** Connaître les pipelines de déploiements gitlab-ci                                                |
 | Helm             | **Conseillé** Savoir utiliser et créer un chart HELM                                                             |
 | GitOps           | **Obligatoire** Comprendre les principes de déploiement GitOps                                                   |
 | Openshift        | **Conseillé** Comprendre les différences avec kubernetes                                                         |

diff --git a/docs/services/artefacts.md b/docs/services/artefacts.md
@@ -29,7 +29,7 @@ Les urls de repositories seront toujours constuites de la même façon **\${NEXU
 ## Dépôts d'images de conteneurs: Harbor
 
 Harbor est la registry d'images de conteneurs utilisé pour stocker, gérer et distribuer les images de conteneurs des différents clusters, ainsi que de les scanner pour détecter les vulnérabilités de sécurité.
-Celui-ci est préconfiguré dans les templates Gitlab CI et utilisable via l'exemple suivant :
+Celui-ci est préconfiguré dans les templates GitLab CI et utilisable via l'exemple suivant :
 
 ```yaml
 build_docker_back:
@@ -46,7 +46,7 @@ build_docker_back:
 Il sera possible de définir différentes variables d'environnement dans GITLAB pour définir le TAG de l'image du conteneur, son nom et le path du Dockerfile:
  - IMAGE_NAMES: Nom de l'image de conteneur qui sera push dans le registry Harbor
  - DOCKERFILE: Chemin relatif depuis la racine du projet vers le Dockerfile
- - TAG: Tag de l'image par default le nom de la branche sera utilisé, il est possible d'utiliser d'autres valeurs disponible dans [Gitlab](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) comme le $CI_COMMIT_SHORT_SHA ou des valeurs personnaliées.
+ - TAG: Tag de l'image par default le nom de la branche sera utilisé, il est possible d'utiliser d'autres valeurs disponible dans [GitLab](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) comme le $CI_COMMIT_SHORT_SHA ou des valeurs personnaliées.
 
 Les images seronts publiées (Push) sur l'url prédéfini de harbor ayant le format suivant :
 

diff --git a/docs/services/gitlab.md b/docs/services/gitlab.md
@@ -2,24 +2,24 @@
 
 ## Présentation
 
-Pour stocker et gérer vos sources applicatifs, l'usine logicielle de l'offre Cloud π Native vous propose le service de gestionnaire de source **Gitlab** en version communautaire.
+Pour stocker et gérer vos sources applicatifs, l'usine logicielle de l'offre Cloud π Native vous propose le service de gestionnaire de source **GitLab** en version communautaire.
 
-Le principe de l'offre Cloud π Native est de laisser les projets autonomes sur leur chaine de construction sur les environnements de développement et notamment les outils utilisés. Ainsi, une équipe projet peut utiliser le gestionnaire de source qu'il souhaite en amont de l'offre Cloud π Native : Github, Gitlab.com, Bitbucket, Gitlab on premise, etc. et sur des dépôts de code publics ou privés. La seule contrainte est que ce gestionnaire soit **accessible depuis Internet** afin qu'il puisse être *copié* sur le GitLab de l'usine logicielle de l'offre Cloud π Native.
+Le principe de l'offre Cloud π Native est de laisser les projets autonomes sur leur chaine de construction sur les environnements de développement et notamment les outils utilisés. Ainsi, une équipe projet peut utiliser le gestionnaire de source qu'il souhaite en amont de l'offre Cloud π Native : Github, GitLab.com, Bitbucket, GitLab on premise, etc. et sur des dépôts de code publics ou privés. La seule contrainte est que ce gestionnaire soit **accessible depuis Internet** afin qu'il puisse être *copié* sur le GitLab de l'usine logicielle de l'offre Cloud π Native.
 
 Dans la suite de cette page :
   - *dépôt externe* correspond au dépôt GIT externe à la plateforme Cloud π Native, et utilisé généreralement pour tester vos développement;
   - *dépôt interne* correspond à la copie du dépôt externe dans le service GitLab l'offre Cloud π Native;
-  - *gitlab interne* correspond à l'instance gitlab de l'offre Cloud π Native.
+  - *gitlab interne* correspond à l'instance GitLab de l'offre Cloud π Native.
 
 ![gitlab-synchro-repos](/img/repo-sync-01.png)
 
-> la copie des dépôts externes vers le gitlab interne est piloté par le Gitlab interne. Le flux de synchronisation *part* de l'instance gitlab interne.
+> la copie des dépôts externes vers le GitLab interne est piloté par le GitLab interne. Le flux de synchronisation *part* de l'instance GitLab interne.
 
 ## Import d'un dépôts externe depuis la Console DSO
 
 La déclaration de dépôts externes à synchroniser se fait depuis la **Console** Cloud π Native, une fois le projet est crée. Les opérations suivantes sont réalisées par la Console DSO:
- - Création d'un groupe Gitlab : <NOM_ORGANISATION>/<NOM_PROJET> sur le gitlab interne;
- - Attribution de droits d'administration sur le groupe Gitlab <NOM_ORGANISATION>/<NOM_PROJET>à l'utilisateur qui crée le projet;
+ - Création d'un groupe GitLab : <NOM_ORGANISATION>/<NOM_PROJET> sur le GitLab interne;
+ - Attribution de droits d'administration sur le groupe GitLab <NOM_ORGANISATION>/<NOM_PROJET>à l'utilisateur qui crée le projet;
  - Création d'un dépôt vide correspondant au dépôt distant dans le groupe ci-dessus;
  - Création d'un dépôt "mirror" avec les informations de synchrnonisation permettant, de réaliser un mirroir du dépôt GIT externe vers le dépôt interne créé plus haut.
 
@@ -36,7 +36,7 @@ Deux types de dépôts sont pris en comptes par l'offre Cloud π Native :
  - Dépôt applicatifs
  - Dépôt d'infrastructure applicatifs.
 
-### Dépôts applicatifs et chaine de construction Gitlab-ci 
+### Dépôts applicatifs et chaine de construction gitlab-ci 
 
 Les dépôts applicatifs contiennent le code source de vos applications.
 
@@ -47,7 +47,7 @@ Les projets applicatifs sont analysés et construits et les images de conteneurs
 
 ### Variables prédéfinies gitlab-ci DSO
 
-Un certains nombres de variables pré-définies, en plus des variables standards de gitlab :
+Un certains nombres de variables pré-définies, en plus des variables standards de GitLab :
 
  - http_proxy, https_proxy, HTTP_PROXY et HTTPS_PROXY, PROXY_HOST, PROXY_PORT,  : paramètres liés au proxy de l'environnement.
  - MVN_CONFIG_FILE : fichier de configuration Maven avec le paramètrage pré-défini de l'environnement et du projet en cours, notamment pour le dépot d'artefact sur le repo Nexus.
@@ -58,7 +58,7 @@ Un certains nombres de variables pré-définies, en plus des variables standards
  - REGISTRY_URL : URL d'accès à l'instance Harbor (image repository)
  - SONAR_HOST_URL : URL d'accès à l'instance SonarQube (analyse de qualité statique)
  - VAULT_AUTH_PATH : PATH dans l'URL d'accès à VAULT pour l'authentification par jwt
- - VAULT_AUTH_ROLE : PATH dans l'URL d'accès à VAULT pour la récupération des roles depuis les appels de Gitlab
+ - VAULT_AUTH_ROLE : PATH dans l'URL d'accès à VAULT pour la récupération des roles depuis les appels de GitLab
  - VAULT_SERVER_URL : URL d'accès à l'instance Vault (gestionnaire de secrets)
 
 ### Dépôt source d'infrastructure applicatifs