OpenShift의 최신 애플리케이션, 2부: 체인 빌드

안녕하세요 여러분! 이는 Red Hat OpenShift에서 최신 웹 애플리케이션을 배포하는 방법을 보여주는 시리즈의 두 번째 게시물입니다.

이전 게시물에서는 OpenShift 플랫폼에서 최신 웹 애플리케이션을 구축하고 배포하도록 설계된 새로운 S2I(소스-이미지) 빌더 이미지의 기능에 대해 약간 다루었습니다. 그런 다음 애플리케이션을 빠르게 배포하는 주제에 관심이 있었고 오늘은 S2I 이미지를 "순수한" 빌더 이미지로 사용하고 이를 관련 OpenShift 어셈블리와 결합하는 방법을 살펴보겠습니다.

클린 빌더 이미지

XNUMX부에서 언급했듯이 대부분의 최신 웹 애플리케이션에는 일반적으로 코드 변환, 다중 파일 연결 및 축소와 같은 작업을 수행하는 소위 빌드 단계가 있습니다. 이러한 작업의 결과로 얻은 파일(정적 HTML, JavaScript 및 CSS)은 출력 폴더에 저장됩니다. 이 폴더의 위치는 일반적으로 사용되는 빌드 도구에 따라 다르며 React의 경우 ./build 폴더가 됩니다(이에 대해서는 아래에서 더 자세히 설명하겠습니다).

소스-이미지(S2I)

이 게시물에서는 "S2I란 무엇이며 어떻게 사용하는가"라는 주제는 다루지 않습니다. 여기에) 그러나 Web App Builder 이미지의 기능을 이해하려면 이 프로세스의 두 단계를 명확하게 이해하는 것이 중요합니다.

조립 단계

조립 단계는 본질적으로 docker build를 실행하고 새로운 Docker 이미지로 끝날 때 발생하는 과정과 매우 유사합니다. 따라서 이 단계는 OpenShift 플랫폼에서 빌드를 시작할 때 발생합니다.

Web App Builder 이미지의 경우 애플리케이션의 종속성을 설치하고 빌드를 실행하는 역할을 담당합니다. 스크립트 조립. 기본적으로 빌더 이미지는 npm run 빌드 구성을 사용하지만 이는 NPM_BUILD 환경 변수를 통해 재정의될 수 있습니다.

앞서 말했듯이 이미 빌드된 완성된 애플리케이션의 위치는 사용하는 도구에 따라 다릅니다. 예를 들어 React의 경우 ./build 폴더가 되고 Angular 애플리케이션의 경우 project_name/dist 폴더가 됩니다. 그리고 이전 게시물에서 이미 보여드린 것처럼 기본적으로 빌드되도록 설정된 출력 디렉터리의 위치는 OUTPUT_DIR 환경 변수를 통해 재정의될 수 있습니다. 출력 폴더의 위치는 프레임워크마다 다르기 때문에 생성된 출력을 이미지의 표준 폴더, 즉 /opt/apt-root/output에 복사하기만 하면 됩니다. 이는 이 기사의 나머지 부분을 이해하는 데 중요하지만 지금은 다음 단계인 실행 단계를 빠르게 살펴보겠습니다.

실행 단계

이 단계는 어셈블리 단계에서 생성된 새 이미지에 대해 docker run이 호출될 때 발생합니다. OpenShift 플랫폼에 배포할 때도 마찬가지입니다. 기본 스크립트 실행 использует 서브 모듈 위의 표준 출력 디렉터리에 있는 정적 콘텐츠를 제공합니다.

이 방법은 애플리케이션을 빠르게 배포하는 데 적합하지만 일반적으로 이 방식으로 정적 콘텐츠를 제공하는 것은 권장되지 않습니다. 실제로는 정적 콘텐츠만 제공하므로 이미지 내부에 Node.js를 설치할 필요가 없습니다. 웹 서버만 있으면 충분합니다.

즉, 조립할 때 한 가지가 필요하고, 실행할 때 다른 것이 필요합니다. 이런 상황에서는 체인으로 연결된 빌드가 유용합니다.

연결된 빌드

이것이 그들이 쓴 내용입니다. 체인 빌드 OpenShift 문서에서:

"두 개의 어셈블리를 함께 연결할 수 있습니다. 하나는 컴파일된 엔터티를 생성하고 다른 하나는 해당 엔터티를 실행하는 데 사용되는 별도의 이미지에서 해당 엔터티를 호스팅합니다."

즉, Web App Builder 이미지를 사용하여 빌드를 실행한 다음 동일한 NGINX인 웹 서버 이미지를 사용하여 콘텐츠를 제공할 수 있습니다.

따라서 Web App Builder 이미지를 "순수한" 빌더로 사용하는 동시에 작은 런타임 이미지를 가질 수 있습니다.

이제 구체적인 예를 들어 이를 살펴보겠습니다.

