8.10.4. 연결 빌드

애플리케이션 이미지에서 컴파일하는 데 필요한 종속 항목을 포함하여 컴파일된 언어(Go, C, C++, Java 등)의 경우 이미지의 크기가 늘어나거나 악용될 수 있는 취약점이 발생할 수 있습니다.

이러한 문제를 방지하려면 두 개의 빌드를 함께 연결할 수 있습니다. 하나는 컴파일된 아티팩트를 생성하는 빌드와 아티팩트를 실행하는 별도의 이미지에 아티팩트를 배치하는 두 번째 빌드입니다. 다음 예에서 S2I( Source-to-Image ) 빌드는 Docker 빌드와 결합하여 아티팩트를 컴파일한 다음 별도의 런타임 이미지에 배치됩니다.

첫 번째 빌드는 애플리케이션 소스를 가져와서 WAR 파일이 포함된 이미지를 생성합니다. 이미지는 artifact-image 이미지 스트림으로 푸쉬합니다. 출력 아티팩트의 경로는 사용된 S2I(Source-to-Image) 빌더의 assemble 스크립트에 따라 달라집니다. 이 경우 /wildfly/standalone/deployments/ROOT.war 로 출력됩니다.

apiVersion: v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
    type: Git
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift
    type: Source

두 번째 빌드에서는 Image Source 를 사용하여 첫 번째 빌드의 출력 이미지 내부의 WAR 파일에 대한 경로를 사용합니다. 인라인 Dockerfile 은 해당 WAR 파일을 런타임 이미지에 복사합니다.

apiVersion: v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    type: Dockerfile
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from: 1
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 2
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 3
        kind: ImageStreamTag
        name: jee-runtime:latest
    type: Docker
  triggers:
  - imageChange: {}
    type: ImageChange

이 설정의 결과는 두 번째 빌드의 출력 이미지에 WAR 파일을 생성하는 데 필요한 빌드 툴을 포함할 필요가 없다는 것입니다. 또한 두 번째 빌드에 이미지 변경 트리거 가 포함되어 있기 때문에 첫 번째 빌드가 실행되고 바이너리 아티팩트가 포함된 새 이미지를 생성할 때마다 두 번째 빌드가 자동으로 트리거되어 해당 아티팩트가 포함된 런타임 이미지를 생성합니다. 따라서 두 빌드 모두 두 단계가 있는 단일 빌드로 작동합니다.