ocp 기본 및 아키텍쳐

 

 

https://ocwokocw.tistory.com/40

아키텍처 - 정책과 수준

https://access.redhat.com/documentation/ko-kr/openshift_container_platform/4.6/html/architecture/architecture-rhcos

5장. RHCOS(Red Hat Enterprise Linux CoreOS) 4.6 | Red Hat Customer Portal

 

https://jhleed.tistory.com/161

[OpenShift] 오픈시프트 간단한 소개 / 장점 / 아키텍처 정리

https://laughcryrepeat.tistory.com/105

05 아키텍처 - 2

https://www.youtube.com/watch?v=ft9b4bTRtoI 

 

 

 

오픈시프트: 컨테이너 엔진과 쿠버네티스를 기반으로 어플리케이션을 쉽게 배포하고 관리할 수 있게 만든 파스 플랫폼.

쿠버네티스가 기본적인 골격과 확장성을 가진 플랫폼이라면, 오픈시프트는 쿠버네티스 위에 파스를 위한 여러가지 엔터프라이즈급 기능을 가진 솔루션.

예를 들면 프로메테우스, 그라파나, alert 매니저를 이용한 모니터링, 인증 및 보안 기능들, 데브옵스 툴 등을 포함하고 있다.

 

- 마스터노드: 전체노드를 관리하는 역할.

실제 어플리케이션을 실행하는 노드들 -> 이런노드를 워커노드라고 함.

마스터노드의 os는 코어os여야하고 워커노드는 코어os나 레드햇 리눅스(rhel)을 사용.

- 퍼시스턴스 스토리지: 컨테이너는 재개동 되면 원본이미지가 초기화되기 때문에 저장할 필요가 있는 부분은 나스로 연결해서 저장.

오픈시프트에서 실행되는 컨테이너는 워커노드의 내부아이피로 생성되기 때문에 외부에서 직접 연결되지 않음.

그래서 내부에서 외부를 연결해줄 라우팅 레이어가 필요.

오픈시프트에서는 이 라우터가 별도로 구성이 되면서 어플리케이션을 생성하면 생성된 도메인 네임에 따라 라우팅 정보가 자동으로 등록됨.

 

 

 

오픈시프트 4를 기준으로 개발이나 테스트용으로 사용할수있는 최소구성사례 

마스터는 3중화 해야함.

오픈시프트를 구성 및 운영을 위한 베스천 노드도 필수.

그외에 라우터나 모니터링을 위한 인프라 노드가 별도로 있는 것이 좋음.

인프라노드와 워커노드는 필요에 따라 줄이거나 통합할 수 있다.

다만 기본적으로 이렇게 구성하는것이 좋음.

배포같은 경우는 haproxy로 대체할 수 있다.

 

운영용으로 사용할수있는 구성사례

마스터 3중화에 추가로 외부 트래픽이 들어오는 라우터도 2중화를 해야함.

모니터링에 필요한 노드도 성능에 영향이 가지않도록 인프라로 별도 구분을 하는것이 중요.

L4는 내부 마스터 api 용과 외부 라우터 트래픽 용으로 별도로 구분하는 것이 좋다만, 상황에 따라 두개를 하나로 합칠 수 있다.

 

 

오픈시프트의 활용 내용

오픈시프트는 파스의 솔루션이다.

아이아스(Iaas)가 os 까지 만들어서 서비스를 실행해준다면 파스는 어플리케이션이 실행되는 플랫폼까지 만들어서 서비스 실행.

오픈시프트는 그 서비스를 컨테이너 이미지 형태로 만들어서 서비스해줌.

그래서 이 컨테이너 이미지를 만들때 깃에 들어있는 어플리케이션을 합쳐서 만드는 빌드 기능을 제공.

 

 

이미지 내부를 보면 이런식으로 구성이 되어있음.

이미지가 톰캣이라고 하면 젤 밑에 시스템 라이브러리 그위에 jre , 톰캣 바이너리, 어플리케이션으로 구성이 됨.

이 이미지를 컨테이너로 실행하는 구조.

근데 문제는 이 어플리케이션이 계속 바뀜.

 

그래서 오픈시프트에서는 이미지를 이런식으로 만듬.

계속 바뀌는 부분과 안바뀌는 부분 나눠서 안바뀌는 부분은 베이스 이미지로 만들고 바뀌는 부분만 깃에다가 저장해놓고 배포시점에 합쳐서 합쳐진 이미지를 배포한다.

