diff --git a/docs/guide/best-practices.md b/docs/guide/best-practices.md index b588b66..3381b1a 100644 --- a/docs/guide/best-practices.md +++ b/docs/guide/best-practices.md @@ -4,33 +4,33 @@ Une application Cloud π Native doit respecter les [Twelve-Factor](https://12factor.net/fr/) -D'autres bonnes pratiques à réspecter impérantivement: +D'autres bonnes pratiques à respecter impérativement : 1. Base de code - Le code de l'application et de déploiement doit etre **versionné** dans un dépôt de source de type **Git** (Public/Privée) **accessible depuis internet**. + Le code de l'application et de l'infrastructure doit être **versionné** dans un dépôt de source de type **Git** (Public/Privée) **accessible depuis internet**. 2. Dépendances - __TOUTES__ dépendances necessaires à la constuction de l'application (Libraries,Images, ...) doivent provenir des dépôts de librairies connus tels que Maven, Composer et Node. Il est aussi possible de construire les dépendences par l'offre Cloud π Native et les déposer dans son gestionnaire d'artefact. + __TOUTES__ dépendances nécessaires à la construction de l'application (Libraries,Images, ...) doivent provenir des dépôts de librairies connues tels que Maven, Composer et Node. Il est aussi possible de construire les dépendances par l'offre Cloud π Native et les déposer dans son gestionnaire d'artefact. 3. Configuration / Service Externe - __TOUTES__ la configuration applicative pouvant être amenée a être modifié, par exemple la configuration entre deux environnements applicatifs est la plus part du temps différente. Elle doit donc être injectée par des variables d'environnement au runtime ou via un fichier de configuration dynamique via une ConfigMap + __TOUTES__ la configuration applicative pouvant être amenée à être modifié, par exemple la configuration entre deux environnements applicatifs la plupart du temps différente. Elle doit donc être injectée par des variables d'environnement au runtime ou via un fichier de configuration dynamique via une ConfigMap 4. Port - Afin de respecter les préconisation de sécurité, les applications déployées doivent écouter sur des ports > 1024. + Afin de respecter les préconisations de sécurité, les applications déployées doivent écouter sur des ports > 1024. 6. Logs - L'application __NE DOIT PAS__ écrire dans un fichier de logs spécifique mais écrire l'ensemble de ces logs dans la sortie standards (stdout) au format GELF ou à defaut JSON. + L'application __NE DOIT PAS__ écrire dans un fichier de logs spécifique, mais écrire l'ensemble de ces logs dans la sortie standards (stdout) au format GELF ou à défaut JSON. Les logs seront accessibles plus facilement de cette manière depuis les outils de supervisions. 7. Processus - Les applications doivent être __STATELESS__, si des données de session/cache doivent être utilisé et partagé par l'application alors elles doivent faire l'objet d'un service externe prévus à cet effet telsque Redis. + Les applications doivent être __STATELESS__, si des données de session/cache doivent être utilisés et partagé par l'application alors elles doivent faire l'objet d'un service externe prévus à cet effet tel que Redis. 8. Processus d’administration @@ -42,22 +42,22 @@ L'ensemble de ces bonnes pratiques sont détaillés dans la documentation OpenSh L'application déployée doit être conteneurisée (sous la forme d'un ou plusieurs conteneurs). - Les __Dockerfiles__ doivent être dans le dépôt pour permettre à la chaine de reconstruire l'application. - - Les images de bases des __Dockerfiles__ doivent être accessibles publiquement ou reconstuire par l'offre Cloud π Native . + - Les images de bases des __Dockerfiles__ doivent être accessibles publiquement ou reconstuite par l'offre Cloud π Native . - Les images doivent être __rootless__, l'utilisateur qui lance le processus au sein du conteneur ne doit pas être `root`. - L'utilisateur lançant le processus dans le conteneur doit avoir les droits adéquats en lecture / écriture sur le système de fichiers si l'application doit manipuler ce dernier. - - Des sondes de "Readiness"/"Liveness" doivent être implémenté. + - Des sondes de "Readiness"/"Liveness" doivent être implémentées. - Des limits/requests doivent etre mise en place. ## Déploiement -L'application doit se déployer à l'aide de fichiers d'__Infrastructure As Code__: +L'application doit se déployer à l'aide de fichiers d'__Infrastructure As Code__ : - Utiliser des manifestes [kubernetes](https://kubernetes.io/) avec Kustomize pour variabliser vos manifestes (cf. [tutoriels](/guide/tutorials)) - Utiliser des charts [helm](https://helm.sh/) (cf. [tutoriels](/guide/tutorials) pour avoir des exemples de fichiers). - Utiliser [Kustomize](https://kustomize.io/) ## Labels -Les ressources doivent comporter des labels permettant de les identifier. les labels pourraient etre decomposés de la facon suivante : +Les ressources doivent comporter des labels permettant de les identifier. Ils peuvent être décomposés de la façon suivante : ``` Yaml App : " " @@ -71,7 +71,7 @@ Tous les labels disponibles [ici](/agreement/labels-list). ## Tag d'images -Les images poussées dans le registry devront etre unique et identifiés via un Sha ou Short-Sha qui pourrait etre lié au commit Git. Grace a cela une gestion des releases et un rollback seront possibles. +Les images poussées dans le registry devront être unique et identifiés via un Sha ou Short-Sha qui pourrait être lié au commit Git. Grace à cela une gestion des releases et un rollback seront possibles. Exemple de valeur pour le Tag de l'image : @@ -84,9 +84,9 @@ CI_JOB_ID ## Politiques de nommage -Les noms de toutes les ressources Openshift ne doivent jamais etre trop longs, il est donc conseillé de choisir des noms courts. -il se pourrait que des ressources ne soient pas déployées si le nom est trop long. -Coté exploitation, cela facilite grandement la gestion. +Les noms de toutes les ressources Openshift ne doivent jamais être trop longs, il est donc conseillé de choisir des noms courts. +Il se pourrait que des ressources ne soient pas déployées si le nom est trop long. +Côté exploitation, cela facilite grandement la gestion. Exemple : @@ -103,19 +103,19 @@ PVC : env-name-pvc ## Secrets -Les secrets comportent toutes les informations sensibles. Les différents types de secrets peuvent etre : +Les secrets comportent toutes les informations sensibles. Les différents types de secrets peuvent être : - Passwords - Certificats - Usernames - Tokens -Toutes les secrets devront etre contenus dans un Vault qui sera mis a disposition pour l'ensemble des projets. Les objets contenus dans le Vault sont séparés par projets (NS). +Tous les secrets devront être contenus dans un Vault qui sera mis a disposition pour l'ensemble des projets. Les objets contenus dans le Vault sont séparés par projets (NS). ## Liveness et Readiness -Il est très important de mettre en place ces checks afin de vérifier l'etat de vos applications. Ceci est nécessaire pour assurer la haute disponibilité et la résilience de vos applications. -Cela peut-etre une fonctionnalité de l'application, une page d'un site web, une entrée en base de donnée, etc. +Il est très important de mettre en place ces checks afin de vérifier l'état de vos applications. Ceci est nécessaire pour assurer la haute disponibilité et la résilience de vos applications. +Cela peut-être une fonctionnalité de l'application, une page d'un site web, une entrée en base de données, etc. ``` Yaml livenessProbe: @@ -135,9 +135,9 @@ readinessProbe: ## SSL -Afin d'optimiser un flux sécurisé,il est préférable que cela soit de bout en bout. +Afin d'optimiser un flux sécurisé, il est préférable que cela soit de bout en bout. -Exemple du schéma de distribution de la requete. +Exemple du schéma de distribution de la requête. Users --HTTPS-> ReverseProxy --HTTPS-> Ingress Kubernetes --HTTPS-> Container (Best Case) @@ -145,12 +145,12 @@ Users --HTTPS-> ReverseProxy --HTTPS-> Ingress Kubernetes --HTTP-> Container ( ## HPA (Horizontal Pod Autoscaling) -Le scaling est très important afin de répondre aux besoins en termes d'affluence. il est aujourd'hui un atout majeur pour avoir une application qui soit le plus disponible possible avec des performances élevées. Pour cela il est donc possible de définir des triggers afin d'upscale l'applicatif (CPU, RAM, Métriques Applicatives). +Le scaling est très important afin de répondre aux besoins en termes d'affluence. Il est aujourd'hui un atout majeur pour avoir une application qui soit le plus disponible possible avec des performances élevées. Pour cela il est donc possible de définir des triggers afin d'upscale l'applicatif (CPU, RAM, Métriques Applicatives). ## QOS -Il est important de définir les consommations de chaque POD (prévisionnelles), Savoir si il serait intéressant que certains disposent d’une "request" égal a la "limit" afin d’assurer une réservation des ressources. (Guaranteed Class) -L'utilisation du "Burstable" n'est pas pas une bonne pratique. il est vraiment necessaire d'avoir une "limit" même si celle-ci n'est pas équivalente a la "request". +Il est important de définir les consommations de chaque POD (prévisionnelles), savoir si il serait intéressant que certains disposent d’une "request" égal a la "limit" afin d’assurer une réservation des ressources. (Guaranteed Class) +L'utilisation du "Burstable" n'est pas pas une bonne pratique. Ll est vraiment nécessaire d'avoir une "limit" même si celle-ci n'est pas équivalente a la "request". Exemple : @@ -165,14 +165,14 @@ requests: ## Taille des images -Il est très important de construire des images les plus légères possibles, c'est a dire utiliser uniquement les paquets nécéssaires au bon fonctionnement de l'application ainsi que la meilleure image de base. +Il est très important de construire des images les plus légères possibles, c'est à dire utiliser uniquement les paquets nécessaires au bon fonctionnement de l'application ainsi que la meilleure image de base. C'est un gros vecteur de sécurité, de charge stockage et réseau. Exemple d'image base Lightway : Alpine ## Politiques réseau -Les "Network policies" sont par défaut en "Deny ALL". Il est donc à vous de déifnir les flux entrants et sortants sur les namespaces de vos projets. +Les "Network policies" sont par défaut en "Deny ALL". Il est donc à vous de définir les flux entrants et sortants sur les namespaces de vos projets. ReverseProxy-->Networkpolicies-->Pods (Ingress) diff --git a/docs/guide/deployment-with-argo.md b/docs/guide/deployment-with-argo.md index e31ee5b..a1a7114 100644 --- a/docs/guide/deployment-with-argo.md +++ b/docs/guide/deployment-with-argo.md @@ -3,28 +3,28 @@ Une fois qu'un dépôt d'infrastructure est synchronisé, il convient de se rendre sur le service ArgoCD depuis la liste des services : ![argocd](/img/tuto/4argocd.png) -Cliquez sur le projet nouvellement créé afin de finaliser son configuration: modification du dépôt d'infrastructure par défaut, ou le cluster de déploiement applicative. +Cliquez sur l'application nouvellement créé afin de finaliser sa configuration : -Allez dans le menu en haut et cliquez sur App detail : +Allez dans le menu en haut et cliquez sur details : ![ArgoCD-menus](/img/tuto/4argocd-menus-bouton.png) -Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par defaut par la console et selectionner le cluster de déployement. +Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par défaut par la console. ![ArgoCD-app-details](/img/tuto/4argocd-app-details.png) -Notamment: +Notamment : -- **CLUSTER**: correspond au cluster sur lequel l'application doit être déployée, cela dépends des informations saisie lors de l'étape de [gérer les environnements](/guide/environments-management). -- **TARGET REVISION**: correspond à la branche du repo d'infra à déployer, par defaut il point sur HEAD (master). A adapter si le repo utilise une branche -- **PATH** qui est positionné à base par defaut et qui correspond à un déploiement de type fichiers de manifests ou kustmize. Dans le cas d'un déploiement de type HELM, modifier le PATH point pointer vers la racine en mettant un point dans le champs : . ou préciser le répertoire correspondant à la racine du chart +- **CLUSTER** : correspond au cluster sur lequel l'application doit être déployée, celà dépends des informations renseignées lors de l'étape de [gérer les environnements](/guide/environments-management). +- **TARGET REVISION** : correspond à la branche du dépôt d'infra à déployer, par défaut il point sur HEAD (master). +- **PATH** qui est positionné sur "helm/" par défaut. Vous devez indiquer le bon chemin vers vos fichiers de déploiement de type manifests, kustomize ou helm. - Dans l'onglet **PARAMETERS**, il est possible de surcharger certaines valeurs du fichier values (mais il est préférable de modifier le fichier values directement) Finir la saisie en cliquant sur le bouton *SAVE* -Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le repo sur gitlab Cloud π Native en cliquant sur les boutons: +Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le dépôt sur gitlab Cloud π Native en cliquant sur les boutons: -- *REFRESH* pour forcer la synchronisation depuis le repo gitlab de la plateforme Cloud π Native +- *REFRESH* pour forcer la synchronisation depuis le dépôt gitlab de la plateforme Cloud π Native - *SYNC* pour forcer le rafraichissement entre l'état défini par git et l'état réel des objets créés par ArgoCD. -Une fois le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à : +Une fois que le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à : ![ArgoCD-menus](/img/tuto/4argocd-menus.png) diff --git a/docs/guide/environments-management.md b/docs/guide/environments-management.md index 1c42e7d..d06c69d 100644 --- a/docs/guide/environments-management.md +++ b/docs/guide/environments-management.md @@ -8,7 +8,7 @@ La console crée automatiquement : - un namespace applicatif par environnement sur le cluster correspondant. - le pullsecret associé au projet. - les quotas correspondant à l'environnement sur le namespace - - une application ArgoCD par environnement et par repo de code infrastructure. + - une application ArgoCD par environnement et par dépôt de code infrastructure. ## Création d'un environnement @@ -16,7 +16,7 @@ La console crée automatiquement : Donner : - Un nom à l'environnement, par exemple integration - - Un type (dev / staging / integration / prod) le type d'environnement donne accès à des quotas différents + - Un type environnement (dev / staging / integration / prod), celui-ci donne accès à des quotas différents ![type](/img/environnement/type-env.png) - Un dimensionnement (quota) ![quota](/img/environnement/quota-env.png) diff --git a/docs/guide/get-started.md b/docs/guide/get-started.md index a4523e6..0f6443f 100644 --- a/docs/guide/get-started.md +++ b/docs/guide/get-started.md @@ -19,26 +19,24 @@ Créer un projet sur la console (un détail des opérations à mener est trouvab Ajouter vos collaborateurs sur le projet, un guide est disponible [ici](/guide/team) -Les collaborateurs devant accéder à Argo CD devront être ajoutés à chaque environnement concernés, voir le guide [ici](/guide/team#attribution-de-droits-a-un-membre) ## Etape 4 - Ajouter un dépôt synchronisé -Ajouter vos dépôts (qui devront par la suite être synchronisé - manuellement ou via un automatisation), un guide est disponible [ici](/guide/repositories-management). +Ajouter vos dépôts (qui peuvent être synchronisés - manuellement ou via un automatisation), un guide est disponible [ici](/guide/repositories-management). Il existe deux types de dépôts: -- dépôt avec du code applicatif: génère une image docker utilisée plus tard dans vos déploiements (doit contenir un Dockerfile et un fichier gitlab-ci nommé `.gitlab-ci-dso.yaml`) -- dépôt avec du code d'infrastructure: manifest / template kuztomize / chart helm générant votre infrastructure via ArgoCD +- dépôt avec du code applicatif : génère une image docker utilisée plus tard dans vos déploiements (doit contenir un Dockerfile et un fichier gitlab-ci nommé `.gitlab-ci-dso.yaml`) +- dépôt avec du code d'infrastructure : manifest / template kuztomize / chart helm générant votre infrastructure via ArgoCD -> Note: il est possible d'avoir un seul dépôt avec les 2 fonctionnalités +> Note: il est possible d'avoir un seul dépôt avec les deux fonctionnalités ## Etape 5 - Ajouter un environnement -Un environnement est un namespace cloisonné au sens kubernetes permettant de déployer le code d'infrastructure du dépôt idoine. +Un environnement est un namespace cloisonné au sens kubernetes permettant de déployer le code d'infrastructure. Pour déployer un environnement un guide est disponible [ici](/guide/environments-management). -> Note: les collaborateurs du projet devant intervenir sur ArgoCD concernant l'infrastructure doivent être rajouté sur chaque environnement, un guide disponible [ici](/guide/team#attribution-de-droits-a-un-membre). ## Divers diff --git a/docs/guide/projects-management.md b/docs/guide/projects-management.md index e4e71f2..79a183c 100644 --- a/docs/guide/projects-management.md +++ b/docs/guide/projects-management.md @@ -1,12 +1,12 @@ # Gestion des projets -Un projet est un espace virtuel (namespace au sens kubernetes) cloisonné pour une seule application. +Un projet est un espace virtuel cloisonné pour une seule application. -Chaque projet contient une liste de collaborateurs (voir [Gestion des équipes](/guide/team)) ainsi qu'un ou plusieurs dépôts de code (voir [Gestion des dépôts](/guide/repositories-management.md)) +Celui-ci permet la gestion d'une équipe et des droits associés aux membres (voir [Gestion des équipes](/guide/team)), de dépôts de code (voir [Gestion des dépôts](/guide/repositories-management.md)) ainsi que des environnements (voir [Gestion des environnements](/guide/repositories-management.md)) ## Création d'un projet -Une fois connecté sur la console, le menu gauche présente une entrée "Mes Projets" contenant la liste de ses projets. +Une fois connecté sur la console, le menu gauche présente une entrée "Mes Projets" contenant la liste de vos projets. ![mes projets](/img/tuto/2tuto-mes-projets.png) Cliquez sur le bouton **+ Créer un projet** afin d'ajouter un nouveau projet: @@ -14,31 +14,31 @@ Cliquez sur le bouton **+ Créer un projet** afin d'ajouter un nouveau projet: Sur cet écran il est nécessaire de renseigner : -- **Nom de l'organisation**: correspondant à l'entité administratif de rattachement. -- **Nom du projet**: ce nom servira à créer un groupe dans gitlab de la plateforme Cloud π Native et sera une composante du namespace Kubernetes créé. +- **Nom de l'organisation** : correspondant à l'entité administrative de rattachement. +- **Nom du projet** : ce nom servira à créer un projet sur la plateforme Cloud π Native. Valider la saisie en cliquant sur **Commander mon espace projet** -La création d'un projet va lancer le provisionnement des différents [services](/platform/introduction.html#services-core-proposes-par-la-plateforme), ce qui signifie principalement la configuration de ces outils avec un espace dédié pour le projet, son cloisonnement avec les autres projets et l'authentification des utilisateurs projet dans ces outils. Cette opération pourra prendre quelques minutes et le nouveau projet est présenté en cours de construction: +La création d'un projet va lancer le provisionnement des différents [services](/platform/introduction.html#services-core-proposes-par-la-plateforme), ce qui signifie principalement la configuration de ces outils avec un espace dédié pour le projet, son cloisonnement avec les autres projets et l'authentification des utilisateurs dans ces outils. Cette opération pourra prendre quelques minutes et le nouveau projet est présenté en cours de construction. -A la fin du processus de création, liste de tous vos projets est affiché avec le nouveau projet disponible +A la fin du processus de création, liste de tous vos projets sont affichés avec le nouveau projet disponible. ![tuile projet](/img/guide/project/monprojettuile.png) -Au clic sur le projet, une page de tableau de bord est affichée +Au clic sur le projet, une page de tableau de bord est affichée. ![projet - tableau de bord](/img/guide/project/monprojet_tableaudebord.png) -Deux informations affichées: +Deux informations concernant les statuts sont affichés : - si le projet est verrouillé, demander à la ServiceTeam les raisons et le déverrouillage du projet -- si les dernières opérations concernant le projet ont réussi +- si les dernières opérations ont réussi -Un certain nombre d'actions sont disponibles: +Un certain nombre d'actions sont disponibles : -- **Reprovisionner le projet**: la console DSO étant en cours de développement actif, des changements ont lieu et peuvent perturber le bon fonctionnement des projets. Ce bouton permet de mettre à jour son projet par rapport aux derniers développement de la console. -- **Afficher les secrets des services**: affiche des configurations utiles mais sensible des projets (seul le propriétaire du projet peut voir les secrets) +- **Reprovisionner le projet** : la console DSO étant en cours de développement actif, divers changements ont lieu (correction de bugs, ajouts de nouvelles fonctionnalitées). Ce bouton permet de mettre à jour son projet par rapport aux derniers développement de la console. +- **Afficher les secrets des services** : affiche des configurations utiles mais sencible des projets (par défaut seul le propriétaire du projet peut voir les secrets) ![mon projet - secrets](/img/guide/project/monprojet_secrets.png) La partie GitLab permet d'avoir le token ainsi que l'id du dépôt mirror (permettant de cloner son dépôt primaire sur Cloud Pi Native). Cela permet d'automatiser cette action via des pipelines sur votre dépôt primaire. Concernant Harbor, la registry stockant les images construites sur la plateforme CPiN Pour la section Kubernetes, le nom du secret permettant de s'authentifier auprès d'Harbor. -- **Supprimer le projet monprojet**: après confirmation, supprime définitivement le projet. Aucune restauration n'est possible. +- **Supprimer le projet monprojet** : après confirmation, supprime définitivement le projet. Aucune restauration n'est possible. diff --git a/docs/guide/repositories-management.md b/docs/guide/repositories-management.md index c8d2d8e..304f34a 100644 --- a/docs/guide/repositories-management.md +++ b/docs/guide/repositories-management.md @@ -1,6 +1,6 @@ # Gestion des dépôts -En phase de développement, les équipes projets sont autonomes et travaillent avec leurs outils sans contraintes apportées par la plateforme Cloud π Native. La synchronisation des dépôts est le processus qui permet de *copier* les dépôts externes stockés sur github, gitab.com, bitbucket, etc. vers le repo de code de la plateforme Cloud π Native. la seule contrainte est que le repo externe soit accessible depuis Internet. Ce repo peut être public ou privé. Pour plus d'information, voir la page dédiée au [repo de code](/services/gitlab) +En phase de développement, les équipes projets sont autonomes et travaillent avec leurs outils. La synchronisation des dépôts est le processus qui permet de *copier* les dépôts externes stockés sur github, gitab.com, bitbucket, etc. vers le dépôt de code de la plateforme Cloud π Native. la seule contrainte est que le dépôt externe soit accessible depuis Internet. Ce dépôt peut être public ou privé. Pour plus d'information, voir la page dédiée au [dépôt de code](/services/gitlab) Cliquez sur le menu gauche **Dépôts** ![menu-projet-depot](/img/tuto/3tuto-depots.png) @@ -9,44 +9,38 @@ Cliquez sur le menu gauche **Dépôts** Puis sur le bouton **+ Ajouter un nouveau dépôt** -Remplir le formulaire de des dépôts: +Remplir le formulaire des dépôts : -- Choisir un nom -- Saisir l'URL du repo git distant. Dans le cas d'un repo privé cocher la case et préciser les credentials d'accès -- Deux types de repo peuvent être ajoutés: - - Un repo applicatif: contenant du code applicatif et qui sera construit afin de créer des images Docker à déployer sur l'infrastructure cible. - - Un repo d'infra: contenant les manifests de déploiement ou chart HELM contenant *l'infrastructure as code* du projet à déployer -- Il est possible de spécifier si le dépôt sera lié ou non à un dépôt externe (Github, GitLab, Bitbucket, ...). +- Choisir un nom pour votre dépôt interne (herbéger sur la plateforme) +- Deux types de dépôt peuvent être ajoutés : + - Un dépôt applicatif: contenant du code applicatif et qui sera construit afin de créer des images Docker à déployer sur l'infrastructure cible. Choix par défaut. + - Un dépôt d'infra: contenant les manifests de déploiement ou chart HELM contenant *l'infrastructure as code* du projet a déployé. Il suffit de cocher la case associée. +- Si vous n'avez pas de dépôts distants vous pouvez selectionner le bouton "Dépôt sans source git externe". +- Dans le cas contraire, il vous suffit de saisir l'URL du dépôt git distant. Dans le cas d'un dépôt privé cocher la case et préciser les informations d'accès **Il est recommandé de passer par l'ajout d'un dépôt dans la console et non de le faire directement dans Gitlab. A chaque modification dans la console, celle-ci vérifie la cohérence des dépôts configurés avec ceux qui existent vraiment et supprime ceux en trop.** ![ajout dépôt](/img/tuto/3tuto-depots-ajouter.png) -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. Ces fichiers seront utilisés par le GitLab de Cloud π Native pour effectuer les divers tests, scans et déploiements du projet. - -![gitlab-ci-dso](/img/tuto/3tuto-depots-ajouter-gitlab-ci.png) - Cliquer enfin sur le bouton `Ajouter le dépôt`. -Lorsqu'un dépôt est créé dans la console en tant que `dépôt d'infrastructure`, la plateforme créée automatiquement l'application [ArgoCD](https://argo-cd.readthedocs.io/en/stable/) associée qui permettra le déploiement. - -Une fois que le dépôt est correctement ajouté, il apparait avec une icône indiquant son statut : +> Cette opération demande d'attendre jusqu'à quelques minutes. -depots synchronisés ok +Lorsqu'un dépôt est créé dans la console en tant que `dépôt d'infrastructure`, la plateforme créée automatiquement l'application [ArgoCD](https://argo-cd.readthedocs.io/en/stable/) associée qui permettra le déploiement. -> Cette opération demande d'attendre jusqu'à quelques minutes. -> -> Des exemples de dépôts sont disponibles dans la sections [tutoriels](tutorials). +> Des exemples de dépôts sont disponibles dans la section [tutoriels](tutorials). ## Synchronisation d'un dépôt -Il est possible de synchroniser son dépôt depuis la console. Pour cela cliquer sur la tuile d'un dépôt, une page s'ouvre avec tout en haut la branche à synchroniser et un bouton **Lancer la synchronisation** +Il est possible de synchroniser son dépôt depuis la console, pour cela il suffit de cliquer sur la tuile d'un dépôt. +Deux options sont disponibles : + - Synchroniser toutes les branches + - Renseigner le nom d'une branche a synchronisé +Le bouton **Lancer la synchronisation** démarre une pipeline sur la GitLab DSO afin de synchroniser le dépôt. ![repository synchro](/img/guide/repository_synchro.png) -Ce bouton lancer une pipeline sur la GitLab DSO afin de synchroniser la branche voulue. - -> Il est possible de lancer via curl cette pipeline, le propriétaire du projet peut retrouver la commande dans les secrets du projet. +> Il est possible de lancer via curl cette pipeline,la commande est disponible dans les secrets du projet. > Cette commande pourra servir de base pour un GitHub action, etc... > > Exemple de GitHub Action : @@ -74,4 +68,4 @@ Ce bouton lancer une pipeline sur la GitLab DSO afin de synchroniser la branche > "https://gitlab.apps.dso.numerique-interieur.com/api/v4/projects/$GIT_MIRROR_PROJECT_ID/trigger/pipeline" > ``` > -> A noter dans l'exemple précedent qu'il convient d'utiliser le bon url Gitlab. +> A noter dans l'exemple précèdent qu'il convient d'utiliser le bon url Gitlab. diff --git a/docs/guide/roles.md b/docs/guide/roles.md index 41debab..968d329 100644 --- a/docs/guide/roles.md +++ b/docs/guide/roles.md @@ -10,7 +10,7 @@ La page Rôles présente la liste des rôles du projet : ![default](/img/guide/roles/default.png) -Par défaut le rôle `Tout le monde` regroupe tous les membres de l'équipe avec les permissions suivantes: +Par défaut le rôle `Tout le monde` regroupe tous les membres de l'équipe avec les permissions suivantes : - Reprovisionner le projet - Voir les environnements @@ -24,22 +24,22 @@ Cliquer sur le bouton `Ajouter un rôle`. Le champ de texte `Nom du rôle` permet de choisir le nom du rôle à créer. -Détail des permissions: +Détail des permissions : - Projet - - Gérer le projet: Permet de gérer tout le projet et ses ressources associées - - Gérer les rôles du projet: Permet de gérer les rôles du projet et les membres associés (attention, les membres associés peuvent donc gérer leurs propres permissions) - - Gérer les membres du projet: Permet d'inviter des utilisateurs et de les retirer - - Afficher les secrets: Permet d'afficher les secrets générés par les services (sur la page tableau de bord) - - Reprovisionner le projet: Permet de reprovisionner le projet (sur la page tableau de bord) + - Gérer le projet : Permet de gérer tout le projet et ses ressources associées + - Gérer les rôles du projet : Permet de gérer les rôles du projet et les membres associés (attention, les membres associés peuvent donc gérer leurs propres permissions) + - Gérer les membres du projet : Permet d'inviter des utilisateurs et de les retirer + - Afficher les secrets : Permet d'afficher les secrets générés par les services (sur la page tableau de bord) + - Reprovisionner le projet : Permet de reprovisionner le projet (sur la page tableau de bord) - Environnements - - Gérer les environnement: Permet de créer, éditer, supprimer des environnements - - Voir les environnement: Permet de visualiser tous les environnements et leurs configurations + - Gérer les environnement : Permet de créer, éditer, supprimer des environnements + - Voir les environnement : Permet de visualiser tous les environnements et leurs configurations - Dépôts - - Gérer les dépôts: Permet de créer, éditer, supprimer des dépôts - - Voir les dépôts: Permet de visualiser tous les dépôts et leurs configurations + - Gérer les dépôts : Permet de créer, éditer, supprimer des dépôts + - Voir les dépôts : Permet de visualiser tous les dépôts et leurs configurations Cliquer sur le bouton `Enregistrer` pour créer le rôle. @@ -53,11 +53,11 @@ Dans l'exemple, Aurahan est associé au rôle Dev. Les modifications concernant les membres d'un rôle sont sauvegardées automatiquement. -Il est possible de retrouver un récapitulatif des rôles associés aux membres du projet sur la page `Equipes`: +Il est possible de retrouver un récapitulatif des rôles associés aux membres du projet sur la page `Equipes` : ![Menu](/img/guide/roles/recap_membres_projet.png) -Ici: +Ici : - Baptiste est le créateur du projet - Pierre a le rôle ops @@ -67,3 +67,46 @@ Ici: Pour supprimer un rôle, sélectionner celui-ci dans la liste des rôles et cliquer sur le bouton `Supprimer` +## Exemple de rôle + +Voici quelques exemples de rôle pour une équipe. + +Admin : + +> Celui-ci permet de gérer l'ensemble des ressources du projet + +- Projet + - [x] Gérer le projet + - [ ] Gérer les rôles du projet + - [ ] Gérer les membres du projet + - [ ] Afficher les secrets + - [ ] Reprovisionner le projet + +- Environnements + - [ ] Gérer les environnement + - [ ] Voir les environnement + +- Dépôts + - [ ] Gérer les dépôts + - [ ] Voir les dépôts + +Devops : + +> Celui-ci permet de gérer les dépôts ainsi que les environnements + +- Projet + - [ ] Gérer le projet + - [ ] Gérer les rôles du projet + - [ ] Gérer les membres du projet + - [x] Afficher les secrets + - [x] Reprovisionner le projet + +- Environnements + - [x] Gérer les environnement + - [x] Voir les environnement + +- Dépôts + - [x] Gérer les dépôts + - [x] Voir les dépôts + + diff --git a/docs/guide/team.md b/docs/guide/team.md index 6811d11..d950eef 100644 --- a/docs/guide/team.md +++ b/docs/guide/team.md @@ -1,6 +1,6 @@ # Gestion des équipes -Cette page présente la gestion des équipes sur un projets. +Cette page présente la gestion des équipes sur un projet. Cette fonctionnalité se trouve dans le menu "Equipe" sur un projet. @@ -18,7 +18,7 @@ Depuis cette liste, il est possible de retirer une personne de la liste sur l'ic L'ajout d'une personne au projet s'effectue sur la partie basse de la page en saisissant l'adresse e-mail d'une personne existante dans le référentiel utilisateur CPiN. -Lors de la saisie une auto-complétion permet de rechercher les personnes existantes dans le référentiel utilisateurs +Lors de la saisie une auto-complétion permet de rechercher les personnes existantes dans le référentiel utilisateur. ![Menu](/img/team/members.png) @@ -26,15 +26,5 @@ Lors de la saisie une auto-complétion permet de rechercher les personnes exista ## Attribution de droits à un membre -> Attention, seul le créateur du projet peut ajouter des repos de code à un projet. +Une fois qu'une personne a été ajoutée à un projet, un rôle par défaut lui est attribué. Celui-ci lui permet de voir les dépôts, les environnements ainsi que l'option de reprovisionner le projet. Vous pouvez consulter le guide [suivant](/guide/roles) pour une gestion des droits avancés. -Une fois qu'une personne a été ajoutée à un projet, il convient de lui donner des droits sur les environnements du projet. Pour cela, aller dans le menu environnement, choisir l'environnement sur lequel ajouter la personne et aller en bas de page. Saisir le nom de la personne dans le champ de saisie Accréditer un membre du projet. - -![Attribution de droits](/img/team/permission-environnement.png) - -Une fois selectionner, lui attribuer les droits (sur ArgoCD): - - r : droits de lecture seule sur l'environnement (visibilité du projet sur ArgoCD) - - rw : droits de lecture et écriture sur l'environnement (visibilité du projet sur ArgoCD et modification des values) - - rwd : droits de lecture, écriture et suppression sur l'environnement (visibilité du projet sur ArgoCD et modification des values et suppression des objets : pods etc.) - -> L'attribution de droits à un membre pour un environnement est une opération *nécessaire* pour donner accès à ArgoCD sur l'environnement concerné.