컨테이너 내에서 Buildah를 실행하기 위한 지침

컨테이너 런타임을 별도의 도구 구성 요소로 분리하면 어떤 이점이 있나요? 특히 이러한 도구는 서로를 보호하기 위해 결합되기 시작할 수 있습니다.

많은 사람들이 컨테이너화된 OCI 이미지를 구축한다는 아이디어에 매력을 느낍니다. Kubernetes 또는 이와 유사한 시스템. 지속적으로 이미지를 수집하는 CI/CD가 있다고 가정해 보겠습니다. Red Hat OpenShift/Kubernetes는 빌드 중 로드 밸런싱 측면에서 매우 유용합니다. 최근까지 대부분의 사람들은 단순히 컨테이너에 Docker 소켓에 대한 액세스 권한을 부여하고 docker build 명령을 실행할 수 있도록 허용했습니다. 몇 년 전에 우리는 보여줬어요이는 매우 안전하지 않으며 실제로 비밀번호 없는 루트나 sudo를 제공하는 것보다 더 나쁩니다.

그렇기 때문에 사람들은 지속적으로 Buildah를 컨테이너에서 실행하려고 합니다. 간단히 말해서 우리는 만들었습니다. 예 우리 의견으로는 Buildah를 컨테이너 내에서 실행하고 해당 이미지를 게시하는 것이 가장 좋은 방법입니다. quay.io/buildah. 시작하자...

조정

이러한 이미지는 Dockerfiles에서 빌드되었으며 Buildah 저장소의 폴더에 있습니다. 빌드이미지.
여기서 우리는 살펴볼 것입니다 Dockerfile의 안정적인 버전.

# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest

# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf

호스트 Linux 커널 수준에서 구현된 OverlayFS 대신 컨테이너 내부의 프로그램을 사용합니다. 퓨즈 오버레이, 현재 OverlayFS는 Linux 기능을 사용하여 SYS_ADMIN 권한을 부여한 경우에만 마운트할 수 있기 때문입니다. 그리고 우리는 루트 권한 없이 Buildah 컨테이너를 실행하고 싶습니다. 퓨즈 오버레이는 매우 빠르게 작동하며 VFS 스토리지 드라이버보다 성능이 더 좋습니다. Fuse를 사용하는 Buildah 컨테이너를 실행할 때 /dev/fuse 장치를 제공해야 합니다.

podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

다음으로 추가 저장을 위한 디렉터리를 만듭니다. 컨테이너/저장 추가 읽기 전용 이미지 저장소를 연결하는 개념을 지원합니다. 예를 들어, 한 머신에서 오버레이 스토리지 영역을 구성한 다음 NFS를 사용하여 이 스토리지를 다른 머신에 마운트하고 풀을 통해 다운로드하지 않고도 해당 스토리지의 이미지를 사용할 수 있습니다. 호스트의 일부 이미지 스토리지를 볼륨으로 연결하고 컨테이너 내부에서 사용하려면 이 스토리지가 필요합니다.

# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot

마지막으로 BUILDAH_ISOLATION 환경 변수를 사용하여 Buildah 컨테이너가 기본적으로 chroot 격리로 실행되도록 지시합니다. 우리는 이미 컨테이너에서 작업하고 있으므로 여기서는 추가 단열이 필요하지 않습니다. Buildah가 네임스페이스로 구분된 자체 컨테이너를 생성하려면 SYS_ADMIN 권한이 필요합니다. 이를 위해서는 컨테이너의 SELinux 및 SECCOMP 규칙을 완화해야 하며, 이는 보안 컨테이너에서 빌드하려는 우리의 선호 사항에 반합니다.

컨테이너 내에서 Buildah 실행

위에서 설명한 Buildah 컨테이너 이미지 다이어그램을 사용하면 이러한 컨테이너를 시작하는 방법을 유연하게 변경할 수 있습니다.

속도 대 안전

컴퓨터 보안은 항상 프로세스 속도와 이를 둘러싼 보호 수준 사이의 절충안입니다. 이 진술은 컨테이너를 조립할 때도 마찬가지이므로 아래에서는 그러한 타협에 대한 옵션을 고려할 것입니다.

위에서 설명한 컨테이너 이미지는 /var/lib/containers에 저장 공간을 유지합니다. 따라서 콘텐츠를 이 폴더에 마운트해야 하며 이를 수행하는 방법은 컨테이너 이미지 빌드 속도에 큰 영향을 미칩니다.

세 가지 옵션을 고려해 봅시다.

1 옵션을 선택합니다. 최대 보안이 필요한 경우 각 컨테이너에 대해 컨테이너/이미지에 대한 자체 폴더를 만들고 볼륨 마운트를 통해 컨테이너에 연결할 수 있습니다. 게다가 컨테이너 자체의 /build 폴더에 컨텍스트 디렉터리를 배치합니다.

# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah  -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah  push  image1 registry.company.com/myuser
# rm -rf /var/lib/containers1

보안. 이러한 컨테이너에서 실행되는 Buildah는 최대 보안을 갖습니다: 기능을 사용하는 루트 권한이 부여되지 않으며 모든 SECOMP 및 SELinux 제한 사항이 적용됩니다. 이러한 컨테이너는 —uidmap 0과 같은 옵션을 추가하여 사용자 네임스페이스 격리를 사용하여 실행할 수도 있습니다. 100000:10000.

성능. 그러나 컨테이너 레지스트리의 모든 이미지가 매번 호스트에 복사되고 캐싱이 전혀 작동하지 않기 때문에 여기서 성능은 최소화됩니다. 작업이 완료되면 Buildah 컨테이너는 이미지를 레지스트리로 보내고 호스트의 콘텐츠를 삭제해야 합니다. 다음에 컨테이너 이미지가 빌드되면 호스트에 아무것도 남지 않으므로 레지스트리에서 다시 다운로드해야 합니다.

2 옵션을 선택합니다. Docker 수준 성능이 필요한 경우 호스트 컨테이너/스토리지를 컨테이너에 직접 마운트할 수 있습니다.

# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah  -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled  quay.io/buildah/stable buildah push image2 registry.company.com/myuser

보안. 이는 컨테이너가 호스트의 스토리지를 수정할 수 있게 하고 잠재적으로 Podman 또는 CRI-O에 악성 이미지를 제공할 수 있기 때문에 컨테이너를 구축하는 가장 안전하지 않은 방법입니다. 또한 Buildah 컨테이너의 프로세스가 호스트의 스토리지와 상호 작용할 수 있도록 SELinux 분리를 비활성화해야 합니다. 이 옵션은 컨테이너가 나머지 보안 기능에 의해 잠겨 있고 단순히 호스트에서 컨테이너를 실행할 수 없기 때문에 Docker 소켓보다 여전히 좋습니다.

성능. 캐싱이 완전히 사용되므로 여기서는 최대값입니다. Podman 또는 CRI-O가 이미 호스트에 필요한 이미지를 다운로드한 경우 컨테이너 내부의 Buildah 프로세스는 이를 다시 다운로드할 필요가 없으며 이 이미지를 기반으로 하는 후속 빌드도 캐시에서 필요한 것을 가져올 수 있습니다. .

3 옵션을 선택합니다. 이 방법의 핵심은 여러 이미지를 컨테이너 이미지용 공통 폴더를 사용하여 하나의 프로젝트로 결합하는 것입니다.

# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z 
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah  -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200 
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3  registry.company.com/myuser

이 예에서는 실행 사이에 프로젝트 폴더(/var/lib/project3)를 삭제하지 않으므로 프로젝트 내의 모든 후속 빌드는 캐싱의 이점을 얻습니다.

보안. 옵션 1과 2 사이에 있습니다. 한편으로 컨테이너는 호스트의 콘텐츠에 액세스할 수 없으므로 Podman/CRI-O 이미지 스토리지에 잘못된 내용을 넣을 수 없습니다. 반면, 디자인의 일부로 컨테이너가 다른 컨테이너의 조립을 방해할 수 있습니다.

성능. Podman/CRI-O를 사용하여 이미 다운로드한 이미지를 사용할 수 없기 때문에 호스트 수준에서 공유 캐시를 사용할 때보다 상황이 더 나쁩니다. 그러나 Buildah가 이미지를 다운로드하면 해당 이미지는 프로젝트 내의 모든 후속 빌드에서 사용될 수 있습니다.

추가 저장용량

У 컨테이너/스토리지 컨테이너를 시작하고 구축할 때 컨테이너 엔진이 읽기 전용 오버레이 모드에서 외부 이미지 저장소를 사용할 수 있는 추가 저장소(추가 저장소)와 같은 멋진 기능이 있습니다. 기본적으로 Storage.conf 파일에 하나 이상의 읽기 전용 스토리지를 추가하면 컨테이너를 시작할 때 컨테이너 엔진이 해당 스토리지에서 원하는 이미지를 찾을 수 있습니다. 또한 이러한 저장소에서 이미지를 찾을 수 없는 경우에만 레지스트리에서 이미지를 다운로드합니다. 컨테이너 엔진은 쓰기 가능한 스토리지에만 쓸 수 있습니다.

위로 스크롤하여 quay.io/buildah/stable 이미지를 빌드하는 데 사용하는 Dockerfile을 보면 다음과 같은 줄이 있습니다.

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

