| Entreprise démarcher pour Stage | Date du démarchage | Lieux | Réponse |
| Rehzzo | 10/24 | Montauroux | Positif |
Voici le résumé des semaines de mon deuxième Stage en bts sio.
Stage Semaine 1
– Création d’une image docker + tag de l’image
– Installation de la CLI Nfs pour provisionner des PV automatiquement. (Sur une infra Kubernetes local)
– Mise en place de la charte helm argocd. (Sur une infra Kubernetes local)
– Configuration / Deploiement d’une charte Helm Harbor. (Sur une infra Kubernetes local)
– Déploiement d’image sur la Registry Harbor
– Mise en place d’un public Cloud (OpenStack)
– Création de fichier tofu (Fork de terraform) pour définir les ressources souhaitées (load-balancer, router, instance, groupe de sécurité, ip flottant, listener pour le load-balancer avec ses membre, réseaux interne,subnet..).
– Création d’une pipeline CI/CD pour déployer automatiser le déploiement d’une version à partir d’un gitlab et déployer la nouvelle version de l’image sur une application via Argocd (En cours)
Contexte
Cette semain été orienter beaucoup dans la découverte de technologie qui vont être utiliser dans le stage : kubernetes, Terraform. Et aussi des méthodes de travaille comme l’utilisation de gitlab pour chaque tache éffectuer via des tickets. Toute les configurations qui sont crée sont ensuite push sur le gitlab pour les conserver. L’infra kubernetes au début de la première semaine été Local.
Compétence : Docker, Kubernetes, Helm, ArgoCD, NFS, OpenStack, Terraform, CI/CD, gestion des ressources cloud, déploiement automatisé, gestion des registres d’images, gestion des infrastructures cloud, gestion des pipelines de déploiement, administration des ressources réseau.
Stage Semaine 2
– Déploiement d’une pipeline sur Gitlab CI/CD
– Installation d’un Gitlab via un docker-compose + reverse proxy nginx + configuration d’un postfix pour l’envoi de mails de gitlab (Oublie de mot de passe)
– Configuration d’un ingress controller pour un serveur web nginx (Sur une infra cloud)
– Personnalisation d’une charte WordPress (En viabilisant les valeurs souhaitez pour les déclarer ensuite dans un value.yaml)
– Déploiement d’une charte nginx sur Argocd à partir d’un dépôt Gitlab
Contexte
Durant cette deuxième semaine, l’objectif était de me familiariser avec une infrastructure cloud de production, accompagné du tuteur de stage avant chaque validation de déploiement. L’installation de GitLab s’est faite sur un VPS à part, ayant pour but de s’entraîner. Le reste était directement dans un environnement de production.
Compétence : GitLab CI/CD, Docker, Nginx, Postfix, reverse proxy, configuration d’Ingress Controller, serveur web, personnalisation de chartes Helm, configuration de values.yaml, déploiement automatisé avec Argocd, gestion de ressources cloud.
Stage Semaine 3
– Mise en place d’un footer sur un site web avec toute la procédure sur Gitlab (Création de Ticket, importation du code, modification du code, commit, merge request en incluant le ticket et le responsable + revue de code ensuite) c’était dans le but de comprendre la manière de travailler des devs et réseaux ensemble.
– Configuration de groupe de sécurité, règle de redirection de load-balance (OpenStack)
– Création de cloud-init utilisé dans la déclaration d’instance via Terraform pour standardiser l’état voulue de la machine lors du déploiement.
– Déployer de Cert-Manager pour la gestion automatique des certificats avec une demande de certificat pour le développement (Pas de limite) et pour la prod (Limiter par semaine)
Contexte
Durant cette troisième semaine, j’ai participé à plusieurs tâches visant à mieux comprendre les processus de déploiement et de collaboration entre les équipes. J’ai mis en place un footer sur un site web en suivant la procédure sur GitLab, incluant la création de tickets, l’importation et la modification du code, puis le commit, la merge request et la revue de code, afin de comprendre la méthode de travail des développeurs et des équipes réseaux. J’ai également configuré des groupes de sécurité et des règles de redirection pour le load-balancer sous OpenStack. De plus, j’ai créé un cloud-init utilisé dans la déclaration d’instances via Terraform pour standardiser l’état souhaité des machines lors de leur déploiement. Enfin, j’ai déployé Cert-Manager pour la gestion automatique des certificats, en configurant des demandes de certificats sans limite pour le développement et limitées par semaine pour la production.
Compétence: GitLab, gestion de tickets, processus de développement (commit, merge request, revue de code), sécurité réseau, configuration de groupes de sécurité, OpenStack, load-balancer, cloud-init, Terraform, déploiement d’instances, gestion des certificats, Cert-Manager, automatisation des certificats.
Stage Semaine 4
– Installation de la Chart Helm Openstack CCM et CSI pour intégrer kubernetes avec Openstack.
– Création d’une storage class pour créer automatiquement des volumes persistants (PVC) sur Openstack.
– Installation de keycloak pour gérer l’authentification centralisée, avec un domaine, ingress controller en terminaison tls, et de la storage class précédemment crée.
– Configuration de Keycloak domain, utilisateurs, groupes, et rôles et configuration du serveur smtp (utilisation d’infomaniak) pour l’envoi de mails de réinitialisation de mot de pass ou validation de compte
– Configuration de l’authentification Keycloak pour ArgoCD en crée un client sur client avec son client scope pour ensuite que le token possède les groupes créés dans key cloak et que argod les récupère pour ensuite associer ce groupe a des permissions voulue. (2 groupes associer à des rôles déjà présent admin, readonly + création de 2 groupes avec des permissions choisie une par une developer, support)
Contexte
Les installations et configurations de cette semaine ont été orientées vers l’automatisation et la centralisation de la gestion des ressources. Le CSI me permet de déclarer une StorageClass qui est ensuite utilisée dans les value.yaml des chartes afin que la charte puisse créer automatiquement le volume voulu. Idem pour cert-manager avec les clusters issu : en le précisant, un certificat est automatiquement délivré si le challenge est réussi.
Maintenant grâce à keycloak je peux centraliser la gestion des comptes et de leurs permissions sur toutes les applications (ArgoCD, Harbor pour le moment). Grâce à un compte admin, je crée un domaine pour mes applications et, dans ce domaine, je crée des comptes d’application servant uniquement à la connexion aux apps. Lors de la création des comptes, je peux forcer certaines actions à la première connexion (vérification des emails, modification du mot de passe temporaire, mise à jour des informations du compte).
Compétence : Installation Helm, OpenStack CCM, OpenStack CSI, Kubernetes, création de storage class, volumes persistants (PVC), installation Keycloak, gestion de l’authentification centralisée, domaine, Ingress Controller, TLS, configuration SMTP, gestion des utilisateurs, groupes, rôles, réinitialisation de mot de passe, validation de compte, configuration d’authentification Keycloak pour ArgoCD, création de client, token, groupes et permissions, gestion des rôles (admin, readonly, developer, support).
Semaine 5
– Installation de harbor via chart helm + exposition via ingress + utilisation du cluster issuer pour délivrer le certificat + utilisation de la storage class pour obtenir un volume pour le stockage et pour la registry utilisation d’un bucket s3 pour stocker les images et les charts.
– Création d’une chart helm pour déployer un site web via une image docker préalablement construite utilisant la version légère nginxalpine et une Chart Helm créer.
– Installation de la stack kube-prometheus regroupant : Prometheus, Grafana, Alert-manager + configuration de la connexion Grafana toujours via le keycloak installé précédent en associant les groupes keycloak à des rôles grafana déjà présents pour centraliser la gestion des accès (Exposition de Grafana via Ingress Controller + cluster issuer pour délivrer le certificat + utilisation de la Storage Class pour stocker les données)
Contexte
Les installations et configurations de cette semaine ont été orientées le déploiements d’applications, la gestion des registres d’images Docker et la mise en place de la surveillance de l’infrastructure. L’intégration de Keycloak a été utilisée pour la gestion des accès et la sécurisation des services, notamment Grafana pour la surveillance.
La stack Kube-Prometheus a été déployée pour fournir une surveillance complète avec Prometheus, Grafana et Alertmanager, tout en intégrant l’authentification centralisée via Keycloak pour simplifier la gestion des accès.
Compétence : Gestion des registres d’images Docker avec Harbor, Stockage dans bucket , création de charts Helm personnalisés, installation de Kube-Prometheus + grafana + alert-manager pour la surveillance et les metrics, intégration de Keycloak pour l’authentification centralisée de grafana, gestion des utilisateurs et des rôles dans Grafana via keycloak
Semaine 6
– Installation de Velero pour la sauvegarde des ressources du cluster, configuration de l’accès au bucket pour le stockage de ses sauvegardes.
– Mise en place d’une charte Helm pour une application web ayant un backend, un frontend, une base de données PostgreSQL, un stockage S3.
– Installation de PostgreSQL-operator fournie par Zalando permettant de faire des clusters de base de données PostgreSQL avec un système d’élection pour une plus grande résilience (Patroni).
– Installation d’un oauth2-proxy pour l’authentification des applications avec Keycloak pour celles qui ne prévoient pas par défaut une page d’authentification.
Contexte
Cette semaine de stage a été centrée sur la création d’une charte Helm pour le déploiement d’une application web comprenant un backend, un frontend, une base de données PostgreSQL, ainsi qu’un stockage S3. J’ai également mis en place des outils de sécurité pour gérer l’authentification des applications via oauth2-proxy et Keycloak pour les applications ne proposant pas une authentification par défault et une intégration à un IAM. En ce qui concerne la résilience de l’application j’ai l’installer PostgreSQL-operator (Fournie par Zalando) faisant du Patroni pour la gestion des clusters de bases de données.
Compétence : Sauvegarde Kubernetes, Velero, Kubernetes, S3, Déploiement avec Helm, Helm, Kubernetes, PostgreSQL, S3, Gestion de bases de données, PostgreSQL-operator, Patroni, Kubernetes, Authentification avec oauth2-proxy, oauth2-proxy, Keycloak, Kubernetes.
Information stage
Maître de stage : Mathieu REHO, Société REHZZO