이렇게 깃에 어플리케이션을 이미지 합치는 것을 오픈시프트에서는 s2i 이미지빌드라고 함.

 

다시 위위 이미지로 돌아가서 컨테이너 엔진은 자기 os내부에 있는 컨테이너만 관리할 수 있다.

따라서 오픈시프트처럼 여러수에 걸쳐있는 컨테이너를 한꺼번에 관리하려면 컨테이너 말고 별도의 개념이 필요한데 그게 바로 파드이다.

파드는 컨테이너를 포함하는 구조로 되어있고 아이피도 컨테이너가 아닌 파드에 부여된다. 그래서 오픈시프트에서는 전체 호스트에 걸쳐 유일한 아이피를 파드에 부여하고 관리할 수 있는것이다. 파드의 아이피는 파드 생성 시점에 결정된다. 파드는 기본적으로 확장가능, 특정아이피를 고정해서 사용할 수 없다. 이것이 파드의 큰 특징.

 

오픈시프트는 어플리케이션을 생성하면 바로 파드가 생성.

이 파드는 오픈시프트에서 쉽게 확장가능.

이 확장성있는 구조를 만들기 위해서 내부적으로 다양한 오브젝트를 만들어 관리함.

(이미지 설명)

그리고 파드는 스케일 아웃이 가능..그래서 그 앞단에는 로드밸런싱을 위한 클러스터 아이피가 필요. 서비스라는 오브젝트가 그걸 가짐. 그앞에는 외부의 아이피를 파드로 연결해주는 라우트가 존재. 라우트는 어플리케이션의 도메인이름에 대한 내부 서비스 매핑정보를 알기 떄문에 외부에서 들어오는 트래픽을 내부 파드로 연결하는 역할담당.

 

 

 

그럼 사용자관점에서는 어떤구조로 어플리케이션이 생성되는지 구조를 알아보자.

사용자, 즉 유저는 권한을 부여받아 로그인 할 수 있는 주체.

유저는 프로젝트를 만들수 있다. 프로젝트는 오픈시프트에서 어플리케이션을 생성해서 사용하는 논리적인 공간이다. 유저는 프로젝트를 만들고 그 프로젝트 안에 여러가지 오브젝트를 만들어서 사용.

유저는 어플리케이션을 만든후에 소스가 변경되면 그것을 반영하기위해 빌드와 배포를 수시로 함

빌드컨피그에서 빌드를 할수있고 디플로이먼트에서 배포를 할 수 있다. 각각은 실행될때마다 실행내역을 남김

 

 

 

이 빌드와 배포가 어떤식으로 수행되는지 알아보자.

개발자가 소스를 업뎃한후 빌드를 실행하면 빌드와 노드 배포까지 자동으로 실행.

먼저 개발자가 소스를 깃에 푸시함.

오픈시프트에 이미지가 실행되면 빌더 이미지가 소스에 내려받아 새로운 이미지 생성.

새 이미지를 노드에 배포하여 컨테이너로 실행.

새 어플리케이션을 배포하기 위해 소스를 이미지에 넣어 실행가능한 어플리케이션 이미지로 만드는 과정을 s2i빌드라고함.

 

 

 

빌드에서 소스를 이미지에 넣는방법은 피일 복사를 누가하냐에 따라 3가지 방법이 있다.

파이프라인 빌드는 깃에 있는 젠킨스에 의해 정의된 형태로 소스가 이미지 내부로 복사가 된다.

파이프라인 빌드는 젠킨스를 이용하므로 이미지 빌드외에 추가적인 테스트나 작업을 하기에 아주 좋다.

젠킨스의 파이프라인 스크립트를 오픈시프트에서 수행하는것으로 생각하면 된다.

 

 

빌드가 성공적으로 완료되면 배포 자동으로 진행됨.

오픈시프트에서는 디플로이먼트 컨피그에서 미리 정의된 내용으로 배포를 진행하고 배포된 파드가 잘 실행되고 있는지 

주기적으로 헬스 체크함.

만약 일시적 문제가 생겨서 응답이 없으면 문제가 되는 파드를 제거하고 새로운  파드를 생성해서 서비스를 지속해 나간다 이게 바로 오토 힐링이다.

 

 

 

어플리케이션이 업뎃되면 새로 빌드를 하고 배포를 한다. 오픈시프트에서는 새로 배포된 이미지에 대한 히스토리를 가짐.

