Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Checklist pour concevoir une application dans le cloud: 10 conseils à l’attention des concepteurs et architectes

Checklist pour concevoir une application dans le cloud: 10 conseils à l’attention des concepteurs et architectes

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!
Au delà de la hype - et des trolls, 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 mettre en pratique et qui m'ont aidé dans mes derniers projets.

Ces derniers traiteront :

- de la pertinence du cloud dans vos projets et organisations
- du choix des solutions technologiques
- des contraintes de conception liées à K8S
- du développement
- de la gestion des livraisons au travers de la CI
- de l’observabilité
- et plus encore !

33003e72c00afccb1b1989e1ec21d21d?s=128

Alexandre Touret

March 30, 2022
Tweet

More Decks by Alexandre Touret

Other Decks in Technology

Transcript

  1. Checklist pour concevoir une application dans le cloud: 10 conseils

    à l’attention des concepteurs et architectes 1
  2. Alexandre Touret Architecte / Développeur #Java #API #CI #Cloud #Software_Craftsmanship

    2 @touret_alex https://blog.touret.info
  3. Un peu de contexte ... 1.

  4. 4

  5. Technologies utilisées 5

  6. 6 Besoin Les connaissances Le contexte La conception Démarrage Les

    environnements d’exécution L’observabilité CI/CD La configuration Les logs
  7. En avez vous VRAIMENT besoin ? Besoin Les connaissances Le

    contexte La conception Démarrage Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  8. Application gestion Périmètre maîtrisé Déploiement déjà automatisé 8

  9. Quelles sont les contraintes techniques? Avez-vous des SLOs contraignantes? (ex.

    disponibilité supérieure à 99%) Avez vous vraiment besoin de scaler dynamiquement votre application ? 9
  10. Mise à disposition d’environnements 10 Avez vous besoin de délivrer

    des environnements à la demande (et très rapidement)?
  11. Les bases de Docker & Cie Besoin Les connaissances Le

    contexte La conception Démarrage Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  12. 12

  13. Il vous faudra connaître 13

  14. 14

  15. De mon côté…

  16. Le contexte Besoin Les connaissances Le contexte La conception Démarrage

    Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  17. « 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 17
  18. Quel est le RACI ? Est-ce que votre organisation est

    compatible ? 18 RACI & Responsabilités
  19. Une vulnérabilité de la libc6 → qui le corrige :

    l’OPS ou le développeur? 19 Un exemple
  20. Les applications stateless et les autres ... Besoin Les connaissances

    Le contexte La conception Démarrage Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  21. 21 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
  22. 22 Pour une API Port Binding Disposability Dev Prod Parity

    Processes Config Concurrency
  23. Démarrage (rapide) de l’application Besoin Les connaissances Le contexte La

    conception Démarrage Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  24. 24

  25. Bien choisir ses frameworks et environnements d’exécution Besoin Les connaissances

    Le contexte La conception Démarrage Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  26. 26

  27. 27 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
  28. L’ observabilité Besoin Les connaissances Le contexte La conception Démarrage

    Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  29. 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 29
  30. liveness & readiness probes livenessProbe: failureThreshold: 3 httpGet: path: /actuator/health/liveness

    port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 30 readinessProbe: failureThreshold: 3 httpGet: path: /actuator/health/readiness port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1
  31. Monitoring ▪ Micrometer ▪ Prometheus ▪ Grafana 31

  32. Micrometer • Permet d’exporter des métriques (par ex. Le TTR

    d’une API en utilisant l’annotation @Timed) • Ces métriques peuvent être agrégées dans Prometheus dependencies { implementation 'io.micrometer:micrometer-registry-prometheus’ }
  33. 33 management: endpoints: enabled-by-default: true web: exposure: include: '*' jmx:

    exposure: include: '*' endpoint: health: show-details: always enabled: true probes: enabled: true shutdown: enabled: true prometheus: enabled: true metrics: enabled: true health: livenessstate: enabled: true readinessstate: enabled: true datasource: enabled: true metrics: web: client: request: autotime: enabled: true Actuator configuration Metrics configuration
  34. La CI/CD Besoin Les connaissanc es Le contexte La conception

    Démarrage Les environneme nts d’exécution L’observabili té CI/CD La configuration Les logs
  35. Deux sortes de pipelines • Création plateforme • Build &

    Deploy
  36. Platform provisionning terraform apply

  37. Application build & deploy Build •Application Java •Image Docker •Chart

    Helm Tests •Tests unitaires et d’integration •Smoke tests de la nouvelle image Docker Deployment •Déploiement continu de la branche develop •Déploiement de la release
  38. Exemple Migration Spring Boot, Image Docker, JDK Testé en local

    → Dev → Recette ⇒ En 1 jour 38
  39. La configuration Besoin Les connaissances Le contexte La conception Démarrage

    Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  40. Comment configurer votre application cloud native? 40 ▪ Variables d’environnement

    ▪ Config Maps ▪ Secrets
  41. 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 41
  42. 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 42
  43. Quid des fichiers de configuration ? On peut les spécifier

    “comme des variables” directement dans les config maps On peut les externaliser 43
  44. Les fichiers dans les config maps volumeMounts: - mountPath: /config

    name: configuration-volume readOnly: true [...] volumes: - configMap: defaultMode: 420 name: configuration name: configuration-volume 44 apiVersion: v1 kind: ConfigMap [...] data: my.conf: {{- (.Files.Glob "conf/*").AsConfig | nindent 2 }}
  45. Limitations ▪ Error: UPGRADE FAILED: ConfigMap "my- service" is invalid:

    data: Too long: must have at most 1048576 characters
  46. Externaliser les valeurs apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: labels: [...]

    spec: maxReplicas: {{ .Values.myapp.maxReplicaCount }} minReplicas: {{ .Values.myapp.minReplicaCount }} [...] targetCPUUtilizationPercentage: {{ .Values.myapp.replicationThreesold }} 46
  47. Le fichier values.yml myapp: minReplicaCount: "2" maxReplicaCount: "6" replicationThreesold: 80

    47
  48. Les templates de fichier apiVersion: v1 kind: ConfigMap metadata: name:

    configuration labels: [...] data: application.properties: |- {{ tpl (.Files.Get "conf/application.properties") . | nindent 4}} 48
  49. 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 }} 49 Le fichier values.yml configmap: application: org_hibernate_stat: ERROR org_springframework_security: ERROR
  50. 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 }} 50
  51. Logger efficacement Besoin Les connaissances Le contexte La conception Démarrage

    Les environnements d’exécution L’observabilité CI/CD La configuration Les logs
  52. L’utilisation des logs Dans la console: kubectl logs --tail Agrégateur

    de logs (ex. ELK) 52
  53. Flux de sortie des containers Docker stdout & stderr Inutile

    de configurer la sortie vers des fichiers 53
  54. 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 54
  55. Distributed tracing Vous pouvez identifier et corréler vos différents appels

    dans votre plateforme microservices en implémentant OpenTracing. 55
  56. 56

  57. Sur GCP ▪ Vous avez par défaut: □ Un explorateur

    de logs (Google Logs Explorer ~ELK) □ Un rapport d’ erreurs (~ dashboard ELK) □ Un analyseur de traces distribuées 57
  58. 58

  59. Error Reporter ▪ Par défaut, il agrège toutes les erreurs

    de votre plateforme ▪ Vous pouvez également ajouter vos erreurs business (ex. HTTP 500) 59
  60. 60

  61. Distributed tracing 61

  62. En résumé 62

  63. Evitez le hype driven development Pensez à votre organisation Travaillez

    sur l’observabilité dès les premières étapes Automatisez tout (ou presque)
  64. Merci! Des questions? 64