Spring Boot & Containers - Do's & Don'ts
1 j'aime•330 vues
Le document présente des bonnes pratiques et des pièges à éviter lors de l'utilisation de Spring Boot avec des conteneurs comme Docker et Kubernetes. Il aborde des sujets tels que la configuration, les healthchecks, l'optimisation des images Docker, et les meilleures pratiques pour gérer les ressources et la sécurité dans un environnement Kubernetes. Cet exposé est basé sur l'expérience de l'auteur et vise à faciliter les déploiements d'applications tout en évitant les erreurs courantes.
Spring Boot & Containers - Do's & Don'ts
- 1. Spring Boot & Containers Do’s & Don’ts + + = Julien Wittouck - @CodeKaio ��
- 2. Salut 👋 Moi c’est Julien ❤ 🎸 🤘 🎮 Freelance @CodeKaio Associé @Ekité Teacher @univ-lille 👶 Speaker (DevFest Lille - Sunny Tech)
- 4. Exécuter une application dans un container c’est facile Un Dockerfile 🐋, un jar 📦 et hop 🚀
- 5. Moi qui mets mon container en prod
- 6. Les admins sys qui voient mon container en prod
- 7. J’écris des (mauvais) Dockerfile depuis 2015 J’écris du Spring Boot depuis la version 1.0 (2014)
- 8. Bonnes pratiques Spring Boot & Containers
- 9. 3 parties
- 10. Spring Boot, Docker et Kubernetes - c’est facile
- 11. Spring Boot, Docker et Kubernetes - C’est compliqué
- 12. Spring Boot, Docker et Kubernetes - C’est compliqué
- 13. Spring Boot, Docker et Kubernetes - C’est compliqué
- 14. Spring Boot & JVM Bonnes pratiques “Your Spring Boot app, prepare you must” – Yoda, The Empire Strikes Back (1980)
- 15. la configuration 🔧 💡 Utiliser les profils Spring Prévoir des profil de configuration multiples: ● par environnement : local, TU, development, staging, production… ● par typologie de déploiement : on-premises, Kubernetes sur un cloud, serverless 🎉 composition de profils en fonction de l’endroit où on déploie ⚠ jamais de secrets dans les properties ! Doc Spring Profile Specific Files
- 16. les healthcheck 🏥 💡 Exposer des endpoint HTTP pour connaître la santé de l’application ● est-elle démarrée ? ● est-elle prête à répondre à des requêtes ? (Connexion à la BDD dispo par ex.) 🎉 spring-boot-starter-actuator ● utilisé par les healthcheck Docker, et par les probes Kubernetes ● peut être utilisé par les healthcheck de Load Balancing (on-premises) ● utilisé par des sondes de monitoring
- 17. spring-boot-starter-actuator 😎 Plein de endpoint cools pour débugger une appli ● /actuator/env : récupérer la configuration ● /actuator/httpexchanges : récupérer les 100 dernières requêtes traitées ● /actuator/loggers : récupérer et modifier ( 🤯 ) la configuration des logs ● /actuator/health & /actuator/metrics : récupérer la vie de l’application ● /actuator/mappings : liste les endpoints de l’application … management.endpoints.web.exposure.include=*
- 18. les métriques 📈 💡 Exposer des métriques techniques et fonctionnelles 🎉 spring-boot-starter-actuator embarque micrometer ajout d’une dépendance pour être compatible Prometheus ou OpenMetrics ● /actuator/prometheus : liste les métriques au format Prometheus
- 19. les métriques 📈
- 20. les métriques 📈
- 21. graceful shutdown 🛑 💡 Configurer l’application pour qu’elle s’éteigne proprement, en terminant les dernières requêtes HTTP en cours de traitement Permettra de faire des déploiement en Rolling Update sans coupure de service server.shutdown=graceful
- 22. JVM ⚡ Ayez conscience des besoins de votre application CPU/RAM: ● vos futurs paramètres -Xms et -Xmx ● vos futurs resources.requests/limits.cpu/memory Kubernetes Faites des tirs de performance pour les découvrir ou les valider
- 23. native-image 💡 Expérimentez le build d’image native ⚡ : booste le temps de démarrage des applications (qq millisecondes !) ⚠ : attention aux limitations de Spring Boot ⚠ : coût de compilation élevé 🛑 : avec GraalVM community, uniquement le GC Serial 😢 https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html
- 24. Spring Boot & JVM Les pièges à éviter “It’s a trap” – Admiral Ackbar, Return of the Jedi (1983)
- 26. ForkJoinPool, on oublie Parallélisme par défaut = nombre de CPU “visibles” par la JVM 💡 Usage de stream.parallel() à bannir Aucun contrôle sur le pool utilisé, peut être contre productif si le pool ne contient que 2 threads ! CompletableFuture peut être utilisé en contrôlant le pool de threads utilisé.
- 28. Filesystem, on oublie Les containers sont volatiles 💸 Créés/supprimés au bon vouloir des orchestrateurs. Le filesystem ne persiste pas, sauf gestion de volumes. 💡 Limiter l’adhérence des applications au filesystem Pour le code générant des fichiers (exports PDF, XLS), manipuler des InputStream/OutputStream qui pointent vers des buckets par exemple.
- 30. spring-boot-starter-actuator sur 8080, on oublie ⚠ Attention à l’exposition de l’actuator 💡 Utiliser un port différent pour exposer l’actuator ou configurer spring-security sur les endpoints (facile à faire, mais rend l’usage vraiment compliqué) server.port=8080 management.server.port=9090
- 32. logger sur le filesystem, on oublie Pratique en VMs, couplé à une centralisation À laisser tomber en container. (pas d’adhérence au filesystem) 💡 Logger sur la console stdout/stderr Logger sur le filesystem du container implique: ● un filesystem dispo en écriture ● un outil pour extraire les logs du container (déployé en sidecar k8s 😟) ● docker log et kubectl log qui ne marchent pas ! 😟 💡 Prévoir une configuration double avec des profils différents si l’application est hybride.
- 33. 🔧 trop de trucs dans application.properties/yaml
- 34. application.properties/yaml Ces fichiers contiennent les propriétés qui sont communes à tous les profils. ❌ interdit d’y mettre des properties d’un environnement de dev. 💡 Privilégiez la création d’un profil Spring ‘local’ par exemple. Doc Spring Externalized Configuration à connaître par 💙
- 37. Docker Bonnes pratiques “Would it help if I got out and push your container image ?” – Leia, The Empire Strikes Back (1980)
- 38. Partir d’un Dockerfile simple, et l’améliorer ℹ Un bon guide : https://spring.io/guides/topicals/spring-boot-docker/ Dockerfile qui contient un jar Dockerfile multi-layers Dockerfile multi-layer et multi-stage
- 39. Dockerfile simple (simpliste) Une image 🐋, un fat-jar 📦 buildé par maven et hop 🚀
- 40. Sélectionnez une image de base Les questions à se poser (avec les ops) : ❓ layer distribution ? ubuntu ? alpine ? ❓ jdk ? / jre ? ❓ version de java (17 ? 20 ?) Un bon point de départ: ℹ eclipse-temurin:17–jre alpine eclipse-temurin:17-jre-alpine 163 Mo 7 Mo ubuntu:jammy eclipse-temurin:17-jdk 377 Mo 78 Mo ubuntu:jammy eclipse-temurin:17-jre 188 Mo 78 Mo
- 41. Optimisez vos layers ❌ avoir le moins de layers possibles ✅ layers réutilisables ✅ petites layers ⚡ optimiser la construction ⚡ optimiser le déploiement si juste un bout de code a changé ubuntu:jammy eclipse-temurin:17-jre mon-application.jar 80 Mo 188 Mo 78 Mo ubuntu:jammy eclipse-temurin:17-jre mon-application/libs 70 Mo 188 Mo 78 Mo mon-application/classes 10 Mo
- 42. Dockerfile multi-layers 📦 On builde le fat-jar 💥 On explose le fat-jar 🐋 On ajoute une layer pour : ● les libs ● les meta data ● les classes ⚡ On tire partie du cache Docker ⚡ L’appli démarre plus vite
- 43. Dockerfile multi-layers & multi-stage 🐋 Tout dans le Dockerfile ⚡ Top pour la CI ! 🤯 : presque des builds reproductibles
- 44. Tirez partie du cache Docker 🐋 👍 Pratique pour une intégration continue ✅ Permet de ne pas reconstruire les layers n’ayant pas été modifiées 😰 Fastidieux à configurer, mais ça vaut le coup https://docs.docker.com/build/cache/backends/ cache 🐋 ubuntu:jammy eclipse-temurin:17-jre mon-application/libs 70 Mo 188 Mo 78 Mo mon-application/classes 10 Mo
- 45. Remplissez votre container de Heap 😅 Si votre container a 2 CPU et 4Go de RAM, la JVM va réserver 1Go de heap seulement par défaut ✅ -Xms et -Xmx à 75% de la RAM allouée au container ou ✅ -XX:InitialRAMPercentage=75 -XX:MaxRAMPercentage=75
- 46. Attention au GC 🧹 utilisé ! # CPU GC <1 Serial 1 Serial >1 G1 ∞ G1 ⚠ Le ZGC n’est pas par défaut, à forcer si vous voulez l’expérimenter pour viser des temps de pause de GC plus faibles. Un bon article ici : https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html ⚠ Attention au GC Serial si vous utilisez une image native
- 47. Docker 🐋 & la JVM ☕ 💡 Proposez des paramètres de JVM par défaut Positionnez la variable JAVA_TOOL_OPTIONS avec ces valeurs Mettez à dispo une variable supplémentaire JAVA_OPTS pour la customisation
- 48. Versionning des images 🏷 💡 Utilisez le même versionning pour vos images Docker 🐋 que pour votre application 📦. Une bonne idée peut-être de récupérer le champ version du pom.xml et de l’utiliser pour tagger vos images docker.
- 49. ❌ n’utilisez jamais le user root 🗡, chaque Dockerfile doit avoir une directive USER ❌ jamais de secrets dans un Dockerfile (ça reste dans les layers) ✅ mettez à jour vos images “parentes” régulièrement ✅ préférez pointer sur des images parentes avec un tag précis, comme : eclipse-temurin:17.0.6_10-jre Cela rend la montée version explicite, plutôt que refaire un docker image build —no-cache 🗡 ✅ extrayez un SBOM de vos images (distrib+middleware+software), vos RSO/RSSI seront contents 😇, et ce sera plus facile pour vous lors de la prochaine faille log4j 😅 Sécurité 🔒
- 50. Autres outils de build 🔧 💡 Expérimentez jib ou un buildpack Ces outils permettent de construire des images Docker 🐋, sans avoir de Dockerfile Ils implémentent les bonnes pratiques, c’est ça en moins à gérer de votre côté https://github.com/GoogleContainerTools/jib https://buildpacks.io/
- 51. Observez vos images 👀 💡 utilisez dive pour explorer vos images/layers observer le filesystem des images en interactif afficher des axes d’optimisation https://github.com/wagoodman/dive
- 53. Scannez vos images à la recherche de CVE 🔒 💡 utilisez trivy pour analyser vos images/layers Listing des CVE sur toutes les layers: ✅ : distrib ✅ : appli Va même fouiller dans les jar ! https://aquasecurity.github.io/trivy/
- 55. Docker Les pièges à éviter “You’ll be malfunctioning within a day, you nearsighted scrap container !” – C3PO, A New Hope (1977)
- 57. .dockerignore 🙈 Liste les fichiers à ignorer lors de la construction de l’image Docker Ignorer les répertoires habituels: .git/ target/ build/ node_modules/ .idea/ .settings/ ⚡ Booste la construction des images
- 58. 🪫 Chercher à tout prix à utiliser une image customisée
- 59. FROM mon_image_custom:latest ❌ Construire et maintenir une image parente nécessite beaucoup d’effort en suivi des mise à jour distribution, et middleware 😫 Vous aurez déjà assez de travail pour suivre et monter de version vos applis en prod Si vous avez des contraintes particulières (comme des certificats à injecter dans vos JVM), c’est obligatoire, sinon oubliez
- 60. 🪫 Chercher à tout prix à utiliser des images minimalistes (alpine)
- 61. ubuntu ⚔ alpine jdk ⚔ jre ℹ Docker/Containerd optimise le stockage ℹ une layer n’est présente qu’une fois sur le filesystem final (le node Kubernetes ou votre machine) 💡 Penser à la prod : Une image plus petite contiendra moins d’outils qui peuvent être utiles (curl, jfr…) Que cherche t-on à optimiser ? Les machines chez les Clouds ont un réseau performant, le stockage est peu coûteux … alpine eclipse-temurin:17-jre-alpine 163 Mo 7 Mo ubuntu:jammy eclipse-temurin:17-jdk 377 Mo 78 Mo ubuntu:jammy eclipse-temurin:17-jre 188 Mo 78 Mo
- 62. 😰 Se casser la tête avec DinD (Docker in Docker)
- 63. 💡 Utilisez Kaniko ou Jib 💡 builder vos images Docker dans un cluster Kubernetes, utilisez Kaniko ou Jib: ✅ Pas besoin de docker pour builder une image ✅ Fonctionne en “user-space” Linux, pas besoin d’être root ✅ Kaniko “exécute” les Dockerfile comme un docker image build ✅ Jib crée directement une image sans avoir besoin d’un Dockerfile https://github.com/GoogleContainerTools/kaniko https://github.com/GoogleContainerTools/jib
- 64. Kubernetes Bonnes pratiques “Pit tit tu ti ti tuuuuuuu ti pip tu pi piiiiip ti ti” – R2D2, every damn SW movie (1973-2019)
- 65. Utilisez des deployments, et pas des pods tous seuls Déployez vos applications dans des namespaces 🤗 des classiques, mais toujours bon à rappeler
- 66. Utilisez des requests/limits 📊 📝 Un bon guide : https://learn.microsoft.com/en-us/azure/developer/java/containers/overview Visez une QoS “Burstable” ou “Garanteed”: ✅ CPU request ✅ CPU limits optionnelle : permet le Burst de CPU ✅ Memory request ✅ Memory limit : bonne pratique pour des JVM Personne n’aime les OutOfMemoryError 😨🚩
- 67. Chargez votre configuration avec des configMap ou des secrets ✅ N’hésitez pas à utiliser ces objets “natifs” Kubernetes Les ConfigMap et Secret k8s peuvent être montés en variables d’environnement ou en fichier Spring Boot comprend bien les variables d’environnement, et charge les fichiers dispo dans spring.config.location https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe -configuration-properties.relaxed-binding.environment-variables https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.files
- 68. Les secrets k8s 🔒 ne sont pas secrets 🔓 Oui, c’est du bluff 😅 Pour les secrets vraiment secrets, clés d’API et autres mots de passe, plusieurs solutions: ✅ : Sealed Secrets (Bitnami) : le plus simple ✅ : Vault (Hashicorp) : le plus complexe (avec sidecar) ✅ : Key vaults managées des Cloud : le plus vendor lock-in
- 69. Jamais 2 pods sur le même node ou sur la même zone 🤗 Un classique, mais toujours bon à rappeler Ça se fait facilement avec des contraintes de topologie sur un Deployment ou au niveau du cluster https://kubernetes.io/docs/concepts/scheduling-eviction /topology-spread-constraints/
- 70. Ne montez pas de token de service-account sur vos pods, sauf si nécessaire ça évite de laisser un 🥷 faire le foufou dans votre namespace si votre RBAC est mal configuré https://kubernetes.io/docs/tasks/configure-pod-contain er/configure-service-account/#opt-out-of-api-credentia l-automounting
- 71. Laissez mourir vos pods en paix 💀 Quand Kubernetes supprime un Pod: 🗡 : il SIGTERM le Pod 🗡 : il met à jour les règles de routage (iptables) 🗡 : il supprime le Pod des Service concernés Pendant ce temps, il se peut que des requêtes soient envoyées au Pod, alors qu’il est en train de s’éteindre (tous les Nodes ne sont pas mis à jour au même instant) Un preStop hook permet de retarder le SIGTERM pendant que le reste se met à jour https://www.thoughtworks.com/insights/blog/cloud/shutdo wn-services-kubernetes
- 72. Kubernetes Les pièges à éviter “I find your lack of resource reservation disturbing” – Darth Vader, A New Hope (1977)
- 73. 🔧 rebuilder votre application pour changer une conf
- 74. 🚩 vous n’avez rien suivi, je vous envoie le seigneur Vador
- 76. spring-cloud-kubernetes ✅ : Facile à utiliser, charge la config directement depuis l’API k8s, nécessite un ServiceAccount avec les droits adéquats. ⚠ : Attention, votre code va commencer à dépendre de l’infrastructure ! 🤔 : C’est probablement peu souhaitable. A désactiver en local. 🙅 : Aucun développeur ne veut faire tourner un cluster k8s sur son poste.
- 77. 🛵🔧 Charger la configuration avec un sidecar
- 78. Sidecars, Vaults 🔒 et autres 💡 Déposer un fichier de properties contenant des secrets pré-chargés dans le filesystem d’un pod. Bonne idée pour externaliser les secrets ⚠ : Attention à la complexité des sidecar 🙅 : Aucun développeur ne souhaite devoir exécuter un agent Vault sur son poste.
- 79. ⏫ Utiliser un VPA/HPA en surveillant la RAM
- 80. Vertical & Horizontal Pod Autoscalers 💡 : c’est une bonne idée de les utiliser ❌ : N’utilisez jamais la memory comme métrique ⚠ Vos ReplicaSet vont scaler au max et ne jamais redescendre ! On configure la JVM pour occuper tout l’espace disponible La JVM ne rend (presque) jamais la mémoire qui n’est plus utilisée Observer le CPU c’est déjà un bon début
- 81. ⏭ Utiliser le tag ‘latest’
- 82. Une version toujours à jour ? ❓ Comment on rollback une image qui s’appelle latest ❌ On peut pas ! kubectl rollout undo deployment/incom-deployment
- 84. Économiser un pull 💡 une bonne idée si on est rigoureux dans la gestion du versionning des images. 🔊 “Mon image ne se met pas à jour” - Un développeur triste 😢 qui a publié une nouvelle image en écrasant le numéro de version. ❌ Ne cherchez pas à économiser l’exécution d’un image pull Si les layers sont les mêmes (même hash), l’image ne sera pas re-téléchargée 💡 Utilisez imagePullPolicy: Always
- 85. 🔒 Laisser la sécurité au niveau du Dockerfile
- 86. securityContext et autres trucs rigolos 🔒 🔊 “J’ai déclaré un user dans mon Dockerfile” - Un dev sérieux 🔊 “Ouais, mais peut être que tout le monde le fait pas” - Un ops sérieux ✅ securityContext dans les déploiements k8s pour forcer un user non-root, un filesystem en read-only, et empêcher les élévations de privilèges:
- 87. 42 C’est le nombre de bonnes pratiques qu’on a vu ensemble
- 88. Learn you own path “R2-D2, you know better than to trust a strange speaker (or ChatGPT).” – C3PO, The Empire Strikes Back (1980)
- 89. “Questions ?”
- 90. 🙏 Merci 💙 Follow me on : @CodeKaio julien-wittouck + + = �