12 Factor App Kubernetes 

Who am I ? Michel Hubert CTO Econocom Services 

Quels sont les enjeux d’une architecture Web ? XX - TITRE DE LA PRENTATION - 00.00.2022 • Scalabilité • Sécurité • Time To Market 

Qu’est-ce que le 12 Factor App ? • Le “12 Factor app” est un manifeste qui propose 12 bonnes pratiques concernant le développement d’applications web. • Ce manifeste, écrit par Adam Wiggins (co-fondateur d’Heroku), est né de ses observations et de son expérience dans le développement et le déploiement d’applications web. • Ce manifeste s’applique à tous les langages et toutes les plateformes, c’est pourquoi il se contente de décrire les décisions de conception de haut niveau sans donner de détail sur l’implémentation. • Nous allons dans cette session étudier comme appliquer cette méthodologie sur un projet à base de Kubernetes dans Azure (AKS) 

12 Factor App 1. Base de code 2. Dépendances 3. Configuration 4. Services externes 5. Build / Release / Run 6. Processus 7. Association de ports 8. Concurrence 9. Jetable 10. Parité Dev / Prod 11. Logs 12. Process d’administration 12… uniquement ? ….. D’autres son disponibles….. XX - TITRE DE LA PRENTATION - 00.00.2022 

1. Code Base Single source of Truth (SSOT) Everything as Code Infra as Code : Terraform Configuration as Code : Ansible / AppConfiguration / DSC Pipeline as Code : GitHub Actions (YAML) Docs as Code : Terraform Docs Image/container as Code : Docker File / ACR XX - TITRE DE LA PRENTATION - 00.00.2022 

2. Dependencies Gestion avancée de librairies (factorisation de code) Nuget, votre meilleur ami. XX - TITRE DE LA PRENTATION - 00.00.2022 Azure DevOps Artifacts – GitHub Packages 

2. Dependencies Warning : Sécurité dans l’utilisation de librairies OpenSource Surveillez les bases CVE Utilisez des outils comme GitHub Advanced Security ou Cast Highlight Passez de DevOps à DevSecOps ! XX - TITRE DE LA PRENTATION - 00.00.2022 

1. Dependencies XX - TITRE DE LA PRENTATION - 00.00.2022 

3. Configuration XX - TITRE DE LA PRENTATION - 00.00.2022 • Séparer la configuration du code • Les microservices doivent être indépendants de leur environnement d’exécution • Les microservices doivent passer d’un environnement à un autre sans modifier le code ! • Mettre en place une solution pour stocker centralement les configurations. 

3. Configuration XX - TITRE DE LA PRENTATION - 00.00.2022 

3. Configuration 

4. Backend services XX - TITRE DE LA PRENTATION - 00.00.2022 • A l’origine les containers sont stateless (et doivent le rester). • On parle d’architecture immuable • Externaliser le stockage des données (SQL et NoSQL) 

4. Backend services XX - TITRE DE LA PRENTATION - 00.00.2022 

4. Backend services XX - TITRE DE LA PRENTATION - 00.00.2022 

5. Build / Release / Run XX - TITRE DE LA PRENTATION - 00.00.2022 « You build it, you deploy it, you run it » 

5. Build / Release / Run XX - TITRE DE LA PRENTATION - 00.00.2022 

5. Build / Release / Run XX - TITRE DE LA PRENTATION - 00.00.2022 Intégrer des tests de montée en charge, stress, aux limites dans vos chaines CI/CD (Préproduction) 

5. Build / Release / Run 

5. Build / Release / Run XX - TITRE DE LA PRENTATION - 00.00.2022 Le véritable challenge : Montées de version ! 

5. Build / Release / Run XX - TITRE DE LA PRENTATION - 00.00.2022 Service A Service B Service C – v1 v1 v1 

5. Build / Release / Run Service A Service B Service C – v2 v1 v1 Deploy V2 

5. Build / Release / Run Service A Service B Service C – v1.2 v1 v1 Deploy V1.2 Pas de rupture côté interface 

5. Build / Release / Run Service A Service B Service C – v1.2 v1 v1 Deploy V2 Service C – v2 

5. Build / Release / Run Service A Service B Service C – v1.2 v1 v2 Deploy V2 Service C – v2 

5. Build / Release / Run Service A Service B Service C – v1.2 v2 v2 Deploy V2 Service C – v2 

