Plateforme Cedille

• 1: Document de vision
• 2: Pour commencer
• 2.1: Préparer votre environnement local
• 2.2: Exemple
• 3: Workflow
• 4: Hardware
• 5: Applications
• 5.1:
• 5.2: Déployer des applications
• 5.3: Déployer des applications système
• 6: Cluster Kubernetes
• 6.1: Sandbox
• 6.2: Prod
• 6.3: Staging
• 7: SRE
• 7.1: SLO
• 7.2: Surveillance
• 7.3: Sécurité
• 8: Référence
• 8.1: Paramètre de référence
• 9: LOG791
• 9.1: Rétrospectives
• 9.2: Rapport final
• 9.3: Rétrospective 1
• 9.4:
• 9.5: Rétrospective 2
• 9.6: Rétrospective 3
• 10: Guide de contribution

1 - Document de vision

Plateforme CEDILLE - Document de vision

Organization: Cedille, École de Technologie Supérieure

Voici une vue d’ensemble sur notre nouvelle plateforme CEDILLE. Cette section est conçue pour vous donner une vue d’ensemble claire du ‘pourquoi’ et du ‘quoi’ de notre projet. Ici, nous plongeons dans la raison d’être de notre plateforme basée sur Kubernetes, exploitée par le SaaS Omni de SideroLabs, décrivant en détail pourquoi nous avons entrepris ce voyage et comment nous pensons que cela va transformer la façon dont on gère nos services d’hébergement sur nos serveurs bare-metal.

Table des matières

• Plateforme CEDILLE - Document de vision
  • Table des matières
  • 1. Survol
    • 1.1 Problématique
    • 1.2 Objectif
    • 1.3 Porté
    • 1.3 Définitions et acronymes
  • 2. Position du produit
    • 2.1 Énoncé du problème
    • 2.2 Énoncé du produit
  • 3. Utilisateur et parties prenantes
    • 3.1 Sommaire des parties prenantes
    • 3.2 Sommaire des utilisateurs
    • 3.3 Environnement utilisateur
  • 3.4 Besoins des principaux utilisateurs
  • 4. Présentation du produit
    • 4.1 Contexte du produit
    • 4.2 Hypothèses et dépendances
      • Hypothèses
      • Dépendances
    • 4.3 Licence
    • 4.4 Caractéristiques du produit
    • 5. Contraintes
    • 6. Attributs de qualité
  • 7. Autres exigences
    • 7.1 Normes et standards
    • 7.2 Exigences en matière de documentation

1. Survol

1.1 Problématique

Le club Cédille est responsable de l’hébergement et de l’aide au développement d’un nombre important de sites web et services web pour les clubs étudiants de l’ÉTS. De plus, le club cherche à donner à ses membres une occasion d’apprentissage des technologies DevOps, Kubernetes et de gestion de serveur.

En ce moment, les services sont déployés sur un Kubernetes hébergé par Google Cloud (GKE). Toutefois, cette plateforme engendre des coûts importants et l’augmentation de clubs hébergés rend le maintien d’utilisation de cette plateforme une difficulté financière. De plus, la structure des opérations de maintenances et de déploiement est en ce moment trop complexe pour assurer une courbe d’apprentissage intéressante pour les membres du club.

Aussi, la solution actuelle n’offre pas assez de flexibilité et de contrôle pour permettre aux membres d’expérimenter les technologies utilisées. Enfin, l’ÉTS est en processus de révision de ses pratiques de sécurité suite aux nouvelles directives gouvernementales, ainsi CÉDILLE doit retravailler son infrastructure pour répondre aux nouvelles exigences.

1.2 Objectif

À cause des problèmes mentionnées et des nouveaux requis, le club CÉDILLE a récemment acheté des serveurs physiques et y a installé Kubernetes. La décision a été prise d’en profiter pour revoir l’ensemble de l’infrastructure et des systèmes DevOps afin de mieux répondre aux besoins du club, de ses clients et de l’ÉTS.

Pour ce faire, nous déploieront plusieurs systèmes d’automatisation, d’observabilité et de redondance. La volonté sera ici de rendre l’expérience des clients de CÉDILLE plus fluide et plus consistante. De plus, nous viseront à rendre plus clair le processus de développement et maintenance pour les membres du club CÉDILLE eux-mêmes. Lorsque possible, les logiciels libres et cloud-native seront à favoriser afin de respecter la philosophie du club étudiant CÉDILLE.

1.3 Porté

Cette solution devra être exhaustive afin de couvrir les différents cas d’utilisation tout en respectant les requis de sécurité demandé par l’ÉTS. Toutefois, il est important de délimiter ce qui fait partie du projet et ce qui n’en fera pas parti à ce stage-ci:

Inclus

• Toutes les définitions de l’infrastructure et de la typologie réseau
• Les systèmes de redondance
• Les systèmes d’observabilité
• La gestion d’environnements (pré-production, productions, etc.)
• La gestion des déploiements, notamment progressifs (bleu-vert, canary…)
• Les systèmes de sécurité
• Pipelines de tests et déploiement (CI/CD)

Exclus

• Configuration d’environnement de développements pour les développeurs
• Programmation des sites web qui seront sur l’infrastructure
• Effectuer la migration complète de services (certains services en preuve de concept d’ici la fin de ce projet, les autres après la fin de ce projet)

1.3 Définitions et acronymes

Table 1.3.1: Définitions et acronymes

2. Position du produit

2.1 Énoncé du problème

Le club Cédille assume la tâche d’héberger et de soutenir le développement d’une multitude de sites web et services en ligne pour les associations étudiantes de l’ÉTS. En outre, le club vise à offrir à ses membres des opportunités d’acquisition de compétences dans les domaines du DevOps, de Kubernetes et de la gestion des serveurs.

À l’heure actuelle, notre infrastructure repose sur un cluster Kubernetes géré par Google Cloud (GKE). Cependant, les frais associés à cette plateforme sont élevés, et avec l’augmentation du nombre de clubs que nous soutenons, les coûts deviennent financièrement problématiques. De surcroît, la gestion majoritairement automatisée par Google Cloud limite notre flexibilité pour personnaliser nos solutions d’hébergement et restreint les occasions d’apprentissage pour nos membres.

Table 2.1.1: Énoncé du problème

2.2 Énoncé du produit

Le club a décidé de migrer les serveurs vers des serveurs physiques, qui seront déployés à l’ÉTS. Le produit nommé Plateforme CEDILLE est une infrastructure d’hébergement basée sur des serveurs physiques, déployée à l’ÉTS, et gérée via une licence Omni de Sidero Labs. Cette plateforme vise à offrir une solution durable et évolutive pour héberger les sites web et les autres services des clubs étudiants. La plateforme utilise une architecture GitOps, intégrant divers outils d’automatisation, de surveillance et de sécurité pour simplifier la gestion tout en maintenant un haut niveau de performance et de sécurité.

Tableau 2.2.1: Énoncé du produit

3. Utilisateur et parties prenantes

3.1 Sommaire des parties prenantes

Les parties prenantes sont toutes les personnes ou entités ayant un intérêt dans la réalisation du projet.

Table 3.1.1: Résumé des parties prenantes

3.2 Sommaire des utilisateurs

Les utilisateurs sont toutes les personnes ou entités qui utiliseront ce produit.

Table 3.2.1 : Sommaire des utilisateurs

3.3 Environnement utilisateur

Les administrateurs de la plateforme (U1) peuvent se connecter à la Plateforme CEDILLE via une interface web ou des outils en ligne de commande pour gérer les différents services. Le Département informatique de l’ÉTS (S3) veille à ce que la connectivité et la sécurité des services soient maintenues, tout en respectant les réglementations et les normes en vigueur.

Les clubs étudiants et leurs membres (U2) interagissent avec la Plateforme CEDILLE via des portails web et des applications pour accéder à des informations, des services et des ressources diverses. Ils doivent également communiquer leurs besoins et exigences via le serveur Discord.

La réglementation des clubs est supervisée par la Régie des clubs de l’ÉTS (S2), qui s’assure que la Plateforme CEDILLE sert les intérêts des clubs étudiants et est en conformité avec la réglementation institutionnelle.

Les clubs étudiants de l’ÉTS (S4) jouent un rôle actif en tant que fournisseurs d’exigences et de commentaires. Ils sont les utilisateurs finaux des services et ont donc un rôle clé à jouer pour s’assurer que la Plateforme CEDILLE répond à leurs besoins et attentes.

L’ensemble de la Plateforme CEDILLE et des services connexes doit être conforme aux normes et aux bonnes pratiques en matière de DevOps telle que défini à la section Normes et standards.

Toutes les parties doivent respecter les normes et les protocoles mis en place pour assurer la sécurité, la performance et la disponibilité de la Plateforme CEDILLE. Ces normes sont définies et maintenues par le club CEDILLE (S1) et le Département informatique de l’ÉTS (S3).

3.4 Besoins des principaux utilisateurs

Les besoins sont déterminés à partir d’une série d’entrevues et rencontre avec les parties prenantes. Des rapports de ces entrevues et rencontres se trouvent à l’annexe 1 de ce document.

De plus, les besoins d’administrations sont largement déterminés par les auteurs de ce document, puisqu’ils seront aussi responsable de l’administration de la plateforme qui sera mise en place.

Tableau 3.4.1: Définition des priorité

Table 3.4.1: Besoins des principaux utilisateurs

4. Présentation du produit

Le produit est un système qui va permettre le déploiement et l’hébergement d’applications Web et autres pour les clubs étudiants de l’ÉTS. L’objectif est que l’architecture du système suit la philosophie du DevOps dans chaque couche d’implémentation.

4.1 Contexte du produit

Figure 4.1.1: Contexte du produit

4.2 Hypothèses et dépendances

Cette section énumère les hypothèses et dépendances qui sont essentielles pour le développement et le déploiement de la Plateforme CEDILLE.

Hypothèses

• Disponibilité du Matériel: Nous supposons que tous les serveurs et équipements matériels nécessaires seront disponibles en temps opportun et répondront aux spécifications de configuration requises.
• Expertise Technique: L’hypothèse est faite que les membres du club ont ou acquerront les compétences nécessaires en technologies DevOps, Kubernetes et gestion de serveur.
• Soutien Institutionnel: Nous supposons que l’ÉTS fournira un soutien continu pour le projet, notamment en termes d’espaces pour les serveurs et d’accès à des ressources en réseau.

Dépendances

• Système d’Exploitation: Notre plateforme dépend du système d’exploitation Talos linux compatibles avec Kubernetes.
• Kubernetes: Le bon fonctionnement de la plateforme repose sur la dernière version stable de Kubernetes.
• Outils de Surveillance: La plateforme dépend de solutions de surveillance comme Pixie, OpenTelemetry, ClickHouse et Grafana pour le suivi des performances et de l’état du système.

4.3 Licence

Étant donné que le club CEDILLE a une dimension éducative et vise à enseigner les technologies DevOps, Kubernetes, et la gestion de serveur, le choix d’une licence qui favorise la flexibilité, l’accessibilité et la collaboration est crucial. C’est pourquoi nous avons opté pour la licence Apache 2.0 pour notre infrastructure.

4.4 Caractéristiques du produit

Tableau 4.4.1: Définition des priorité

Tableau 4.4.2 : Caractéristiques du produit

5. Contraintes

Table 5.1 :Contraintes

6. Attributs de qualité

Interopérabilité

AQ1 - Le système doit facilement s’intégrer avec des outils tiers tels que des services d’observabilité.

Performance

AQ2 – La performance des application des clubs doivent être suffisants selon les besoins de chaque application.

Modifiabilité

AQ3 – Tout élement du système doit être facilement modifiable, préférablement par le code source.

Securité

AQ4 – La confidentialité des données doit être conservée en tout temps.

AQ5 – La configuration du sytème est seulement modifiable par les parties autorisés.

AQ6 – Les secrets sont chriffés au repos et ne sont pas exposés plubliquement.

Usabilité

AQ6 – Chaque couche du système doit être documenté

AQ7 – Le système doit être compréhensible pour tout membre du club Cedille (nouveau et anciens).

Évolutivité

AQ8 – Le système devrait gérer la mise à l’échelle des applications selon les besoins en performance.

7. Autres exigences

7.1 Normes et standards

• On vise à utilisé la norme ISO 32675:2022 comme ligne directrice pour notre infrastructure.

7.2 Exigences en matière de documentation

