ისწავლეთ მიკროსერვისების დანერგვა. ნაწილი 1. საგაზაფხულო ჩექმა და დოკერი

ჰეი ჰაბრ.

ამ სტატიაში მინდა ვისაუბრო ჩემს გამოცდილებაზე მიკროსერვისების ექსპერიმენტებისთვის სასწავლო გარემოს შექმნის შესახებ. როდესაც ყოველ ახალ ხელსაწყოს ვსწავლობდი, ყოველთვის მინდოდა მისი გამოცდა არა მხოლოდ ადგილობრივ აპარატზე, არამედ უფრო რეალისტურ პირობებშიც. ამიტომ გადავწყვიტე შემექმნა გამარტივებული მიკროსერვისის აპლიკაცია, რომელიც შემდგომში შეიძლება „დაფაროს“ ყველანაირი საინტერესო ტექნოლოგიით. პროექტის მთავარი მოთხოვნაა მისი მაქსიმალური ფუნქციონალური სიახლოვე რეალურ სისტემასთან.

თავდაპირველად, მე დავყავი პროექტის შექმნა რამდენიმე ეტაპად:

1. შექმენით ორი სერვისი - 'backend' (backend) და 'gateway' (gateway), ჩაალაგეთ ისინი დოკერის სურათებში და დააყენეთ ისინი ერთად იმუშაონ

   საკვანძო სიტყვები: Java 11, Spring Boot, Docker, გამოსახულების ოპტიმიზაცია

2. Kubernetes-ის კონფიგურაციის განვითარება და სისტემის დანერგვა Google Kubernetes Engine-ში

   საკვანძო სიტყვები: Kubernetes, GKE, რესურსების მართვა, ავტოსკალირება, საიდუმლოებები

3. ჩარტის შექმნა Helm 3-ით კლასტერის უკეთესი მართვისთვის

   ტეგები: Helm 3, დიაგრამის განლაგება

4. ჯენკინსის და მილსადენის დაყენება კლასტერში კოდის ავტომატური მიწოდებისთვის

   საკვანძო სიტყვები: ჯენკინსის კონფიგურაცია, დანამატები, კონფიგურაციის ცალკეული საცავი

ვაპირებ თითოეულ ნაბიჯს ცალკე სტატია მივუძღვნა.

ამ სტატიების სერიის ფოკუსი არის არა ის, თუ როგორ უნდა დავწეროთ მიკროსერვისები, არამედ როგორ გავააქტიუროთ ისინი ერთ სისტემაში. მიუხედავად იმისა, რომ ეს ყველაფერი, როგორც წესი, დეველოპერის პასუხისმგებლობის მიღმაა, ვფიქრობ, მაინც სასარგებლოა მათი გაცნობა მინიმუმ 20%-ით (რაც, როგორც მოგეხსენებათ, იძლევა შედეგის 80%-ს). ზოგიერთი უპირობოდ მნიშვნელოვანი თემა, როგორიცაა უსაფრთხოება, დარჩება ამ პროექტისგან, რადგან ავტორს ცოტა რამ ესმის იმის შესახებ, რომ ეს სისტემა შექმნილია მხოლოდ პირადი სარგებლობისთვის. მივესალმები ნებისმიერ მოსაზრებას და კონსტრუქციულ კრიტიკას.

მიკროსერვისების შექმნა

სერვისები დაიწერა Java 11-ში Spring Boot-ის გამოყენებით. სერვისთაშორისი ურთიერთქმედება ორგანიზებულია REST-ის გამოყენებით. პროექტი მოიცავს ტესტების მინიმალურ რაოდენობას (ისე, რომ მოგვიანებით ჯენკინსში არის რაღაც შესამოწმებელი). სერვისების წყაროს კოდი ხელმისაწვდომია GitHub-ზე: backend и კარიბჭე.

თითოეული სერვისის სტატუსის შესამოწმებლად, მათ დამოკიდებულებებს დაემატა Spring Actuator. ის შექმნის /actuator/health endpoint-ს და დააბრუნებს 200 სტატუსს, თუ სერვისი მზად არის ტრაფიკის მისაღებად, ან 504-ს, თუ პრობლემა არსებობს. ამ შემთხვევაში, ეს საკმაოდ ფიქტიური შემოწმებაა, რადგან სერვისები ძალიან მარტივია და გარკვეული ფორსმაჟორის შემთხვევაში, უფრო სავარაუდოა, რომ ისინი სრულიად მიუწვდომელი გახდებიან, ვიდრე ნაწილობრივ ფუნქციონირებს. მაგრამ რეალურ სისტემებში Actuator-ს შეუძლია დაეხმაროს პრობლემის დიაგნოსტირებაში, სანამ მომხმარებლები დაიწყებენ მასზე ბრძოლას. მაგალითად, თუ მონაცემთა ბაზაში წვდომის პრობლემაა, ჩვენ შეგვიძლია ავტომატურად ვუპასუხოთ ამას და შევაჩეროთ მოთხოვნის დამუშავება გატეხილი სერვისის მაგალითზე.

