Õpime mikroteenuseid käivitama. Osa 1. Spring Boot ja Docker

Tere, Habr.

Selles artiklis tahan rääkida oma kogemusest õppekeskkonna loomisel mikroteenustega eksperimenteerimiseks. Iga uue tööriista õppimisel on mul alati olnud soov proovida seda mitte ainult kohaliku arvuti peal, vaid ka realistlikumates tingimustes. Seetõttu otsustasin luua lihtsustatud mikroteenuste rakenduse, mida saab hiljem "kaunistada" erinevate huvitavate tehnoloogiatega. Projekti peamine nõue on selle maksimaalne funktsionaalne lähedus reaalsele süsteemile.

Algselt jagasin projekti loomise mitmeks sammuks:

1. Luua kaks teenust - 'tagapõhi' (backend) ja 'värav' (gateway), pakkida need Docker piltidesse ja seadistada nende koostöö.

   Märksõnad: Java 11, Spring Boot, Docker, pildi optimeerimine.

2. Kubernetes konfiguratsiooni väljatöötamine ja süsteemi juurutamine Google Kubernetes Engine'is.

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

3. Charti loomine Helm 3 abil, et klastrit tõhusamalt hallata.

   Märksõnad: Helm 3, chart'i juurutamine.

4. Jenkins'i ja toru seadistamine koodi automaatseks edastamiseks klastri.

   Märksõnad: Jenkins'i konfiguratsioon, pistikprogrammid, eraldi konfiguratsioonide hoidla.

Igaastmele plaanin pühendada eraldi artikli.

Selle artikli tsükli suund on pigem selles, kuidas saada mikroteenused töötama ühtses süsteemis, mitte kuidas neid kirjutada. Kuigi kõik need asjad jäävad tavaliselt arendaja vastutusalast välja, arvan, et on ikkagi kasulik olla nendega tuttav vähemalt 20% ulatuses (mis, nagu teada, annab 80% tulemusest). Mõned tingimata olulised teemad, nagu julgeoleku tagamine, jäävad selle projekti kontekstist välja, kuna autor ei tea selles valdkonnas palju, süsteem luuakse ainult isiklikuks kasutamiseks. Ootan hea meelega igasuguseid arvamusi ja konstruktiivset kriitikat.

Mikroteenuste loomine

Teenused on kirjutatud Java 11 abil kasutades Spring Boot'i. Teenuste vaheline suhtlemine on korraldatud REST'i abil. Projekt sisaldab minimaalset arvu teste (et hiljem oleks, mida Jenkins'is testida). Teenuste lähtekood on saadaval GitHub'is: tagapõhi ja värav.

Kasutades Spring Actuator'i, saame jälgida iga teenuse seisundit. See loob lõpp-punkti /actuator/health ja tagastab 200 staatuse, kui teenus on valmis liiklust vastu võtma, või 504, kui esinevad probleemid. Antud juhul on see pigem vale kontroll, kuna teenused on väga lihtsad ja erakorraliste olukordade korral võivad nad olla täielikult kättesaamatud, mitte osaliselt funktsioneerivad. Kuid reaalsetes süsteemides aitab Actuator tuvastada probleeme enne, kui kasutajad nendega kokku puutuvad. Näiteks, kui tekivad andmebaasi juurdepääsuga seotud probleemid, saame automaatselt reageerida, lõpetades vigase teenuse töötamise päringute töötlemiseks.

Tagasiside teenus

Tagasiside teenus loendab ja edastab vastuvõ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"));
    }
}

Läbipääsupunkti teenus

Läbipääsupunkt suunab päringu tagasiside teenusele, lisades sellele järgmise teabe:

• läbipääsupunkti ID. See on vajalik, et serveri vastusest eristada ühte läbipääsupunkti teisest
• Mingi "salajane" väärtus, mis toimib väga olulise paroolina (salajase küpsise krüptimisvõtme numbrina)

Seadistus failis application.properties:

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

Adapter tagasiside teenusega ühendamiseks:

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

Kontroller:

@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("Päringute arv %s (läbipääsupunkt %d, salajane %s)", backendAdapter.getRequests(), instanceId, secret);
    }
}

Pärast seda

Käivitame tagasiside teenuse:

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

Käivitame läbipääsupunkt:

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

Kontrollime:

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

