Docker: Up & Running, 제3판

2장. Docker 환경 살펴보기

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

Docker 구성 및 설치에 들어가기 전에 먼저 Docker가 무엇이며 어떤 이점을 제공하는지 설명하기 위해 광범위한 설문조사를 실시했습니다. 강력한 기술이지만 그 핵심이 엄청나게 복잡한 기술은 아닙니다. 이 장에서는 Docker와 Linux 컨테이너의 작동 방식, 강력한 이유, 그리고 이를 사용하는 몇 가지 이유에 대한 일반적인 사항을 다룹니다. 이 글을 읽고 계신다면 컨테이너를 사용해야 하는 이유가 있을 수 있지만, 시작하기 전에 이해도를 높이는 것도 나쁘지 않습니다.

이 장은 너무 오래 걸리지 않을 테니 걱정하지 마세요. 다음 장에서는 시스템에 Docker를 설치하여 실행하는 방법을 바로 살펴보겠습니다.

프로세스 간소화

Docker는 소프트웨어이기 때문에 잘 도입하고 구현하면 회사 및 팀 프로세스에도 큰 긍정적인 영향을 미칠 수 있다는 사실을 잘 모를 수도 있습니다. 이제 Docker와 Linux 컨테이너가 어떻게 워크플로우와 커뮤니케이션을 모두 간소화할 수 있는지 자세히 살펴보겠습니다. 이는 일반적으로 배포 스토리에서 시작됩니다. 일반적으로 애플리케이션을 프로덕션 환경에 배포하는 주기는 다음과 같은 경우가 많습니다( 그림 2-1 참조):

1. 애플리케이션 개발자는 운영 엔지니어에게 리소스를 요청합니다.

2. 리소스가 프로비저닝되어 개발자에게 전달됩니다.

3. 개발자는 배포를 스크립팅하고 도구화합니다.

4. 운영 엔지니어와 개발자는 배포를 반복적으로 조정합니다.

5. 개발자가 추가 애플리케이션 종속성을 발견합니다.

6. 운영 엔지니어는 추가 요구 사항을 설치하기 위해 노력합니다.

7. 4~6단계를 n번 더 반복합니다.

8. 애플리케이션이 배포됩니다.

그림 2-1. 기존 배포 워크플로(Docker 사용 안 함)

저희의 경험에 따르면 기존 프로세스를 따르는 경우, 새로운 애플리케이션을 프로덕션 환경에 배포하는 데는 복잡한 새 시스템의 경우 일주일 이상 걸릴 수 있습니다. 이는 그다지 생산적이지 않으며, DevOps 관행이 많은 장벽을 완화하기는 하지만 여전히 많은 노력과 팀원 간의 커뮤니케이션이 필요한 경우가 많습니다. 이 프로세스는 기술적으로 어렵고 비용이 많이 들 수 있지만, 더 나쁜 것은 개발팀이 앞으로 수행할 혁신의 종류를 제한할 수 있다는 점입니다. 새 소프트웨어를 배포하는 것이 어렵고 시간이 많이 걸리며 다른 팀의 리소스에 의존하는 경우 개발자는 새 배포에 따른 불이익을 피하기 위해 기존 애플리케이션에 모든 것을 구축하거나 더 심하게는 새로운 개발 노력이 필요한 문제 해결을 피할 수도 있습니다.

Heroku와 같은 푸시 배포 시스템( )은 개발자가 애플리케이션과 대부분의 종속성을 제어할 ...