Õpime mikroteenuseid juurutama. Osa 1. Spring Boot ja Docker

Tere, Habr.

Selles artiklis tahan rääkida oma kogemustest õpik keskkonna loomisel mikroteenuste jaoks eksperimenteerimiseks. Iga uue tööriista uurimisel on mul alati olnud soov proovida seda mitte ainult kohalikul masinal, vaid ka realistlikumates tingimustes. Seetõttu otsustasin luua lihtsustatud mikroteenuste rakenduse, mida oleks hiljem võimalik "varustada" mitmesuguste huvitavate tehnoloogiate abil. Peamine nõue projektile on selle maksimaalne funktsionaalne sarnasus reaalsüsteemiga.

Alguses jagasin projekti loomise mitmeks sammuks:

1. Loo kaks teenust — ‘backend’ ja ‘gateway’, pakendi need docker-piltidesse ja seadista nende koostöö.

   Kasutatud märksõnad: Java 11, Spring Boot, Docker, pildieditamise optimeerimine.

2. Kubernetes konfiguratsiooni arendamine ja süsteemi paigaldamine Google Kubernetes Engine'i.

   Kasutatud märksõnad: Kubernetes, GKE, ressursside haldamine, automaatne skaleerimine, saladused.

3. Helm 3 abil chart'i loomine klastrihalduse tõhustamiseks.

   Kasutatud märksõnad: Helm 3, chart'i paigaldamine.

4. Jenkins'i ja töövoo seadistamine koodi automaatseks kohaletoimetamiseks klastrisse.

   Kasutatud märksõnad: Jenkins'i konfiguratsioon, pistikprogrammide seadistamine, eraldi konfiguratsioonide hoidla.

Iga sammu jaoks plaanin kirjutada eraldi artikli.

Selle artiklite seeria fookus pole mitte selles, kuidas mikroteenuseid kirjutada, vaid kuidas neid tõhusalt töötama panna ühes süsteemis. Kuigi need teemad jäävad sageli arendaja vastutusalast välja, arvan, et on ikkagi kasulik neist vähemalt 20% ulatuses teada (mille kohta on teada, et see annab 80% tulemusest). Mõned kindlasti olulised teemad, nagu küberturvalisus, jäävad selle projekti raames kõrvale, kuna autor ei mõista seda valdkonda piisavalt. Süsteem luuakse rangelt isiklikuks kasutamiseks. Ootan kõiki arvamusi ja konstruktiivset kriitikat.

Mikroteenuste loomine

Teenused on kirjutatud Java 11 kasutades Spring Booti. Teenustevaheline suhtlus on korraldatud RESTi abil. Projekt sisaldab minimaalset arvu teste (et hiljem oleks, mida Jenkinsis testida). Teenuste lähtekood on saadaval GitHubis: tagakülg ja lünk.

Kuna iga teenuse olekut kontrollida, on nende sõltuvusse lisatud Spring Actuator. See loob lõpp-punkti /actuator/health ja tagastab 200 staatuse, kui teenus on liikluse vastuvõtmiseks valmis, või 504 probleemide korral. Sel juhul on see pigem näiline kontroll, kuna teenused on väga lihtsad, ja mingisuguse erakorralise olukorra korral muutuvad nad tõenäoliselt täielikult kättesaamatuks, mitte ei jää osaliselt funktsioneerima. Kuid reaalsetes süsteemides võib Actuator aidata probleemide diagnoosimisel enne, kui kasutajad hakkavad neid lahendama. Näiteks, kui esinevad probleemid andmebaasi juurdepääsuga, saame automaatselt sellele reageerida, lõpetades katkise teenuse abil päringute töötlemise.

Tagasi side teenus

Tagasi side teenus loendab lihtsalt ja edastab vastu võetud päringute arvu.

Kontrolleri kood:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

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

Kontrolleri test:

@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"));
    }
}

Gateway teenus

Šluzi suunab päringu tagaküljeteenusele, lisades sellele järgmise teabe:

• šluzi id. See on vajalik, et serveri vastusest eristada ühte šluzi teisest
• Teatud "saladus", mis toimib väga olulise paroolina (šifreerimise võtme nr cookies)

Seadistus failis application.properties:

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

Adapter tagaküljega suhtlemiseks:

@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();
    }
}

Kontrollija:

@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("Number of requests %s (gateway %d, secret %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

Käivitamine:

Käivitame backend:

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

Käivitame gateway:

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

Kontrollin:

$ curl http://localhost:8080/
Number of requests 1 (gateway 38560358, secret "default-secret")

Kõik töötab. Tähelepanelik lugeja märkab, et meid ei takista midagi backend'i otse külastada, ümbersõitmise käigus gateway'st (http://localhost:8081/requests). Selle parandamiseks peaksid teenused olema ühendatud ühte võrgusse ning välispidiselt peaks "kuni" olema vaid gateway.
Samuti jagab mõlemad teenused ühte failisüsteemi, genereerivad vooge ja võivad ühel hetkel hakata üksteist segama. Oleks hea isoleerida meie mikroteenused. Selleks võib rakendusi jagada erinevatele masinatele (palju raha, keeruline), kasutada virtuaalmasinaid (ressursimahukas, pikk käivitamine) või kasutada konteineriseerimist. Oodatult valime kolmanda variandi ja Docker konteineriseerimise tööriistana.

Docker

Lühidalt öeldes loob Docker isoleeritud konteinerid, igaühe oma rakenduse jaoks. Dockerit kasutamiseks tuleb kirjutada Dockerfile — juhend rakenduse kokkupanekuks ja käivitamiseks. Seejärel saab luua pildi ja laadida selle pildiregistrisse (№ DockerHub) ning ühe käsuga käivitada oma mikroteenuse igas Dockeriga varustatud keskkonnas.

Dockerfile

Üks olulisemaid pildi omadusi on selle suurus. Kompaktne pilt laaditakse eemalt kiiremini alla, võtab vähem ruumi ja teie teenus käivitub kiiremini. Iga pilt ehitatakse aluspildi põhjal ja soovitatav on valida võimalikult minimalistlik variant. Heaks valikuks on Alpine — täielik Linuxi distributsioon miinimumpakettidega.

Katsume alguses kirjutada Dockerfile "puhtalt" (ütlen kohe, et see on halb viis, ärge tehke nii):

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"]

Siin me kasutame Alpine'i põhjalikku pilti, millel on juba JDK installitud meie projekti koostamiseks. ADD käskliselt lisame pildi praeguse katalooge src, määrame selle töökaustaks (WORKDIR) ja käivitame koostamise. EXPOSE 8080 käsk annab Dockerile märku, et konteineri rakendus kasutab porti 8080 (see ei tee rakendust välistele juurdepääsetavaks, kuid võimaldab näiteks teise konteineri sees samas Docker-võrgus rakendust välja kutsuda).

Teenuste pakkimiseks piltidesse tuleb täita käsud iga projekti juurest:

docker image build . -t msvc-backend:1.0.0

Selle tulemusena saame pildi, mille suurus on 456 MB (millest põhjalik pilt JDK 340 võttis MB). Ja see kõik just seetõttu, et meie projektis on klasse, mis võib sõrmedega kokku lugeda. Pildi suuruse vähendamiseks:

• Kasutame mitmeastmelist koostamist. Esimeses etapis koostame projekti, teises etapis installime JRE ja kolmandas etapis kopeerime kõik uude puhtasse Alpine'i pilti. Lõpuks jäävad pildile vaid vajalikud komponendid.
• Kasutame Java modulariseerimist. Alates Java 9-st on võimalik jlink tööriistaga luua JRE ainult vajalikest moodulitest.

Uudishimu jaoks, siin on hea artikkel piltide suuruse vähendamise lähenemistest https://habr.com/ru/company/ruvds/blog/485650/.

Lõplik Dockerfile:

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"]

Uuendame pildi ja selle suurus vähenes 6 korda, olles 77 MB. Mitte paha. Valmis pildid saab seejärel üles laadida piltide registrisse, et need oleksid internetist allalaadimiseks saadaval.

Teenuste ühis запуска Dockeris

Esiteks peavad meie teenused olema ühes võrgus. Dockeris on mitu tüüpi võrke ja kasutame nende seas kõige lihtsamat — bridge, mis võimaldab ühendatud konteineritel töötada ühel puhul. Loome võrgu järgmise käsuga:

docker network create msvc-network

Järgmise sammuna käivitame backend konteineri nimega ‘backend’ kujutisega microservices-backend:1.0.0:

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

Tasub märkida, et bridge-võrk pakub konteinerite nimede põhjal teenuste avastamist otse välja. See tähendab, et backend teenus on dokkeri võrgus kergesti ligipääsetav aadressil http://backend:8080.

Käivitame gateway:

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

Selles käsus määratleme, et suuname meie hosti 80. pordi 8080. konteineri pordile. Env valikud kasutame keskkonnaparameetrite määramiseks, mis springi poolt automaatselt loetakse ja ületavad application.properties omadusi.

Pärast käivitamist kutsume välja http://localhost/ ja veendume, et kõik töötab nagu eelmisel korral.

Kokkuvõte

Kokkuvõttes oleme loonud kaks lihtsat mikroteenust, pakkinud need dockeri konteineritesse ja käivitanud need ühel masinal. Saadud süsteemil on siiski mitmeid puudusi:

• Halb talitlushäire taluvus - kõik töötab ühel serveril
• Halb skaleeritavus - koormuse suurenedes oleks hea automaatselt juurutada lisaseenteenuseid ja tasakaalustada nende vahel koormust.
• Käivitamise keerukus — meie jaoks oli vajalik sisestada vähemalt 3 käsku, sealhulgas teatud parameetritega (see kehtib ainult 2 teenuse kohta)

Selleks, et lahendada ülalnimetatud probleeme, on olemas mitmeid lahendusi, nagu Docker Swarm, Nomad, Kubernetes või OpenShift. Kui kogu süsteem on kirjutatud Java-s, võiks vaadata ka Spring Cloudi poole (hea artikkel).

V järgmises osas ma räägin sellest, kuidas ma seadistasin Kubernetes't ja deployisin projekti Google Kubernetes Engine'is.

Allikas: habr.com