Apprenons à déployer des microservices. Partie 1. Spring Boot et Docker

Bonjour, Habr.

Dans cet article, je souhaite partager mon expérience dans la création d'un environnement d'apprentissage pour expérimenter avec les microservices. En étudiant chaque nouvel outil, j'ai toujours voulu l'essayer non seulement sur ma machine locale, mais aussi dans des conditions plus réalistes. C'est pourquoi j'ai décidé de créer une application microservices simplifiée, que je pourrai ensuite "agrémenter" de diverses technologies intéressantes. L'exigence principale du projet est sa plus grande proximité fonctionnelle avec un système réel.

Au départ, j'ai divisé la création du projet en plusieurs étapes :

1. Créer deux services : un ‘backend’ et une ‘passerelle’ (gateway), les empaqueter en images Docker et configurer leur coopération

   Mots-clés : Java 11, Spring Boot, Docker, optimisation d'image

2. Développement de la configuration Kubernetes et déploiement du système sur Google Kubernetes Engine

   Mots-clés : Kubernetes, GKE, gestion des ressources, autoscaling, secrets

3. Création d'un chart avec Helm 3 pour une gestion plus efficace du cluster

   Mots-clés : Helm 3, déploiement de chart

4. Configuration de Jenkins et création d'un pipeline pour une livraison automatique du code dans le cluster

   Mots-clés : configuration Jenkins, plugins, dépôt de configurations séparées

Je prévois de consacrer un article à chaque étape.

L'orientation de ce cycle d'articles ne consiste pas à expliquer comment écrire des microservices, mais à faire en sorte qu'ils fonctionnent dans un système unifié. Bien que toutes ces choses soient généralement en dehors des responsabilités du développeur, je pense qu'il est tout de même utile de les connaître au moins à 20% (qui, comme on le sait, apportent 80% du résultat). Certains sujets indéniablement importants, comme la sécurité, seront laissés de côté dans ce projet, car l'auteur n'y comprend que peu de choses. Le système est conçu uniquement pour un usage personnel. Je suis ouvert à toute opinion et critique constructive.

Création de microservices

Les services ont été écrits en Java 11 avec Spring Boot. L'interaction entre services est organisée à l'aide de REST. Le projet comprendra un nombre minimal de tests (afin d'avoir quelque chose à tester dans Jenkins). Le code source des services est disponible sur GitHub : backend et passerelle.

Pour vérifier l'état de chaque service, Spring Actuator a été ajouté à leurs dépendances. Il créera un endpoint /actuator/health et retournera le statut 200 si le service est prêt à recevoir du trafic, ou 504 en cas de problème. Dans ce cas, c'est une vérification plutôt fictive, car les services sont très simples, et en cas de coup dur, ils deviendront probablement complètement inaccessibles plutôt que de conserver une partie de leur fonctionnalité. Mais dans des systèmes réels, Actuator peut aider à diagnostiquer un problème avant que les utilisateurs ne commencent à se heurter à celui-ci. Par exemple, en cas de problèmes d'accès à la base de données, nous pourrons réagir automatiquement à cela en arrêtant de traiter les requêtes avec une instance défectueuse du service.

Service Backend

Le service backend comptera simplement et renverra le nombre de requêtes reçues.

Code du contrôleur :

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

    @GetMapping("/requests")
    public Long getRequestsCount() {
        return counter.incrementAndGet();
    }
}

Test du contrôleur :

@WebMvcTest(RequestsCounterController.class)
public class RequestsCounterControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void firstRequest_one() throws Exception {
        mockMvc.perform(get("/requests"))
            .andExpect(status().isOk())
            .andExpect(MockMvcResultMatchers.content().string("1"));
    }
}

Service Gateway

La passerelle redirigera la requête vers le service backend, en l'enrichissant d'informations supplémentaires :

