응용 프로그램을 배포하는 컨테이너 인 것처럼 deb 패키지를 사용하는 데 단점이 있습니까?

우리 팀은 현재 Nodejs 앱을 Docker와 같은 컨테이너에서 실행하는 대신 deb 패키지로 배포해야하는지 결정하려고합니다.

나는이 블로그를 읽고이 생각이있어 여기에 기존의 파이썬 응용 프로그램에 대한 DEB 패키지를 사용하기위한 좋은 인수를합니다. 이 블로그의 주요 요점은 Docker 에코 시스템 (포트 공유, 권한, Docker 이미지 호스팅 등)을 유지하는 문제입니다.

"원래 컨테이너 인 dep-packages"는 포트 충돌에 대한 우려가없고 가상 환경 내에서 모든 종속성이 유지 관리되는 소규모 서비스에 적합합니다.

그러나 내 직감은 deb 패키지가 적합하다면 더 일반적이며 docker는보다 언어 별 솔루션으로 광고 될 것이라고 말합니다. docker와 같은 전체 시스템을 사용하는 대신 deb 패키지와 같은 것을 사용하여 서비스를 배포하는 데 단점이 있습니까?

첫째, Docker 는 때때로 임시 패키징 시스템 으로 여겨지고 사용되지만 실제로는 완전히 다른 문제를 해결합니다. Docker 는 프로그램 실행 에 관한 것 입니다. 도커의 시스템을 설명 할 수 있도록 서비스 가능 스케일링 의지 및 제어 떼 용기를. 데비안 패키지 는 프로그램 설치용이며 소프트웨어 버전 간의 종속성 을 처리 할 수 있습니다. 도커 하강 패키징 시스템으로 자격이없는 것은 확실합니다. 각“패키지”는 하나의 종속성 만 가질 수 있으며 시스템에는“재귀 빌드”옵션이 없으며 복잡한 버전 제약 조건을 지원하지 않습니다!

응용 프로그램 용 데비안 패키지 를 기꺼이 작성하려는 경우 Docker 를 사용 하여 응용 프로그램을 배포 할 수도 있습니다 . 이것은 apt_setup.sh다음과 같은 구성 스크립트 를 사용하여 얻을 수 있습니다

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

그리고 Dockerfile라인을 따라

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(특정 상황에서는 노드 소스 저장소와 apt-transport-https 와 같은 일부 도우미 패키지를 apt_setup.sh추가하여 더 복잡 할 수 있습니다 .)

따라서 데비안 패키지 와 Docker를 동시에 사용할 수 있습니다 .

내 직감 […]은 deb 패키지가 잘 맞으면 더 일반적 일 것이라고 말합니다.

이것은도 커가 왜 임시 패키징 시스템 으로 인기가 있고 왜 독창적이지 않은지 스스로에게 묻게하는 올바른 장애입니다 . (위 참조.)

특정 배포판의 "공식"패키징 시스템은 다른 많은 사람들이 일부 컴퓨팅 환경에 소프트웨어를 설치할 수있는 가능성 일뿐입니다. npm 또는 opam 과 같은 커뮤니티 특정 패키지 관리자 , pkgsrc 와 같은 포트 트리 및 일반 소스 코드 배포와 같은 다른 많은 소스가 있습니다 . 이러한 관점에서 애드혹 패키징 시스템 으로서 Docker 의 성공을 쉽게 이해할 수 있습니다.

• Docker 사양은 쉘 스크립트와 매우 유사하며 소스가 무엇이든 쉘을 사용하여 소프트웨어를 설치합니다.

• Docker 에는 자체 제작 된 아티팩트 인 Docker Hub 를 호스팅하기위한 "내장"(유료) 서비스가 있습니다.

이제 패키지 시스템으로서 Docker 이미지 보다 데비안 패키지 의 장점은 무엇 입니까? 설치시 종속성을 엄격하게 제어합니다. (업그레이드 및 다운 그레이드 가능성도 있지만 불변 서버 패턴을 구현하는 경우 실질적으로 중요하지 않습니다 .)

결론

단일 버전 (SaaS에 일반적인)으로 단일 제품 만 배포 한 경우 버전 관리 요구 사항이 매우 간단하며 애드혹 패키지 관리자 로 Docker 를 사용 하면 큰 결점이 없어야합니다. 단일 제품 또는 여러 제품의 여러 버전으로 작업하자마자, 버전 제약 문제의 복잡성으로 인해 해결해야 할 문제가 커지고 이에 대한 적절한 도구가 필요합니다. 데비안 패키지 또는 일부 구성 관리 시스템 일 수 있습니다. 다른 출처에서 소프트웨어를 혼합.

예, 단점이 있습니다.

.deb 패키지를 사용하면 동일한 호스트에 동일한 응용 프로그램의 두 가지 버전을 가질 수 없습니다. 앱이 nodejs에 의존하는 경우 배포 가능한 패키지에 의존해야합니다. 예를 들어 배포 버전이 고착되어 있거나 직접 설치해야합니다.