첫 번째 줄에서는 컨테이너 이미지 내에서 /etc/containers/storage.conf를 수정하여 스토리지 드라이버가 /var/lib/shared 폴더에 있는 "additionalimagestores"를 사용하도록 지시합니다. 그리고 다음 줄에서는 컨테이너/스토리지의 남용이 없도록 공유 폴더를 만들고 몇 개의 잠금 파일을 추가합니다. 기본적으로 우리는 단순히 빈 컨테이너 이미지 저장소를 만드는 것입니다.

이 폴더보다 높은 레벨에 컨테이너/스토리지를 마운트하면 Buildah가 해당 이미지를 사용할 수 있습니다.

이제 위에서 설명한 옵션 2로 돌아가 보겠습니다. Buildah 컨테이너는 호스트의 컨테이너/저장소를 읽고 쓸 수 있으며 그에 따라 Podman/CRI-O 수준의 이미지 캐싱으로 인해 최대 성능을 가지지만 최소한의 보안을 제공합니다. 스토리지에 직접 쓸 수 있기 때문입니다. 이제 여기에 추가 스토리지를 추가하고 두 가지 장점을 모두 활용해 보겠습니다.

# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v  /var/lib/containers4:/var/lib/containers:Z  quay.io/buildah/stable 
 buildah  -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro  
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4  registry.company.com/myuser
# rm -rf /var/lib/continers4

호스트의 /var/lib/containers/storage는 읽기 전용 모드로 컨테이너 내부의 /var/lib/shared에 마운트됩니다. 따라서 컨테이너에서 작업하는 Buildah는 이전에 Podman/CRI-O를 사용하여 다운로드한 모든 이미지를 사용할 수 있지만(hello, 속도) 자체 스토리지(hello, 보안)에만 쓸 수 있습니다. 또한 이는 컨테이너에 대한 SELinux 분리를 비활성화하지 않고 수행된다는 점에 유의하세요.

중요한 뉘앙스

어떠한 경우에도 기본 저장소에서 이미지를 삭제해서는 안 됩니다. 그렇지 않으면 Buildah 컨테이너가 충돌할 수 있습니다.

그리고 이것이 모든 장점은 아닙니다

추가 스토리지의 가능성은 위의 시나리오에만 국한되지 않습니다. 예를 들어 모든 컨테이너 이미지를 공유 네트워크 스토리지에 배치하고 모든 Buildah 컨테이너에 이에 대한 액세스 권한을 부여할 수 있습니다. CI/CD 시스템이 컨테이너 이미지를 구축하기 위해 정기적으로 사용하는 수백 개의 이미지가 있다고 가정해 보겠습니다. 우리는 이러한 모든 이미지를 하나의 스토리지 호스트에 집중시킨 다음 선호하는 네트워크 스토리지 도구(NFS, Gluster, Ceph, ISCSI, S3...)를 사용하여 모든 Buildah 또는 Kubernetes 노드에 이 스토리지에 대한 일반 액세스를 제공합니다.

이제 이 네트워크 스토리지를 /var/lib/shared의 Buildah 컨테이너에 마운트하는 것으로 충분합니다. 그게 전부입니다. Buildah 컨테이너는 더 이상 풀을 통해 이미지를 다운로드할 필요가 없습니다. 따라서 우리는 사전 채우기 단계를 버리고 즉시 컨테이너를 출시할 준비가 되었습니다.

물론 라이브 Kubernetes 시스템이나 컨테이너 인프라 내에서 이미지를 풀 다운로드하지 않고도 어디서나 컨테이너를 시작하고 실행할 수 있습니다. 또한 업데이트된 이미지를 업로드하라는 푸시 요청을 수신한 컨테이너 레지스트리는 이 이미지를 공유 네트워크 스토리지에 자동으로 보낼 수 있으며, 여기에서 즉시 모든 노드에서 사용할 수 있게 됩니다.

컨테이너 이미지 크기가 수 기가바이트에 달하는 경우도 있습니다. 추가 스토리지 기능을 사용하면 노드 전체에서 이러한 이미지를 복제하는 것을 방지하고 컨테이너를 거의 즉각적으로 시작할 수 있습니다.

또한 현재 오버레이 볼륨 마운트라는 새로운 기능을 개발 중입니다. 이를 통해 컨테이너 구축 속도가 더욱 빨라집니다.

결론

Kubernetes/CRI-O, Podman 또는 Docker의 컨테이너 내에서 Buildah를 실행하는 것은 docker.socket을 사용하는 것보다 실행 가능하고 간단하며 훨씬 더 안전합니다. 이미지 작업의 유연성이 크게 향상되었으므로 다양한 방법으로 이미지를 실행하여 보안과 성능 간의 균형을 최적화할 수 있습니다.

추가 스토리지 기능을 사용하면 이미지를 노드로 다운로드하는 속도를 높이거나 완전히 제거할 수 있습니다.

출처 : habr.com