17.3. 튜토리얼: OpenShift 개념
17.3.1. S2I(Source-to-Image)
S2I(Source-to-Image)는 소스 코드에서 재현 가능한 컨테이너 이미지를 빌드하는 툴킷 및 워크플로입니다. S2I는 컨테이너 이미지에 소스 코드를 삽입하고 컨테이너에서 소스 코드를 준비하여 바로 실행할 수 있는 이미지를 생성합니다. 자체 조립 빌더 이미지를 생성하면 컨테이너 이미지를 사용하여 런타임 환경을 버전처럼 빌드 환경을 정확히 버전화하고 제어할 수 있습니다.
17.3.1.1. 작동 방식
Ruby와 같은 동적 언어의 경우 빌드 시간 및 런타임 환경은 일반적으로 동일합니다. Ruby, Bundler, Rake, Apache, GCC 및 Ruby 애플리케이션을 설정하고 실행하는 데 필요한 기타 모든 패키지가 이미 설치되어 있다고 가정하면 빌더 이미지가 다음 단계를 수행합니다.
- 빌더 이미지는 알려진 디렉터리에 애플리케이션 소스가 삽입된 컨테이너를 시작합니다.
- 컨테이너 프로세스는 해당 소스 코드를 적절한 실행 가능한 설정으로 변환합니다. 예를 들어 Bundler를 사용하여 종속성을 설치하고 소스 코드를 Ruby 구성 파일을 찾기 위해 Apache가 사전 구성된 디렉터리로 이동합니다.
- 그런 다음 새 컨테이너를 커밋하고 이미지 진입점을 Ruby 애플리케이션을 호스팅하도록 Apache를 시작하는 스크립트로 설정합니다.
C, C++, Go 또는 Java와 같은 컴파일된 언어의 경우 컴파일에 필요한 종속성이 런타임 아티팩트의 크기를 초과할 수 있습니다. S2I는 런타임 이미지를 작게 유지하기 위해 다중 단계 빌드 프로세스를 활성화합니다. 여기서 첫 번째 빌더 이미지에서 실행 파일과 같은 바이너리 아티팩트가 추출되고 실행 프로그램을 올바른 위치에 배치하는 두 번째 런타임 이미지에 삽입됩니다.
예를 들어 Tomcat 및 Maven에 대한 재현 가능한 빌드 파이프라인을 생성하려면 다음을 수행합니다.
- WAR 파일이 삽입될 것으로 예상되는 OpenJDK 및 Tomcat이 포함된 빌더 이미지를 생성합니다.
- 첫 번째 이미지 Maven 및 기타 표준 종속 항목에 계층화된 두 번째 이미지를 생성하고 Maven 프로젝트가 삽입될 것으로 예상합니다.
- Java 애플리케이션 소스 및 Maven 이미지를 사용하여 S2I를 시작하여 원하는 애플리케이션 WAR를 생성합니다.
- 이전 단계의 WAR 파일과 초기 Tomcat 이미지를 사용하여 S2I를 두 번 시작하여 런타임 이미지를 생성합니다.
이미지 내부에 빌드 논리를 배치하고 이미지를 여러 단계로 결합함으로써 런타임 환경은 빌드 툴을 프로덕션에 배포하지 않고도 빌드 환경에 가깝습니다.
17.3.1.2. S2I 이점
- 재현 가능
- 컨테이너 이미지 내에서 캡슐화하고 호출자를 위해 삽입된 소스 코드의 간단한 인터페이스를 정의하여 빌드 환경을 엄격하게 버전 지정할 수 있습니다. 재현 가능한 빌드는 컨테이너화된 인프라에서 보안 업데이트 및 지속적인 통합을 가능하게 하는 핵심 요구 사항이며 빌더 이미지는 반복성 및 스왑 실행 시간을 보장합니다.
- 유연성
- Linux에서 실행할 수 있는 기존 빌드 시스템은 컨테이너 내에서 실행할 수 있으며 각 개별 빌더는 더 큰 파이프라인의 일부가 될 수도 있습니다. 애플리케이션 소스 코드를 처리하는 스크립트를 빌더 이미지에 삽입할 수 있으므로 작성자는 기존 이미지를 적용하여 소스 처리를 활성화할 수 있습니다.
- 속도
- 단일 Dockerfile에 여러 계층을 빌드하는 대신 작성자는 단일 이미지 계층에서 애플리케이션을 나타낼 것을 권장합니다. 이렇게 하면 생성 및 배포 중에 시간이 단축되고 최종 이미지의 출력을 보다 효과적으로 제어할 수 있습니다.
- 보안
- Dockerfile은 컨테이너의 일반적인 작동 제어 없이 실행됩니다. 일반적으로 root로 실행되며 컨테이너 네트워크에 액세스할 수 있습니다. S2I는 빌드가 단일 컨테이너에서 시작되므로 빌더 이미지에 사용할 수 있는 권한 및 권한을 제어할 수 있습니다. OpenShift와 같은 플랫폼에 어셈블하여 S2I를 사용하면 관리자가 빌드 시 개발자가 보유한 권한을 제어할 수 있습니다.
17.3.2. 라우트
OpenShift 경로는 서비스를 호스트 이름으로 공개하므로 외부 클라이언트가 이름으로 연결할 수 있습니다. OpenShift에서 Route 오브젝트가 생성되면 기본 제공 HAProxy 로드 밸런서에서 요청된 서비스를 노출하고 지정된 구성으로 외부에서 사용할 수 있도록 합니다.
Kubernetes Ingress 오브젝트와 유사하게 Red Hat은 요구 사항을 채우기 위해 경로 개념을 작성한 다음 커뮤니티 뒤에 있는 설계 원칙을 커뮤니티에 기여하여 Ingress 설계에 크게 영향을 미쳤습니다. 경로에는 다음 차트에서 볼 수 있는 몇 가지 추가 기능이 있습니다.
| 기능 | OpenShift에서 Ingress | OpenShift의 경로 |
|---|---|---|
| 표준 Kubernetes 오브젝트 | X | |
| 서비스에 대한 외부 액세스 | X | X |
| 영구(sticky) 세션 | X | X |
| 로드 밸런싱 전략(예: 라운드 로빈) | X | X |
| rate-limit 및 throttling | X | X |
| IP 허용 목록 | X | X |
| 보안을 개선하기 위한 TLS 엣지 종료 | X | X |
| 보안 개선을 위한 TLS 재암호화 | X | |
| 보안을 개선하기 위한 TLS passhtrough | X | |
| 여러 가중치 백엔드(스플릿 트래픽) | X | |
| 패턴 기반 호스트 이름 생성 | X | |
| 와일드카드 도메인 | X |
호스트 이름의 DNS 확인은 라우팅과 별도로 처리됩니다. 관리자가 항상 라우터로 올바르게 확인하거나 라우터로 확인하도록 독립적으로 호스트 이름 DNS 레코드를 수정하는 클라우드 도메인을 구성했을 수 있습니다.
개별 경로는 주석에 특정 구성을 제공하여 일부 기본값을 덮어쓸 수 있습니다.
추가 리소스
17.3.3. 이미지 스트림
이미지 스트림은 이미지에 대한 태그 매핑, 스트림에 이미지가 태그될 때 적용되는 메타데이터 덮어쓰기 및 레지스트리의 Docker 이미지 리포지토리에 대한 선택적 참조를 저장합니다.
17.3.3.1. 이미지 스트림 이점
이미지 스트림을 사용하면 컨테이너 이미지의 태그를 쉽게 변경할 수 있습니다. 그러지 않으면 태그를 수동으로 변경하려면 이미지를 다운로드하여 로컬로 변경한 다음 모두 푸시해야 합니다. 태그를 수동으로 변경한 다음 배포 오브젝트를 업데이트하여 애플리케이션을 승격하는 데는 여러 단계가 포함됩니다.
이미지 스트림을 사용하면 컨테이너 이미지를 한 번 업로드하고 OpenShift에서 해당 가상 태그를 내부적으로 관리합니다. 하나의 프로젝트에서는 developer 태그를 사용하고 내부적으로만 참조할 수 있지만 프로덕션에서는 production 태그를 사용하고 내부적으로도 관리할 수 있습니다. 레지스트리를 처리할 필요가 없습니다.
또한 배포 구성과 함께 이미지 스트림을 사용하여 새 이미지가 표시되거나 태그가 참조가 변경되면 배포를 시작하는 트리거를 설정할 수도 있습니다.
17.3.4. 빌드
빌드는 입력 매개변수를 결과 오브젝트로 변환하는 프로세스입니다. 대부분의 경우 프로세스는 입력 매개변수 또는 소스 코드를 실행 가능한 이미지로 변환하는 데 사용됩니다. BuildConfig 오브젝트는 전체 빌드 프로세스에 대한 정의입니다.
OpenShift Container Platform은 빌드 이미지에서 Docker 형식의 컨테이너를 생성하고 컨테이너 이미지 레지스트리로 푸시하여 Kubernetes를 활용합니다.
build 오브젝트는 일반적인 특성을 공유합니다.
- 빌드 입력
- 빌드 프로세스를 완료하기 위한 요구사항
- 빌드 프로세스 로깅
- 성공적인 빌드의 리소스 게시
- 빌드의 최종 상태 게시
빌드에서는 CPU 사용량, 메모리 사용량, 빌드 또는 Pod 실행 시간과 같은 리소스 제한 사항을 활용합니다.
추가 리소스
