Научете како да распоредите микросервис. Дел 1. Spring Boot и Docker

Еј Хабр.

Во оваа статија, сакам да зборувам за моето искуство за создавање средина за учење за експериментирање со микросервиси. Кога ја учев секоја нова алатка, секогаш сакав да ја пробам не само на мојата локална машина, туку и во пореални услови. Затоа, решив да создадам поедноставена апликација за микросервис, која подоцна може да се „закачи“ со секакви интересни технологии. Главниот услов за проектот е неговата максимална функционална близина на реалниот систем.

Првично, го поделив создавањето на проектот во неколку чекори:

1. Создадете две услуги - 'backend' и 'gateway', спакувајте ги во докер слики и конфигурирајте ги да работат заедно

   Клучни зборови: Java 11, Spring Boot, Docker, оптимизација на слики

2. Развој на системот за конфигурација и распоредување Kubernetes во Google Kubernetes Engine

   Клучни зборови: Kubernetes, GKE, управување со ресурси, автоматско скалирање, тајни

3. Направете графикон користејќи Helm 3 за поефикасно управување со кластерите

   Клучни зборови: кормила 3, распоредување на графикони

4. Поставување на Jenkins и pipeline за автоматско доставување на кодот до кластерот

   Клучни зборови: Џенкинс конфигурација, приклучоци, посебно складиште за конфигурации

Планирам да посветам посебна статија на секој чекор.

Фокусот на оваа серија написи не е како да се напишат микросервисите, туку како да се натераат да работат во еден единствен систем. Иако сите овие работи обично се надвор од одговорноста на развивачот, мислам дека сепак е корисно да се запознаат барем 20% со нив (што е познато дека сочинува 80% од резултатот). Некои апсолутно важни теми, како што е безбедноста, ќе бидат изоставени од овој проект, бидејќи авторот малку разбира за ова; системот се создава исклучиво за лична употреба. Го поздравувам секое мислење и конструктивна критика.

Создавање микросервис

Услугите беа напишани во Java 11 користејќи Spring Boot. Комуникацијата меѓу услугите се организира со користење на REST. Проектот ќе вклучува минимален број на тестови (така што подоцна ќе има што да се тестира во Џенкинс). Изворниот код за услугите е достапен на GitHub: задниот дел и Порта.

За да може да се провери состојбата на секоја од услугите, на нивната зависност беше додаден Spring Actuator. Ќе создаде крајна точка /активатор/здравје и ќе врати статус од 200 ако услугата е подготвена да прифати сообраќај, или 504 во случај на проблеми. Во овој случај, ова е прилично фиктивна проверка, бидејќи услугите се многу едноставни и под некаков вид на виша сила е поверојатно тие да станат целосно недостапни отколку да останат делумно оперативни. Но, во реалните системи, Actuator може да помогне да се дијагностицира проблемот пред корисниците да почнат да го погодуваат. На пример, ако се појават проблеми со пристапот до базата на податоци, ќе можеме автоматски да одговориме на ова со запирање на обработката на барањата со скршен примерок на услугата.

Услуга за заднина

Заднинската услуга едноставно ќе го брои и ќе го врати бројот на прифатени барања.

Код на контролорот:

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

Услуга за портал

Портата ќе го проследи барањето до услугата за поддршка, дополнувајќи ја со следните информации:

• ИД на портата. Потребно е за да може една инстанца на портата да се разликува од друга со одговорот на серверот
• Одредена „тајна“ која ќе игра улога на многу важна лозинка (клучен број за шифрирање на важно колаче)

Конфигурација во application.properties:

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

Адаптер за комуникација со задниот дел:

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

Лансира:

Ајде да го стартуваме задниот дел:

./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 - инструкции за градење и извршување на апликацијата. Следно, можете да ја изградите сликата, да ја поставите во регистарот на слики (бр. ДокерХаб) и распоредете го вашиот микросервис во која било приклучена околина со една команда.

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) и ја започнуваме изградбата. Командата EXPOSE 8080 му сигнализира на докерот дека апликацијата во контејнерот ќе ја користи својата порта 8080 (ова нема да ја направи апликацијата достапна однадвор, туку ќе овозможи пристап до апликацијата, на пример, од друг контејнер на истата докерска мрежа ).

За да ги спакувате услугите во слики, треба да ги извршите командите од коренот на секој проект:

docker image build . -t msvc-backend:1.0.0

Како резултат на тоа, добиваме слика од 456 MB во големина (од кои основната слика JDK 340 зеде MB). И сето тоа и покрај фактот дека часовите во нашиот проект може да се избројат на еден прст. За да ја намалите големината на нашата слика:

• Ние користиме повеќестепено склопување. Во првиот чекор ќе го составиме проектот, во вториот ќе го инсталираме JRE, а во третиот чекор ќе го копираме сето ова во нова чиста алпска слика. Севкупно, конечната слика ќе ги содржи само потребните компоненти.
• Ајде да користиме java модуларизација. Почнувајќи со Java 9, можете да ја користите алатката jlink за да креирате JRE само од модулите што ви се потребни

За љубопитните, еве добра статија за пристапите за намалување на големината на сликите https://habr.com/ru/company/ruvds/blog/485650/.

Конечна Docker-датотека:

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 MB. Не е лошо. Потоа, готовите слики може да се прикачат во регистарот на слики, така што вашите слики се достапни за преземање од Интернет.

Водење услуги заедно во Docker

За почеток, нашите услуги мора да бидат на истата мрежа. Постојат неколку типови на мрежи во Docker, а ние ги користиме најпримитивните од нив - bridge, кој ви овозможува да ги вмрежувате контејнерите што работат на истиот хост. Ајде да создадеме мрежа со следнава команда:

docker network create msvc-network

Следно, ајде да лансираме контејнер за заднина наречена „заднина“ со сликата microservices-backend:1.0.0:

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

Вреди да се напомене дека мрежата на мостот обезбедува услуга откривање надвор од кутијата за контејнери со нивните имиња. Односно, услугата за заднина ќе биде достапна во рамките на мрежата Docker на 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