From 82a5532f9f979e94a74f4224a42b8ff90c8abfcf Mon Sep 17 00:00:00 2001 From: Baptiste Noleau Date: Mon, 10 Jun 2024 16:16:04 +0200 Subject: [PATCH 1/2] gitlab --- docs/agreement/faq.md | 4 ++-- docs/guide/get-started.md | 16 ++++++++-------- docs/guide/secrets-management.md | 2 +- docs/installation/versions.md | 2 +- docs/platform/glossary.md | 2 +- docs/platform/introduction.md | 8 ++++---- docs/platform/skills-matrix.md | 2 +- docs/services/artefacts.md | 4 ++-- docs/services/gitlab.md | 18 +++++++++--------- docs/services/sonarqube.md | 4 ++-- 10 files changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/agreement/faq.md b/docs/agreement/faq.md index 29c042f..202ca30 100644 --- 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 index 197ca7b..42e7cb3 100644 --- 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: 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. 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é `/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é `/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 `/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 `/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/secrets-management.md b/docs/guide/secrets-management.md index d3876c2..db52506 100644 --- 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 index e8b73c9..b2ff9d0 100644 --- 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 index 8ef9cc6..9077648 100644 --- 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 index 8369a9d..2972c66 100644 --- 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 index 74f2eb7..1ff75de 100644 --- 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 index 4420af7..2aa8c3d 100644 --- 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 index 3529381..7a3976c 100644 --- 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 : / sur le gitlab interne; - - Attribution de droits d'administration sur le groupe Gitlab /à l'utilisateur qui crée le projet; + - Création d'un groupe GitLab : / sur le GitLab interne; + - Attribution de droits d'administration sur le groupe GitLab /à 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 diff --git a/docs/services/sonarqube.md b/docs/services/sonarqube.md index 215cc90..a3c9788 100644 --- a/docs/services/sonarqube.md +++ b/docs/services/sonarqube.md @@ -6,12 +6,12 @@ Pour l'analyse statique (bonnes pratiques et sécurité) de vos code sources app Des *Quality gates* sont positionnées afin de garantir que le code construit respecte les normes de sécurité et de qualité. -Les variables d'environnement suivantes sont disponibles depuis Gitlab lors des étapes de construction et permettant de contacter sonar : +Les variables d'environnement suivantes sont disponibles depuis GitLab lors des étapes de construction et permettant de contacter sonar : - SONAR_HOST_URL - SONAR_TOKEN -SonarQube est préconfiguré pour certains outils telsque npm et Maven, présents dans les templates [Gitlab](https://cloud-pi-native.fr/services/gitlab.html) et utilisable via l'exemple suivant : +SonarQube est préconfiguré pour certains outils telsque npm et Maven, présents dans les templates [GitLab](https://cloud-pi-native.fr/services/gitlab.html) et utilisable via l'exemple suivant : ```yaml test_front: From d458db26f161b30cb85dc9536c1079b9748d510b Mon Sep 17 00:00:00 2001 From: Baptiste Noleau Date: Mon, 10 Jun 2024 17:49:22 +0200 Subject: [PATCH 2/2] dashboard --- docs/guide/metrics.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/guide/metrics.md b/docs/guide/metrics.md index 9247fd8..a9d7bf4 100644 --- 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.