From 2216b2075cadc0a28024e93b7e73866d478d4181 Mon Sep 17 00:00:00 2001 From: clevandowski Date: Fri, 9 Aug 2024 16:05:10 +0200 Subject: [PATCH 1/4] feat(IntegrationAcquiredCompany): add case study for archi devops --- .../IntegrationAcquiredCompany/exercise.md | 65 +++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 caseStudies/IntegrationAcquiredCompany/exercise.md diff --git a/caseStudies/IntegrationAcquiredCompany/exercise.md b/caseStudies/IntegrationAcquiredCompany/exercise.md new file mode 100644 index 0000000..4eca38c --- /dev/null +++ b/caseStudies/IntegrationAcquiredCompany/exercise.md @@ -0,0 +1,65 @@ +# Intégration du SI d'une entreprise acquise + +## Objectif + +L'objectif de cet exercice est de vous mettre dans la peau d'un architecte d'entreprise "devops" qui doit intégrer le système d'information d'une entreprise acquise dans le SI de l'entreprise acquérante. + +## Contexte technique de l'entreprise **Alpha** + +L'entreprise **Alpha** est une entreprise de taille moyenne qui opère dans le secteur de la distribution de produits électroniques. Elle a récemment acquis l'entreprise **Beta**, une entreprise de taille similaire qui opère dans le secteur de la distribution de produits informatiques. + +L'entreprise **Alpha** dispose d'un système d'information (SI) basé sur une infrastructure cloud pilotée par Terraform. Cette infrastructure est composée de plusieurs applications front et backoffice déployées sur Kubernetes (avec autoscaler), de bases de données PostgreSQL, et d'un CDN, le tout en service managé. + +Les outils de développement et de déploiement utilisés par l'entreprise **Alpha** sont basés sur des technologies open source et des services managés: + +- Github pour le versionning des sources +- Github Action pour l'intégration continue +- Helm pour le packaging des applications +- ArgoCD pour le déploiement des applications sur Kubernetes +- ElasticSearch pour la recherche et l'analyse des logs +- Prometheus / Grafana pour la surveillance des applications +- Les bases de données sont sauvegardées régulièrement sur le système de stockage (bucket, blob, storage...) du provider cloud, en plus du système fourni par le service managé. + +L'entreprise **Alpha** a également mis en place une architecture de microservices pour ses applications front et backoffice, avec une API Gateway et un OIDC pour l'authentification et l'autorisation des utilisateurs. + +## Contexte technique de l'entreprise **Beta** + +L'entreprise **Beta** dispose également d'un système d'information basé sur une infrastructure cloud + +Les applications sont constituées de plusieurs fronts et d'une api backoffice monolithique, qui s'appuie sur une base de données Oracle. + +Une équipe Data est également en charge de l'analyse des données et de la création de rapports via des scripts shell lancés via des taches cron, les traitements étant trop consommateur de ressources pour être lancés dans la journée. + +L'infrastructure cloud de l'entreprise **Beta** est basée sur des machines virtuelles statiques. + +Ces dernières sont créées par des scripts shell (voir manuellement) qui ne sont pas toujours à jour. Les machines virtuelles utilisent des distributions linux hétérogène (CentOS, Debian, Fedora) et ne sont pas régulièrement mises à jour. Certain de ces systèmes sont anciens et ne sont plus supportés par les éditeurs. + +Ansible est utilisé à la fois comme outil de configuration des VMs et de déploiement des applications et le système de surveillance est basé sur Nagios. + +L'outil de versionning des sources est un Gitlab installé au sein de l'infrastructure de l'entreprise **Beta**, avec 3 VMs dédiées (Gitlab, Gitlab Runner, Gitlab CI). Il y a 2 repositories Gitlab: un pour les front et le backoffice, et un pour l'équipe Data. + +Les ops de l'entreprise **Beta** créent le week-end des VMs avec énormément de ressources de calcul dédiées à l'équipe Data pour qu'ils puissent traiter les données plus rapidement. + +## Tâches + +Proposez une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha**, de sorte qu'elle soit faite de manière progressive et sans interruption de service majeure (c'est à dire dans les heures ouvrées), mais toutefois rapidement, efficacement (dans un délai d'environs 6 mois) et de manière à réduire les coûts. + +## Eléments de réponse attendus de la part du candidat + +Globalement, le candidat doit proposer une stratégation d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** en prenant en compte les éléments suivants: + +- Décrire la manière dont les 2 SIs vont être connectés (vpc peering si possible, vpn, LB privé, etc.) + +- Définir une stratégie globale de migration: bottom-up (d'abord la bases puis les applis) ou top-down. Il faut éviter de faire un mix des deux stratégies qui risque de cumuler la compléxité des deux approches. + +- Les applications de l'entreprise **Beta** doivent être déployées sur Kubernetes. Pour cela il faut les containeriser et mettre en place leur conf Helm. On peut faire cela en synchronisant les sources des applications de l'entreprise **Beta** avec un repository Github de l'entreprise **Alpha** et en utilisant Github Action pour construire les images Docker et les déployer sur Kubernetes. + +- Autorisation / habilitation: il faut que les applications de l'entreprise **Beta** puissent communiquer avec les applications de l'entreprise **Alpha**. Il faut donc permettre aux applications de l'entreprise **Beta** de s'authentifier sur l'OIDC de l'entreprise **Alpha**. + +- De la même manière, les scripts "cronés" de l'équipe Data de l'entreprise **Beta** doivent être containerisés et déployés sur Kubernetes via Github Action, des cronjobs, etc. Cela doit permettre de résoudre implicitement les besoins de scalabilité. + +- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles et les déployer sur Kubernetes. Il sera toujours possible de les découper en microservices par la suite. + +- Il n'est pas nécessaire de migrer les bases de données Oracle de l'entreprise **Beta** vers PostgreSQL, mais il est nécessaire de les intégrer dans le SI de l'entreprise **Alpha** afin de profiter des services managés de sauvegarde et de monitoring. + +- Il n'y a pas d'intérêt à investir dans l'infrastucture de l'entreprise **Beta** (machines virtuelles, scripts shell, Nagios, Gitlab) qui sera progressivement remplacée par l'infrastructure de l'entreprise **Alpha** (Kubernetes, ArgoCD, ElasticSearch, Prometheus / Grafana, Github, etc.), sauf éventuellement sur le court terme pour assurer la continuité de service. From ffc623a00040b3ab15c07213cf4184a052315625 Mon Sep 17 00:00:00 2001 From: clevandowski Date: Fri, 9 Aug 2024 16:33:21 +0200 Subject: [PATCH 2/4] feat(IntegrationAcquiredCompany): add domain name and certificates management --- caseStudies/IntegrationAcquiredCompany/exercise.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/caseStudies/IntegrationAcquiredCompany/exercise.md b/caseStudies/IntegrationAcquiredCompany/exercise.md index 4eca38c..83e6784 100644 --- a/caseStudies/IntegrationAcquiredCompany/exercise.md +++ b/caseStudies/IntegrationAcquiredCompany/exercise.md @@ -19,6 +19,7 @@ Les outils de développement et de déploiement utilisés par l'entreprise **Alp - ElasticSearch pour la recherche et l'analyse des logs - Prometheus / Grafana pour la surveillance des applications - Les bases de données sont sauvegardées régulièrement sur le système de stockage (bucket, blob, storage...) du provider cloud, en plus du système fourni par le service managé. +- Les endpoints https sont exposés via un ingress controller coté Kubernetes, un LoadBalancer du provider cloud, avec un certificat SSL wildcard fourni par Let's Encrypt mis à jour via cert-manager. L'entreprise **Alpha** a également mis en place une architecture de microservices pour ses applications front et backoffice, avec une API Gateway et un OIDC pour l'authentification et l'autorisation des utilisateurs. @@ -40,9 +41,13 @@ L'outil de versionning des sources est un Gitlab installé au sein de l'infrastr Les ops de l'entreprise **Beta** créent le week-end des VMs avec énormément de ressources de calcul dédiées à l'équipe Data pour qu'ils puissent traiter les données plus rapidement. +Un load balancer est utilisé pour exposer les applications en https, mais le certificat SSL est signé par un service tiers (comme Gandi ou Ionos) qui gère aussi le domaine. A chaque renouvellement du certificat, il faut le mettre à jour manuellement sur le load balancer, ce qui a déjà causé des interruptions de service. + ## Tâches -Proposez une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha**, de sorte qu'elle soit faite de manière progressive et sans interruption de service majeure (c'est à dire dans les heures ouvrées), mais toutefois rapidement, efficacement (dans un délai d'environs 6 mois) et de manière à réduire les coûts. +Présentez en 30' une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** après de la direction informatique. + +Elle doit se faire de manière progressive et sans interruption de service majeure (c'est à dire dans les heures ouvrées), mais toutefois rapidement, efficacement (dans un délai d'environs 6 mois) et de manière à réduire les coûts. ## Eléments de réponse attendus de la part du candidat @@ -58,8 +63,10 @@ Globalement, le candidat doit proposer une stratégation d'intégration du SI de - De la même manière, les scripts "cronés" de l'équipe Data de l'entreprise **Beta** doivent être containerisés et déployés sur Kubernetes via Github Action, des cronjobs, etc. Cela doit permettre de résoudre implicitement les besoins de scalabilité. -- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles et les déployer sur Kubernetes. Il sera toujours possible de les découper en microservices par la suite. +- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles. Il sera toujours possible de les découper en microservices par la suite. -- Il n'est pas nécessaire de migrer les bases de données Oracle de l'entreprise **Beta** vers PostgreSQL, mais il est nécessaire de les intégrer dans le SI de l'entreprise **Alpha** afin de profiter des services managés de sauvegarde et de monitoring. +- Il n'est pas nécessaire de migrer la base de données Oracle de l'entreprise **Beta** vers PostgreSQL, mais il est nécessaire de l'intégrer dans le SI de l'entreprise **Alpha** afin de profiter des services managés de sauvegarde et de monitoring. - Il n'y a pas d'intérêt à investir dans l'infrastucture de l'entreprise **Beta** (machines virtuelles, scripts shell, Nagios, Gitlab) qui sera progressivement remplacée par l'infrastructure de l'entreprise **Alpha** (Kubernetes, ArgoCD, ElasticSearch, Prometheus / Grafana, Github, etc.), sauf éventuellement sur le court terme pour assurer la continuité de service. + +- Pour les noms de domaines, on peut changer le fournisseur de nom de domaine de l'entreprise **Beta** pour le mettre chez le fournisseur de l'entreprise **Alpha** et ainsi bénéficier de la gestion des certificats SSL par cert-manager. From d022cd690061821f200cdeb29f38d98fd84bb350 Mon Sep 17 00:00:00 2001 From: Cyrille Levandowski <8653293+clevandowski@users.noreply.github.com> Date: Fri, 13 Dec 2024 08:59:18 +0100 Subject: [PATCH 3/4] Apply suggestions from code review Co-authored-by: Fabien Leite Co-authored-by: YAHIAOUI Samir --- caseStudies/IntegrationAcquiredCompany/exercise.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/caseStudies/IntegrationAcquiredCompany/exercise.md b/caseStudies/IntegrationAcquiredCompany/exercise.md index 83e6784..62319f3 100644 --- a/caseStudies/IntegrationAcquiredCompany/exercise.md +++ b/caseStudies/IntegrationAcquiredCompany/exercise.md @@ -33,7 +33,7 @@ Une équipe Data est également en charge de l'analyse des données et de la cr L'infrastructure cloud de l'entreprise **Beta** est basée sur des machines virtuelles statiques. -Ces dernières sont créées par des scripts shell (voir manuellement) qui ne sont pas toujours à jour. Les machines virtuelles utilisent des distributions linux hétérogène (CentOS, Debian, Fedora) et ne sont pas régulièrement mises à jour. Certain de ces systèmes sont anciens et ne sont plus supportés par les éditeurs. +Ces dernières sont créées par des scripts shell (voir manuellement) qui ne sont pas toujours à jour. Les machines virtuelles utilisent des distributions linux hétérogènes (CentOS, Debian, Fedora) et ne sont pas régulièrement mises à jour. Certains de ces systèmes sont anciens et ne sont plus supportés par les éditeurs. Ansible est utilisé à la fois comme outil de configuration des VMs et de déploiement des applications et le système de surveillance est basé sur Nagios. @@ -45,7 +45,7 @@ Un load balancer est utilisé pour exposer les applications en https, mais le ce ## Tâches -Présentez en 30' une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** après de la direction informatique. +Présentez en 30' une stratégie d'intégration du SI de l'entreprise **Beta** dans le SI de l'entreprise **Alpha** auprès de la direction informatique. Elle doit se faire de manière progressive et sans interruption de service majeure (c'est à dire dans les heures ouvrées), mais toutefois rapidement, efficacement (dans un délai d'environs 6 mois) et de manière à réduire les coûts. @@ -63,7 +63,7 @@ Globalement, le candidat doit proposer une stratégation d'intégration du SI de - De la même manière, les scripts "cronés" de l'équipe Data de l'entreprise **Beta** doivent être containerisés et déployés sur Kubernetes via Github Action, des cronjobs, etc. Cela doit permettre de résoudre implicitement les besoins de scalabilité. -- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles. Il sera toujours possible de les découper en microservices par la suite. +- Afin d'être le plus efficace possible, il faut éviter de rentrer dans un découpage des applications existante, mais plutôt les containeriser telles quelles. Il sera toujours possible de les découper en services par la suite. - Il n'est pas nécessaire de migrer la base de données Oracle de l'entreprise **Beta** vers PostgreSQL, mais il est nécessaire de l'intégrer dans le SI de l'entreprise **Alpha** afin de profiter des services managés de sauvegarde et de monitoring. From 8dcc35b8d8b9ffd943f846139614ca6e8ea48b82 Mon Sep 17 00:00:00 2001 From: clevandowski Date: Fri, 13 Dec 2024 09:16:31 +0100 Subject: [PATCH 4/4] Prise en compte des retours --- caseStudies/IntegrationAcquiredCompany/exercise.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/caseStudies/IntegrationAcquiredCompany/exercise.md b/caseStudies/IntegrationAcquiredCompany/exercise.md index 62319f3..e50f83b 100644 --- a/caseStudies/IntegrationAcquiredCompany/exercise.md +++ b/caseStudies/IntegrationAcquiredCompany/exercise.md @@ -25,13 +25,13 @@ L'entreprise **Alpha** a également mis en place une architecture de microservic ## Contexte technique de l'entreprise **Beta** -L'entreprise **Beta** dispose également d'un système d'information basé sur une infrastructure cloud +L'entreprise **Beta** dispose également d'un système d'information basé sur une infrastructure cloud. Les applications sont constituées de plusieurs fronts et d'une api backoffice monolithique, qui s'appuie sur une base de données Oracle. Une équipe Data est également en charge de l'analyse des données et de la création de rapports via des scripts shell lancés via des taches cron, les traitements étant trop consommateur de ressources pour être lancés dans la journée. -L'infrastructure cloud de l'entreprise **Beta** est basée sur des machines virtuelles statiques. +L'infrastructure cloud de l'entreprise **Beta** est basée sur des machines virtuelles. Ces dernières sont créées par des scripts shell (voir manuellement) qui ne sont pas toujours à jour. Les machines virtuelles utilisent des distributions linux hétérogènes (CentOS, Debian, Fedora) et ne sont pas régulièrement mises à jour. Certains de ces systèmes sont anciens et ne sont plus supportés par les éditeurs. @@ -41,7 +41,7 @@ L'outil de versionning des sources est un Gitlab installé au sein de l'infrastr Les ops de l'entreprise **Beta** créent le week-end des VMs avec énormément de ressources de calcul dédiées à l'équipe Data pour qu'ils puissent traiter les données plus rapidement. -Un load balancer est utilisé pour exposer les applications en https, mais le certificat SSL est signé par un service tiers (comme Gandi ou Ionos) qui gère aussi le domaine. A chaque renouvellement du certificat, il faut le mettre à jour manuellement sur le load balancer, ce qui a déjà causé des interruptions de service. +Un load balancer est utilisé pour exposer les applications en https, mais le certificat SSL est signé par un service tiers (comme Gandi) qui gère aussi le domaine. A chaque renouvellement du certificat, il faut le mettre à jour manuellement sur le load balancer, ce qui a déjà causé des interruptions de service. ## Tâches