Checklist pour concevoir une application dans le cloud.10 conseils à l'attention des développeurs
•
0 j'aime•30 vues
Kubernetes et les technologies cloud sont aujourd'hui les standards pour déployer des applications de toutes sortes dans le cloud: api, batchs, microservices et même des monolithes! Ils apportent des solutions à beaucoup de problèmes mais aussi une grande complexité. Il peut donc être très difficile pour les développeurs et concepteurs d'identifier les contraintes de telles architectures. Dans cette présentation, vous (re)découvrirez dix astuces et conseils que j'ai pu appliquer et qui m'ont aidé dans mes derniers projets. Ces derniers traiteront : de l'environnement de l'application du choix des solutions techologiques du développement des contraintes de conception liées à K8S et plus encore !
Signaler
Partager
Checklist pour concevoir une application dans le cloud.10 conseils à l'attention des développeurs
- 1. Checklist pour concevoir une application dans le cloud 10 conseils à l'attention des concepteurs Alexandre Touret / @touret_alex
- 2. Alexandre Touret Architecte / Développeur #Java #API #CI #Software_Craftsmanship 2 @touret_alex https://blog.touret.info
- 3. Un peu de contexte ... 1.
- 4. 4
- 7. Application gestion Périmètre maîtrisé Déploiement déjà automatisé 7
- 8. Quelles sont les contraintes techniques? Avez-vous des SLOs contraignantes? (ex. disponibilité supérieure à 99%) Avez vous vraiment besoin de scaler dynamiquement votre application ? 8
- 9. Mise à disposition d’environnements 9 Avez vous besoin de délivrer des environnements à la demande (et très rapidement)?
- 10. Les bases de Docker & Cie
- 11. 11
- 13. 13
- 14. Le contexte
- 15. « les organisations qui conçoivent des systèmes [...] tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation. » — M. Conway 15
- 16. Quel est le RACI ? Est-ce que votre organisation est compatible ? 16 RACI & Responsabilités
- 18. 18 Codebase One codebase tracked in revision control, many deploys Dependencies Explicitly declare and isolate dependencies Config Store config in the environment Backing Services Treat backing services as attached resources Build, release, run Strictly separate build and run stages Backing Services Treat backing services as attached resources Processes Execute the app as one or more stateless processes Port Binding Export services via port binding Disposability Maximize robustness with fast startup and graceful shutdown Dev/prod parity Keep development, staging, and production as similar as possible Logs Treat logs as event streams Admin processes Run admin/management tasks as one-off processes Source: https://12factors.net
- 19. 19 Pour une API
- 21. 21
- 22. Bien choisir ses frameworks et environnements d’exécution
- 23. 23
- 24. 24 Items à identifier ✓ Rapidité du démarrage ✓ Gestion des arrêts ✓ Capacité à s’intégrer dans Docker et K8S ✓ Observabilité ✓ Mémoire et CPU utilisées ✓ Gestion des dépendances et du patch management
- 25. TOMCAT vs FAT JARS → Un compromis Production - Équipes de développement 25
- 26. L’ observabilité
- 27. Adresser sur ce sujet dès la conception ! Ne pas attendre la mise en production :) Exposer via des endpoints REST l’état de votre système Faire attention aux FRAMEWORKS utilisés 27
- 28. liveness & readiness probes livenessProbe: failureThreshold: 3 httpGet: path: /actuator/health/liveness port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 28 readinessProbe: failureThreshold: 3 httpGet: path: /actuator/health/readiness port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1
- 29. Spring Actuator management.health.probes.enabled=true LivenessStateHealthIndicator & ReadinessStateHealthIndicator 29
- 30. 30 @Component public class MongoDBActuatorHealthIndicator implements HealthIndicator { [...] @Override public Health health() { // ping database } @Override public Health getHealth(boolean includeDetails) { if (!includeDetails) { return health(); } else { var statuses = mongoDBHealthService.findStatusForAllConfigurations(); return Health.status(checkStatus(statuses)).withDetails(statuses).build(); } } [...] }
- 32. La CI/CD
- 33. Étapes à intégrer dans votre chaîne ✓ Tests unitaires + intégration ✓ Création d’image Docker automatique ✓ “Smoke tests” de l’image crée ✓ Déploiement continu de la branche develop ✓ Déploiement de vos charts HELM (linter?) ✓ Déploiement d’une release ✓ ... 33
- 34. Exemple Migration Spring Boot, Tomcat, JDK Testé en local → Dev → Recette ⇒ En 1 jour 34
- 35. La configuration
- 36. 36 ▪ Variables d’environnement ▪ Config Maps ▪ Secrets
- 37. Les variables d’environnement spec: containers: - env: - name: JAVA_OPTS value: >- -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -Dfile.encoding=UTF-8 - Djava.security.egd=file:/dev/./urandom 37
- 38. Les config maps apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: 2021-03-11T18:38:34Z name: my-config-map [...] data: JAVA_OPTS: >- -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/./urandom 38
- 39. Quid des fichiers de configuration ? On peut les spécifier “comme des variables” directement dans les config maps On peut les externaliser 39
- 40. Les fichiers dans les config maps volumeMounts: - mountPath: /config name: configuration-volume readOnly: true [...] volumes: - configMap: defaultMode: 420 name: configuration name: configuration-volume 40 apiVersion: v1 kind: ConfigMap [...] data: my.conf: {{- (.Files.Glob "conf/*").AsConfig | nindent 2 }}
- 41. Externaliser les valeurs apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: labels: [...] spec: maxReplicas: {{ .Values.myapp.maxReplicaCount }} minReplicas: {{ .Values.myapp.minReplicaCount }} [...] targetCPUUtilizationPercentage: {{ .Values.myapp.replicationThreesold }} 41
- 42. Le fichier values.yml myapp: minReplicaCount: "2" maxReplicaCount: "6" replicationThreesold: 80 42
- 43. Les templates de fichier apiVersion: v1 kind: ConfigMap metadata: name: configuration labels: [...] data: application.properties: |- {{ tpl (.Files.Get "conf/application.properties") . | nindent 4}} 43
- 44. Les templates Le fichier application.properties logging.level.org.hibernate.stat={{ .Values.configmap.application.org_hib ernate_stat }} logging.level.org.springframework.sec urity={{ .Values.configmap.application.org_spr ingframework_security }} 44 Le fichier values.yml configmap: application: org_hibernate_stat: ERROR org_springframework_security: ERROR
- 45. Les fichiers binaires apiVersion: v1 # Definition of secrets kind: Secret [...] type: Opaque # Inclusion of binary configuration files data: my_keystore.jks: {{ .Files.Get "secrets/my_keystore.jks" | b64enc }} 45
- 47. L’utilisation des logs Dans la console: kubectl logs --tail Agrégateur de logs (ex. ELK) 47
- 48. Flux de sortie des containers Docker stdout & stderr Inutile de configurer la sortie vers des fichiers 48
- 49. Bonnes pratiques Indiquer dans vos LOGS: Les éléments de votre conteneur (Image, containerID,...) Les éléments de contexte K8S (IP POD, ID POD, namespace,...) Log4j Docker Support – Log4j Kubernetes Support 49
- 50. Pour aller plus loin Vous pouvez logger et tracer les appels à vos APIS: Requête, ID de l’appelant, ID de corrélation,... zalando/logbook: An extensible Java library for HTTP request and response logging 50
- 52. Sharing is caring! Tweettez @TheCloudFirstIO #TCF21 et tentez de gagnez vos stickers collector ! 10 gagnants seront tirés au sort dans la journée
- 53. Cette session vous a plu ? Faites-nous votre retour, et gagnez peut-être l’un des 30 packs stickers collector! https://feedback.thecloudfirst.io