죄송합니다, OpenShift, 우리는 당신에게 충분히 감사하지 않았고 당신을 당연하게 여겼습니다

이 게시물은 우리 직원이 Kubernetes에서 애플리케이션을 개발하고 OpenShift에서 그러한 개발의 세부 사항에 대해 고객과 꽤 많은 대화를 나누었기 때문에 작성되었습니다.

우리는 일반적으로 Kubernetes는 Kubernetes일 뿐이며 OpenShift는 이미 Microsoft AKS 또는 Amazon EKS와 같은 Kubernetes 플랫폼이라는 테제부터 시작합니다. 이러한 각 플랫폼에는 특정 대상 고객에 초점을 맞춘 고유한 장점이 있습니다. 그리고 그 이후 대화는 이미 특정 플랫폼의 강점과 약점을 비교하는 것으로 흘러갑니다.

일반적으로 우리는 "들어봐, OpenShift 또는 AKS, EKS, 일부 사용자 정의 Kubernetes, 예 모든 Kubernetes에서 코드를 실행하는 것은 중요하지 않습니다. (줄여서 KUK라고 부르자) "거기나 저기나 정말 간단합니다."

그런 다음 가장 단순한 "Hello World"를 사용하여 CMC와 Red Hat OpenShift Container Platform(이하 OCP 또는 단순히 OpenShift) 간의 공통점과 차이점을 보여주기로 계획했습니다.

그러나 이 게시물을 작성하는 과정에서 우리는 OpenShift 사용에 너무 익숙해져서 OpenShift가 어떻게 성장하여 단순한 Kubernetes 배포를 훨씬 뛰어넘는 놀라운 플랫폼으로 변모했는지 깨닫지 못하고 있음을 깨달았습니다. 우리는 OpenShift의 장엄함을 간과하면서 OpenShift의 성숙함과 단순함을 당연하게 여기는 경향이 있습니다.

일반적으로 적극적인 회개의 시간이 왔으며 이제 우리는 KUK와 OpenShift에서 "Hello World"의 커미셔닝을 단계별로 비교하고 가능한 한 객관적으로 수행할 것입니다. 주제에 대한 태도). 이 문제에 대한 순전히 주관적인 의견에 관심이 있다면 읽을 수 있습니다. 여기 (EN). 그리고 이 포스트에서 우리는 사실과 사실만을 고수할 것입니다.

클러스터

따라서 "Hello World"에는 클러스터가 필요합니다. 서버, 레지스트리, 네트워크, 데이터 전송 등에 대한 비용을 지불하지 않으려면 퍼블릭 클라우드에 "아니오"라고 말합시다. 따라서 간단한 단일 노드 클러스터를 선택합니다. 미니쿠베 (KUK의 경우) 및 코드 레디 컨테이너 (OpenShift 클러스터의 경우). 이 두 옵션 모두 설치가 정말 쉽지만 노트북에 상당히 많은 리소스가 필요합니다.

KUK-e에서 조립

자, 가자.

1단계 - 컨테이너 이미지 구축

Minikube에 "Hello World"를 배포하는 것으로 시작하겠습니다. 이를 위해서는 다음이 필요합니다.

1. 1. 도커를 설치했습니다.
2. 2. 힘내 설치.
3. 3. Maven 설치(실제로 이 프로젝트는 mvnw 바이너리를 사용하므로 Maven 없이도 가능합니다.)
4. 4. 실제로 소스 자체, 즉 리포지토리 복제 github.com/gcolman/quarkus-hello-world.git

첫 번째 단계는 Quarkus 프로젝트를 만드는 것입니다. Quarkus.io를 사용해 본 적이 없더라도 두려워하지 마십시오. 쉽습니다. 프로젝트에서 사용하려는 구성 요소(RestEasy, Hibernate, Amazon SQS, Camel 등)를 선택한 다음 Quarkus 자체가 사용자의 참여 없이 maven 원형을 설정하고 모든 것을 github에 넣습니다. 즉, 문자 그대로 마우스를 한 번만 클릭하면 완료됩니다. 이것이 우리가 Quarkus를 사랑하는 이유입니다.

"Hello World"를 컨테이너화된 이미지로 빌드하는 가장 쉬운 방법은 필요한 모든 작업을 수행하는 Docker용 quarkus-maven 확장을 사용하는 것입니다. Quarkus의 등장으로 이 작업은 정말 쉽고 간단해졌습니다. container-image-docker 확장을 추가하면 maven 명령으로 이미지를 만들 수 있습니다.

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

마지막으로 Maven을 사용하여 이미지를 빌드합니다. 결과적으로 우리의 소스 코드는 컨테이너 런타임에서 이미 실행될 수 있는 미리 만들어진 컨테이너 이미지로 바뀝니다.

