Docker가 사용 사례에 적합합니까?

우리 회사는 기본적으로 Ubuntu 12.04를 실행하는 미니 컴퓨터 "Smartbox"로 구성된 시스템을 판매합니다. 이 상자는 Django 응용 프로그램과 그와 관련된 여러 가지 다른 시작 프로세스를 실행합니다. 그다지 많지 않습니다. 우리는이 상자들을 수천 개 가지고 있습니다. 다양한 정도의 성공을 거둔 deb 패키지를 통해 패키지 종속성, 프로세스 등록 등을 관리합니다.

우리는 현장에서 사용자에게 효율적이고 강력하게 업데이트를 제공 할 수있는 방법이 필요합니다. 우리는 또한 OS를 업그레이드 할 때 (우리가 알 수 있듯이 우분투 업그레이드가 기한이 지났음) 패키지가 "정상 작동"한다고 상대적으로 안전하다고 느낄 수있는 것이 필요합니다.

Docker에 대해서는 많이 알지 못하지만 처음 문제에 대해 들었을 때 Docker가 처음으로 생각되었습니다. 그러나 내가 그것에 대해 더 많이 생각했을 때 나는 그렇지 않다고 느꼈습니다.이 상자는 우리 상자이기 때문에 Docker의 가치 제안의 큰 부분 인 OS를 제어합니다. 따라서 우리 상자가 항상 우분투가 될 것이라는 것을 알고 기본적으로 Django 앱과 실행할 프로세스가 있으면 Docker가 deb 패키지보다 낫습니까?

TL; DR : Ubuntu를 항상 실행하는 플랫폼에 대한 Docker vs deb 패키지는 플랫폼 독립성이 그렇게 중요하지 않습니다.

100 % 확신하지는 못하지만 Docker 솔루션은 OS가있는 (물리적입니까?) 어플라이언스가 있고 앱이 설치되어 있고 OS가있는 어플라이언스가있는 것 같습니다. Docker가 있고 앱이있는 단일 컨테이너를 실행합니다. 그것은 호스트에서 OS를 업데이트 할 필요가 없으며, 쉽게 피할 수 없는 이점 으로 복잡성 계층을 추가합니다 (그리고 Docker 와 OS 를 계속 패치 해야하므로 더 많은 업데이트가 필요합니다 ) 질문에 언급 된 특정 영역에 관한 한.

그러나 가상 어플라이언스에서 Docker 컨테이너로 전환하려는 경우 잠재적으로 문제를 해결할 수 있지만 Docker를 제품의 종속성으로 추가합니다. Docker를 사용하지 않는 사람을 종료하고 제품을 사용하기 위해 Docker를 스택에 추가하고 싶지 않습니다. 이전과 같이 (현재 "레거시") 가상 어플라이언스를 계속 제공하여 Docker를 사용하지 않거나 사용하지 않는 대상을 계속 지원할 수 있지만 이제는 대신 두 개의 배포가 있기 때문에 작업량을 두 배로 늘 렸습니다. 하나.

Docker와 오랫동안 일했습니다. 플랫폼 독립성은 좋지만 Docker에서 가장 유용하다고 생각하는 것은 아닙니다.

우선, 반복성을 얻습니다. Dockerfile을 작성하고, 개발자 시스템의 컨테이너에서 디버그하고, 연속 통합 서버에서 테스트를 실행 한 다음 최종 제품에서 테스트를 수행하면 모든 환경에서 동일하게 작동 함을 알 수 있습니다. 개발자가 자신의 컴퓨터에 설치 한 종속성을 잊지 마십시오. 또한 개발자는 책상에서 Ubuntu를 사용할 필요가 없습니다. 우리에게 아치 리눅스 사용자를 행복하게 유지하는 것이 중요합니다 :-)

둘째, 업그레이드 시나리오의 경우 한 번에 여러 버전을 머신으로 가져올 수 있습니다. 당신이 할 경우 docker pull myapp:2.0동안이 1.0실행되고, 당신은에 교체 할 수 있습니다 2.0매우 빠르게. 전체 OS 업그레이드를 수행하는 것보다 훨씬 빠릅니다. 여러 마이크로 서비스 인스턴스가있는 오케 스트레이터를 사용하는 경우 서비스를 전혀 방해하지 않는 롤링 업그레이드를 수행 할 수도 있습니다.