그래서 새로 배포된 이미지에 문제가 있으면 이미지를 통쨰로 바꾸는 방식으로 롤백가능.

롤백을 쉽고 빠르게 가능.

 

 

오픈시프트의 주요기능

cpu 사용에 따라 파드의 수를 확장 또는 감소시킬수 있다.

 

 

 

 

 

오픈시프트에서는 s2i빌드 등을 통해서 소스빌드 및 배포와 같은 간단한 형태의 ci/cd를 구성할 수 있다.

젠킨스를 추가 구성하면 젠킨스의 파이프라인을 사용할 수 있으므로 소스빌드 뿐만 아니라 여러가지 테스트와 코드검사등 다양한 내용 추가할 수 있다.

 

오픈시프트에서 일반적으로 많이 사용하는 어플리케이션 구조이다.

파드가 기존의 vm이라고 생각하면 되고, 앞단의 로드밸런싱은 자동으로 구성되므로 이를위한 웹서버는 구성필요가 없음.

이중화를 위해 톰캣파드를 두개 끼우고 디비는 오픈시프트에 오르지 않고 기존방식대로 사용하게 된다.

기존방식대로 사용하는 이유는 디비는 데이터가 중요하므로 사라지지 않도록 퍼시스턴트 볼륨을 붙여서 사용해야하는데 네트워크로 볼륨을 붙이면 기존 방식보다 속도가 떨어지므로 성능에 크리티컬함.

 

 

 

기존의 어플리케이션을 오픈시프트로 옮기는 서비스 마이그레이션에 대한 내용

오픈시프트에서는 어플리케이션을 실행하려면 이미지가 있어야함 그리고 이미지로 부터 실행된 파드의 아이피가 실행시점에 동적으로 할당.

따라서 아이피가 고정되어있는 것을 기반으로 작성된 어플리케이션 로직이나 라이센스 체킹방식이 있다면 문제가 된다.

그리고 컨테이너 내부에는 os가 구동되지 않는다. 그래서 크론탭같은 os의 특정 서비스를 이용하는 어플리케이션도 문제가 된다.

그리고 파드를 재생성하면 컨테이너가 초기화되기 떄문에 어플리케이션 기동중에 생긴 로그파일들이나 변경된 부분들은 삭제가된다. 따라서 중요한 파일들은 nfs로 마운트해서 따로 저장해야함.

이런부분만 고려하면 큰문제 없이 마이그레이션 가능.

 

 

 

기존에 web was가 연동되어 있는 레거시 시스템이 있다.

이것을 오픈시프트로 옮길경우의 고려사항 정리.

 

 

 

 

웹 와스 연동방식에서 웹서버를 떼어내는 것이 좋다. 왜냐면 와스 파드가 재가동되면 아이피가 바뀌기때문에 기존에 아이피를 미리 적어놔야하는 프록시방식으로는 동적으로 연동을 할 수 없다. 그래서 오픈시프트는 이를 위해서 기본적으로 라우터 기능이 들어가 있기 때문에 와스 단일 구조로 가는것이 좋다.

그리고 컨테이너를 재개동하면 내부의 파일이 초기화되기 때문에 저장이 필요한 디렉토리에는 나스를 붙여야한다.

특정 와스의 세션 클러스터링이나 apm이 오픈시프트 항목에서 작동하는지도 해당 벤더에 확인해야한다.

라이센스의 확인 방식이 아이피나 호스트네임에 상관이 없는지도 확인해야함.

기능은 문제가 없는데 라이센스발급이 특정 아이피로만 이루어 진다면 문제가 된다.

 

 

빌드구성을 위한 cicd의 측면

컨테이너를 사용하려면 와스이미지안에 어플리케이션을 넣어야함. 그리고 오픈시프트에서는 이를 위해 빌드기능을 제공한다고 했음.

대신 소스는 깃서버에 들어있어야함. 깃서버에는 어플리케이션 뿐만아니라 여러가지 설정파일들도 넣을 수 있다. 이미 깃을 사용하고 있으면 문제가 되지 않지만 그렇지 않다면 cicd를 깃을 사용하도록 변경을 해야한다.

이렇게 구성된 빌드를 호출하면 이미지 빌드에서 최종배포까지 자동으로 호출되도록 cicd를 구성할 수 있다.

 

 

 

 

마지막으로 어플리케이션 측면에서 보는거

개발이나 운영환경별로 달라지는 ~