./mvnw -X clean package -Dquarkus.container-image.build=true

사실 그게 전부입니다. 이제 액세스할 수 있도록 서비스를 포트 8080에 매핑하여 docker run 명령으로 컨테이너를 실행할 수 있습니다.

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

컨테이너 인스턴스가 시작된 후 남은 것은 curl 명령으로 서비스가 실행 중인지 확인하는 것입니다.

그래서 모든 것이 작동했고 정말 쉽고 간단했습니다.

2단계 - 컨테이너를 컨테이너 이미지 리포지토리에 제출

지금은 생성한 이미지가 로컬 컨테이너 스토리지에 로컬로 저장됩니다. KUK 환경에서 이 이미지를 사용하려면 다른 리포지토리에 넣어야 합니다. Kubernetes에는 이러한 기능이 없으므로 dockerhub를 사용합니다. 첫 번째는 무료이고 두 번째는 (거의) 모든 사람이 사용하기 때문입니다.

이것은 또한 매우 간단하며 여기에는 dockerhub 계정만 필요합니다.

따라서 dockerhub를 설치하고 거기에 이미지를 보냅니다.

3단계 - Kubernetes 시작

"Hello World"를 실행하기 위해 kubernetes 구성을 구성하는 방법에는 여러 가지가 있지만 가장 간단한 방법을 사용하겠습니다.

먼저 minikube 클러스터를 시작합니다.

minikube start

4단계 - 컨테이너 이미지 배포

이제 코드와 컨테이너 이미지를 kubernetes 구성으로 변환해야 합니다. 즉, dockerhub의 컨테이너 이미지를 가리키는 포드와 배포 정의가 필요합니다. 이를 수행하는 가장 쉬운 방법 중 하나는 이미지를 가리키는 배포 생성 명령을 실행하는 것입니다.

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

이 명령을 사용하여 컨테이너 이미지에 대한 포드 사양을 포함해야 하는 배포 구성을 생성하도록 COOK에 지시했습니다. 이 명령은 또한 이 구성을 Minikube 클러스터에 적용하고 컨테이너 이미지를 다운로드하고 클러스터에서 포드를 실행하는 배포를 생성합니다.

5단계 - 서비스에 대한 액세스 열기

컨테이너 이미지가 배포되었으므로 이제 이 Restful 서비스에 대한 외부 액세스를 구성하는 방법에 대해 생각할 시간입니다. 실제로 이 서비스는 코드에 프로그래밍되어 있습니다.

여기에는 여러 가지 방법이 있습니다. 예를 들어, 노출 명령을 사용하여 서비스 및 엔드포인트와 같은 적절한 Kubernetes 구성 요소를 자동으로 생성할 수 있습니다. 실제로 이것은 배포 개체에 대한 노출 명령을 실행하여 수행할 작업입니다.

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

잠시 노출 명령의 "-type" 옵션에 대해 살펴보겠습니다.

서비스를 실행하는 데 필요한 구성 요소를 노출하고 생성할 때 무엇보다도 소프트웨어 정의 네트워크 내부에 있는 hello-quarkus 서비스에 외부에서 연결할 수 있어야 합니다. 그리고 매개변수 유형 로드 밸런서와 같은 것을 생성하고 연결하여 트래픽을 해당 네트워크로 라우팅할 수 있습니다.

예를 들어, 쓰기 유형=로드밸런서, Kubernetes 클러스터에 연결하기 위해 퍼블릭 클라우드 로드 밸런서를 자동으로 초기화합니다. 물론 이것은 훌륭하지만 이러한 구성이 특정 퍼블릭 클라우드에 밀접하게 연결되어 있고 다른 환경의 Kubernetes 인스턴스 간에 전송하기가 더 어렵다는 점을 이해해야 합니다.

우리의 예에서 유형=노드포트즉, 우리 서비스에 대한 호출은 노드의 IP 주소와 포트 번호를 통해 이루어집니다. 이 옵션을 사용하면 퍼블릭 클라우드를 사용할 수 없지만 몇 가지 추가 단계가 필요합니다. 먼저 자체 로드 밸런서가 필요하므로 클러스터에 NGINX 로드 밸런서를 배포합니다.

6단계 - 로드 밸런서 설정

minikube에는 인그레스 컨트롤러와 같은 외부 액세스에 필요한 구성 요소를 쉽게 생성할 수 있는 여러 플랫폼 기능이 있습니다. Minikube는 Nginx 수신 컨트롤러와 함께 번들로 제공되며 이를 활성화하고 구성하기만 하면 됩니다.

minikube addons enable ingress

이제 단 하나의 명령으로 Minikube 클러스터 내에서 작동할 Nginx 수신 컨트롤러를 생성합니다.

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

7단계 - 인그레스 설정