5. Build / Release / Run Définir votre stratégie de déploiement / montée de version : Canary Blue/Green Feature Flags A/B Testing 

6. Process • Les microservices doivent être STATELESS ! • Ne pas stocker en mémoire, ni en local • Objectif : Scalabilité Horizontale ! • Minimiser le Downtime 

6. Process 

6. Process Un bus de message permet d’atténuer un pic de charge sur l’écriture en base de données 

6. Process 

6. Process 

7. Port Binding Sans conteneurs, chaque fois que vous déployez un nouveau service (ou une nouvelle version), vous devez éviter les collisions pour les ports déjà utilisés sur chaque hôte. L’isolation de conteneur vous permet d’exécuter tous les processus (y compris plusieurs versions du même microservice) sur le même port (en utilisant des espaces de noms réseau dans le noyau Linux) sur un seul hôte. L’objet Service expose ensuite le pool de microservices sur tous les hôtes et effectue un équilibrage de charge rudimentaire des demandes entrantes. 

8. Concurrency Le Facteur VIII est très lié au Facteur VI (Processes). Kubernetes (à partir de service stateless) permet l’autoscalling des services facilement. Autoscalling basé sur des métriques type CPU / mémoire ou métriques externes (taille d’une queue) 

9. Disposability • Caractéristiques d’un microservice (ou son Pod) : • ne se met pas à jour • ne se backup pas • peut être détruit (pb technique ou scalabilité) • Un problème ? Une mise à jour ? • On redéploie ! 

10. Dev/Prod Parity Règle de base : Les environnements sont ISO ! Grâce à l’infra as code, avoir cette parité semble facile… jusqu’à ce que…. On parle de la partie base de données ! Pas de recette miracle, quelques outils peuvent aider comme RedGate. 

11. Logs Enfer du debugging ! 

11. Logs 

11. Logs 

11. Logs 1. Tagguer avec un ID tous les messages entrants 2. Le service enregistre l’ID 3. L’ID est transmis au service de logs 4. Tagguer toute nouvelle requête avec cet ID Correlation ID 

11. Logs Transaction de End 2 End 

11. Logs 

12. Process d’administration • Lancez les processus d’administration et de maintenance comme des one-off- processes • La formation de processus est la liste des processus qui sont utilisés pour le fonctionnement normal de l’application (comme gérer les requêtes web) lorsqu’elle tourne. Les développeurs vont souvent vouloir effectuer des tâches occasionnelles d’administration ou de maintenance, comme : • Lancer les migrations de base de données. • Lancer une console (également appelée terminal REPL). • Exécuter des scripts ponctuels inclus dans le dépôt de code. • Les processus ponctuels d’administration devraient être lancés dans un environnement identique à ceux des processus standards de l’application. • Ils s’exécutent sur une release, en utilisant la même base de code et configuration que tout processus qui tourne pour cette release. • Le code d’administration doit être livré avec le code de l’application afin d’éviter les problèmes de synchronisation. Leitmotiv : Automatiser !! 

• Et Maintenant ? • Passons au 15 Factor App : pour les applications Cloud Native • API First • Télémétrie • Sécurité - Authentication / Authorization 

13. API First ▪ Qui dit micro-service, dit API ! ▪ 2 API : ▪ API public pour communiquer avec le « monde extérieur » ▪ API privée dite admin pour administrer, paramétrer le service ▪ Deux techniques pour requêter un service : ▪ GetProfilesById ▪ GET http://myapi.looksfamiliar.com/profiles/user/id/99999 ▪ GetProfilesByLocation ▪ GET http://myapi.looksfamiliar.com/profiles?location=Massachusetts 

14. Télémétrie ▪ Observabilité : Log + Métriques ▪ Ajouter un « health » report à vos micro-services ▪ Logger des métriques « métier » ▪ Solution possible : Application Insights 

14. Télémétrie • Health Pattern 

14. Télémétrie Etat du cluster 

14. Télémétrie 

15. Sécurité - AuhtN/Z ▪ Sécuriser vos API (par exemple jeton JSON) ▪ SSO ▪ RBAC pour les autorisations ▪ MFA + Authentification via les réseaux sociaux pour le B2C ▪ Merci qui ? Merci Azure AD (MFA, B2C, …) ▪ Couche réseau ▪ DDOS : Azure DDOS ▪ Database protection (vulnérabilités) Microsoft Defender ▪ SSL –HTTPS (Azure Front Door) ▪ Firewall 

Conclusion 

No content

Merci.