이 게시물에서는 Dockerfile의 세부 사항에 대해 걱정할 필요 없이 컨테이너를 구축하는 여러 가지 방법을 빠르게 보여드리겠습니다.

왜

Docker를 사용하는 파이프라인을 설정한 대부분의 개발자는 자체 Docker 이미지 빌드와 함께 제공되는 세부 정보를 이미 잘 알고 있지만 처음 접하는 사람에게는 이것이 다소 어려울 수 있습니다. 다음과 같이 고려해야 할 사항:

고급 캐싱

보안 관련 모범 사례 적용

가벼운 최종 이미지를 얻기 위한 다단계 설정

기본 이미지를 최신 상태로 유지

이미지 재현성

이 모든 것이 완전히 새로운 경우 컨테이너로 시작하는 가장 좋은 방법은 첫 번째 단계로 Buildpacks를 배우는 것입니다.

뭐

Buildpacks는 2011년에 Heroku에 의해 시작되었으며 현재 공식적으로 Cloud Native Computing Foundation의 일부이며 최근 샌드박스에서 인큐베이션으로 전환되었습니다( see post ). 이를 통해 소스 코드를 기반으로 필요한 빌드 도구를 자동으로 감지하고 코드를 사용 가능한 이미지로 변환할 수 있습니다.

깃랩

Gitlab에는 현재 두 가지 접근 방식이 사용됩니다.

도커 인 도커

Kaniko 빌드 실행기

둘 다 Dockerfile을 시작점으로 사용하는 반면 Kaninko는 도커 데몬을 실행할 필요조차 없습니다. 이것이 컨테이너 구축에서 가장 선호되는(그리고 고급인) 접근 방식인 이유입니다. 아래에서는 Auto DevOps를 시작으로 애플리케이션을 구축하는 다양한 접근 방식을 보여줍니다. 예제 Git 리포지토리fastify-example-buildpacks에서도 이러한 접근 방식을 찾을 수 있습니다.

Auto DevOps가 포함된 빌드팩

Gitlab에서는 "Auto DevOps"와 함께 즉시 빌드팩을 사용할 수 있습니다. "Auto DevOps"는 자동으로 Herokuish 빌드를 기본값으로 사용하여 프로젝트를 빌드하고 Gitlab 레지스트리에 게시합니다. GitLab 에이전트에서 AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED 환경 변수를 사용하여 이를 재정의할 수 있습니다. 이를 통해 Cloud Native Foundation의 일부인 Buildpack을 사용할 수 있습니다. 현재 이것은 Gitlab의 베타 버전이지만 현재 Herokuish 빌드를 대체할 것으로 기대합니다.

include:
  - template: Auto-DevOps.gitlab-ci.yml

variables:
  AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED: 'true'

Pack CLI가 포함된 빌드팩

사용되는 Buildpack을 더 많이 제어하려면 에이전트에 설치해야 하는 Pack CLI를 사용할 수 있습니다. 이는 다음 예제를 통해 쉽게 수행할 수 있습니다.

docker:
  stage: build
  services:
    - docker:19.03.12-dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ''
  image: docker:19.03.12
  before_script:
    - wget https://github.com/buildpacks/pack/releases/download/v0.13.1/pack-v0.13.1-linux.tgz
    - tar xvf pack-v0.13.1-linux.tgz
    - rm pack-v0.13.1-linux.tgz
  script:
    - ./pack build $IMAGE_NAME --builder gcr.io/buildpacks/builder

이는 Google에서 제공하는 빌드팩을 명시적으로 사용합니다. 이에 대한 자세한 내용은 Github에서 확인할 수 있습니다.

Google Cloud Platform을 사용한 빌드팩

이제 앱을 Cloud Run에 직접 배포할 수도 있습니다. 필요한 유일한 명령은 다음과 같습니다.

gcloud beta run deploy --source=[DIRECTORY] [CLOUD_RUN_SERVICE]

단점

사용자 지정 빌드 스크립트는 지원되지 않으므로 예를 들어 애플리케이션이 이미지로 패키지가 되도록 하려면 여전히 TypeScript를 컴파일해야 합니다. 또한 특정 기본 종속성은 처음부터 기본 이미지에서 시작해야 하는 인수가 될 수 있으므로 Buildpack을 사용하는 것이 약간 쓸모 없게 됩니다. 마지막으로 생성되는 이미지는 애플리케이션에 필요하지 않은 다양한 사용 사례를 제공하기 때문에 더 큽니다.

요약

buidpacks로 시작하고 컨테이너를 사용자 지정해야 하는 경우 생성된 기본 이미지를 선택 해제하고 Dockerfile을 사용하여 원하는 대로 완전히 사용자 지정할 수 있습니다.