훈련을 위해 우리는 간단한 리액트 애플리케이션, create-react-app 명령줄 도구를 사용하여 생성되었습니다.

그것은 우리가 모든 것을 하나로 모으는 데 도움이 될 것입니다 OpenShift 템플릿 파일.

이 파일을 더 자세히 살펴보고 매개변수 섹션부터 시작하겠습니다.

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: The source URL for the application
    displayName: Source URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: The branch name for the application
    displayName: Source Branch
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: The location within the source repo of the application
    displayName: Source Directory
    value: .
    required: true
  - name: OUTPUT_DIR
    description: The location of the compiled static files from your web apps builder
    displayName: Output Directory
    value: build
    required: false

여기에 있는 모든 내용은 매우 명확하지만 OUTPUT_DIR 매개변수에 주목할 가치가 있습니다. 우리 예제의 React 애플리케이션의 경우 React는 기본값을 출력 폴더로 사용하므로 걱정할 것이 없지만 Angular 등의 경우 필요에 따라 이 매개변수를 변경해야 합니다.

이제 ImageStreams 섹션을 살펴보겠습니다.

- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-builder  // 1 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-runtime  // 2 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: web-app-builder-runtime // 3
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: nginx-image-runtime // 4
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: 'centos/nginx-112-centos7:latest'

세 번째와 네 번째 이미지를 살펴보세요. 둘 다 Docker 이미지로 정의되어 있으며 해당 이미지의 출처를 명확하게 확인할 수 있습니다.

세 번째 이미지는 web-app-builder이며 8.x 태그가 지정된 nodeshift/ubi2-s10i-web-app에서 가져온 것입니다. 도커 허브.

네 번째는 최신 태그가 있는 NGINX 이미지(버전 1.12)입니다. 도커 허브.

이제 처음 두 이미지를 살펴보겠습니다. 둘 다 시작 시 비어 있으며 빌드 단계에서만 생성됩니다. 첫 번째 이미지인 React-web-app-builder는 web-app-builder-runtime 이미지와 소스 코드를 결합하는 어셈블리 단계의 결과입니다. 이것이 바로 이 이미지 이름에 "-builder"를 추가한 이유입니다.

두 번째 이미지(react-web-app-runtime)는 nginx-image-runtime과 React-web-app-builder 이미지의 일부 파일을 결합한 결과입니다. 이 이미지는 배포 중에도 사용되며 웹 서버와 애플리케이션의 정적 HTML, JavaScript, CSS만 포함합니다.

혼란스러운? 이제 빌드 구성을 살펴보겠습니다. 좀 더 명확해집니다.

우리 템플릿에는 두 가지 빌드 구성이 있습니다. 첫 번째는 다음과 같습니다. 매우 표준적입니다.

  apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-builder
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-builder:latest // 1
    source:   // 2 
      git:
        uri: ${SOURCE_REPOSITORY_URL}
        ref: ${SOURCE_REPOSITORY_REF}
      contextDir: ${SOURCE_REPOSITORY_DIR}
      type: Git
    strategy:
      sourceStrategy:
        env:
          - name: OUTPUT_DIR // 3 
            value: ${OUTPUT_DIR}
        from:
          kind: ImageStreamTag
          name: web-app-builder-runtime:latest // 4
        incremental: true // 5
      type: Source
    triggers: // 6
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - imageChange: {}
      type: ImageChange

보시다시피, 레이블 1이 있는 줄은 이 빌드의 결과가 이전에 ImageStreams 섹션에서 본 것과 동일한 React-web-app-builder 이미지에 배치될 것임을 나타냅니다.

2로 표시된 줄은 코드를 어디서 얻을 수 있는지 알려줍니다. 우리의 경우 이는 git 저장소이며 위치, 참조 및 컨텍스트 폴더는 위에서 이미 본 매개변수에 의해 결정됩니다.

3으로 표시된 줄은 매개변수 섹션에서 이미 본 것입니다. 이 예제에서는 build라는 OUTPUT_DIR 환경 변수를 추가합니다.
4라고 표시된 줄은 ImageStream 섹션에서 이미 본 web-app-builder-runtime 이미지를 사용하라는 의미입니다.

5번 줄은 S2I 이미지가 지원하고 Web App Builder 이미지가 지원하는 경우 증분 빌드를 사용하겠다는 의미입니다. 처음 실행 시 조립 단계를 완료한 후 이미지는 node_modules 폴더를 아카이브 파일에 저장합니다. 그런 다음 후속 실행 시 이미지는 이 폴더의 압축을 풀어 빌드 시간을 줄입니다.

마지막으로 6으로 표시된 줄은 무언가 변경될 때 수동 개입 없이 빌드가 자동으로 실행되도록 하는 몇 가지 트리거일 뿐입니다.

전반적으로 이것은 꽤 표준적인 빌드 구성입니다.

이제 두 번째 빌드 구성을 살펴보겠습니다. 첫 번째 것과 매우 유사하지만 한 가지 중요한 차이점이 있습니다.

apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-runtime
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-runtime:latest // 1
    source: // 2
      type: Image
      images:                              
        - from:
            kind: ImageStreamTag
            name: react-web-app-builder:latest // 3
          paths:
            - sourcePath: /opt/app-root/output/.  // 4
              destinationDir: .  // 5
             
    strategy: // 6
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: nginx-image-runtime:latest
        incremental: true
      type: Source
    triggers:
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - type: ImageChange
      imageChange: {}
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: react-web-app-builder:latest // 7

따라서 두 번째 빌드 구성은 React-web-app-runtime이며 매우 표준적으로 시작됩니다.

1로 표시된 줄은 새로운 것이 아닙니다. 단순히 빌드 결과가 반응 웹 앱 런타임 이미지에 저장된다는 의미입니다.

이전 구성에서와 같이 2로 표시된 줄은 소스 코드를 가져올 위치를 나타냅니다. 그러나 여기서는 이미지에서 가져온 것이라고 말하고 있습니다. 또한, 우리가 방금 생성한 이미지에서 - React-web-app-builder(3으로 표시된 줄에 표시됨)에서. 사용하려는 파일은 이미지 내부에 있으며 그 위치는 4번 줄에 설정되어 있습니다. 이 경우에는 /opt/app-root/output/입니다. 기억하신다면 여기에 애플리케이션 구축 결과를 기반으로 생성된 파일이 저장되는 곳입니다.

레이블 5가 있는 용어에 지정된 대상 폴더는 단순히 현재 디렉터리입니다(이 디렉터리는 모두 로컬 컴퓨터가 아닌 OpenShift라는 마법 같은 것 내에서 실행된다는 점을 기억하세요).

전략 섹션(6번 줄)도 첫 번째 빌드 구성과 유사합니다. 이번에는 ImageStream 섹션에서 이미 본 nginx-image-runtime을 사용하겠습니다.

마지막으로, 7번 줄은 React-web-app-builder 이미지가 변경될 때마다 이 빌드를 활성화하는 트리거 섹션입니다.

그렇지 않으면 이 템플릿에는 꽤 표준적인 배포 구성과 서비스 및 경로와 관련된 사항이 포함되어 있지만 너무 자세히 설명하지는 않겠습니다. 배포될 이미지는 React-web-app-runtime 이미지입니다.

애플리케이션 배포

이제 템플릿을 살펴보았으므로 이를 사용하여 애플리케이션을 배포하는 방법을 살펴보겠습니다.

oc라는 OpenShift 클라이언트 도구를 사용하여 템플릿을 배포할 수 있습니다.

$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app

위 스크린샷의 첫 번째 명령은 template./openshiftio/application.yaml을 찾기 위한 의도적인 엔지니어링 방법입니다.

두 번째 명령은 이 템플릿을 기반으로 새 애플리케이션을 생성합니다.

이러한 명령이 작동하면 두 개의 어셈블리가 있음을 알 수 있습니다.

개요 화면으로 돌아가면 실행된 포드가 표시됩니다.

링크를 클릭하면 기본 React 앱 페이지인 앱으로 이동합니다.

보충 1

Angular 애호가들을 위해 우리는 또한 예제 애플리케이션.

OUTPUT_DIR 변수를 제외하고 여기의 패턴은 동일합니다.

보충 2

이 기사에서는 NGINX를 웹 서버로 사용했지만 이를 Apache로 교체하는 것은 매우 쉽습니다. 파일에서 템플릿을 변경하기만 하면 됩니다. NGINX 이미지 에 아파치 이미지.

결론

이 시리즈의 첫 번째 부분에서는 OpenShift 플랫폼에 최신 웹 애플리케이션을 신속하게 배포하는 방법을 보여주었습니다. 오늘 우리는 웹 앱 이미지의 기능과 체인 빌드를 사용하여 웹 앱 이미지를 NGINX와 같은 순수 웹 서버와 결합하여 보다 생산 준비가 된 애플리케이션 빌드를 만드는 방법을 살펴보았습니다. 이 시리즈의 다음 기사이자 마지막 기사에서는 OpenShift에서 애플리케이션용 개발 서버를 실행하고 로컬 및 원격 파일의 동기화를 보장하는 방법을 보여 드리겠습니다.

이 기사 시리즈의 내용

• 파트 1 : 단 몇 단계만으로 최신 웹 애플리케이션을 배포하는 방법;
• 2부: 프로덕션 배포를 위해 연결된 OpenShift 어셈블리를 사용하여 NGINX와 같은 기존 HTTP 서버 이미지와 함께 새 S2I 이미지를 사용하는 방법
• 3부: OpenShift 플랫폼에서 애플리케이션용 개발 서버를 실행하고 이를 로컬 파일 시스템과 동기화하는 방법.

추가 리소스

• 무료 전자책 OpenShift에 배포.
• 에 관한 정보 오픈시프트와 쿠버네티스.

출처 : habr.com