응용 프로그램을 서버에 배포 할 때는 일반적으로 응용 프로그램과 함께 번들로 제공되는 것과 플랫폼 (운영 체제 및 설치된 패키지)에서 제공 할 수있는 것과 분리됩니다. 그 중 하나는 플랫폼을 응용 프로그램과 독립적으로 업데이트 할 수 있다는 것입니다. 예를 들어 전체 응용 프로그램을 다시 작성하지 않고 플랫폼에서 제공하는 패키지에 보안 업데이트를 긴급하게 적용해야하는 경우에 유용합니다.
전통적으로 보안 업데이트는 패키지 관리자 명령을 실행하여 운영 체제에 업데이트 된 버전의 패키지 (예 : RHEL의 "yum update")를 설치하여 간단하게 적용되었습니다. 그러나 컨테이너 이미지가 기본적으로 애플리케이션 과 플랫폼을 모두 번들로 제공하는 Docker와 같은 컨테이너 기술의 출현으로 컨테이너 가있는 시스템을 최신 상태로 유지하는 일반적인 방법은 무엇입니까? 호스트와 컨테이너에는 호스트에서 업데이트 및 업데이트가 필요한 자체의 독립적 인 패키지 세트가 있으므로 컨테이너 내부의 패키지는 업데이트되지 않습니다. Docker 컨테이너가 특히 특징 인 RHEL 7 릴리스에서는 컨테이너의 보안 업데이트를 처리하는 Redhat의 권장 방법이 무엇인지 들어 보는 것이 흥미로울 것입니다.
몇 가지 옵션에 대한 생각 :
- 패키지 관리자가 호스트에서 패키지를 업데이트하게하면 컨테이너 내부의 패키지는 업데이트되지 않습니다.
- 업데이트를 적용하기 위해 모든 컨테이너 이미지를 재생성해야하는 것은 애플리케이션과 플랫폼 사이의 분리를 방해하는 것 같습니다 (플랫폼을 업데이트하려면 Docker 이미지를 생성하는 애플리케이션 빌드 프로세스에 액세스해야합니다).
- 실행중인 각 컨테이너 내에서 수동 명령을 실행하면 번거롭고 다음에 컨테이너가 애플리케이션 릴리스 아티팩트에서 업데이트 될 때 변경 사항을 겹쳐 쓸 위험이 있습니다.
따라서 이러한 접근 방식 중 어느 것도 만족스럽지 않습니다.
1
지금까지 본 가장 좋은 아이디어는 Project Atomic 입니다. 나는 생각하지 않습니다 매우 하지만 황금 시간대에 대 한 준비입니다.
—
마이클 햄튼
Valko, 어떤 워크 플로를 끝냈습니까? 장기 컨테이너 (예 : php-cgi 호스팅)를 실행 중이며 지금까지 찾은
—
miha
docker pull debian/jessie것은 이미지를 업데이트 한 다음 기존 이미지를 다시 작성하고 컨테이너를 중지하고 다시 실행하는 것입니다 ( 새 이미지로). 내가 만든 이미지는 이전 이미지와 이름이 같으므로 시작은 스크립트를 통해 수행됩니다. 그런 다음 "이름이없는"이미지를 제거합니다. 더 나은 워크 플로에 감사드립니다.
miha : 그것은 내가 한 일과 비슷하게 들립니다. 기본적으로 새로운 릴리스의 일부로 모든 이미지를 지속적으로 업데이트하고 다시 작성합니다. 새 이미지를 사용하여 컨테이너를 다시 시작하십시오.
—
Markus Hallmann 10
Johannes Ziemke가 말한 것과 정확히 일치하는 주요 명령 줄이 포함 된 스크립트가 있기 때문에 여기에 가장 좋은 대답 이 많이 도움이됩니다.
—
Hudson Santos
흥미로운 질문입니다. 나 자신이 궁금하다. 하나의 도커 호스트에서 20 개의 응용 프로그램을 실행중인 경우 기본 이미지를 업그레이드하고 다시 빌드하고 다시 시작해야합니다! 20 개의 응용 프로그램을 사용하면 보안 업데이트가 해당 응용 프로그램 모두에 영향을 주 었는지 아니면 그 중 하나에 만 영향을주는지도 알 수 없습니다. 예를 들어 보안 업데이트가 libpng에만 영향을주는 경우 Apache라는 이미지를 다시 작성해야합니다. 따라서 불필요한 재 구축 및 재시작이 가능합니다.
—
Dalibor Filus