이제 hello-quarkus 요청을 수락하도록 Nginx 수신 컨트롤러를 구성해야 합니다.

마지막으로 이 구성을 적용해야 합니다.

kubectl apply -f ingress.yml

우리는 이 모든 작업을 자체 시스템에서 수행하고 있으므로 노드의 IP 주소를 /etc/hosts 파일에 추가하여 minikube에 대한 http 요청을 NGINX 로드 밸런서에 전달합니다.

192.168.99.100 hello-quarkus.info

이제 Nginx 인그레스 컨트롤러를 통해 외부에서 minikube 서비스를 사용할 수 있습니다.

글쎄요, 쉬웠죠? 아니면 별로?

OpenShift에서 실행(코드 준비 컨테이너)

이제 이 모든 것이 Red Hat OpenShift Container Platform(OCP)에서 어떻게 수행되는지 살펴보겠습니다.

Minikube의 경우와 마찬가지로 CRC(Code Ready Containers) 형태의 단일 노드 OpenShift 클러스터가 포함된 체계를 선택합니다. 이전에는 minishift라고 불렸고 OpenShift Origin 프로젝트를 기반으로 했지만 지금은 CRC이며 Red Hat의 OpenShift Container Platform을 기반으로 합니다.

죄송합니다. "OpenShift는 훌륭합니다!"라고 말하지 않을 수 없습니다.

처음에 우리는 OpenShift에서의 개발이 Kubernetes에서의 개발과 다르지 않다고 생각했습니다. 사실, 그것이 바로 그 방식입니다. 그러나이 게시물을 작성하는 과정에서 우리는 OpenShift가 없을 때 얼마나 많은 불필요한 움직임을 만들어야하는지 기억했기 때문에 다시 한 번 아름답습니다. 우리는 일이 쉬운 것을 좋아하며 Minikube와 비교하여 OpenShift에서 예제를 배포하고 실행하는 것이 얼마나 쉬운지 이 게시물을 작성하게 된 동기를 부여했습니다.

프로세스를 실행하고 수행해야 할 작업을 살펴보겠습니다.

따라서 minikube 예제에서 우리는 Docker로 시작했습니다… 잠깐, 더 이상 머신에 Docker를 설치할 필요가 없습니다.

그리고 우리는 로컬 자식이 필요하지 않습니다.
그리고 Maven은 필요하지 않습니다.
그리고 컨테이너 이미지를 직접 만들 필요가 없습니다.
그리고 컨테이너 이미지의 리포지토리를 찾을 필요가 없습니다.
수신 컨트롤러를 설치할 필요가 없습니다.
수신도 구성할 필요가 없습니다.

이해했나요? OpenShift에서 애플리케이션을 배포하고 실행하려면 위의 어느 것도 필요하지 않습니다. 그리고 프로세스 자체는 다음과 같습니다.

1단계 – OpenShift 클러스터 시작하기

Red Hat의 Code Ready Containers를 사용합니다. 이는 본질적으로 Minikube와 동일하지만 완전한 단일 노드 Openshift 클러스터만 포함합니다.

crc start

2단계 - OpenShift 클러스터에 애플리케이션 구축 및 배포

바로 이 단계에서 OpenShift의 단순성과 편리함이 그 모든 영광을 드러냅니다. 모든 Kubernetes 배포판과 마찬가지로 클러스터에서 애플리케이션을 실행하는 방법은 많습니다. 그리고 KUK의 경우와 마찬가지로 가장 간단한 것을 구체적으로 선택합니다.

OpenShift는 항상 컨테이너화된 애플리케이션을 구축하고 실행하기 위한 플랫폼으로 구축되었습니다. 컨테이너 구축은 항상 이 플랫폼의 필수적인 부분이므로 해당 작업을 위한 추가 Kubernetes 리소스가 많이 있습니다.

OpenShift의 소스 2 이미지(S2I) 프로세스를 사용할 것입니다. 이 프로세스에는 소스(코드 또는 바이너리)를 가져와 OpenShift 클러스터에서 실행되는 컨테이너화된 이미지로 변환하는 여러 가지 방법이 있습니다.

이를 위해서는 두 가지가 필요합니다.

• git 저장소의 소스 코드
• 조립이 수행되는 빌더 이미지.

Red Hat과 커뮤니티에서 유지 관리하는 이러한 이미지가 많이 있으며 Java 애플리케이션을 구축하고 있으므로 OpenJDK 이미지를 사용할 것입니다.

OpenShift Developer 그래픽 콘솔과 명령줄 모두에서 S2I 빌드를 실행할 수 있습니다. new-app 명령을 사용하여 빌더 이미지와 소스 코드를 가져올 위치를 알려줍니다.

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