마이크로 서비스 모델을 사용하는 경우 Docker는 공격시 공격자가 악용 할 경우 수행 할 수있는 피해량을 제한 할 수있는 샌드 박스도 제공합니다. 전체 기계를 제어하는 ​​대신 하나의 컨테이너 만 제어 할 수 있습니다.

주요 단점은 호스트 OS와 일종의 오케스트레이션이 필요하다는 것입니다. 여기에는 많은 선택이 있지만, 평가하고, 제자리에 놓고, 유지하는 데 드는 작업량을 과소 평가하지 마십시오.

큰 도커는 개발자와 운영 직원 모두에게 많은 이점을 제공합니다. 일부 응용 프로그램에 도커를 사용하고 매우 안정적이고 강력한 접근 방식입니다.

도커를 입양 할 때의 문제는 올바른 질문을하는 소리가 들리지 않으며 가장 중요한 요구 사항을 해결하지 않고 인생을 더 복잡하게 만들 수 있다는 것입니다.

당신이 물어봐야 할 첫 번째 질문은 (당신이 처음이라고 말한) OS 및 응용 프로그램의 업데이트는 어떻게 처리됩니까? 현재 방법론이 귀하 (회사)에게 효과적입니까? 무엇이 잘 작동합니까? 무엇을 개선 할 수 있습니까? 현장의 대상 컴퓨터에서 물리적 구성 감사를 수행하여 올바른 OS 패치, 응용 프로그램 및 무단 변경이 있는지 확인하십시오.

나는 도커를 좋아하지만, 현재 잘 작동하고 개선해야 할 부분을 포함하여 현재 위치를 평가하지 않고 도커 악 대차에 뛰어 들지 않을 것입니다.

Docker와 Debian 패키징 시스템은 겹치는 영역이 작지만 본질적으로 두 가지 매우 다른 문제를 해결합니다 .

• 데비안 패키징 시스템은 호스트에 소프트웨어를 설치하고 가능한 한 쉽게 업그레이드 할 수 있도록 만들어졌습니다. "소프트웨어 X 버전 A에는 버전 B 이상의 소프트웨어 Y가 필요합니다"또는 "소프트웨어 X는 소프트웨어 Z 버전 C와 함께 설치해서는 안됩니다"와 같은 소프트웨어 구성 요소 간의 복잡한 종속성 및 제약 조건 패턴을 처리 할 수 ​​있습니다.

• Docker 시스템은 여러 호스트 (예 : Docker swarm 또는 Kubernetes 클러스터)에서 서비스, 특히 마이크로 서비스를 쉽게 설명하고 배포하기 위해 고안되었습니다.

이 두 가지 문제는 본질적으로 직교 적이므로 해결해야 할 배포 문제가 주어지면 솔루션의 일부로 둘 중 하나를 사용하거나 전혀 사용하지 않을 수 있습니다. 둘 다 사용할 때, 데비안 패키지는 Docker 이미지 제작에 사용되며 Dockerfile (컨테이너에서 실행 된 "가상 시스템"을 설명하는 Docker 이미지를 준비하는 데 사용되는 레시피)은 기본적으로 데비안 저장소를 데비안 패키징 시스템의 소스와 패키지를 설치하십시오.

이것을 염두에두고, 당신이 정말로 찾고있는 것은 불변의 서버 패턴 을 구현하는 것 같습니다.. 클라우드 기술의 최근 개발로 소프트웨어 패키지 시스템 (데비안 패키징 시스템 등)의 기존 소프트웨어 업그레이드 시스템을 사용하는 것이 아니라 전체 서버를 한 번에 간단히 교체하여 소프트웨어를 업그레이드 할 수있었습니다. (일부 사람들은이 개발 이전에 서버에 3 개의 OS가 있고, 2 개는 어플라이언스를 실행하는 데 사용되며 2 개는 어플라이언스 교체를 수행하는 데 사용되는 미니 OS입니다. 지나치게 복잡하지는 않지만 항상 틈새.) 패키지 관리자를 사용하여 서버에서 소프트웨어를 업그레이드하는 데 익숙한 경우 서버의 최종 상태는 서버의 "업그레이드 기록"에 따라 달라집니다. 특히 오류가 발생하는 경우 업그레이드 과정. 이 이질성은 나쁘고