• id de la passerelle. Cela permet de distinguer une instance de passerelle d'une autre par la réponse du serveur.
• Une "clé secrète", qui agira comme un mot de passe essentiel (n° de clé de chiffrement d'un cookie important).

Configuration dans application.properties :

backend.url=http://localhost:8081
instance.id=${random.int}
secret="default-secret"

Adaptateur pour la communication avec le backend :

@Service
public class BackendAdapter {

    private static final String REQUESTS_ENDPOINT = "/requests";

    private final RestTemplate restTemplate;

    @Value("${backend.url}")
    private String backendUrl;

    public BackendAdapter(RestTemplateBuilder builder) {
        restTemplate = builder.build();
    }

    public String getRequests() {
        ResponseEntity response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

Contrôleur :

@RestController
@RequiredArgsConstructor
public class EndpointController {

    private final BackendAdapter backendAdapter;

    @Value("${instance.id}")
    private int instanceId;

    @Value("${secret}")
    private String secret;

    @GetMapping("/")
    public String getRequestsCount() {
        return String.format("Nombre de requêtes %s (passerelle %d, clé secrète %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

Lancement :

Démarrage du backend :

./mvnw package -DskipTests
java -Dserver.port=8081 -jar target/microservices-backend-1.0.0.jar

Démarrage de la passerelle :

./mvnw package -DskipTests
java -jar target/microservices-gateway-1.0.0.jar

Vérifions :

$ curl http://localhost:8080/
Nombre de requêtes 1 (passerelle 38560358, secret "default-secret")

Tout fonctionne. L'observateur attentif remarquera qu'il n'y a rien qui nous empêche d'accéder directement au backend en contournant la passerelle (http://localhost:8081/requests). Pour corriger cela, les services doivent être regroupés dans un seul réseau, et seule la passerelle doit être exposée à l'extérieur.
De plus, les deux services partagent un même système de fichiers, générant des flux qui peuvent commencer à interférer l'un avec l'autre à un moment donné. Il serait souhaitable d'isoler nos microservices. Cela peut être réalisé en répartissant les applications sur différentes machines (coûteux, compliqué), en utilisant des machines virtuelles (exigeant en ressources, démarrage lent) ou en utilisant la conteneurisation. Comme prévu, nous choisissons la troisième option et Docker comme outil de conteneurisation.

Docker

En résumé, Docker crée des conteneurs isolés, un pour chaque application. Pour utiliser Docker, il est nécessaire d'écrire un Dockerfile — une instruction pour construire et exécuter l'application. Ensuite, vous pouvez créer une image, la télécharger dans un registre d'images (n° DockerHub) et déployer votre microservice dans n'importe quel environnement conteneurisé d'un seul coup.

Dockerfile

Une des caractéristiques les plus importantes de l'image est sa taille. Une image compacte se téléchargera plus rapidement depuis le dépôt distant, prendra moins de place, et votre service démarrera plus rapidement. Chaque image est construite sur la base d'une image de base, et il est recommandé de choisir l'option la plus minimaliste. Une bonne option est Alpine — une distribution Linux complète avec un minimum de paquets.

Pour commencer, essayons d'écrire un Dockerfile "à la va-vite" (je précise que c'est une mauvaise approche, ne faites pas ça) :

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests
EXPOSE 8080
ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

Ici, nous utilisons une image de base basée sur Alpine avec JDK déjà installé pour construire notre projet. Avec la commande ADD, nous ajoutons le répertoire actuel src à l'image, le désignons comme répertoire de travail (WORKDIR) et lançons la construction. La commande EXPOSE 8080 indique à Docker que l'application dans le conteneur utilisera son port 8080 (cela ne rend pas l'application accessible de l'extérieur, mais permet d'accéder à l'application depuis un autre conteneur dans le même réseau Docker).

Pour emballer les services dans des images, il faut exécuter les commandes depuis la racine de chaque projet :

docker image build . -t msvc-backend:1.0.0

Nous obtenons donc une image de 456 Mo (dont l'image de base JDK 340 a occupé Mo). Et tout cela alors que le nombre de classes dans notre projet se compte sur les doigts de la main. Pour réduire la taille de notre image :

• Utilisons une construction multi-étapes. Dans la première étape, nous allons construire le projet, dans la seconde, nous installerons JRE, et dans la troisième étape, nous copierons tout cela dans une nouvelle image Alpine propre. Au final, seule les composants nécessaires seront présents dans l'image finale.
• Nous allons utiliser la modularisation de Java. Depuis Java 9, il est possible de créer un JRE uniquement à partir des modules requis à l'aide de l'outil jlink.

Pour les curieux, voici un bon article sur les approches pour réduire la taille des images. https://habr.com/ru/company/ruvds/blog/485650/.

Dockerfile final :

FROM adoptopenjdk/openjdk11:jdk-11.0.5_10-alpine as builder
ADD . /src
WORKDIR /src
RUN ./mvnw package -DskipTests

FROM alpine:3.10.3 as packager
RUN apk --no-cache add openjdk11-jdk openjdk11-jmods
ENV JAVA_MINIMAL="/opt/java-minimal"
RUN /usr/lib/jvm/java-11-openjdk/bin/jlink 
    --verbose 
    --add-modules 
        java.base,java.sql,java.naming,java.desktop,java.management,java.security.jgss,java.instrument 
    --compress 2 --strip-debug --no-header-files --no-man-pages 
    --release-info="add:IMPLEMENTOR=radistao:IMPLEMENTOR_VERSION=radistao_JRE" 
    --output "$JAVA_MINIMAL"

FROM alpine:3.10.3
LABEL maintainer="Anton Shelenkov anshelen@yandex.ru"
ENV JAVA_HOME=/opt/java-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"
COPY --from=packager "$JAVA_HOME" "$JAVA_HOME"
COPY --from=builder /src/target/microservices-backend-*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

Nous recréons l'image, et elle a finalement été réduite de 6 fois, ne faisant plus que 77 Mo. Pas mal. Ensuite, les images prêtes peuvent être téléchargées dans le registre d'images, afin que vos images soient accessibles pour téléchargement depuis Internet.

Exécution conjointe de services dans Docker.

Tout d'abord, nos services doivent être sur le même réseau. Il existe plusieurs types de réseaux dans Docker, et nous allons utiliser le plus basique d'entre eux — le bridge, qui permet de connecter des conteneurs exécutés sur le même hôte. Créons un réseau avec la commande suivante :

docker network create msvc-network

Ensuite, lançons le conteneur backend nommé ‘backend’ avec l'image microservices-backend:1.0.0 :

docker run -dit --name backend --network msvc-net microservices-backend:1.0.0

Il convient de noter que le réseau bridge offre par défaut la découverte de services pour les conteneurs par leur nom. Cela signifie que le service backend sera accessible à l'intérieur du réseau Docker à l'adresse http://backend:8080.

Démarrage de la passerelle :

docker run -dit -p 80:8080 --env secret=my-real-secret --env BACKEND_URL=http://backend:8080/ --name gateway --network msvc-net microservices-gateway:1.0.0

Dans cette commande, nous spécifions que nous redirigeons le port 80 de notre hôte vers le port 8080 du conteneur. Nous utilisons l'option env pour définir des variables d'environnement qui seront automatiquement lues par Spring et remplaceront les propriétés de application.properties.

Après le démarrage, nous appelons http://localhost/ et nous assurons que tout fonctionne comme la dernière fois.

Conclusion

Au final, nous avons créé deux microservices simples, les avons emballés dans des conteneurs Docker et les avons exécutés ensemble sur une seule machine. Cependant, le système résultant présente plusieurs inconvénients :

• Mauvaise tolérance aux pannes — tout fonctionne sur un seul serveur.
• Mauvaise évolutivité — en cas d'augmentation de la charge, il serait souhaitable de déployer automatiquement des instances supplémentaires des services et de répartir la charge entre elles.
• Complexité de démarrage — nous avons dû entrer au moins 3 commandes, avec des paramètres spécifiques (et cela uniquement pour 2 services).

Pour résoudre les problèmes énumérés ci-dessus, il existe plusieurs solutions telles que Docker Swarm, Nomad, Kubernetes ou OpenShift. Si tout le système est écrit en Java, il vaut la peine de se tourner vers Spring Cloud (un bon article).

Dans de la partie suivante je parlerai de la façon dont j'ai configuré Kubernetes et déployé le projet sur Google Kubernetes Engine.

Source : habr.com