이제 동일한 호스트에서 여러 응용 프로그램을 호스팅하려는 경우 두 가지 버전으로 동일한 것에 의존 할 때 매우 빠르게 벽에 부딪 칠 것입니다.

docker의 주요 목표는 각 응용 프로그램을 호스팅 시스템 및 다른 호스트의 동일한 호스트에서 분리하는 것입니다. 이 격리를 수행하는 데는 두 가지 이유가 있습니다. 1. 호스트가 인수하거나 다른 응용 프로그램에 영향을 줄 수있는 앱의 침해를 피하려면 2. 응용 프로그램에 정확한 종속성을 부여하고 시스템 업데이트 또는 다른 응용 프로그램의 영향을받지 않도록합니다. 의존.

응용 프로그램을 설치하기위한 데비안 (또는 RedHat) 패키지는 올바르게 수행하면 좋습니다. 패키지는 자주 변경되지 않는 응용 프로그램을 배포하기 위해 사용됩니다. 데비안 패키지는 버전 관리, 의존성 관리, 설치 전 및 설치 후 스크립트 등과 같은 오버 헤드를 포함합니다.

대부분의 경우 일부 이전 버전에서 새 버전으로 업그레이드하려면 스크립트를주의 깊게 작성하고, 버전 세부 사항에주의를 기울여야합니다. 기존 상태를 변경하는 것은 어렵 기 때문입니다. 현재 상태를 변경하지 않고 새로운 상태로 바꾸는 것이 훨씬 쉽습니다.

오류가 발생하기 쉬우므로 각 배포에서 구성 또는 종속성 또는 응용 프로그램을 완전히 교체하기로 결정한 경우 대부분의 조직 (이전에 사용)은 완전히 새로운 VM 또는 클라우드 인스턴스로 전환합니다. 즉, "클린"서버에서 패키지를 설치하고 서버에서 파일 및 구성을 변경하는 것은 더 이상 문제가되지 않습니다.

패키지를 만들고 돌연변이의 오류와 복잡성을 이해하지 못한 개발자들은 그 결과 많은 어려움을 겪었습니다.

VM 교체는 응용 프로그램을 교체하기 만하면 최적이되지 않으므로 경량 컨테이너가 해답이되었습니다. Docker (또는 다른 LWC)를 사용하면 서버 자체를 교체하지 않고도 모든 종속성을 포함하여 사용자 기반을 교체 할 수 있습니다. 또한 동일한 서버에서 서로 다른 종속성을 가진 동일한 응용 프로그램의 여러 버전을 호스팅하고 업그레이드시 들어오는 네트워크 트래픽 만 전환 할 수 있습니다. 롤백 (청록색)에서 네트워크 트래픽을 다시 전환 할뿐만 아니라 패키지를 통해 배포를 관리하는 경우 매우 어려웠습니다.

컨테이너는 모든 응용 프로그램 코드, 종속성 및 구성을 이미지에 묶는 방법을 소개합니다. 이 이미지에는 기존 운영 체제 패키지보다 훨씬 우수한 여러 속성이 있습니다. 예를 들어, 버전 관리를 활성화하는 태그가 있지만 공간을 절약 할 수있는 레이어도 있습니다. 레지스트리를 사용하여 이러한 이미지를 서버 및 개발 환경으로 쉽게 전달할 수 있습니다. 이러한 이미지는 거의 모든 환경과 서버에서 컨테이너로 실행될 수 있습니다. 여기에는 개발자의 랩톱과 프로덕션 환경이 포함됩니다. 다시 말하지만 VM 및 / 또는 패키지 기반 소프트웨어 버전에서는 훨씬 더 어려운 일입니다. 개발자의 랩톱에서 동일한 이미지를 테스트하고 프로덕션 환경에서 동일한 비트와 바이트를 유지하면 많은 "

컨테이너 런타임이 아닌 Docker의 이미지 패키징 부분에 대해 구체적으로 이야기하면 몇 가지 사소한 비트가 있습니다. 가장 큰 점은 Docker 이미지가 chroot와 비슷하다는 것입니다. 즉, 시스템 패키지가 사용하지 않은 동적 링크를 선택할 수있는 동안 사용중인 모든 파일이 이미지에 명시 적으로 포함되어야하므로 실수로 공유 시스템 상태에 의존하지 못하게됩니다 다른 패키지와 더 많이 얽히거나 기대됩니다. 이것은 OpenSSL과 같은 복잡한 C 종속성이 사용자 모르게로드 될 수 있습니다. 또한 deb 패키지를 사용한다고 Docker의 스토리지 시스템에서 공유 비트를 중복 제거하지 않습니다. 어떤 경우에는 이것이 좋은 일, 더 나은 I / O 성능 및 더 적은 이동 부분 일 수 있지만 다른 경우에는 문제가 될 수 있습니다.