Mettre en production

Sur le poste du développeur, la Librairie tourne bien : on la lance d'une commande, on lit son journal à l'écran, on l'arrête quand on veut. En production, tout change. L'application tourne sur une machine où personne ne la regarde ; il faut savoir de l'extérieur si elle va bien, combien de requêtes elle sert, ce qu'elle a fait cette nuit. Elle doit se livrer en un seul objet, identique partout, et s'installer sans compiler. Ses réglages sensibles (le mot de passe de la base) ne doivent pas figurer dans le dépôt. Et quand on la remplace par une nouvelle version, elle doit s'arrêter proprement, sans couper les commandes en cours.

Ce chapitre traite ces besoins avec les outils de Spring Boot : Actuator pour surveiller, des journaux structurés, le jar exécutable, une configuration par variables d'environnement, une image Docker, et l'arrêt gracieux. Il se termine par une mise en production simulée, sur une seule machine.

Le projet code/ch11/librairie part de celui du chapitre 10. Les sorties montrées viennent de ce projet (Docker Engine 28, image eclipse-temurin:21-jre). Dans les journaux de développement, on a retiré date, niveau et numéro de processus.

11.1 Surveiller avec Actuator

Une dépendance :

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

et des réglages, qui n'exposent sur le web que le nécessaire :

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true
  info:
    env:
      enabled: true

info:
  application:
    description: API de la Librairie du Campus

Comme toute adresse non prévue est refusée depuis le chapitre 8, la sécurité dit qui voit quoi : la santé et les informations sont publiques, le reste est réservé à l'administrateur.

                // chapitre 11 : la santé et les informations sont publiques, le reste d'Actuator non
                .requestMatchers("/actuator/health", "/actuator/health/**", "/actuator/info").permitAll()
                .requestMatchers("/actuator/**").hasRole("ADMIN")

La santé. Pour un visiteur anonyme, un seul mot :

$ curl -s http://localhost:8000/actuator/health
{"groups":["liveness","readiness"],"status":"UP"}

Pour l'administrateur (show-details: when-authorized), le détail de chaque indicateur ; on a abrégé le chemin du disque :

$ curl -s -u admin:libraire-2026 http://localhost:8000/actuator/health
{"components":{"db":{"details":{"database":"PostgreSQL","validationQuery":"isValid()"},"status":"UP"},"diskSpace":{"details":{"total":994662584320,"free":12667768832,"threshold":10485760,"path":"…/librairie/.","exists":true},"status":"UP"},"livenessState":{"status":"UP"},"ping":{"status":"UP"},"readinessState":{"status":"UP"},"ssl":{"details":{"expiringChains":[],"invalidChains":[],"validChains":[]},"status":"UP"}},"groups":["liveness","readiness"],"status":"UP"}

Spring Boot a créé seul un indicateur pour chaque chose qu'il sait vérifier : la base (il lui demande si la connexion est valide), l'espace disque, les certificats. L'état global est UP si tous le sont. On en écrit un pour la Librairie à l'exercice 11.2.

$ curl -s http://localhost:8000/actuator/health/readiness
{"status":"UP"}

Les informations. Le but build-info du greffon Maven écrit, à chaque construction, un fichier META-INF/build-info.properties que /actuator/info publie, avec la description donnée sous info :

                <executions>
                    <execution>
                        <goals>
                            <goal>build-info</goal>
                        </goals>
                    </execution>
                </executions>

$ curl -s http://localhost:8000/actuator/info
{"application":{"description":"API de la Librairie du Campus"},"build":{"artifact":"librairie","name":"librairie","time":"2026-10-02T22:11:03.697Z","version":"1.0.0","group":"fr.librairie"}}

Quand un client signale un problème, la première question est : quelle version tourne ? La réponse est là. Le projet est d'ailleurs passé de 0.0.1-SNAPSHOT à la version 1.0.0 dans le pom.xml : on livre une version numérotée, jamais un instantané.