우리는이 상자들을 수천 개 가지고 있습니다. 다양한 정도의 성공을 거둔 deb 패키지를 통해 패키지 종속성, 프로세스 등록 등을 관리합니다.

이것과 관련이 있습니다. 변경 불가능한 서버 패턴은 문제에서 "업그레이드 기록"개념을 본질적으로 파괴하여이 오류의 원인을 제거합니다.

불변의 서버 패턴을 구현하는 다양한 옵션이 있습니다. 두 가지 인기있는 선택은 Docker 이미지, 이미지 또는 클라우드 공급자의 "마스터 인스턴스 이미지"를 사용하는 것입니다 (AWS에서는 AMI, Google Compute Engine에서는 사용자 지정 이미지라고 함). . 유스 케이스는 클라우드 기반 기술의 사용을 금지하므로 Docker 이미지가 유일하게 적합한 것으로 가정합니다. (완료를 위해 Docker의 대안으로 Virtual Box 또는 유사한 가상화 솔루션을 사용하는 것과 같은 다른 접근법을 사용하는 것이 가능합니다.)

변경 불가능한 서버 패턴 기술을 사용하는 경우 서버를 나타내는 새로운 아티팩트 (Docker 이미지)를 소개하며이 아티팩트도 테스트 할 수 있으며 서비스로드 외에 프로덕션 설정을 그대로 복제하는 설정을 얻는 것이 매우 쉽습니다.

지금까지 설명한 구체적인 문제를 고려하기 위해 Docker로 불변 서버 패턴을 구현하는 것이 실제로 원하는 것으로 가정 해 봅시다. Docker 시스템과 데비안 패키징 시스템은 상호 배타적이지 않고 보완 적이므로 (참조. 소개) 소프트웨어 용 데비안 패키지를 준비해야한다면 여전히 문제를 해결해야합니다.

Docker 이미지 또는 호스트에 데비안 패키지를 사용하여 소프트웨어를 설치하는 것은 해결해야하는 버전 관리 문제의 복잡성에 있습니다. 동시에 여러 버전의 소프트웨어를 실행하는 경우 가끔 다운 그레이드해야하며 신중하게 문서화해야하는 복잡한 버전 요구 사항이있는 경우 데비안 패키지가 반드시 필요합니다. 그렇지 않으면이 단계를 건너 뛸 수 있지만 이미 이러한 패키지를 제작 및 배포하려고 노력했기 때문에 작업을 포기하는 데 실질적인 가치는 없습니다. 따라서 데비안 꾸러미를 계속 제작 해 보시기 바랍니다.

좋은 옵션 일 수 있다고 생각합니다 (추가 테스트가 필요합니다)

컨테이너의 모든 태그 / 버전이 포함 된 URL을 제공 할 수 있으며 클라이언트는 해당 URL을 읽고 새 버전의 컨테이너가 있는지 확인합니다.

개인 파일 / 설정을 로컬에 저장할 수 있으며 업그레이드시 해당 정보를 잃어 버릴 염려가 없으며, 만들고 테스트 한 내용이 모두 같은 방식으로 작동하도록 보장 할 수 있습니다.

심지어 사용자에게 사용 가능한 버전 중 원하는 버전을 선택할 수있는 가능성을 제공 할 수도 있습니다 (가능한 경우).

""하나의 패키지 만 업그레이드 ""와 같이 컨테이너의 새 버전 만 검색하는 것에 대해 이야기 할 것입니다. 데비안 패키지를 다루는 것보다 훨씬 좋습니다.)

Docker는 나에게 합리적으로 들립니다. 집에서 컨테이너를 변경하고 테스트 한 다음 릴리스 프로세스에 따라 컨테이너를 항상 다시 시작하십시오.

컨테이너가 다시 시작할 때 변경 사항을 유지하지 않으므로 데이터 볼륨을 원하므로 데이터 저장소를 고려해야합니다. 당신이 그것을 파고 나면 더 많은 고려 사항이있을 것입니다. 현재 작업중 인 시스템 (모든 도커 기반)은 1 년 이상 개발되어 왔으며 컨테이너, 구성 등을 변경 해야하는 영역을 여전히 찾고 있습니다.