이제 애플리케이션이 생성되었습니다. 이를 통해 S2I 프로세스는 다음 작업을 수행했습니다.

• 애플리케이션 빌드와 관련된 모든 종류의 서비스 빌드 포드를 만들었습니다.
• OpenShift 빌드 구성을 생성했습니다.
• 빌더 이미지를 내부 OpenShift 도커 레지스트리에 다운로드했습니다.
• "Hello World"를 로컬 저장소에 복제했습니다.
• 거기에 maven pom이 있는 것을 보고 maven으로 앱을 컴파일했습니다.
• 컴파일된 Java 애플리케이션을 포함하는 새 컨테이너 이미지를 생성하고 이 이미지를 내부 컨테이너 레지스트리에 넣습니다.
• 포드, 서비스 등에 대한 사양으로 Kubernetes 배포를 생성했습니다.
• 배포 컨테이너 이미지를 시작했습니다.
• 서비스 빌드 포드를 제거했습니다.

이 목록에는 많은 항목이 있지만 중요한 점은 전체 빌드가 OpenShift 내부에서만 발생하고 내부 Docker 레지스트리가 OpenShift 내부에 있으며 빌드 프로세스가 모든 Kubernetes 구성 요소를 생성하고 클러스터에서 실행한다는 것입니다.

콘솔에서 S2I 실행을 시각적으로 모니터링하면 빌드 중에 빌드 포드가 어떻게 실행되는지 확인할 수 있습니다.

이제 빌더 포드의 로그를 살펴보겠습니다. 먼저 maven이 작업을 수행하고 종속성을 다운로드하여 Java 애플리케이션을 빌드하는 방법을 볼 수 있습니다.

Maven 빌드가 완료되면 컨테이너 이미지의 빌드가 시작되고 이 빌드된 이미지가 내부 저장소로 전송됩니다.

모든 것, 조립 과정이 완료되었습니다. 이제 애플리케이션의 포드와 서비스가 클러스터에서 시작되었는지 확인하겠습니다.

oc get service

그게 다야. 그리고 한 팀만 있습니다. 우리가 해야 할 일은 외부 액세스를 위해 이 서비스를 노출하는 것입니다.

3단계 - 외부에서 액세스할 수 있도록 서비스를 노출합니다.

KUK의 경우와 마찬가지로 OpenShift 플랫폼에서 "Hello World"도 외부 트래픽을 클러스터 내부의 서비스로 안내하기 위한 라우터가 필요합니다. OpenShift에서는 이것이 매우 쉽습니다. 먼저 기본적으로 HAProxy 라우팅 구성 요소가 클러스터에 설치됩니다(동일한 NGINX로 변경 가능). 둘째, Routes라는 특별하고 고도로 구성 가능한 리소스가 있는데, 이는 오래된 Kubernetes의 Ingress 객체를 연상시킵니다(사실 OpenShift의 Routes는 Ingress 객체의 설계에 큰 영향을 미쳤으며 이제 OpenShift에서 사용할 수 있습니다). World" 및 기타 거의 모든 경우에 추가 구성 없이 표준 경로로 충분합니다.

"Hello World"에 대한 라우팅 가능한 FQDN을 생성하려면(예, OpenShift에는 서비스 이름별 라우팅을 위한 자체 DNS가 있음) 서비스를 노출하기만 하면 됩니다.

oc expose service quarkus-hello-world

새로 생성된 경로를 보면 FQDN 및 기타 라우팅 정보를 찾을 수 있습니다.

oc get route

마지막으로 브라우저에서 서비스에 액세스합니다.

하지만 지금은 정말 쉬웠습니다!

우리는 쿠버네티스와 이 기술로 할 수 있는 모든 것을 좋아하며 단순성과 가벼움도 좋아합니다. Kubernetes는 분산되고 확장 가능한 컨테이너를 매우 쉽게 작동하도록 설계되었지만 그 단순성은 더 이상 애플리케이션을 프로덕션으로 가져오기에 충분하지 않습니다. 그리고 바로 여기에서 OpenShift가 등장합니다. OpenShift는 시대에 발맞추고 주로 개발자에게 초점을 맞춘 Kubernetes를 제공합니다. S2I, ODI, 개발자 포털, OpenShift 운영자 프레임워크, IDE 통합, 개발자 카탈로그, Helm 통합, 모니터링 등의 도구 생성을 포함하여 특히 개발자를 위해 OpenShift 플랫폼을 맞춤화하기 위해 많은 노력을 기울였습니다.

이 기사가 귀하에게 흥미롭고 유용했기를 바랍니다. 또한 포털의 OpenShift 플랫폼에서 개발하는 데 유용한 추가 리소스, 자료 및 기타 항목을 찾을 수 있습니다. 레드햇 개발자.

출처 : habr.com