Back end სერვისი

backend სერვისი უბრალოდ დათვლის და დააბრუნებს მიღებული მოთხოვნების რაოდენობას.

კონტროლერის კოდი:

@RestController
public class RequestsCounterController {

    private final AtomicLong counter = new AtomicLong();

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

კონტროლერის ტესტი:

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

სერვისის კარიბჭე

კარიბჭე გაგზავნის მოთხოვნას backend სერვისში, ავსებს მას შემდეგი ინფორმაციით:

• კარიბჭის ID. ეს საჭიროა ისე, რომ სერვერის პასუხის საშუალებით შესაძლებელი იყოს კარიბჭის ერთი ინსტანციის მეორისგან გარჩევა
• ზოგიერთი "საიდუმლო", რომელიც შეასრულებს ძალიან მნიშვნელოვანი პაროლის როლს (მნიშვნელოვანი ქუქი-ფაილის დაშიფვრის გასაღების ნომერი)

კონფიგურაცია application.properties-ში:

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

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<String> response = restTemplate.getForEntity(
backendUrl + REQUESTS_ENDPOINT, String.class);
        return response.getBody();
    }
}

კონტროლერი:

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

გაშვება:

ჩვენ ვიწყებთ backend-ს:

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

კარიბჭის დაწყება:

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

ჩვენ შეამოწმოთ:

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