• Architecture Technique : Schémas et explications détaillées de l’architecture des serveurs, du réseau et de la pile technologique.
• Documentation de la Configuration : Instructions pour la mise en place et la configuration de l’environnement, y compris les serveurs physiques, Kubernetes, et tous les autres outils utilisés.
• Manuel Utilisateur : Documentation destinée aux membres du club et autres utilisateurs de la plateforme, expliquant comment déployer et gérer leurs services.
• Procédures de Secours et de Restauration : Protocoles à suivre en cas de défaillance du système ou d’autres types d’urgences.

2 - Pour commencer

Information in this section helps your user try your project themselves.

• What do your users need to do to start using your project? This could include downloading/installation instructions, including any prerequisites or system requirements.

• Introductory “Hello World” example, if appropriate. More complex tutorials should live in the Tutorials section.

Consider using the headings below for your getting started page. You can delete any that are not applicable to your project.

Prerequisites

Are there any system requirements for using your project? What languages are supported (if any)? Do users need to already have any software or tools installed?

Installation

Where can your user find your project code? How can they install it (binaries, installable package, build from source)? Are there multiple options/versions they can install and how should they choose the right one for them?

Setup

Is there any initial setup users need to do after installation to try your project?

Try it out!

Can your users test their installation, for example by running a command or deploying a Hello World example?

2.1 - Préparer votre environnement local

Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

90’s four loko seitan photo booth gochujang freegan tumeric listicle fam ugh humblebrag. Bespoke leggings gastropub, biodiesel brunch pug fashion axe meh swag art party neutra deep v chia. Enamel pin fanny pack knausgaard tofu, artisan cronut hammock meditation occupy master cleanse chartreuse lumbersexual. Kombucha kogi viral truffaut synth distillery single-origin coffee ugh slow-carb marfa selfies. Pitchfork schlitz semiotics fanny pack, ugh artisan vegan vaporware hexagon. Polaroid fixie post-ironic venmo wolf ramps kale chips.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

First Header 2

This is a normal paragraph following a header. Knausgaard kale chips snackwave microdosing cronut copper mug swag synth bitters letterpress glossier craft beer. Mumblecore bushwick authentic gochujang vegan chambray meditation jean shorts irony. Viral farm-to-table kale chips, pork belly palo santo distillery activated charcoal aesthetic jianbing air plant woke lomo VHS organic. Tattooed locavore succulents heirloom, small batch sriracha echo park DIY af. Shaman you probably haven’t heard of them copper mug, crucifix green juice vape single-origin coffee brunch actually. Mustache etsy vexillologist raclette authentic fam. Tousled beard humblebrag asymmetrical. I love turkey, I love my job, I love my friends, I love Chardonnay!

Deae legum paulatimque terra, non vos mutata tacet: dic. Vocant docuique me plumas fila quin afuerunt copia haec o neque.

On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.

Scenester tumeric pickled, authentic crucifix post-ironic fam freegan VHS pork belly 8-bit yuccie PBR&B. I love this life we live in.

Second Header 2

This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

Header 3

This is a code block following a header.

Next level leggings before they sold out, PBR&B church-key shaman echo park. Kale chips occupy godard whatever pop-up freegan pork belly selfies. Gastropub Belinda subway tile woke post-ironic seitan. Shabby chic man bun semiotics vape, chia messenger bag plaid cardigan.

Header 4

• This is an unordered list following a header.
• This is an unordered list following a header.
• This is an unordered list following a header.

Header 5

1. This is an ordered list following a header.
2. This is an ordered list following a header.
3. This is an ordered list following a header.

Header 6

There’s a horizontal rule above and below this.

Here is an unordered list:

• Liverpool F.C.
• Chelsea F.C.
• Manchester United F.C.

And an ordered list:

1. Michael Brecker
2. Seamus Blake
3. Branford Marsalis

And an unordered task list:

• Create a Hugo theme
• Add task lists to it
• Take a vacation

And a “mixed” task list:

• Pack bags
• ?
• Travel!

And a nested list:

• Jackson 5
  • Michael
  • Tito
  • Jackie
  • Marlon
  • Jermaine
• TMNT
  • Leonardo
  • Michelangelo
  • Donatello
  • Raphael

Definition lists can be used with Markdown syntax. Definition headers are bold.

Name

Godzilla

Born

1952

Birthplace

Japan

Color

Green

Tables should have bold headings and alternating shaded rows.

If a table is too wide, it should scroll horizontally.

Code snippets like var foo = "bar"; can be shown inline.

Also, this should vertically align with this and this.

Code can also be shown in a block element.

foo := "bar";
bar := "foo";

Code can also use syntax highlighting.

func main() {
  input := `var foo = "bar";`

  lexer := lexers.Get("javascript")
  iterator, _ := lexer.Tokenise(nil, input)
  style := styles.Get("github")
  formatter := html.New(html.WithLineNumbers())

  var buff bytes.Buffer
  formatter.Format(&buff, style, iterator)

  fmt.Println(buff.String())
}

Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.

Inline code inside table cells should still be distinguishable.

Small images should be shown at their actual size.

Large images should always scale down and fit in the content container.

The photo above of the Spruce Picea abies shoot with foliage buds: Bjørn Erik Pedersen, CC-BY-SA.

Components

Alerts

Another Heading

Add some sections here to see how the ToC looks like. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

This Document

Inguina genus: Anaphen post: lingua violente voce suae meus aetate diversi. Orbis unam nec flammaeque status deam Silenum erat et a ferrea. Excitus rigidum ait: vestro et Herculis convicia: nitidae deseruit coniuge Proteaque adiciam eripitur? Sitim noceat signa probat quidem. Sua longis fugatis quidem genae.

Pixel Count

Tilde photo booth wayfarers cliche lomo intelligentsia man braid kombucha vaporware farm-to-table mixtape portland. PBR&B pickled cornhole ugh try-hard ethical subway tile. Fixie paleo intelligentsia pabst. Ennui waistcoat vinyl gochujang. Poutine salvia authentic affogato, chambray lumbersexual shabby chic.

Contact Info

Plaid hell of cred microdosing, succulents tilde pour-over. Offal shabby chic 3 wolf moon blue bottle raw denim normcore poutine pork belly.

External Links

Stumptown PBR&B keytar plaid street art, forage XOXO pitchfork selvage affogato green juice listicle pickled everyday carry hashtag. Organic sustainable letterpress sartorial scenester intelligentsia swag bushwick. Put a bird on it stumptown neutra locavore. IPhone typewriter messenger bag narwhal. Ennui cold-pressed seitan flannel keytar, single-origin coffee adaptogen occupy yuccie williamsburg chillwave shoreditch forage waistcoat.

This is the final element on the page and there should be no margin below this.

2.2 - Exemple

3 - Workflow

4 - Hardware

Tutorials are complete worked examples made up of multiple tasks that guide the user through a relatively simple but realistic scenario: building an application that uses some of your project’s features, for example. If you have already created some Examples for your project you can base Tutorials on them. This section is optional. However, remember that although you may not need this section at first, having tutorials can be useful to help your users engage with your example code, especially if there are aspects that need more explanation than you can easily provide in code comments.

5 - Applications

Application existantes

Système

Mayastor

Description de la configuration actuelle

Mayastor est un système de stockage en blocs distribué implémenté avec le protocole NVMEoF. Entre autres, il permet l’accès et la réplication des données sur tous les noeuds du cluster Kubernetes.

En ce moment, on maintient deux copies de toute donnée en tout temps:

# /system/mayastor/storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
parameters:
  ioTimeout: "30"
  protocol: nvmf
  repl: "2"
  stsAffinityGroup: 'true'
provisioner: io.openebs.csi-mayastor

Justification du choix

Comparé a d’autre solutions comme Ceph:

• est très simple a déployer et configurer
• à une basse complexité de son système et ses composantes
• est concu dès le debut pour l’utilisation dans Kubernetes

Par exemple, on a fait plusieurs tentatives d’installation de Ceph, mais le système n’était pas stable pour la petite taille de cluster et était très mal-adapté pour l’utilisation dans Kubernetes.

References utilisés pour le déploiement

• https://www.talos.dev/v1.5/kubernetes-guides/configuration/storage/#mayastor
• https://mayastor.gitbook.io/introduction/quickstart/deploy-mayastor

Utilisation

