Red Hat OpenShift

지금 프로젝트가 레드헷 클라우드 환경에서 개발을 하고 있다. 

 

Red Hat OpenShift

 

자체 관리형 배포옵션

 

Red Hat® OpenShift®는 애플리케이션을 규모에 맞춰 빌드, 현대화, 배포할 수 있는 통합 플랫폼입니다 선택한 인프라에서 애플리케이션을 출시할 수 있는 일련의 완전한 서비스로 더 스마트하고 빠르게 작업할 수 있습니다.

 

Red Hat OpenShift란?

Red Hat OpenShift는 쿠버네티스로 구동되는 업계 최고의 하이브리드 클라우드 애플리케이션 플랫폼으로, 검증을 통해 신뢰성을 확보한 서비스를 결합하여 애플리케이션 개발, 현대화, 배포, 실행, 관리에 수반되는 마찰을 줄입니다. OpenShift는 퍼블릭 클라우드, 온프레미스, 하이브리드 클라우드 또는 엣지 아키텍처 전반에서 일관된 경험을 제공합니다.

자체 관리형 또는 전체 관리형 솔루션을 선택하세요. OpenShift는 실행 방식에 관계없이 팀이 중요한 작업에 집중할 수 있도록 지원합니다.

 

Red Hat OpenShift는 주요 클라우드 제공업체를 통해 턴키 애플리케이션 플랫폼으로 제공됩니다. 선택한 클라우드 제공업체를 통해 애플리케이션을 규모에 맞게 빌드, 현대화, 배포하세요.

 

 

https://nice-engineer.tistory.com/entry/Red-Hat-Openshift-%EB%9E%80

[Red Hat] Openshift 란 ?

 

✔︎ Openshift vs Kubernetes

1. OpenShift product vs kubernetes project

kubernetes는 오픈소스 프로젝트(또는 프레임워크)이지만, Openshift는 다양한 엔터프라이즈 기능이 포함된 제품이다.

Openshift Container Platform 은 Subscription 구매 시 유상 지원을 포함하는 인프라에 설치할 수 있는 제품이다. 

k8s는 많은 배포판(distribution)을 가지고 있지만 그것은 단지 프로젝트일 뿐이며 이슈/장애가 발생하면 커뮤니티나 외부 전문가에 의존할 수 밖에 없다.

 

2. OpenShift limited installation vs. install Kubernetes (almost) anywhere

OpenShift를 설치하기로 결정한 경우 OpenShift Container Platform용 Red Hat Enterprise Linux (또는 Red Hat Atomic)를 사용하고 OKD용 CentOS를  추가로 사용해야 한다. 다른 Linux 배포판에는 설치가 어렵다.

반면 kubernetes는 데비안, 우분투 및 기타 많은 리눅스 배포판에 대부분 설치할 수 있다.

 

3. OpenShift는 Kubernetes보다 엄격한 보안 정책을 가지고 있음

OpenShift 제품의 고객이 기업이기 때문일 수도 있지만 사실 Kubernetes보다 기본 정책이 엄격하다.

예를 들어, Docker Hub에서 사용할 수 있는 대부분의 컨테이너 이미지는 OpenShift에서는 실행되지 않는다.

root로 컨테이너를 실행하는 것을 금지하고 많은 공식적인 이미지들조차도 이 요구 사항을 충족하지 못하기 때문이다.

 

4. OpenShift 템플릿이 Kubernetes Helm 차트보다 flexibility가 낮음

 

5. Routers on OpenShift vs. Ingress on Kubernetes

 

6. 배포에 대한 접근

OpenShift에는 Controller가 아닌 DeploymentConfig라는 유사한 객체가 있지만 전체 프로세스를 제어하는 전용 Pod를 기반으로 하는 정교한 로직이 있다.

실행중인 많은 인스턴스와의 조정이 쉽지 않기 때문에 InitContainers는 동일하지 않다는 단점이 있으나 데이터베이스 스키마 변경 같은 업데이트를 위해 환경을 준비하기 위한 후크(Hook)를 사용할 수 있다는 장점이 있다.

 

7. Better management of container images

OpenShift는 컨테이너 이미지 관리를 위한 ImageStream 기능이 있어 Container Registry에서 이미지의 태그를 변경하는 것이 쉽다.

ImageStream을 사용하면 컨테이너 이미지를 한번 올린 다음 OpenShift에서 내부적으로 가상 태그를 관리할 수 있다. 

하나의 프로젝트에서 devel 태그를 사용하고 내부적으로 참조만 변경하면 stable이나 prod 태그를 사용하고 내부적으로 관리할 수 있다. OpenShift에서는 레지스트리를 다루지 않는다.

 