ყველაფერი მუშაობს. ყურადღებიანი მკითხველი შენიშნავს, რომ არაფერი გვიშლის ხელს, რომ პირდაპირ შევიდეთ ბექენდზე, კარიბჭის გვერდის ავლით (http://localhost:8081/requests). ამის გამოსწორების მიზნით, სერვისები უნდა გაერთიანდეს ერთ ქსელში და მხოლოდ კარიბჭე უნდა "გამორჩეს" გარეთ.
ასევე, ორივე სერვისი იზიარებს ერთ ფაილურ სისტემას, აწარმოებს ნაკადებს და ერთ მომენტში შეიძლება დაიწყოს ერთმანეთში ჩარევა. კარგი იქნებოდა ჩვენი მიკროსერვისების იზოლირება. ამის მიღწევა შესაძლებელია სხვადასხვა აპარატებზე აპლიკაციების განაწილებით (ბევრი ფული, რთული), ვირტუალური მანქანების გამოყენებით (რესურსზე ინტენსიური, ხანგრძლივი გაშვება) ან კონტეინერიზაციის გამოყენებით. როგორც მოსალოდნელი იყო, ვირჩევთ მესამე ვარიანტს და docker როგორც კონტეინერიზაციის საშუალება.

docker

მოკლედ, დოკერი ქმნის იზოლირებულ კონტეინერებს, თითო აპლიკაციაზე. დოკერის გამოსაყენებლად, თქვენ უნდა დაწეროთ Dockerfile - ინსტრუქციები აპლიკაციის შექმნისა და გაშვებისთვის. შემდეგი, შეგიძლიათ შექმნათ სურათი, ატვირთოთ იგი გამოსახულების რეესტრში (No. დოკერჰაბი) და განათავსეთ თქვენი მიკროსერვისი ნებისმიერ dockerized გარემოში ერთი ბრძანებით.

dockerfile

სურათის ერთ-ერთი ყველაზე მნიშვნელოვანი მახასიათებელი მისი ზომაა. კომპაქტური სურათი უფრო სწრაფად ჩამოიტვირთება დისტანციური საცავიდან, დაიკავებს ნაკლებ ადგილს და თქვენი სერვისი უფრო სწრაფად დაიწყება. ნებისმიერი სურათი აგებულია საბაზისო სურათის საფუძველზე და რეკომენდებულია ყველაზე მინიმალისტური ვარიანტის არჩევა. კარგი ვარიანტია Alpine, სრული Linux დისტრიბუცია მინიმალური პაკეტებით.

დასაწყისისთვის, შევეცადოთ დავწეროთ Dockerfile "შუბლზე" (მაშინვე ვიტყვი, რომ ეს ცუდი გზაა, არ გააკეთოთ ეს):

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

აქ ჩვენ ვიყენებთ ალპურ ბაზის სურათს JDK-ით უკვე დაინსტალირებული ჩვენი პროექტის ასაშენებლად. ADD ბრძანებით სურათს ვამატებთ მიმდინარე src დირექტორიას, ვნიშნავთ სამუშაოდ (WORKDIR) და ვიწყებთ build-ს. EXPOSE 8080 ბრძანება სიგნალს აძლევს დოკერს, რომ კონტეინერში არსებული აპლიკაცია გამოიყენებს თავის პორტს 8080 (ეს არ გახდის აპლიკაციას გარედან წვდომას, მაგრამ საშუალებას მისცემს აპლიკაციას წვდომა ჰქონდეს, მაგალითად, იმავე დოკერის ქსელის სხვა კონტეინერიდან. ).

სერვისების გამოსახულებებად შეფუთვისთვის, თქვენ უნდა შეასრულოთ ბრძანებები თითოეული პროექტის ძირიდან:

docker image build . -t msvc-backend:1.0.0

შედეგი არის 456 MB სურათი (აქედან საბაზისო JDK გამოსახულება 340 MB). და ეს ყველაფერი იმისდა მიუხედავად, რომ ჩვენს პროექტში გაკვეთილები თითზე შეიძლება დაითვალოს. ჩვენი სურათის ზომის შესამცირებლად:

• ჩვენ ვიყენებთ მრავალსაფეხურიან შეკრებას. პირველ ეტაპზე ჩვენ ავაშენებთ პროექტს, მეორე ეტაპზე დავაინსტალირებთ JRE-ს, ხოლო მესამე ეტაპზე ყველაფერს დავაკოპირებთ ახალ სუფთა ალპურ სურათში. მთლიანობაში, მხოლოდ საჭირო კომპონენტები იქნება საბოლოო გამოსახულებაში.
• მოდით გამოვიყენოთ ჯავის მოდულარიზაცია. Java 9-დან დაწყებული, შეგიძლიათ გამოიყენოთ jlink ინსტრუმენტი JRE-ის შესაქმნელად მხოლოდ თქვენთვის საჭირო მოდულებიდან

ცნობისმოყვარეებისთვის აქ არის კარგი სტატია გამოსახულების შემცირების მიდგომების შესახებ. https://habr.com/ru/company/ruvds/blog/485650/.

საბოლოო 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 [email protected]"
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"]

ჩვენ ხელახლა ვქმნით სურათს და შედეგად, მან წონაში 6-ჯერ დაკარგა, რაც 77 მბ-ს შეადგენს. Ცუდი არაა. ამის შემდეგ, მზა სურათები შეიძლება აიტვირთოს გამოსახულების რეესტრში, რათა თქვენი სურათები ხელმისაწვდომი იყოს ინტერნეტიდან ჩამოსატვირთად.

Docker-ში ერთობლივი სერვისები

დასაწყისისთვის, ჩვენი სერვისები უნდა იყოს იმავე ქსელში. დოკერში არსებობს რამდენიმე ტიპის ქსელი და ჩვენ ვიყენებთ მათგან ყველაზე პრიმიტიულს - bridge-ს, რომელიც საშუალებას გაძლევთ დააკავშიროთ კონტეინერები, რომლებიც მუშაობენ იმავე ჰოსტზე. შექმენით ქსელი შემდეგი ბრძანებით:

docker network create msvc-network

შემდეგი, დაიწყეთ backend კონტეინერი სახელად 'backend' microservices-backend:1.0.0 სურათით:

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

აღსანიშნავია, რომ ხიდის ქსელი უზრუნველყოფს კონტეინერების აღმოჩენას მათი სახელწოდებით. ანუ, backend სერვისი ხელმისაწვდომი იქნება დოკერის ქსელის შიგნით http://backend:8080.

კარიბჭის დაწყება:

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

ამ ბრძანებაში ჩვენ მივუთითებთ, რომ ვაგზავნით ჩვენი ჰოსტის 80 პორტს კონტეინერის 8080 პორტში. ჩვენ ვიყენებთ env ვარიანტებს გარემოს ცვლადების დასაყენებლად, რომლებიც ავტომატურად წაიკითხება გაზაფხულზე და გადააჭარბებს თვისებებს application.properties-დან.

დაწყების შემდეგ ვურეკავთ http://localhost/ და დარწმუნდით, რომ ყველაფერი მუშაობს, როგორც წინა შემთხვევაში.

დასკვნა

შედეგად, ჩვენ შევქმენით ორი მარტივი მიკროსერვისი, შევფუთეთ ისინი დოკერის კონტეინერებში და ერთად გავუშვით იმავე მანქანაზე. ამასთან, მიღებულ სისტემას აქვს მთელი რიგი უარყოფითი მხარეები:

• შეცდომების ცუდი ტოლერანტობა - ყველაფერი მუშაობს ჩვენთვის ერთ სერვერზე
• ცუდი მასშტაბირება - როდესაც დატვირთვა იზრდება, კარგი იქნება, რომ ავტომატურად განათავსოთ დამატებითი სერვისის ინსტანციები და დააბალანსოთ დატვირთვა მათ შორის
• გაშვების სირთულე - დაგვჭირდა მინიმუმ 3 ბრძანების შეყვანა და გარკვეული პარამეტრებით (ეს არის მხოლოდ 2 სერვისისთვის)

ზემოაღნიშნული პრობლემების გადასაჭრელად, არსებობს მთელი რიგი გადაწყვეტილებები, როგორიცაა Docker Swarm, Nomad, Kubernetes ან OpenShift. თუ მთელი სისტემა Java-ზეა დაწერილი, შეგიძლიათ გაიხედოთ Spring Cloud-ისკენ (კარგი სტატია).

В შემდეგი ნაწილი მე ვისაუბრებ იმაზე, თუ როგორ დავაყენე Kubernetes და გავავრცელე პროექტი Google Kubernetes Engine-ზე.

წყარო: www.habr.com