마이크로서비스를 배포하는 방법을 알아보세요. 1부. 스프링 부트와 도커

헤이 하브르.

이 기사에서는 마이크로서비스를 실험하기 위한 학습 환경을 만든 경험에 대해 이야기하고 싶습니다. 각각의 새로운 도구를 배울 때면 항상 로컬 컴퓨터뿐만 아니라 보다 현실적인 조건에서도 시도하고 싶었습니다. 따라서 나중에 모든 종류의 흥미로운 기술로 "덮일" 수 있는 단순화된 마이크로 서비스 애플리케이션을 만들기로 결정했습니다. 프로젝트의 주요 요구 사항은 실제 시스템에 대한 기능적 근접성입니다.

처음에는 프로젝트 생성을 여러 단계로 나누었습니다.

1. '백엔드'(백엔드) 및 '게이트웨이'(게이트웨이)의 두 가지 서비스를 만들고 이를 도커 이미지로 압축하고 함께 작동하도록 설정합니다.

   키워드: Java 11, Spring Boot, Docker, 이미지 최적화

2. Google Kubernetes Engine에서 Kubernetes 구성 및 시스템 배포 개발

   키워드: Kubernetes, GKE, 리소스 관리, 자동 확장, 보안 비밀

3. 더 나은 클러스터 관리를 위해 Helm 3로 차트 만들기

   태그: Helm 3, 차트 배포

4. 클러스터에 코드를 자동으로 전달하기 위한 Jenkins 및 파이프라인 설정

   키워드: Jenkins 구성, 플러그인, 별도의 구성 저장소

나는 각 단계에 별도의 기사를 쓸 계획입니다.

이 기사 시리즈의 초점은 마이크로서비스를 작성하는 방법이 아니라 단일 시스템에서 작동하도록 만드는 방법입니다. 이 모든 것들은 보통 개발자의 책임 밖에 있지만 적어도 20% 정도는 익숙해지는 것이 여전히 유용하다고 생각합니다(아시다시피 결과의 80%를 줍니다). 보안과 같은 일부 무조건적인 중요한 주제는 이 시스템이 개인적인 용도로만 만들어지는 것에 대해 작성자가 거의 이해하지 못하기 때문에 이 프로젝트에서 제외됩니다. 어떤 의견이나 건설적인 비판도 환영합니다.

마이크로서비스 생성

서비스는 Spring Boot를 사용하여 Java 11로 작성되었습니다. 서비스 간 상호 작용은 REST를 사용하여 구성됩니다. 프로젝트에는 최소한의 테스트가 포함됩니다(나중에 Jenkins에서 테스트할 항목이 있음). 서비스의 소스 코드는 GitHub에서 사용할 수 있습니다. 백엔드 и 게이트웨이.

각 서비스의 상태를 확인할 수 있도록 Spring Actuator가 종속 항목에 추가되었습니다. /actuator/health 엔드포인트를 생성하고 서비스가 트래픽을 수락할 준비가 된 경우 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을 작성해야 합니다. 다음으로 이미지를 빌드하고 이미지 레지스트리에 업로드할 수 있습니다(No. 도커 허브) 하나의 명령으로 모든 Docker화된 환경에 마이크로 서비스를 배포합니다.

도커 파일

이미지의 가장 중요한 특징 중 하나는 크기입니다. 압축 이미지는 원격 리포지토리에서 더 빨리 다운로드되고 공간을 덜 차지하며 서비스가 더 빨리 시작됩니다. 모든 이미지는 기본 이미지를 기반으로 구축되며 가장 최소한의 옵션을 선택하는 것이 좋습니다. 좋은 옵션은 최소한의 패키지로 구성된 완전한 Linux 배포판인 Alpine입니다.

먼저 "이마에" 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가 이미 설치된 Alpine 기반 기본 이미지를 사용하여 프로젝트를 빌드합니다. ADD 명령을 사용하여 현재 src 디렉토리를 이미지에 추가하고 작업(WORKDIR)으로 표시한 다음 빌드를 시작합니다. EXPOSE 8080 명령은 컨테이너의 애플리케이션이 해당 포트 8080을 사용할 것임을 도커에 알립니다(이렇게 하면 외부에서 애플리케이션에 액세스할 수 없지만 예를 들어 동일한 도커 네트워크의 다른 컨테이너에서 애플리케이션에 액세스할 수 있습니다. ).

서비스를 이미지로 패키징하려면 각 프로젝트의 루트에서 명령을 실행해야 합니다.

docker image build . -t msvc-backend:1.0.0

결과는 456MB 이미지(기본 JDK 이미지가 340MB를 차지함)입니다. 그리고 우리 프로젝트의 클래스가 손가락으로 셀 수 있다는 사실에도 불구하고. 이미지 크기를 줄이려면:

• 우리는 다단계 조립을 사용합니다. 첫 번째 단계에서는 프로젝트를 빌드하고, 두 번째 단계에서는 JRE를 설치하고, 세 번째 단계에서는 모두 깨끗한 새 Alpine 이미지에 복사합니다. 전체적으로 필요한 구성 요소만 최종 이미지에 포함됩니다.
• Java의 모듈화를 사용합시다. 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배 감소하여 77MB에 달했습니다. 나쁘지 않다. 그런 다음 기성 이미지를 이미지 레지스트리에 업로드하여 인터넷에서 이미지를 다운로드할 수 있습니다.

Docker의 공동 실행 서비스

우선, 우리의 서비스는 동일한 네트워크에 있어야 합니다. 도커에는 여러 유형의 네트워크가 있으며 그중 가장 원시적인 브리지를 사용하여 동일한 호스트에서 실행되는 컨테이너를 네트워크로 연결할 수 있습니다. 다음 명령을 사용하여 네트워크를 생성합니다.

docker network create msvc-network

다음으로 microservices-backend:1.0.0 이미지를 사용하여 'backend'라는 백엔드 컨테이너를 시작합니다.

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

브리지 네트워크가 이름별로 컨테이너에 대한 즉시 사용 가능한 서비스 검색을 제공한다는 점은 주목할 가치가 있습니다. 즉, 백엔드 서비스는 도커 네트워크 내에서 다음 위치에서 사용할 수 있습니다. 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 옵션을 사용하여 spring에서 자동으로 읽을 환경 변수를 설정하고 application.properties에서 속성을 재정의합니다.

시작 후, 우리는 전화 http://localhost/ 이전 사례와 같이 모든 것이 작동하는지 확인하십시오.

결론

결과적으로 우리는 두 개의 간단한 마이크로서비스를 만들어 도커 컨테이너에 패키징하고 동일한 시스템에서 함께 시작했습니다. 그러나 결과 시스템에는 여러 가지 단점이 있습니다.

• 열악한 내결함성 - 모든 것이 하나의 서버에서 작동합니다.
• 열악한 확장성 - 로드가 증가할 때 추가 서비스 인스턴스를 자동으로 배포하고 로드 균형을 조정하는 것이 좋습니다.
• 시작의 복잡성 - 최소 3개의 명령과 특정 매개변수를 입력해야 했습니다(2개의 서비스에만 해당).

위의 문제를 해결하기 위해 Docker Swarm, Nomad, Kubernetes 또는 OpenShift와 같은 여러 가지 솔루션이 있습니다. 전체 시스템이 Java로 작성된 경우 Spring Cloud(좋은 기사).

В 다음 부분 Kubernetes를 설정하고 프로젝트를 Google Kubernetes Engine에 배포한 방법에 대해 이야기하겠습니다.

출처 : habr.com