Docker: Up & Running, 제3판

9장. 프로덕션 컨테이너로 가는 길

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이제 단일 호스트에서 컨테이너 스택을 불러오는 도구를 살펴봤으니, 대규모 프로덕션 환경에서 이 작업을 수행하는 방법을 살펴볼 필요가 있습니다. 이 장에서는 저희의 경험을 바탕으로 컨테이너를 프로덕션 환경으로 가져오는 방법을 보여드리고자 합니다. 애플리케이션과 환경에 맞게 조정해야 할 방법은 무수히 많겠지만, 이 장은 Docker 철학을 실질적으로 이해하는 데 도움이 되는 탄탄한 출발점이 될 것입니다.

프로덕션으로 이동하기

애플리케이션을 빌드하고 구성할 수 있는 지점( )에서 프로덕션 시스템에서 실행되는 지점까지 애플리케이션을 가져오는 것은 제로에서 프로덕션으로 가는 가장 어려운 단계 중 하나입니다. 이 과정은 전통적으로 복잡했지만 배송 컨테이너 모델을 통해 크게 단순화되었습니다. 선적 컨테이너가 존재하기 전에 바다를 건너기 위해 배에 물건을 싣는 것이 어땠는지 상상할 수 있다면, 대부분의 전통적인 배포 시스템이 어떤 모습인지 짐작할 수 있을 것입니다. 기존의 배송 모델에서는 무작위 크기의 상자, 상자, 통, 기타 모든 종류의 포장물을 수작업으로 배에 실었습니다. 그런 다음 젠가 퍼즐처럼 전체 더미가 무너지지 않도록 어떤 조각을 먼저 내려야 하는지 알 수 있는 사람이 수동으로 내려야 했습니다.

배송 컨테이너가 모든 것을 바꿨습니다. 이제 우리는 잘 알려진 치수의 표준화된 상자를 갖게 되었습니다. 이러한 컨테이너는 논리적인 순서로 포장 및 하역할 수 있으며, 전체 물품 그룹이 예상되는 시간에 함께 도착합니다. 해운 업계는 이를 매우 효율적으로 관리하기 위해 기계를 구축했습니다. Docker 배포 모델도 매우 유사합니다. 모든 Linux 컨테이너는 동일한 외부 인터페이스를 지원하며, 도구는 내부에 무엇이 들어 있는지에 대한 걱정 없이 컨테이너가 있어야 할 서버에 컨테이너를 드롭하기만 하면 됩니다.

새 모델에서는 애플리케이션의 빌드가 실행 중일 때 배포를 시작하기 위해 많은 사용자 지정 도구를 작성할 필요가 없습니다. 하나의 서버에만 배포하려는 경우 docker 명령줄 도구가 대부분의 작업을 처리합니다. 더 많은 서버로 전송하려면 더 광범위한 컨테이너 에코시스템의 고급 도구 중 일부를 살펴봐야 합니다. 두 경우 모두 컨테이너화된 애플리케이션을 프로덕션 환경으로 옮기기 전에 애플리케이션이 알아야 할 사항과 고려해야 할 사항이 있습니다.

Docker를 사용하여 애플리케이션을 프로덕션 환경으로 가져오는 동안 따라야 할 진행 과정이 있습니다:

1. 개발 상자에서 로컬로 Docker 이미지를 빌드하고 테스트하세요.

2. 테스트 및 배포를 위한 공식 이미지는 보통 지속적 통합(CI) 또는 빌드 시스템에서 빌드합니다.

3. 이미지를 레지스트리에 푸시합니다.

4. Docker 이미지를 서버에 배포한 다음 컨테이너를 구성하고 시작합니다.

워크플로우가 발전함에 따라 결국에는 이러한 모든 단계를 ...