Kõik töötab. Tähelepanelik lugeja märkab, et meil ei ole midagi, mis takistaks pöörduda tagalihtrisse otse, mööda väravat (http://localhost:8081/requests). Selle parandamiseks peavad teenused olema ühendatud ühte võrku ning välja peab „paistma“ vaid värav.
Samuti jagavad mõlemad teenused ühte failisüsteemi, genereerivad piisavalt koormust ning võivad ühel hetkel üksteist segama hakata. Oleks hea isoleerida meie mikroteenus. Seda saab saavutada rakenduste paigutamisega erinevatele masinatele (palju raha, keeruline), virtuaalmasinate kasutamisega (ressursimahukas, aeglane käivitamine) või konteineriseerimise abil. Ootuspäraselt valime kolmanda variandi ja Docker konteineriseerimise tööriistana.

Docker

Lühidalt öeldes loob Docker isoleeritud konteinerid, igaühe rakenduse jaoks eraldi. Dockerit kasutamiseks tuleb kirjutada Dockerfile – juhend rakenduse seadistamiseks ja käivitamiseks. Seejärel saab luua pildi, laadida selle pildiregistrisse ( DockerHub) ja ühe käsuga käivitada oma mikroteenuse igas Dockerisse pandud keskkonnas.

Dockerfile

Üks olulisemaid pildi omadusi on selle suurus. Kompaktne pilt laaditakse kaugelt hoidlast kiiremini alla, võtab vähem ruumi ja teie teenus käivitub kiiremini. Iga pilt ehitatakse põhifoto alusel ja soovitatakse valida võimalikult minimalistlik variant. Hea valik on Alpine – täielik Linuxi distributsioon minimaalsete pakettidega.

Alustuseks proovime kirjutada Dockerfile „otseselt“ (ütlen kohe, et see on halb viisipidamine, ärge tehke niimoodi):

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 kasutame Alpine põhjal põhinevat põhifotot, millele on juba installitud JDK, et ehitada meie projekti. Käsuga ADD lisame pildi praeguse katalooge src, märkime selle töökohana (WORKDIR) ja käivitame ehituse. Käsk EXPOSE 8080 annab Dockerile teada, et rakendus konteineris kasutab oma porti 8080 (see ei tee rakendust väljastpoolt kättesaadavaks, kuid võimaldab rakendusele pöörduda, näiteks teisest konteinerist samas Docker-võrgus).

Teenuste pildiks pakkimiseks peate käivitama käsud igas projekti juures:

docker image build . -t msvc-backend:1.0.0

Tulemusena saame 456 MB suuruse pildi (millest baas JDK 340 hõivas MB). Ja arvestades, et meie projektis on klasse hõlpsasti loetavad. Et vähendada meie pildi suurust:

• Kasutame mitmeastmelist ehitust. Esimeses etapis kogume projekti, teises paigaldame JRE ja kolmandas kopeerime kõik uude puhtasse Alpine pildi. Lõpptulemusena jäävad finišipildis alles vaid vajalikud komponendid.
• Kasutame java modulariseerimist. Alates Java 9-st saab tööriista jlink abil luua JRE ainult vajalikest moodulitest.

Uurimiseks, siin on hea artikkel pildi 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"]

Loodame pildi uuesti ja selle suurus on kokku 6 korda väiksem, ulatudes vaid 77 MB. Mitte paha. Pärast valmis pilte saab registrisse üles laadida, et teie pildid oleksid internetist allalaadimiseks saadaval.

Teenuste koos käitamine Dockeris

Alustamiseks peavad meie teenused olema samas võrgus. Dockeris on saadaval mitu tüüpi võrgud ja meie kasutame kõige lihtsamat neist – bridge, mis võimaldab ühendada võrgusse samal hostil käivitatud konteinerid. Loome võrgus järgmise käsuga:

docker network create msvc-network

Seejärel käivitame tagapoolt konteineri nimega 'backend' pildiga microservices-backend:1.0.0:

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

Tuleb märkida, et bridge-võrk pakub välja teenuste avastamist konteinerite nimede järgi. See tähendab, et tagapoolt teenus on Dockeri võrgus aadressil http://backend:8080.

Käivitame läbipääsupunkt:

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 komandis määrame, et suuname hosti pordi 80 konteineri pordile 8080. Keskkonna valikutele kasutame, et seadistada keskkonnamuutujad, mis Springi poolt automaatselt välja loetakse ning ületavad application.properties omadused.

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

Kokkuvõte

Lõpuks oleme loonud kaks lihtsat mikroteenust, pakkides need Docker konteineritesse ja käivitades need koos ühel masinal. Siiski on sellel süsteemil mitmeid puudusi:

• Halb talitlushäirete taluvus — meil on kõik ühel serveril
• Halb skaleeritavus — kui koormus suureneb, oleks hea automaatselt käivitada täiendavaid teenuse eksemplare ja jaotada koormust nende vahel
• Käivitamise keerulisus — vajame vähemalt 3 käsku, lisaks kindlate parameetritega (see ainult 2 teenuse jaoks)

Nende probleemide lahendamiseks on mitmeid lahendusi, nagu Docker Swarm, Nomad, Kubernetes või OpenShift. Kui kogu süsteem on kirjutatud Java'sse, võiks vaadata Spring Cloudi poole (hea artikkel).

Uues järgmises osas ma räägin, kuidas ma seadistasin Kubernetes ja tõin projekti Google Kubernetes Engine'i.

Allikas: habr.com