8. Integrated CI/CD with Jenkins

Red Hat은 Kubernetes 프로젝트가 발견되기 훨씬 전에 OpenShift를 만들었으며 처음부터 PaaS 플랫폼이었다.

OpenShift의 추가 기능을 사용하면 CI/CD 파이프라인을 사용해 어플리케이션을 쉽게 배포할 수 있다.

 

9. OpenShift projects are more than Kubernetes namespaces

OpenShift에는 추가 기능이 있는 namespace 이상의 프로젝트가 있다.

설명 및 표시 이름과 같은 사소한 것 외에도 (수십 개가 있을 때 도움이 될 수 있음) 프로젝트는 몇 가지 기본 개체를 추가한다.

현재 프로젝트와 함께 몇 가지 역할 (정확한 역할 정의 객체)이 만들어 지지만 기본 프로젝트 템플릿을 수정하고 이를 사용하여 다른 객체를 프로비저닝 할 수 있다.

출처: https://nice-engineer.tistory.com/entry/Red-Hat-Openshift-란#✔︎ Openshift vs Kubernetes-1 [뭉게뭉게 클라우드:티스토리]

 

레드헷 오픈 시프트는 깃과 젠킨스를 통한 CI/CD를 제공한다.

 

 

 

젠킨스란?

https://ict-nroo.tistory.com/31

[Jenkins] 젠킨스란 무엇인가

 

젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모드 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었는데, 이를 nightly-build라 한다. 하지만, 젠킨스는 정기적인 빌드에서 한발 나아가 서브버전, Git 과 같은 버전관리시스템과 연동하여 소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동되도록 설정할 수 있다.

 

각종 배치 작업의 간략화

프로젝트 기간 중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, Deploy작업과 같은 단순 작업에 시간과 노력을 들이는 경우가 빈번하다. 데이터베이스의 구축, 어플리케이션 서버로의 Deploy, 라이브러리 릴리즈와 같이 이전에 CLI로 실행되던 작업들이 젠킨스 덕분에 웹 인터페이스로 손쉽게 가능해졌다.

Build 자동화의 확립

빌드 툴의 경우 Java는 maven과 gradle이 자리잡고 있으며, 이미 빌드 관리 툴을 이용해 프로젝트를 진행하고 있다면 젠킨스를 사용하지 않을 이유가 하나도 없다. 젠킨스와 연동하여 빌드 자동화를 통해 프로젝트 진행의 효율성을 높일 수 있다.

자동화 테스트

자동화 테스트는 젠킨스를 사용해야 하는 가장 큰 이유 중 하나이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI(Continuous Integration)자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git과 같은 버전관리시스템과 연동하여 코드 변경을 감지하고 자동화 테스트를 수행하기 때문에 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다. 제대로 테스트를 거치지 않은 코드를 커밋하게 되면 화난 젠킨스를 만나게 된다.

 

어플리케이션을 더욱 짧은 주기로 고객에게 제공하는 자동화 프로세스 : CI/CD

CI/CD

일단 CI/CD 부터 짚고 넘어가자
CI/CD는 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Deployment)의 약자로 소프트웨어 개발 및 배포의 자동화를 통해 빠르고 안정적인 제품 출시를 목표로 하는 개발 방법론이다.

• CI (지속적인 통합)
  CI는 개발자들이 작성한 코드를 중앙 저장소에 자주 통합하고, 자동화된 빌드와 테스트를 통해 문제를 빠르게 발견하고 해결하는 것이다. 이렇게 하면 개발자들이 서로의 코드와 충돌 없이 효율적으로 협업할 수 있다.

• CD (지속적인 배포)
  모든 변경사항을 자동화된 테스트와 빌드를 거친 후, 실제 사용자에게 자동으로 배포하는 것이다. 이렇게 함으로써 새로운 기능이나 수정사항을 빠르게 사용자에게 제공할 수 있게된다.  

 

 

• 젠킨스를 클라우드 환경에서 실행하면, 하드웨어 및 인프라 관리에 들어가는 시간과 비용을 절약할 수 있다.
• 젠킨스 마스터 및 슬레이브 노드를 적절한 규모로 구성하고 리소스를 효율적으로 사용하도록 최적화 한다.
• 필요에 따라 동적으로 슬레이브 노드를 생성하고 제거하는 클라우드 에이전트 기능을 사용하면 좋다.
• 파이프라인 스크립트는 재사용 가능하고 모듈화된 구조로 작성한다.
• 플러그인을 사용할 때는 호환성에 주의한다.
• 젠킨스에서 보안 설정을 철저히 관리한다.
• https://velog.io/@kakdark/%EC%A0%A0%ED%82%A8%EC%8A%A4

 

 

 

젠킨스란?