Le StorageClass mayastor est selectionné par défault par Kubernetes. Il suffit de créer des PersitentVolumeClaims (https://kubernetes.io/docs/concepts/storage/persistent-volumes) et les volumes seront crées dans Mayastore automatiquement.

ArgoCD

ArgoCD est notre système de GitOps. Il s’occupe de déployer et synchronizer toutes les ressources YAML dans notre repértoire Plateforme-Cedille. Pour le faire, on utiliser Kustomize pour regrouper toutes les ressources de type Application dans le dossier /apps/argo-apps/.

Voici un apercu visuel de cette structure:

TODO: Insérer graphique.

Configuration

Permissions RBAC La configuration RBAC (Role-Based Access Control) dans ArgoCD permet de définir des politiques de sécurité spécifiques pour différents utilisateurs et groupes. Dans notre cas, nous avons défini des rôles au sein de notre organisation Cedille qui correspondent aux différents niveaux d’accès nécessaires.

Les opérateurs (role:org-operators), qui sont membres du groupe ClubCedille:SRE, ont les permissions suivantes :

Obtenir des informations sur les clusters, certificats et dépôts (repositories). Synchroniser, créer et supprimer les applications. Lire, créer, mettre à jour et supprimer les clés GPG. Ces permissions sont configurées via les lignes commençant par p dans le fichier system/argocd/argocd-values.yaml sous policy.csv. Le * indique que l’action est autorisée pour toutes les instances de la ressource spécifiée.

Les relations entre les utilisateurs/groupes GitHub et les rôles ArgoCD sont définies par les lignes commençant par g. Par exemple, tous les membres du groupe ClubCedille:SRE sur GitHub sont assignés au rôle role:org-operators dans ArgoCD et ClubCedille:Exec sont assignés au rôle admin.

Intégration SSO avec GitHub ArgoCD est configuré pour utiliser OAuth2 de GitHub comme fournisseur d’authentification. Cela permet aux membres de notre organisation GitHub de se connecter à ArgoCD avec leurs identifiants GitHub.

Ingress - Contour

Contour est une solution d’Ingress Controller pour Kubernetes. Elle utilise le serveur proxy Envoy comme back-end.

Configuration

Le service proxy de Envoy à été configuré avec un Nodeport pour diriger le traffic externe vers contour qui achemine ensuite les requêtes vers les services dédiés.

Tester

Commencer par déployer une application web comme httpbin. À partir du repertoire du projet :

kubectl apply -f apps/testing/httpbin.yaml

Vérifier ensuite que les 3 pods arrivent à un status Running:

kubectl get po,svc,ing -l app=httpbin

Afin d’utiliser Contour et Envoy, on va utiliser la fonction kubectl port-foward pour diriger le traffic vers envoy :

kubectl -n projectcontour port-forward service/envoy 8888:80

Puis visiter http://local.projectcontour.io:8888/. Pour notre environnement de production, on utiliserait l’adresse du service de Envoy.

Pour plus d’informations sur Contour, consultez la documentation officielle.

Kubevirt

KubeVirt étend les fonctionnalités de Kubernetes en ajoutant des workloads de machines virtuelles à côté des conteneurs.

Configuration

KubeVirt est configuré pour permettre l’exécution et la gestion de machines virtuelles au sein du cluster Kubernetes. Il est nécessaire d’avoir krew installé.

Tester

Pour tester une machine virtuelle Ubuntu, exécutez cette commande:

kubectl virt vnc ubuntu-vm -n vms

Containerized data importer (CDI)

Pour créer votre propre VM à partir d’un ISO, vous devez utiliser le CDI de Kubevirt qui est déjà installé sur notre cluster.

Pour ce faire, créez un PVC (dans cette situation, l’iso d’ubuntu 22.04.3 va être importé dans le PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iso-ubuntu-20-04
  namespace: vms
  labels:
    app: containerized-data-importer
  annotations:
    cdi.kubevirt.io/storage.import.endpoint: "https://releases.ubuntu.com/jammy/ubuntu-22.04.3-desktop-amd64.iso" # Required. Format: (http||s3)://www.myUrl.com/path/of/data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 6Gi

Une fois les changements appliqués, un pod sera créé dans le namespace respectif. Dans cette situation, le pod sera créé dans vms. Ce pod permet de voir la progression de l’installation de l’ISO dans le PVC. Pour voir le progrès:

kubectl logs <nom-du-pod> -n vms -f

Lorsque le téléchargement est terminé, vous pouvez créer votre vm basée sur l’ISO que vous venez de télécharger.

Grafana

Grafana est une plateforme d’analyse et de visualisation de données pour la surveillance des systèmes informatiques.

Configuration

Grafana a été configuré pour collecter, analyser et visualiser les métriques, les logs et les traces des applications de notre infrastructure.

Tester

Visiter https://grafana.omni.cedille.club pour voir ce qui a été fait.

Clickhouse

Clickhouse est un système de gestion de base de données analytique orienté colonnes, optimisé pour les requêtes rapides.

Configuration

Clickhouse est configuré pour collecter et stocker les métriques ainsi que les journaux (logs) provenant d’OpenTelemetry, contribuant directement à une meilleure observabilité. L’intégration avec Grafana, permet d’exploiter ces données à travers des tableaux de bord interactifs pour un suivi précis des systèmes.

Tester

Rendez-vous sur https://grafana.omni.cedille.club. Laissez l’onglet ouvert.

Créez les PV et le déploiement d’un simple serveur clickhouse (si ce n’est pas déjà fait. Pour verifier kubectl get all -n clickhouse-system):

kubectl apply -f apps/samples/clickhouse/pv.yml -n clickhouse-system &&
kubectl apply -f apps/samples/clickhouse/simple.yml -n clickhouse-system

Ensuite, faites un port-forward et tester la connection sur http://localhost:9000/:

kubectl port-forward svc/chi-simple-example-deployment-pv-1-1 9000:9000 -n clickhouse-system # Garder la connection ouverte

Installer le cli de clickhouse et connectez-vous au serveur pour créer une simple table users:

clickhouse-client -h 127.0.0.1 --port 9000 --user default --password <votre-password>

Créer la table users qui va accepter le contenu de script.py

CREATE TABLE users (
    id Int32,
    name String,
    email String,
    preferred_number Int32
) ENGINE = MergeTree()
ORDER BY id;

Ensuite, insérer des données en executant le script:

python3 script.py

Par la suite, il sera possible de voir les changements en faisant un SELECT * from users;

Service Mesh - Kuma

Kuma est une plateforme de gestion de services (Service Mesh) conçue pour le microservice et l’orchestration de réseaux.

Configuration

Kuma est configuré pour orchestrer, sécuriser et observer les communications entre les services du cluster Kubernetes. Il y a uniquement un “meshes” qui a été configurer pour le moment (defaut).

Tester

Commencez par déployer un exemple de service:

kubectl apply -f apps/samples/kuma-demo/demo.yaml -n kuma-demo &&
kubectl apply -f apps/samples/kuma-demo/demo-v2.yaml -n kuma-demo # Permet d'avoir un UI

Ensuite aller visiter l’application déployée:

kubectl port-forward svc/demo-app 5000:5000 -n kuma-demo

Rendez-vous sur http://localhost:5000/.

Finalement, analysez le comportement de Kuma:

kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681

Rendez-vous sur http://localhost:5681/gui/.

Merbridge

Merbridge peut être utilisé avec Kuma pour accélérer le routage du trafic réseau entre les pods en utilisant eBPF, ce qui permet de contourner kube-proxy pour des performances améliorées. Lorsqu’il est intégré à Kuma, Merbridge facilite une communication inter-pods plus rapide et plus efficace, en se synchronisant avec les fonctionnalités de gestion de Kuma. La configuration de Merbridge se fait à l’installation de Kuma pour une amélioration directe du débit et de la latence réseau.

Pour tester Merbridge, il faut simplement vérifier que les pods continuent de communiquer au sein du service mesh après son intégration.

Autres solutions considérées

Linkerd.

Problème: Complexité d’intégration ou de configuration. Voir https://github.com/linkerd/linkerd2/issues/11156

Workloads

apps/sample/kustomize-example-app

Application qui démontre la structure de base a prendre pour déployer une nouvelle application avec Kustomize avec des environments prod et staging.

Pour plus de détails, voir: Déployer des applications

5.1 -

ApplicationName

Description de l’application

Configuration

• Paramètres de configuration qui dévient de l’installation standard. Par exemple, si l’application nécessite une configuration de variables d’environnement spéciales, des volumes persistants avec des droits d’accès précis, ou des ajustements de réseau.
• Détails sur l’intégration avec d’autres services ou applications déjà en place.
• Instructions pour des paramétrages de sécurité avancés, comme les règles de pare-feu ou les politiques d’accès.

Tester

Instructions pour tester l’application :

• Étapes pour vérifier que l’installation est fonctionnelle.
• Les URL ou les endpoints pour accéder à l’application

Autres solutions considérées

Expliquez ici les autres options qui ont été évaluées avant de choisir l’application actuelle. Pour chaque solution alternative envisagée, fournissez les raisons pour lesquelles elle a été rejetée. Cela pourrait inclure :

Manque de fonctionnalités essentielles Complexité d’intégration ou de configuration Considérations de coûts Performances insuffisantes Problèmes de compatibilité Manque de support ou de communauté active

5.2 - Déployer des applications

Application exemplaire (httpbin)

L’application d’exemple est mise en place afin de documenter la méthodologie qui devrait être utilisée pour déployer des applications en production avec Kustomize et ArgoCD.

• Code source: /apps/samples/kustomize-example-app

Survol des étapes a suivre pour déployer une nouvelle app:

1. Création d’un dossier pour l’application. Ex.: /apps/new-app
2. Création de l’arborescence de ressources décrite dans ce document
3. Ajout d’une référence vers la nouvelle application dans l’application de haut niveau /apps/argo-apps/kustomization.yaml

Fonctionnement avec Kustomize

Base

Chaque application devrait définir un dossier base qui contient toutes les ressources Kubernetes que l’application aurait besoin. Ce dossier doit aussi contenir un Kustomization qui pointe sur toute les fichiers Kubernetes de base:

# base/Kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - network.yaml
  - deployment.yaml

Envrionments

Ensuite, il faut définir les dossiers prod et staging qui auront comme objectif de modifier des propriétés dans base selon les besoins différents et d’ajouter des ressources qui ne seront pas communes a tous les environnements.

Par exemple, voici le fonctionnement pour prod:

# prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../base
  - ingress.yaml
  - dns.yaml

patches:
  - path: patch.yaml

Dans l’extrait ci-haut:

1. On inclut le base
2. On inclut les ressources
3. On applique des patches:

# prod/patches.yaml
# [...]
      replicas: 3
      containers:
      - name: httpbin
        resources:
          requests:
            cpu: "0.1"
            memory: "256Mi"
---
# On peut mettre d'autres patches avec des séparateurs ---
---

On voit qu’ici on applique des requêtes de ressources qui seront différentes de base

Ajout de la nouvelle application dans /argo-apps

Créer les fichiers suivants dans votre répertoire d’application:

# argo.yaml : Contiens la ressource ArgoCD "Application" pour votre application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kustomize-example-app-prod
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "2"
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: kustomize-example-app-prod
  source:
    repoURL: https://github.com/ClubCedille/Plateforme-Cedille
    path: apps/samples/kustomize-example-app/prod # On pointe ArgoCD vers notre sous-répertoire pour l'environment prod
    targetRevision: HEAD
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kustomize-example-app-staging
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "2"
spec:
  project: default
  destination:
    server: https://kubernetes.default.svc
    namespace: kustomize-example-app-staging
  source:
    repoURL: https://github.com/ClubCedille/Plateforme-Cedille
    path: apps/samples/kustomize-example-app/staging # On pointe ArgoCD vers notre sous-répertoire pour l'environnement staging
    targetRevision: HEAD 
  syncPolicy:
    syncOptions:
    - CreateNamespace=true

# kustomization.yaml : Kustomization qui contient une seule référence vers le argo.yaml ci-haut
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
 - argo.yaml

Finalement, on peut modifier le fichier /apps/argo-apps/kustomization.yaml pour inclure notre nouvelle application:

# /apps/argo-apps/kustomization.yaml
kind: Kustomization

resources:
  # System
  - ../../system/crossplane/
  - ../../system/grafana/
  # Workload
  - ../samples/kustomize-example-app/ # Ajout de la nouvelle application.

Structure Globale

Fichiers et Ressources

  [argo.yaml] : ArgoCD Application
  [kustomization.yaml] : Pointeur vers argo.yaml
  ── base
  │  ├── [deployment.yaml]  Deployment httpbin
  │  ├── [kustomization.yaml]  Kustomization
  │  └── [network.yaml]  Service httpbin
  ├── prod
  │   ├── [dns.yaml]  RecordSet prod-dns-record
  │   ├── [ingress.yaml]  Ingress httpbin
  │   ├── [kustomization.yaml]  Kustomization
  │   └── [patch.yaml]  Deployment httpbin
  └── staging
      ├── [dns.yaml]  RecordSet staging-dns-record
      ├── [ingress.yaml]  Ingress httpbin
      ├── [kustomization.yaml]  Kustomization
      └── [patch.yaml]  Deployment httpbin

Aperçu dans ArgoCD

5.3 - Déployer des applications système

6 - Cluster Kubernetes

Cluster Kubernetes

Le cluster Kubernetes de la Plateforme Cédille héberge les sites web de tous les clubs étudiants de l’école, ainsi que les projets du club cédille.

Cluster hôte

Le cluster hôte héberge les services de système et infrastructures de base. Le cluster hôte est déployé sur les serveurs du club cédille. Le système d’exploitation utilisé est Talos Linux.

V-Clusters pour chaque environment

Les environnements sont hébergés chacun sur un v-cluster hébergé par le cluster hôte., mais utilisent vcluster pour isoler les environnements dans des clusters virtuels séparés.

6.1 - Sandbox

6.2 - Prod

6.3 - Staging

7 - SRE

Think about your project’s features and use cases. Use these to choose your core tasks. Each granular use case (enable x, configure y) should have a corresponding tasks page or tasks page section. Users should be able to quickly refer to your core tasks when they need to find out how to do one specific thing, rather than having to look for the instructions in a bigger tutorial or example. Think of your tasks pages as a cookbook with different procedures your users can combine to create something more substantial.

You can give each task a page, or you can group related tasks together in a page, such as tasks related to a particular feature. As well as grouping related tasks in single pages, you can also group task pages in nested folders with an index page as an overview, as seen in this example site. Or if you have a small docset like the Docsy User Guide with no Tutorials or Concepts pages, consider adding your feature-specific pages at the top level of your docs rather than in a Tasks section.

Each task should give the user

• The prerequisites for this task, if any (this can be specified at the top of a multi-task page if they’re the same for all the page’s tasks. “All these tasks assume that you understand….and that you have already….”).
• What this task accomplishes.
• Instructions for the task. If it involves editing a file, running a command, or writing code, provide code-formatted example snippets to show the user what to do! If there are multiple steps, provide them as a numbered list.
• If appropriate, links to related concept, tutorial, or example pages.

7.1 - SLO

Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

90’s four loko seitan photo booth gochujang freegan tumeric listicle fam ugh humblebrag. Bespoke leggings gastropub, biodiesel brunch pug fashion axe meh swag art party neutra deep v chia. Enamel pin fanny pack knausgaard tofu, artisan cronut hammock meditation occupy master cleanse chartreuse lumbersexual. Kombucha kogi viral truffaut synth distillery single-origin coffee ugh slow-carb marfa selfies. Pitchfork schlitz semiotics fanny pack, ugh artisan vegan vaporware hexagon. Polaroid fixie post-ironic venmo wolf ramps kale chips.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

First Header 2

This is a normal paragraph following a header. Knausgaard kale chips snackwave microdosing cronut copper mug swag synth bitters letterpress glossier craft beer. Mumblecore bushwick authentic gochujang vegan chambray meditation jean shorts irony. Viral farm-to-table kale chips, pork belly palo santo distillery activated charcoal aesthetic jianbing air plant woke lomo VHS organic. Tattooed locavore succulents heirloom, small batch sriracha echo park DIY af. Shaman you probably haven’t heard of them copper mug, crucifix green juice vape single-origin coffee brunch actually. Mustache etsy vexillologist raclette authentic fam. Tousled beard humblebrag asymmetrical. I love turkey, I love my job, I love my friends, I love Chardonnay!

Deae legum paulatimque terra, non vos mutata tacet: dic. Vocant docuique me plumas fila quin afuerunt copia haec o neque.

On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.

Scenester tumeric pickled, authentic crucifix post-ironic fam freegan VHS pork belly 8-bit yuccie PBR&B. I love this life we live in.

Second Header 2

This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

Header 3

This is a code block following a header.

Next level leggings before they sold out, PBR&B church-key shaman echo park. Kale chips occupy godard whatever pop-up freegan pork belly selfies. Gastropub Belinda subway tile woke post-ironic seitan. Shabby chic man bun semiotics vape, chia messenger bag plaid cardigan.

Header 4

• This is an unordered list following a header.
• This is an unordered list following a header.
• This is an unordered list following a header.

Header 5

1. This is an ordered list following a header.
2. This is an ordered list following a header.
3. This is an ordered list following a header.

Header 6

There’s a horizontal rule above and below this.

Here is an unordered list:

• Liverpool F.C.
• Chelsea F.C.
• Manchester United F.C.

And an ordered list:

1. Michael Brecker
2. Seamus Blake
3. Branford Marsalis

And an unordered task list:

• Create a Hugo theme
• Add task lists to it
• Take a vacation

And a “mixed” task list:

• Pack bags
• ?
• Travel!

And a nested list:

• Jackson 5
  • Michael
  • Tito
  • Jackie
  • Marlon
  • Jermaine
• TMNT
  • Leonardo
  • Michelangelo
  • Donatello
  • Raphael

Definition lists can be used with Markdown syntax. Definition headers are bold.

Name

Godzilla

Born

1952

Birthplace

Japan

Color

Green

Tables should have bold headings and alternating shaded rows.

If a table is too wide, it should scroll horizontally.

Code snippets like var foo = "bar"; can be shown inline.

Also, this should vertically align with this and this.

Code can also be shown in a block element.

foo := "bar";
bar := "foo";

Code can also use syntax highlighting.

func main() {
  input := `var foo = "bar";`

  lexer := lexers.Get("javascript")
  iterator, _ := lexer.Tokenise(nil, input)
  style := styles.Get("github")
  formatter := html.New(html.WithLineNumbers())

  var buff bytes.Buffer
  formatter.Format(&buff, style, iterator)

  fmt.Println(buff.String())
}

Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.

Inline code inside table cells should still be distinguishable.

Small images should be shown at their actual size.

Large images should always scale down and fit in the content container.

The photo above of the Spruce Picea abies shoot with foliage buds: Bjørn Erik Pedersen, CC-BY-SA.

Components

Alerts

Another Heading

Add some sections here to see how the ToC looks like. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

This Document

Inguina genus: Anaphen post: lingua violente voce suae meus aetate diversi. Orbis unam nec flammaeque status deam Silenum erat et a ferrea. Excitus rigidum ait: vestro et Herculis convicia: nitidae deseruit coniuge Proteaque adiciam eripitur? Sitim noceat signa probat quidem. Sua longis fugatis quidem genae.

Pixel Count

Tilde photo booth wayfarers cliche lomo intelligentsia man braid kombucha vaporware farm-to-table mixtape portland. PBR&B pickled cornhole ugh try-hard ethical subway tile. Fixie paleo intelligentsia pabst. Ennui waistcoat vinyl gochujang. Poutine salvia authentic affogato, chambray lumbersexual shabby chic.

Contact Info

Plaid hell of cred microdosing, succulents tilde pour-over. Offal shabby chic 3 wolf moon blue bottle raw denim normcore poutine pork belly.

External Links

Stumptown PBR&B keytar plaid street art, forage XOXO pitchfork selvage affogato green juice listicle pickled everyday carry hashtag. Organic sustainable letterpress sartorial scenester intelligentsia swag bushwick. Put a bird on it stumptown neutra locavore. IPhone typewriter messenger bag narwhal. Ennui cold-pressed seitan flannel keytar, single-origin coffee adaptogen occupy yuccie williamsburg chillwave shoreditch forage waistcoat.

This is the final element on the page and there should be no margin below this.

7.2 - Surveillance

Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

90’s four loko seitan photo booth gochujang freegan tumeric listicle fam ugh humblebrag. Bespoke leggings gastropub, biodiesel brunch pug fashion axe meh swag art party neutra deep v chia. Enamel pin fanny pack knausgaard tofu, artisan cronut hammock meditation occupy master cleanse chartreuse lumbersexual. Kombucha kogi viral truffaut synth distillery single-origin coffee ugh slow-carb marfa selfies. Pitchfork schlitz semiotics fanny pack, ugh artisan vegan vaporware hexagon. Polaroid fixie post-ironic venmo wolf ramps kale chips.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

First Header 2

This is a normal paragraph following a header. Knausgaard kale chips snackwave microdosing cronut copper mug swag synth bitters letterpress glossier craft beer. Mumblecore bushwick authentic gochujang vegan chambray meditation jean shorts irony. Viral farm-to-table kale chips, pork belly palo santo distillery activated charcoal aesthetic jianbing air plant woke lomo VHS organic. Tattooed locavore succulents heirloom, small batch sriracha echo park DIY af. Shaman you probably haven’t heard of them copper mug, crucifix green juice vape single-origin coffee brunch actually. Mustache etsy vexillologist raclette authentic fam. Tousled beard humblebrag asymmetrical. I love turkey, I love my job, I love my friends, I love Chardonnay!

Deae legum paulatimque terra, non vos mutata tacet: dic. Vocant docuique me plumas fila quin afuerunt copia haec o neque.

On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.

Scenester tumeric pickled, authentic crucifix post-ironic fam freegan VHS pork belly 8-bit yuccie PBR&B. I love this life we live in.

Second Header 2

This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

Header 3

This is a code block following a header.

Next level leggings before they sold out, PBR&B church-key shaman echo park. Kale chips occupy godard whatever pop-up freegan pork belly selfies. Gastropub Belinda subway tile woke post-ironic seitan. Shabby chic man bun semiotics vape, chia messenger bag plaid cardigan.

Header 4

• This is an unordered list following a header.
• This is an unordered list following a header.
• This is an unordered list following a header.

Header 5

1. This is an ordered list following a header.
2. This is an ordered list following a header.
3. This is an ordered list following a header.

Header 6

There’s a horizontal rule above and below this.

Here is an unordered list:

• Liverpool F.C.
• Chelsea F.C.
• Manchester United F.C.

And an ordered list:

1. Michael Brecker
2. Seamus Blake
3. Branford Marsalis

And an unordered task list:

• Create a Hugo theme
• Add task lists to it
• Take a vacation

And a “mixed” task list:

• Pack bags
• ?
• Travel!

And a nested list:

• Jackson 5
  • Michael
  • Tito
  • Jackie
  • Marlon
  • Jermaine
• TMNT
  • Leonardo
  • Michelangelo
  • Donatello
  • Raphael

Definition lists can be used with Markdown syntax. Definition headers are bold.

Name

Godzilla

Born

1952

Birthplace

Japan

Color

Green

Tables should have bold headings and alternating shaded rows.

If a table is too wide, it should scroll horizontally.

Code snippets like var foo = "bar"; can be shown inline.

Also, this should vertically align with this and this.

Code can also be shown in a block element.

foo := "bar";
bar := "foo";

Code can also use syntax highlighting.

func main() {
  input := `var foo = "bar";`

  lexer := lexers.Get("javascript")
  iterator, _ := lexer.Tokenise(nil, input)
  style := styles.Get("github")
  formatter := html.New(html.WithLineNumbers())

  var buff bytes.Buffer
  formatter.Format(&buff, style, iterator)

  fmt.Println(buff.String())
}

Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.

Inline code inside table cells should still be distinguishable.

Small images should be shown at their actual size.

Large images should always scale down and fit in the content container.

The photo above of the Spruce Picea abies shoot with foliage buds: Bjørn Erik Pedersen, CC-BY-SA.

Components

Alerts

Another Heading

Add some sections here to see how the ToC looks like. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

This Document

Inguina genus: Anaphen post: lingua violente voce suae meus aetate diversi. Orbis unam nec flammaeque status deam Silenum erat et a ferrea. Excitus rigidum ait: vestro et Herculis convicia: nitidae deseruit coniuge Proteaque adiciam eripitur? Sitim noceat signa probat quidem. Sua longis fugatis quidem genae.

Pixel Count

Tilde photo booth wayfarers cliche lomo intelligentsia man braid kombucha vaporware farm-to-table mixtape portland. PBR&B pickled cornhole ugh try-hard ethical subway tile. Fixie paleo intelligentsia pabst. Ennui waistcoat vinyl gochujang. Poutine salvia authentic affogato, chambray lumbersexual shabby chic.

Contact Info

Plaid hell of cred microdosing, succulents tilde pour-over. Offal shabby chic 3 wolf moon blue bottle raw denim normcore poutine pork belly.

External Links

Stumptown PBR&B keytar plaid street art, forage XOXO pitchfork selvage affogato green juice listicle pickled everyday carry hashtag. Organic sustainable letterpress sartorial scenester intelligentsia swag bushwick. Put a bird on it stumptown neutra locavore. IPhone typewriter messenger bag narwhal. Ennui cold-pressed seitan flannel keytar, single-origin coffee adaptogen occupy yuccie williamsburg chillwave shoreditch forage waistcoat.

This is the final element on the page and there should be no margin below this.

7.3 - Sécurité

Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

90’s four loko seitan photo booth gochujang freegan tumeric listicle fam ugh humblebrag. Bespoke leggings gastropub, biodiesel brunch pug fashion axe meh swag art party neutra deep v chia. Enamel pin fanny pack knausgaard tofu, artisan cronut hammock meditation occupy master cleanse chartreuse lumbersexual. Kombucha kogi viral truffaut synth distillery single-origin coffee ugh slow-carb marfa selfies. Pitchfork schlitz semiotics fanny pack, ugh artisan vegan vaporware hexagon. Polaroid fixie post-ironic venmo wolf ramps kale chips.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

First Header 2

This is a normal paragraph following a header. Knausgaard kale chips snackwave microdosing cronut copper mug swag synth bitters letterpress glossier craft beer. Mumblecore bushwick authentic gochujang vegan chambray meditation jean shorts irony. Viral farm-to-table kale chips, pork belly palo santo distillery activated charcoal aesthetic jianbing air plant woke lomo VHS organic. Tattooed locavore succulents heirloom, small batch sriracha echo park DIY af. Shaman you probably haven’t heard of them copper mug, crucifix green juice vape single-origin coffee brunch actually. Mustache etsy vexillologist raclette authentic fam. Tousled beard humblebrag asymmetrical. I love turkey, I love my job, I love my friends, I love Chardonnay!

Deae legum paulatimque terra, non vos mutata tacet: dic. Vocant docuique me plumas fila quin afuerunt copia haec o neque.

On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.

Scenester tumeric pickled, authentic crucifix post-ironic fam freegan VHS pork belly 8-bit yuccie PBR&B. I love this life we live in.

Second Header 2

This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

Header 3

This is a code block following a header.

Next level leggings before they sold out, PBR&B church-key shaman echo park. Kale chips occupy godard whatever pop-up freegan pork belly selfies. Gastropub Belinda subway tile woke post-ironic seitan. Shabby chic man bun semiotics vape, chia messenger bag plaid cardigan.

Header 4

• This is an unordered list following a header.
• This is an unordered list following a header.
• This is an unordered list following a header.

Header 5

1. This is an ordered list following a header.
2. This is an ordered list following a header.
3. This is an ordered list following a header.

Header 6

There’s a horizontal rule above and below this.

Here is an unordered list:

• Liverpool F.C.
• Chelsea F.C.
• Manchester United F.C.

And an ordered list:

1. Michael Brecker
2. Seamus Blake
3. Branford Marsalis

And an unordered task list:

• Create a Hugo theme
• Add task lists to it
• Take a vacation

And a “mixed” task list:

• Pack bags
• ?
• Travel!

And a nested list:

• Jackson 5
  • Michael
  • Tito
  • Jackie
  • Marlon
  • Jermaine
• TMNT
  • Leonardo
  • Michelangelo
  • Donatello
  • Raphael

Definition lists can be used with Markdown syntax. Definition headers are bold.

Name

Godzilla

Born

1952

Birthplace

Japan

Color

Green

Tables should have bold headings and alternating shaded rows.

If a table is too wide, it should scroll horizontally.

Code snippets like var foo = "bar"; can be shown inline.

Also, this should vertically align with this and this.

Code can also be shown in a block element.

foo := "bar";
bar := "foo";

Code can also use syntax highlighting.

func main() {
  input := `var foo = "bar";`

  lexer := lexers.Get("javascript")
  iterator, _ := lexer.Tokenise(nil, input)
  style := styles.Get("github")
  formatter := html.New(html.WithLineNumbers())

  var buff bytes.Buffer
  formatter.Format(&buff, style, iterator)

  fmt.Println(buff.String())
}

Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.

Inline code inside table cells should still be distinguishable.

Small images should be shown at their actual size.

Large images should always scale down and fit in the content container.

The photo above of the Spruce Picea abies shoot with foliage buds: Bjørn Erik Pedersen, CC-BY-SA.

Components

Alerts

Another Heading

Add some sections here to see how the ToC looks like. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

This Document

Inguina genus: Anaphen post: lingua violente voce suae meus aetate diversi. Orbis unam nec flammaeque status deam Silenum erat et a ferrea. Excitus rigidum ait: vestro et Herculis convicia: nitidae deseruit coniuge Proteaque adiciam eripitur? Sitim noceat signa probat quidem. Sua longis fugatis quidem genae.

Pixel Count

Tilde photo booth wayfarers cliche lomo intelligentsia man braid kombucha vaporware farm-to-table mixtape portland. PBR&B pickled cornhole ugh try-hard ethical subway tile. Fixie paleo intelligentsia pabst. Ennui waistcoat vinyl gochujang. Poutine salvia authentic affogato, chambray lumbersexual shabby chic.

Contact Info

Plaid hell of cred microdosing, succulents tilde pour-over. Offal shabby chic 3 wolf moon blue bottle raw denim normcore poutine pork belly.

External Links

Stumptown PBR&B keytar plaid street art, forage XOXO pitchfork selvage affogato green juice listicle pickled everyday carry hashtag. Organic sustainable letterpress sartorial scenester intelligentsia swag bushwick. Put a bird on it stumptown neutra locavore. IPhone typewriter messenger bag narwhal. Ennui cold-pressed seitan flannel keytar, single-origin coffee adaptogen occupy yuccie williamsburg chillwave shoreditch forage waistcoat.

This is the final element on the page and there should be no margin below this.

8 - Référence

If your project has an API, configuration, or other reference - anything that users need to look up that’s at an even lower level than a single task - put (or link to it) here. You can serve and link to generated reference docs created using Doxygen, Javadoc, or other doc generation tools by putting them in your static/ directory. Find out more in Adding static content. For OpenAPI reference, Docsy also provides a Swagger UI layout and shortcode that renders Swagger UI using any OpenAPI YAML or JSON file as source.

8.1 - Paramètre de référence

Text can be bold, italic, or strikethrough. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. Vape migas chillwave sriracha poutine try-hard distillery. Tattooed shabby chic small batch, pabst art party heirloom letterpress air plant pop-up. Sustainable chia skateboard art party banjo cardigan normcore affogato vexillologist quinoa meggings man bun master cleanse shoreditch readymade. Yuccie prism four dollar toast tbh cardigan iPhone, tumblr listicle live-edge VHS. Pug lyft normcore hot chicken biodiesel, actually keffiyeh thundercats photo booth pour-over twee fam food truck microdosing banh mi. Vice activated charcoal raclette unicorn live-edge post-ironic. Heirloom vexillologist coloring book, beard deep v letterpress echo park humblebrag tilde.

90’s four loko seitan photo booth gochujang freegan tumeric listicle fam ugh humblebrag. Bespoke leggings gastropub, biodiesel brunch pug fashion axe meh swag art party neutra deep v chia. Enamel pin fanny pack knausgaard tofu, artisan cronut hammock meditation occupy master cleanse chartreuse lumbersexual. Kombucha kogi viral truffaut synth distillery single-origin coffee ugh slow-carb marfa selfies. Pitchfork schlitz semiotics fanny pack, ugh artisan vegan vaporware hexagon. Polaroid fixie post-ironic venmo wolf ramps kale chips.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

First Header 2

This is a normal paragraph following a header. Knausgaard kale chips snackwave microdosing cronut copper mug swag synth bitters letterpress glossier craft beer. Mumblecore bushwick authentic gochujang vegan chambray meditation jean shorts irony. Viral farm-to-table kale chips, pork belly palo santo distillery activated charcoal aesthetic jianbing air plant woke lomo VHS organic. Tattooed locavore succulents heirloom, small batch sriracha echo park DIY af. Shaman you probably haven’t heard of them copper mug, crucifix green juice vape single-origin coffee brunch actually. Mustache etsy vexillologist raclette authentic fam. Tousled beard humblebrag asymmetrical. I love turkey, I love my job, I love my friends, I love Chardonnay!

Deae legum paulatimque terra, non vos mutata tacet: dic. Vocant docuique me plumas fila quin afuerunt copia haec o neque.

On big screens, paragraphs and headings should not take up the full container width, but we want tables, code blocks and similar to take the full width.

Scenester tumeric pickled, authentic crucifix post-ironic fam freegan VHS pork belly 8-bit yuccie PBR&B. I love this life we live in.

Second Header 2

This is a blockquote following a header. Bacon ipsum dolor sit amet t-bone doner shank drumstick, pork belly porchetta chuck sausage brisket ham hock rump pig. Chuck kielbasa leberkas, pork bresaola ham hock filet mignon cow shoulder short ribs biltong.

Header 3

This is a code block following a header.

Next level leggings before they sold out, PBR&B church-key shaman echo park. Kale chips occupy godard whatever pop-up freegan pork belly selfies. Gastropub Belinda subway tile woke post-ironic seitan. Shabby chic man bun semiotics vape, chia messenger bag plaid cardigan.

Header 4

• This is an unordered list following a header.
• This is an unordered list following a header.
• This is an unordered list following a header.

Header 5

1. This is an ordered list following a header.
2. This is an ordered list following a header.
3. This is an ordered list following a header.

Header 6

There’s a horizontal rule above and below this.

Here is an unordered list:

• Liverpool F.C.
• Chelsea F.C.
• Manchester United F.C.

And an ordered list:

1. Michael Brecker
2. Seamus Blake
3. Branford Marsalis

And an unordered task list:

• Create a Hugo theme
• Add task lists to it
• Take a vacation

And a “mixed” task list:

• Pack bags
• ?
• Travel!

And a nested list:

• Jackson 5
  • Michael
  • Tito
  • Jackie
  • Marlon
  • Jermaine
• TMNT
  • Leonardo
  • Michelangelo
  • Donatello
  • Raphael

Definition lists can be used with Markdown syntax. Definition headers are bold.

Name

Godzilla

Born

1952

Birthplace

Japan

Color

Green

Tables should have bold headings and alternating shaded rows.

If a table is too wide, it should scroll horizontally.

Code snippets like var foo = "bar"; can be shown inline.

Also, this should vertically align with this and this.

Code can also be shown in a block element.

foo := "bar";
bar := "foo";

Code can also use syntax highlighting.

func main() {
  input := `var foo = "bar";`

  lexer := lexers.Get("javascript")
  iterator, _ := lexer.Tokenise(nil, input)
  style := styles.Get("github")
  formatter := html.New(html.WithLineNumbers())

  var buff bytes.Buffer
  formatter.Format(&buff, style, iterator)

  fmt.Println(buff.String())
}

Long, single-line code blocks should not wrap. They should horizontally scroll if they are too long. This line should be long enough to demonstrate this.

Inline code inside table cells should still be distinguishable.

Small images should be shown at their actual size.

Large images should always scale down and fit in the content container.

The photo above of the Spruce Picea abies shoot with foliage buds: Bjørn Erik Pedersen, CC-BY-SA.

Components

Alerts

Another Heading

9 - LOG791

Liste des Sprints

• Sprint 1 : 10 Septembre 2023 - 8 Octobre 2023
• Sprint 2 : 9 Octobre 2023 - 5 Novembre 2023
• Sprint 3 : 6 Novembre 2023 - 3 Décembre 2023

9.1 - Rétrospectives

Liste des Rétrospectives

1. Rétrospective du Sprint 1 - 11 octobre 2023
2. Rétrospective du Sprint 2 - 8 novembre 2023
3. Rétrospective du Sprint 3 - 6 Décembre 2023

9.2 - Rapport final

Plateforme CEDILLE - Rapport LOG791

Introduction

Dans le cadre du cours LOG-791 et de notre engagement au sein du club Cedille de l’École de Technologie Supérieure (ÉTS), nous avons entrepris le projet de faire la conception et la mise en place de la Plateforme CEDILLE. Ce rapport vise à présenter de manière exhaustive les différentes étapes de notre initiative, depuis sa genèse jusqu’à sa concrétisation actuelle.

Le projet de la Plateforme CEDILLE avait pour objectif principal de transformer l’infrastructure existante du club. Nous avons choisi d’implémenter un cluster Kubernetes sur des serveurs physiques, en exploitant les capacités de Talos OS et la solution Omni de Sidero Labs. Cette démarche se voulait doublement bénéfique : réduire les coûts associés à l’hébergement tout en offrant une opportunité concrète d’apprentissage et de développement des compétences en DevOps, Kubernetes et gestion de serveurs.

Aujourd’hui, nous sommes fiers de constater que la majorité de l’infrastructure et des services systèmes sont opérationnels. Cependant, il convient de souligner que certaines phases de la migration des services hébergés restent à compléter. Ce rapport se propose donc de dresser un bilan de notre parcours, soulignant aussi bien les réussites que les obstacles rencontrés et les enseignements tirés de cette expérience.

Dans les sections suivantes, nous détaillerons la méthodologie adoptée pour la réalisation de ce projet, ainsi que les étapes de développement et de mise en œuvre. Nous mettrons en lumière les défis techniques et organisationnels rencontrés, ainsi que les solutions déployées pour les surmonter. Un éclairage sera également porté sur les alternatives technologiques envisagées, afin d’offrir une vision complète de nos choix et de notre processus de décision.

Nous analyserons ensuite les résultats obtenus, évaluant le succès du projet au regard des objectifs initiaux et des livrables. Un focus particulier sera accordé aux apprentissages et compétences développés tout au long du projet, témoignant de l’impact formateur de ce projet sur l’ensemble des membres de l’équipe. Enfin, la conclusion résumera nos principales réalisations et proposera des recommandations pour les futurs projets de nature similaire.

Par le biais de ce rapport, nous aspirons à vous fournir une vue d’ensemble exhaustive de notre parcours, mettant en évidence nos réalisations ainsi que les leçons clés tirées au cours de cette expérience.

Méthodologie

Pour mener à bien le projet Plateforme CEDILLE, notre équipe d’étudiants a adopté une approche pratique et flexible, combinant des outils de collaboration modernes et des méthodes de travail adaptées à notre contexte étudiant.

Planification initiale et vision du projet

Au début du projet, nous avons commencé par une phase de planification détaillée. Pour cela, on a utilisé un grand tableau pour visualiser l’ensemble de notre stack technologique et comprendre comment les différents éléments interagissaient entre eux. Cette étape a été cruciale pour nous aider à rédiger notre document de vision. Ce document a servi de feuille de route pour tout le projet, en définissant clairement nos objectifs et notre approche.

Organisation du travail et backlog

Une fois notre vision établie, nous avons dressé une liste exhaustive de toutes les tâches à réaliser dans notre backlog sur GitHub. Cela nous a permis d’évaluer l’ampleur du projet et de diviser le travail en trois grandes itérations d’un mois chacune. Cette approche itérative nous a aidés à rester concentrés et à mesurer notre progression de façon régulière.

Retrospectives et ajustements

Après chaque itération, on prenait le temps de faire une rétrospective. Ces moments étaient essentiels pour réfléchir à ce qui s’était bien passé et à ce qu’on pouvait améliorer pour la suite. Grâce à ces rétrospectives, on a pu ajuster notre planification et notre approche pour les itérations suivantes, en tirant des leçons de nos expériences précédentes.

Documentation et suivi sur le wiki

Toute notre progression a été soigneusement documentée sur notre wiki. Pour chaque tâche ou problème rencontré, on créait une entrée sur le wiki avec des liens directs vers les issues correspondantes sur GitHub. Cela a permis à toute l’équipe de suivre facilement l’avancement du projet et de retrouver rapidement les informations pertinentes liées à chaque tâche.

Réunions et communication

La communication constante et efficace a été un pilier de notre projet. Nous avons organisé des séances de travail en présentiel chaque dimanche à l’école pour une collaboration et des discussions techniques approfondies. En complément, des réunions hebdomadaires sur le modèle Scrum étaient tenues tous les lundis, permettant à l’équipe de discuter des avancées, de planifier les prochaines étapes et de résoudre les obstacles rencontrés.

Adoption des principes Agile et DevOps

Notre processus de collaboration a été fortement influencé par les principes Agile et DevOps. Nous avons adopté une approche itérative pour le développement, permettant une adaptation et une réactivité rapides aux changements. Le déploiement continu et les mises à jour de notre architecture ont été gérés via l’Infrastructure as Code (IaC), en utilisant des pipelines CI/CD pour automatiser et rationaliser ces processus. De plus, l’utilisation de templates pour les issues et pull requests sur GitHub a renforcé notre efficacité et a maintenu une norme de clarté et de cohérence dans notre communication et nos pratiques de développement.

Architecture technique

Kubernetes et Sidero Omni

Pour la gestion des applications déployées, nous avons choisi d’utiliser la technologie des conteneurs. Cela permet une meilleure isolation entre les différentes applications et une gestion plus facile des dépendances grâce aux Dockerfiles. Pour gérer les déploiements de conteneurs sur nos systèmes, nous avons choisi d’utiliser Kubernetes puisque c’est le standard en entreprise et que ses capacités de coordination sont extrêmement puissantes. Kubernetes permet 2 types de nodes: controlplane et worker. Dans notre cas, nous avons déployé 3 controlplanes et 3 workers. Les 3 controlplanes permettent au cluster Kubernetes lui-même d’avoir une haute disponibilité (si un des nodes est éteint ou mis à jour, il n’y a pas d’impact sur les capacités du cluster). Les 3 workers permettent aux applications ainsi qu’au stockage d’avoir de la haute disponibilité.

Kubernetes est un système, mais ce n’est pas proprement un système d’exploitation. Ici, nous avons choisi Talos OS: c’est un système d’exploitation Linux entièrement construit autour de Kubernetes. La plupart des processus que l’on trouve dans un système Linux standard sont d’ailleurs manquant afin de réduire la surface d’attaque. De même, une partie importante du système de fichier est en lecture seule.

L’autre avantage de ce système d’exploitation est qu’il peut être entièrement contrôlé par un API, permettant donc de meilleures automatisations. La compagnie qui a développé cet OS a d’ailleurs aussi développé un service SaaS qui se connecte à cet API et automatiser une partie importante de la gestion du cluster: Sidero Omni. Puisque que Sidero est un commanditaire du club étudiant, nous avons droit à une license pour utiliser ce logiciel habituellement payant. Cela nous permet de gérer facilement les différents serveurs à distance via une interface web. Le contrôle via l’API Kubernetes passe aussi par cette solution SaaS, permettant donc un contrôle des accès plus strict avec OAuth.

Gestion GitOps

Pour la gestion des déploiements et des configurations, nous avons choisi une approche pleinement GitOps. Cette approche permet de réduire les étapes impératives et difficiles à reproduire pour avoir des environnements faciles à reproduire. De plus, la traçabilité de git permet d’avoir des flux de contrôle de changements plus avancés et d’identifier la source du problème plus rapidement.

Pour atteindre cet objectif de GitOps, nous avons donc utilisé deux outils : ArgoCD et Terraform. ArgCD est un outil spécifique à Kubernetes, qui est déployé sur le cluster. Celui-ci surveille tous les manifestes Kubernetes sur le répertoire Git et fait les modifications nécessaires pour que le cluster soit configuré accordément à ces manifestes. Cela peut être des configurations comme des déploiements applicatifs. Le second outil, Terraform, est surtout utilisé pour configurer les dépendances autours de Kubernetes. Cet outil permet de définir des configurations de services cloud et de lier des variables entre elles entre plusieurs services, offrant une composition de ressources cloud très puissante. Pour le moment, la création de répertoire git ainsi que la configuration du service de gestion de clées KMS de Google Cloud sont les deux principaux services configurés avec Terraform.

Stockage distribué

Afin d’offrir un service de qualité, il est important que les services restent toujours disponibles même en cas de pannes ou mises à jour de système. Kubernetes offre une façon de distribuer des ressources applicatives pour atteindre de la haute disponibilité. Toutefois, lorsque des données persistantes sont impliquées, cela est un peu plus complexe. En effet, Kubernetes laisse le soin aux administrateurs le soin de définir le stockage, ne fournissant qu’une abstraction. Cela permet une architecture très flexible (compatible autant avec des environnements physiques que cloud), mais implique plus de travail pour le configurer. Une solution simple consiste à utiliser le stockage local d’un noeud pour enregistrer les données. Toutefois, avec cette solution, si le noeud tombe en panne, les données deviennent indisponible et on perd la disponibilité de l’application. Pour éviter cette situation, il faut repartir les données sur différents serveurs de façon à ce qu’il y ait toujours un minimum de 2 copies de chaque donnée sur 2 différents serveurs.

Plusieurs technologies permettent de faire cela, ici, nous avons choisi Mayastor. C’est un engin de stockage basé sur la spécification NVMe-oF, un protocole de disque plus récente que SCSI et qui permet de mieux bénéficier des capacités de parallélisation des SSD. Mayastor est aussi pleinement conçu pour et intégré avec Kubernetes, réduisant les risques de problèmes de compatibilité qui sont parfois présents avec des engins d’abord conçus pour des systèmes non-Kubernetes.

Pour les applications, ils n’utilisent pas directement Mayastor, mais plutôt les abstractions Kubernetes: StorageClass, PersistentVolumeClaim et PersistentVolume. Cela nous permettrait de changer l’engin de stockage dans le futur si nécessaire.

Gestion des secrets

La gestion des secrets est toujours un aspect complexe et où une mauvaise configuration peut avoir des conséquences désastreuses. C’est d’ailleurs souvent à travers la gestion des secrets que l’on voit des pirates informatiques infiltrer des systèmes. Ici, nous avons choisi d’utiliser Hashicorp Vault, standard dans l’industrie pour la gestion de secrets à grande échelle. Pour configurer celui-ci, nous avons déployé un outil développé par la communauté RedHat: Vault Config Operator. Cet outil ajoute des définitions de manifestes Kubernetes (CRD), nous permettant de créer des politiques d’accès, des configurations de rotation de clées ainsi que de définir de nouveaux secrets aléatoires à travers des manifestes Kubernetes qui sont ensuite déployés par ArgoCD. Cette approche nous permet de conserver une approche GitOps sans avoir à exposer les secrets dans les fichiers sur Git.

Observabilité

L’observabilité est une pierre angulaire de toute approche DevOps, permettant à la fois au développeur et aux administrateurs d’identifier rapidement la source d’un problème. Dans un système distribué comme celui que nous avons conçu, les traces sont particulièrements importantes, puisque c’est ce qui nous permet de suivre le chemin d’une requête à travers les multiples systèmes.

Afin de collecter ces traces, nous avons mis à profit un outil appelé Pixi. Cet outil utilise une innovation relativement récente du noyau Linux: eBPF (extended Berkeley Packet Filter). Ceci permet à des applications de rouler certaines opérations dans le contexte privilégié du noyau Linux de façon sécuritaire. Ceci permet à Pixi d’analyse les communications entre les processus et le réseau et de recréer automatiquement des traces, sans avoir à configurer chaque composante pour qu’elle ajoute son contexte à la trace. Par la suite, ces traces sont exportées vers un agent OpenTelemetry. OpenTelemetry est un standard pour tout ce qui est observabilité et permet de faciliter le transfert de traces, métriques et logs entre plusieurs systèmes. Les agents OpenTelemetry agissent comme échangeurs, permettant de recevoir et retransemettre des traces, métriques et logs. Ici, nous redirigeons ces informations vers la base de données de haute performance Clickhouse. Enfin, nous utilisons Grafana pour se connecter à cette base de données et afficher toutes ces traces, métriques et logs.

Autres solutions envisagées

Pendant la phase d’analyse, on a identifié que certains choix techniques pouvaient être réalisés de plusieurs façons. Ainsi, dans le document de vision, on a identifié ces options et on s’est prononcé sur un choix initial (Tableau 4.4.2). Cependant, la phase d’implémentation nous a permis d’avoir une meilleure perspective sur certains choix et la possibilité de les changer. Ainsi, on présente ces choix ici :

Choix de l’engin de stockage

Selon le CAR8, on a planifié d’utiliser Rook-Ceph comme engin de stockage pour Kubernetes. À titre de rappel, l’engin est responsable de fournir un service qui répond aux requêtes CSI dans Kubernetes afin d’allouer des espaces dédiés au pods, d’assurer que ces espaces sont accessibles dans tout le cluster et que les données soient durables et intègres.

Rook-Ceph est une extension de Ceph, qui est un système de stockage distribué qui prédate Kubernetes. En principe, ce dernier répond à tous nos besoins en termes d’engin. Cependant, en pratique, on a remarqué que le système était très instable à notre échelle (3 serveurs).

Après plusieurs essais, on a choisi de remplacer Rook-Ceph par Mayastor, qui est un système conçu dès le début pour Kubernetes. Au final, le déploiement était plus simple et le système est très stable.

Choix de l’engin de gestion des secrets

Étant donné le fait que notre répertoire de code est public et qu’on utilise l’approche GitOps, il est impératif qu’aucun secret ne soit divulgué dans le répertoire de code source. Ainsi, il nous faut une solution logicielle qui fait abstraction des secrets afin de les gérer de manière sécuritaire. Donc, les deux choix principaux pour le faire sont Hashicorp Vault vs Bitnami Sealed Secrets.

Bitnami Sealed Secrets: Les secrets sont quand même présents dans git, mais ils sont cryptés. HashiCorp Vault: Les secrets ne sont pas dans Git, mais leurs configurations et des références le sont. Il offre aussi plusieurs modes de cryptage avancés, la génération dynamique, la rotation automatique et plusieurs autres fonctionnalités avancées.

Ainsi, on a déterminé que Vault serait une meilleure solution pour ce projet puisqu’on le juge plus sécuritaire (puisqu’aucun secret n’est divulgué publiquement comme dans le cas de sealed-secrets) et qu’on aurait besoin des fonctions plus avancées qu’il nous offre.

Choix de la plateforme d’observabilité

Selon le CAR13, on a choisi d’utiliser les technologies ouvertes Pixie, OpenTelemetry et Clickhouse dans une configuration construite sur mesure pour les fins d’observabilité. L’autre choix était de prendre une solution commerciale / tout-en-une, tel que Elastic ou Groundcover.

Ce qui influence notre choix pour cet aspect est qu’une considération importante pour Cédille est de promouvoir l’utilisation de logiciels libres. Ainsi, utiliser des solutions commerciales est à l’encontre de cet objectif, et on essaye d’éviter ce genre de choix quand c’est possible. De plus, on a jugé que la construction d’une solution sur-mesure en combinant ces technologies (Pixie, OpenTelemetry et Clickhouse) aurait une plus grande valeur en tant qu’apprentissage et donnerait un résultat qui répondrait mieux à nos besoins.

Choix d’utilisation d’un Hypervisor

Avant la phase d’analyse et rédaction du document de vision, on a entrepris une phase d’installation et configuration du matériel physique. Dans cette phase, on avait essayé en premier d’utiliser l’hyperviseur XCP-NG comme système d’exploitation principal, le plan étant de configurer nos clusters Kubernetes avec des machines virtuelles.

Afin de respecter notre objectif d’utiliser des configurations déclaratives le plus possible, on devait faire une gestion exhaustive de l’hyperviseur, de son réseau et de son stockage avec Terraform. Ainsi, on n’était pas prêt à accepter le niveau de complexité qui aurait été ajouté par cette méthode, donc on a choisi d’installer Talos Linux directement sur les machines sans Hypervisor.

Le résultat final est que la majorité des configurations et installations sont faites nativement dans le cluster Kubernetes, ce qui offre un haut niveau de cohérence dans le code du projet.

Figure: Comparaison des moyens de déploiement

Défis et Solutions

Résultats

Notre projet a connu une progression significative, marquée par une série de tâches réalisées avec succès, chacune contribuant de manière essentielle à l’avancement global. Voici un résumé des tâches accomplies, présentées dans l’ordre chronologique de leur réalisation ainsi que par livrable :

Livrable 1: Phase initiale de préparation et d’entrevues. Déploiement et configuration initiale

• Préparation de questionnaires spécifiques à chaque client et conduite d’entrevues avec divers clubs et services de l’ÉTS, notamment AlgoETS, Raconteurs d’Angles, Saveurs de Génie, et les services TI. Ces entrevues ont permis de définir les métriques de succès du projet.
• Mise en place du cluster physique avec Talos/Omni et configuration de base de Rook/Ceph. Evaluation de la stack de networking pour Kubernetes.
• Création d’un wiki pour centraliser la documentation et rédaction du document de vision initial.
• Migration physique des serveurs vers la salle de serveurs et configuration de KubeVirt.

Livrable 2: Développement et configuration avancée

• Déploiement d’un cluster sandbox avec Vcluster, installation et configuration de l’external-dns, Hashicorp Vault, et Crossplane sur le cluster.
• Mise en place de la structure Kustomize, configuration d’ArgoCD, Contour (reverse-proxy/ingress), et déploiement de Kuma + Merbridge (service-mesh).
• Configuration et déploiement de Grafana, Gateway API, et Mayastor.
• Documentation approfondie de KubeVirt, Kuma, Merbridge, et Contour.

Livrable 3: Finalisation et optimisation

• Déploiement de cert-manager, documentation de Mayastor et de la configuration d’environnement locale avec Omni.
• Configuration d’OTEL, suivi de Clickhouse avec Open Telemetry, et déploiement d’exemples d’applications comme Grav et Calidum-Rotae.
• Mise à jour de l’architecture dans le README.md, suppression de composants obsolètes (base de données PostgreSQL, numéro de téléphone dans le protobuf), et instrumentation de l’application avec OTEL.

Tâches en cours et non réalisées

Bien que de nombreuses tâches aient été menées à bien, certaines sont encore en cours, notamment le déploiement de cert-manager et la documentation de Vault. Par ailleurs, l’intégration des vclusters avec ArgoCD est en cours de réalisation.

En termes de tâches non réalisées, nous avons décidé de ne pas poursuivre l’installation/configuration de k8s-sigs/external-dns dans le cluster, en raison de contraintes spécifiques au projet.

Résultat final

Notre projet a conduit à l’établissement d’une plateforme de déploiement capable de gérer une variété de services. Cette plateforme marque un progrès dans notre façon de déployer, gérer et surveiller les services informatiques, offrant une solution qui répond aux besoins variés de chaque club.

Pour des applications web, des bases de données ou des services de backend, elle fournit la flexibilité et les capacités nécessaires pour une gestion efficace et sécurisée des déploiements. Avec des outils tels qu’ArgoCD et Kustomize, le processus de déploiement est automatisé, facilitant des mises à jour et une maintenance continues.

Dans le domaine de l’observabilité et du monitoring, la plateforme intègre OpenTelemetry, Grafana et Clickhouse, offrant une vue complète sur les performances et l’état de santé de chaque service déployé. Cette capacité de surveillance est essentielle pour identifier rapidement les problèmes et optimiser les performances.

La gestion des secrets est gérée par l’implémentation de Hashicorp Vault, offrant une approche centralisée et sécurisée qui améliore la sécurité des services et simplifie les processus opérationnels.

La plateforme permet également de créer des environnements isolés avec Vcluster, bénéfique pour les développeurs des différents clubs. Ils peuvent tester et développer dans des environnements séparés sans impacter l’infrastructure principale. Cette fonctionnalité favorise une approche de développement anticipatif, où les tests et la détection des erreurs se font plus tôt dans le cycle de développement.

La gestion du HTTPS et de l’ingress est assurée par Cert-Manager et Contour, fournissant une configuration sécurisée pour l’accès aux services. Cette combinaison assure l’accessibilité et la sécurité des services déployés, avec une gestion automatisée des certificats SSL/TLS. Les phases suivantes de notre travail et dans nos futures initiatives.

Apprentissages et Compétences Acquises

Thomas

Dans le projet Plateforme Cedille, j’ai pris en charge la configuration d’OpenTelemetry, incluant le collecteur et l’opérateur, enrichissant ainsi ma compréhension de l’observabilité des systèmes. En parallèle, j’ai utilisé mes compétences en Golang pour intégrer des traces dans l’application calidum-rotae, en appliquant les principes du tracing distribué pour optimiser le monitoring et le débogage. J’ai également appris à utiliser Clickhouse pour le stockage et l’analyse des données collectées d’OpenTelemetry, et Grafana pour leur visualisation. Cette combinaison d’OpenTelemetry, Clickhouse et Grafana a créé un écosystème de monitoring complet, me permettant de voir comment ces technologies interagissent et se complètent.

Jonathan

Rejoindre ce projet a été pour moi une première expérience dans la création d’une infrastructure informatique. Apprendre à configurer et utiliser les différents services a été un des points forts pour moi. J’ai pu voir comment chaque service apporte sa pierre à l’édifice et comment tout s’imbrique pour créer un système fonctionnel. Cette compréhension pratique m’a armé d’une solide base pour estimer l’effort requis pour déployer chaque service et dimensionner les ressources nécessaires, que ce soit pour une migration d’envergure ou la mise en place d’une nouvelle infrastructure.

Ce projet m’a offert un modèle de référence, non seulement pour mes futurs projets, mais aussi pour quiconque s’intéresse à notre travail, étant donné que tout le projet est accessible publiquement. C’est une expérience qui me sera utile bien au-delà du cadre de ce projet.

Au-delà des aspects techniques, ce projet m’a permis de voir concrètement comment la division du travail en itérations et la planification en fonction des retours ont été des aspects clés qui ont permis une adaptabilité et réactivité productive et continue à travers les itérations.

Michael

Avec ce projet, j’ai eu l’opportunité d’apprendre comment utiliser et concevoir une bonne structure de projet avec Kustomize. Également, j’ai appris comment utiliser ArgoCD pour déployer des applications selon l’approche GitOps. J’ai aussi collaboré avec mes coéquipiers sur les autres aspects du projet, ce qui a été une bonne occasion de pratiquer mes habiletés en communication et en travail d’équipe. Ce qui est de plus grande valeur pour ce projet est le fait qu’on a bâti un tout nouveau système, en équipe. Ainsi, on a débuté avec une idée initiale, discutée, analysée, décidée, architecturée et implémenté chaque niveau du système, ce qui est une expérience de valeur incalculable.

Simon

Avant de démarrer ce projet, j’avais déjà une expérience superficielle avec plusieurs de ces outils. Toutefois, c’était la première fois que j’avais l’occasion d’explorer plus en profondeur ces technologies qui, je crois, formeront le futur des opérations à grande échelle d’entreprises. Notamment ce qui concerne la gestion des secrets et du stockage, je crois que nous avons configuré les outils de façon très intéressante et que cela fonctionnerait très bien pour de milliers de serveurs.

Mais surtout, j’ai beaucoup appris en ce qui concerne le travail d’équipe et l’organisation du travail. Ce projet comportait peu d’objectifs fixes et il aura fallu mettre en place certaines mesures pour atteindre la rigueur requise pour avancer le projet à rythme satisfaisant. Mettre en place de fort processus de suivi des tâches, de Pull Requests, d’ateliers de travail réguliers et plus fut essentiel à la réussite de ce projet.

Conclusion

En rétrospective, le projet Plateforme CEDILLE a été une expérience formatrice, riche en enseignements techniques et en gestion de projet. Nous avons relevé le défi de concevoir et de mettre en place une infrastructure informatique complexe, ce qui a demandé une coordination minutieuse et une collaboration étroite entre les membres de l’équipe.

Une des leçons clés tirées de ce projet est la nécessité de mieux prioriser notre carnet de travail. Avec le recul, nous avons réalisé que certaines opérations étaient bloquantes et auraient dû être traitées en priorité. Par exemple, la configuration de Vault, un composant clé pour la gestion des secrets, aurait pu être réalisée plus tôt étant donné que plusieurs autres services dépendaient de sa mise en place. Cette prise de conscience sera cruciale pour l’efficacité de nos futurs projets.

Avec l’infrastructure principalement en place, notre prochaine étape est de planifier et de réaliser la migration des services existants. Cette phase requiert une gestion méticuleuse pour assurer une transition sans heurts, en mettant l’accent sur la minimisation des interruptions de service et l’optimisation de la performance et de la sécurité.

Pour les futurs projets, notre conseil serait de valoriser l’adaptabilité et la capacité à répondre aux changements imprévus. La flexibilité dans la planification et la volonté de réviser les stratégies face à de nouvelles informations ont été des facteurs clés dans le succès du projet.

En somme, ce projet a été une expérience enrichissante qui a dépassé nos attentes en termes d’apprentissage et de développement professionnel. Nous sommes enthousiastes à l’idée d’appliquer ces compétences et ces connaissances acquises dans les phases suivantes de notre travail et dans nos futures initiatives.

Annexes

Document de vision: https://wiki-cedille-etsmtl-ca-git-vision-cedille.vercel.app/docs/overview/ Sprints: https://wiki-cedille-etsmtl-ca-git-vision-cedille.vercel.app/docs/sprints/ Répertoire Git: https://github.com/ClubCedille/Plateforme-Cedille Suivi des tâches : https://github.com/orgs/ClubCedille/projects/3

9.3 - Rétrospective 1

Rétrospective de le l’itération 1

Date: 11 octobre 2023

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Achat des nouveaux disques : L’évaluation de nos besoins a été complétée, la requête au TI est sur le point d’être envoyée.

2.2 Ne sera pas fait

• Ajouter le réseautage pour le provideur Terraform XCP-NG : Nous avons pris la décision de ne pas utiliser XCP-NG comme hyperviseur pour nos serveurs. Cette décision s’explique par le fait que nous désirons minimiser la complexité de l’infrastructure et qu’il n’y avait pas assez de valeurs ajoutées pour justifier cette configuration. Nous avons opté pour l’outil Vcluster comme alternative pour permettre de configurer différents environnements virtuels à l’intérieur de notre cluster Kubernetes.

3. Problèmes et défis

• Installation (bootstrap) du cluster Kubernetes / Talos: Installation du OS Talos Linux a partir de l’ISO généré par Sidero Omni et creation du cluster avec toutes les machines.

  • Problème: Impossibilité de décrypter les disques durant le premier démmrarage après l’installation d’une machine.
    • Cause: Malheuresement, après plusieurs ré-installation, on n’a pas pu identifier la cause.
    • Solution: Désactiver l’option de cryptage avant l’installation.
  • Problème: L’installation est brisée dès que la clé USB est retirée de la machine après l’installation.
    • Cause: L’identifiant du disque avec l’OS /dev/sdb n’est plus valide si la clé USB est retirée.
    • Solution: Ré-installation du cluster en spécifiant des identifiants de disque durable (/dev/disk/by-id/...) pour chaque machine.

• Configuration d’un ISO/image dans un PVC pour KubeVirt: Utiliser un ISO ubuntu dans un PVC pour l’utiliser comme CD-ROM lors du boot de la VM.

  • Solution : Installer le CDI de KubeVirt qui permet d’importer des images disque depuis un serveur web ou un registre de conteneurs, de cloner des volumes persistants existants, et de télécharger des images disque locales, le tout vers un DataVolume. Bref, il simplifie et optimise l’utilisation des revendications de volumes persistants (PVCs) comme disques pour les machines virtuelles.

• Installation initiale de Rook-Ceph : Installation initiale de rook-ceph (système de fichiers distribué) comme preuve de concept sur notre cluster Kubernetes.

  • Problème : Le cluster Ceph est inutilisable
  • Cause : La configuration des OSD (Object Storage Daemons) échoue.
  • Solution : Manuellement effacer tous les disques et redémarrer l’opérateur rook-ceph.

• Problème 2 : Description détaillée du problème et de son impact.

  • Solution envisagée : Description de la solution ou des étapes pour résoudre le problème.

• Défi 3 : Description du défi et pourquoi il a été un obstacle.

  • Solution envisagée : Mesures ou étapes pour surmonter ce défi à l’avenir.

9.4 -

Rétrospective de l’itération #X

Date: [Date de la réunion]

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Exemple de tâche 3 : Détails sur l’avancement et ce qui reste à faire.

2.2 Ne sera pas fait

• Exemple de tâche 4 : Raison pour laquelle la tâche n’a pas été réalisée.

3. Problèmes et défis

• Problème 1 : Description détaillée du problème et de son impact.

  • Cause : Desription de la cause du problème
  • Solution : Description de la solution ou des étapes pour résoudre le problème.

• Défi 2 : Description du défi et pourquoi il a été un obstacle.

  • Solution : Mesures ou étapes pour surmonter ce défi à l’avenir.

9.5 - Rétrospective 2

Rétrospective de l’itération 2

Date: 8 novembre 2023

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Configurer et deployer Gateway API #27 : La configuration de la Gateway API est actuellement en développement.
• Configurer OTEL #60 : La configuration de l’OpenTelemetry Collector est en cours pour permettre la collecte et l’exportation des données de télémétrie.

2.2 Ne sera pas fait

• Configurer/Deployer Linkerd #32 : Nous avons choisi de ne pas aller de l’avant avec Linkerd en tant que maillage de service pour le moment. Nous avons rencontrés des problèmes similaires à des issues ouvertes sur ce projet (11156 & 10994). Sans solution proposé, ont a decidé de se diriger vers une alternative (Kuma).
• Résoudre les problèmes de stabilité Rook/Ceph : Les problèmes récurrents de stabilité avec ceph ne semblait pas se résoudre. Possiblement du au fait que le logiciel est concu pour beaucoup plus de serevurs et disques. Nous avons plutôt décidé d’utiliser Mayastor, qui est beaucoup plus stable pour nous (voir Deployer et configurer Mayastor)

2.3 À faire

• Deployer cluster staging (vcluster) #6 & Deployer cluster sandbox (vcluster) #7 : Le déploiement du cluster de staging et sandbox avec vcluster est prévu.
• Documenter le déploiement avec Omni #17 : La documentation du processus de déploiement en utilisant Omni doit être créée.
• Documenter la configuration d’environnement locale avec Omni #19 : Il est nécessaire de documenter la configuration de l’environnement local pour Omni.
• Configuration des routes sur Talos #0 : La configuration des routes pour le système d’exploitation Talos doit être mise en place.
• Configurer la gestion à distance des serveurs physiques #16 : Pour permettre à l’équipe d’intéragir avec les serveurs à distance.
• Acheter SSDs

3. Problèmes et défis

• Problème 1 : Stabilité de Rook/Ceph. Le redémarrage d’un node rend le cluster ceph non-healthy. Les pods de ceph sur le serveurs associé ne finissent jamais leur processus de démarrage et ces disques ne sont jamais disponible.

  • Cause : Le problème semble être du au fait qu’un nouveau mon est créé puisque celui du node redémarré est mort. Puisqu’on ne permet pas la colocation de mon, il ne redémarre sur aucun autre serveur. Quand on redémarre sur le serveur on dirait que le nouveau et ancien mon se font compétition. Après une investigation approfondie, du au petit scale du cluster ceph (3 nodes), il semble y avoir une complexité et risque additionel.
  • Solution : Nous avons décidé que résoudre tous ces problèmes est trop de problèmes. Après une rapide preuve de concept, nous avons décidé de changer vers Mayastor. Ce système est bati pour kubernetes à partir de 0, ce qui devrait réduire le genre de problèmes opérationnels rencontrés avec ceph. Voir #33 pour plus de détails.

• Problème 2 : Configuration d’un service mesh pour kubernetes

  • Cause : La nécessité de prendre en charge mTLS dans le cadre de la configuration du service mesh. Le choix du service mesh doit aussi supporter Gateway API.
  • Solution : Nous avions prévu d’installer Linkerd comme service mesh, mais nous avons été confrontés à un problème lié à l’erreur #11156, qui n’était pas résolu au moment de notre installation. Face à cette difficulté, nous avons choisi de nous orienter vers Kuma, qui prend également en charge la Gateway API et offre la gestion du mTLS nécessaire pour nos besoins.

• Problème 3 : Installation et configuration du service External-DNS : Le service a été installé selon les instructions, cependant il ne marche pas et offre peu de détails sur l’erreur.

  • Cause : La cause n’a pas été identifiée pour le moment.
  • Solution : Il est possible qu’on fasse quelques enquêtes de plus pour faire fonctionner le service. On est aussi en train de regarder des solutions alternatives comme: Gestion du DNS avec crossplane et/ou migration du DNS vers Google Cloud.

• Problème 4 : Configuration du SSO pour ArgoCD sans gestion sécurisée des secrets. Nous avons rencontré un problème récurrent lors de la recréation des pods d’ArgoCD où les secrets nécessaires à la configuration du SSO ne pouvaient pas être conservés de manière sécurisée. La configuration initiale a été effectuée en utilisant le fichier values d’un Helm chart, incluant un token secret provenant de GitHub pour permettre l’authentification. Cependant, cela posait un problème de sécurité puisque le secret se retrouvait exposé sur GitHub lorsque le fichier values était sauvegardé. De plus, le secret devait être saisi à nouveau via kubectl à chaque fois que le namespace était recréé pour des raisons de débogage, ce qui ajoutait des tâches répétitives et fastidieuses à notre travail.

  • Solution : Pour résoudre ce problème, nous devons configuré le service Vault par HashiCorp, qui permettra de centraliser la gestion des secrets et de les injecter de manière sécurisée dans nos configurations sans les exposer dans notre dépôt GitHub. Cela réduirait considérablement les risques liés à la sécurité et optimiserait notre flux de travail en évitant la resaisie manuelle des secrets à chaque intervention sur l’infrastructure.

• Problème 5: Le bootstrapping de Hashicorp Vault demandait beaucoup d’étapes manuelles, notamment la génération de certificats TLS.

  • Cause: Un déploiement demande plusieurs étapes qui étaient difficiles à connecter ensemble de facon automatiser:
    1. Générer des certificats
    2. Configurer google cloud KMS pour unseal
    3. Générer une configuration Helm de Vault
    4. Déployer avec Helm
    5. Initialiser Vault
    6. Créer manuellement l’authentification Kubernetes
  • Solution: En utilisant des fonctionnalité de terraform permettant de rouler des commandes manuelles sur le client, nous avons réussi à automatiser plusieurs des opérations qui ne s’automatisais pas facilement avec terraform. La solution est un peu complexe et moins “propre” mais elle fonctionne bien. Nous avons aussi décidé que la fin du process terraform est la génération d’un fichier values.yaml qui est commit sur le répertoire git afin de configurer le déploiement Helm de Vault. Enfin, il reste certaines étapes manuelles, mais elles sont minimes et seront bien documenté à l’itération 3.

9.6 - Rétrospective 3

Rétrospective de l’itération 3

Date: 6 décembre 2023

1. Travail réalisé

2. Travail non terminé

2.1 En cours

• Documenter Vault : Partie administration terminée, partie utilisateur (déployer des secrets) à faire
• Intgration des vclusters avec ArgoCD : Une solution initiale a été essayé et échouée. Une solution de rechange doit être implementée.

2.2 Ne sera pas fait

• Installation/Configuration de k8s-sigs/external-dns dans le cluster :

2.3 À faire

• Deployer cluster staging [vcluster] : Le vcluster est déployé. Il reste a intégrer avec ArgoCD.
• Deployer cluster sandbox [vcluster] : Le vcluster est déployé. Il reste a intégrer avec ArgoCD.
• Mayastor Backup : Le backup est prévu. Une analyse sur le fournisseur externe sera faite.
• Installation plugin Vault+ArgoCD :
• Update ArgoCD and Grafana SSO secrets with vault : Nous étions en attente que le déploiement de vault dans le cluster soit terminés avec un exemple de configuration et gestion de secret pour pouvoir accomplir cette tâche. Elle pourra maintenant être complété avec des nouveaux secrets générés.
• Documenter OTEL (configuration du collecteur et operateur) : Maintenant que la configuration de OTEL avec un exemple de déploiement est complété, on va pouvoir documenter comment la configuration à été effectuée.

3. Problèmes et défis

• Problème 1 : Déploiement du service Calidum-rotae pour la démonstration de OTEL sur le cluster de production partiellement fonctionnel. 50% des requêtes étaient acheminées.

  • Cause : Le service communique avec un service api qui reçoit des requêtes http et les envois dans un channel discord à l’aide d’une webhook. Nous avons réalisé que le problème est externe au service Calidum-rotae et provient du service API qui est déployé sur un autre cluster kubernetes.
  • Solution : Configuration d’une webhook discord directement avec l’application au lieu du service API comme solution temporaire jusqu’à temps que le problème de réception de requêtes soit régler avec l’API.

• Problème 2 : (Tâche en cours) Impossibilité d’enregistrer les clusters virtuels (VCluster) dans ArgoCD de manière sécuritaire.

  • Cause : Malgré le fait que VCluster est supporté officiellement par ArgoCD, l’intégration n’a pas été conçue pour accéder à des VClusters qui sont privés.
  • Solution 1 : (Échoué) Une procédure complexe avec plusieurs scripts bash a été essayée afin d’exécuter tout le processus d’enregistrement à l’intérieur du réseau du cluster vs. le faire sur un poste développeur.
  • Solution 2 : (À essayer) Une meilleure solution proposée par Simon serait d’utiliser Crossplane pour configurer l’enregistrement des vclusters dans ArgoCD de manière déclarative grâce au provider Kubernetes dans Crossplane.

• Problème 3: Lors de nos premiers essais, Grav plantait à la première connexion.

  • Cause: Lors de l’initialisation de grav, celui-ci tente de modifier le fichier de configuration qui est généré par vault, car vault met le mot de passe en texte et grav souhaite changer cela pour un hash. Or le fichier de vault est read-only.
  • Solution: Créer un script de démarrage qui copie le fichier initial vers l’emplacement de destination. Cela permet aussi aux utilisateurs de changer la configuration dans le futur sans passer par nous.

10 - Guide de contribution

We use Hugo to format and generate our website, the Docsy theme for styling and site structure, and Netlify to manage the deployment of the site. Hugo is an open-source static site generator that provides us with templates, content organisation in a standard directory structure, and a website generation engine. You write the pages in Markdown (or HTML if you want), and Hugo wraps them up into a website.

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Quick start with Netlify

Here’s a quick guide to updating the docs. It assumes you’re familiar with the GitHub workflow and you’re happy to use the automated preview of your doc updates:

1. Fork the Goldydocs repo on GitHub.
2. Make your changes and send a pull request (PR).
3. If you’re not yet ready for a review, add “WIP” to the PR name to indicate it’s a work in progress. (Don’t add the Hugo property “draft = true” to the page front matter, because that prevents the auto-deployment of the content preview described in the next point.)
4. Wait for the automated PR workflow to do some checks. When it’s ready, you should see a comment like this: deploy/netlify — Deploy preview ready!
5. Click Details to the right of “Deploy preview ready” to see a preview of your updates.
6. Continue updating your doc and pushing your changes until you’re happy with the content.
7. When you’re ready for a review, add a comment to the PR, and remove any “WIP” markers.

Updating a single page

If you’ve just spotted something you’d like to change while using the docs, Docsy has a shortcut for you:

1. Click Edit this page in the top right hand corner of the page.
2. If you don’t already have an up to date fork of the project repo, you are prompted to get one - click Fork this repository and propose changes or Update your Fork to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
3. Follow the rest of the Quick start with Netlify process above to make, preview, and propose your changes.

Previewing your changes locally

If you want to run your own local Hugo server to preview your changes as you work:

1. Follow the instructions in Getting started to install Hugo and any other tools you need. You’ll need at least Hugo version 0.45 (we recommend using the most recent available version), and it must be the extended version, which supports SCSS.

2. Fork the Goldydocs repo repo into your own project, then create a local copy using git clone. Don’t forget to use --recurse-submodules or you won’t pull down some of the code you need to generate a working site.

   git clone --recurse-submodules --depth 1 https://github.com/google/docsy-example.git
   

3. Run hugo server in the site root directory. By default your site will be available at http://localhost:1313/. Now that you’re serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.

4. Continue with the usual GitHub workflow to edit files, commit them, push the changes up to your fork, and create a pull request.

Creating an issue

If you’ve found a problem in the docs, but you’re not sure how to fix it yourself, please create an issue in the Goldydocs repo. You can also create an issue about a specific page by clicking the Create Issue button in the top right hand corner of the page.

Useful resources

• Docsy user guide: All about Docsy, including how it manages navigation, look and feel, and multi-language support.
• Hugo documentation: Comprehensive reference for Hugo.
• Github Hello World!: A basic introduction to GitHub concepts and workflow.