Docker를 데이터베이스에 사용해서는 안되는 이유는 무엇입니까?

Docker의 사용 사례에 대해 친구와 토론하고 있습니다. 팀의 한 사람이 일종의 범용 유닉스 프로세스 래퍼와 같은 모든 것에 Docker를 사용하려고합니다. 다른 사람은 Docker를 Microservices 및 AWS Lambda 스타일 앱 과 같은 상태 비 저장 애플리케이션 에만 사용해야한다고 생각합니다 .

우리는 둘 다에 대한 개념 증명을 설계했습니다. Docker 클러스터에는 Docker 호스트가 마운트 될 때 마운트되는 공유 드라이브가 있으며 컨테이너의 데이터베이스가 마운트되면 볼륨을 공유 드라이브에 마운트합니다.

내 친구는 여전히 반대의 증거를 보임에도 불구하고 자신의 입장을 고수한다. 또한 그는 Docker가 스택에 복잡성 을 추가하여 불필요한 위험을 추가한다고 주장합니다 .

나는 공감의 행동과 그와의 더 나은 추리를 위해 그의 견해를 듣고 이해하려고 노력하고 있습니다. (우리 모두 잘 지내고 있기 때문에 이것은 농담과 진지한 토론의 혼합입니다).

질문 뒤에 질문은 종류의 : 데이터베이스에있는 소 ? 이 의견 은 데이터베이스에 대한 우수한 자동 백업 및 검색 전략을 소 서버와 구분할 수 없음을 나타냅니다.

내 질문은 : Docker를 데이터베이스에 사용해서는 안되는 이유는 무엇입니까?

편집 : 사람들은 저에게 용어를 명확하게 해달라고 요청했습니다. 데이터베이스 응용 프로그램이 컨테이너에 있고 저장소가 볼륨에 있다고 가정했습니다. RDBMS는 컨테이너에 있고 데이터베이스 저장소는 볼륨에 있습니다.

일부 주석가들은 도커 볼륨 드라이버가 데이터베이스 쓰기와 잘 작동하지 않을 것이라고 제안했습니다. (또는 그 효과에 무언가). 좀 더 확장 해 주시겠습니까?

사람들이 Docker에서 데이터베이스를 실행하는 것에 대해 이야기 할 때 컨테이너에 데이터를 저장한다는 의미는 아닙니다. 그들은 DB 소프트웨어로 도커 이미지를 가지고 데이터를 볼륨 (컨테이너 볼륨이 아닌 바인드 볼륨)으로 마운트하는 것에 대해 이야기하고 있습니다.

볼륨은 Docker에서 필수적인 부분이며 결함이 있거나 고정 된 것이 아닙니다. Docker는 상태 비 저장 (마이크로) 서비스를 위해 만들어진 것이 아닙니다 .

내가 원하는대로 , Docker에서 데이터베이스를 실행하지 않는 기술적 이유를 찾을 수 없으므로 불행히도 인수의 다른 측면을 선택하여 원하는 대답을하지 못할 수도 있습니다.

(나는 베어 메탈과 도커에 익숙한 오라클과 기본 설정을 지나면 작동하기가 다소 악명 높기 때문에 Oracle을 예로 사용하고 있습니다.)

• 컨테이너에 DB 소프트웨어 자체를 패키징하면 일반적인 버전의 이점을 얻을 수 있습니다. 어디에서나 동일한 버전을 사용하고, 종속성 / 공유 라이브러리 문제를 피하고, 개발자 랩톱에서 또는 필요한 곳 ​​어디에서나 동일한 DB를 회전시킬 수 있습니다.
• 그것은이다 스냅 은 어디서나 실행지고; 업데이트는 사소한 것입니다. 모든 Docker 혜택이 적용됩니다. Dockerhub에는 Oracle 이미지가 있습니다.이 이미지를 사용하면 1 ~ 3 분 안에 (그리고 물론 다른 데이터베이스에서도) 작동중인 DB를 스핀 업할 수 있습니다.
• 사람들은 성능 테스트를 수행 한 후 볼륨과 베어 메탈간에 I / O 차이를 발견하지 못했습니다 ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https : // stackoverflow .com / questions / 21889053 / what-is-the-the-time-time-of-a-a-docker-container ).
• 어쨌든 Docker는 어쨌든 모든 I / O를 가로채는 것과는 다릅니다. 표준 Linux 도구 (이 경우 바인드 마운트, Docker-fu를 가능하게하는 내부 커널 테이블 조작)로 창의력을 발휘합니다.
• 분명히 그것은 DB의 두 인스턴스를 실행할 수 있고 동일한 파일에서 작동하도록 할 수는 있지만 아무도 그것을 암시하지는 않습니다. Docker는 볼륨에 자동으로 동시 마법없이 액세스 할 수있는 방법을 제공하지 않습니다. 나머지 혜택은 여전히 ​​적용됩니다. DB 자체가 이와 같은 충돌을 감지하지 못하면 볼륨을 이미 사용 중일 때 두 번째 컨테이너의 회전을 거부하는 CMD 스크립트를 이미지에 제공하는 것이 좋습니다.
• 베어 메탈 DB 서버를 끄지 않는 것처럼 컨테이너를 조심스럽게 돌리거나 내리는 것이 좀 더주의를 기울여야하지만 상당히 관리가 쉬워야합니다.

이제 상황에 따라 그렇지 않은 부드러운 이유 가있을 수 있습니다.

• 예를 들어, Oracle (회사)은 RDBMS를 Docker 컨테이너에서 실행하는 경우 확실히 지원하지 않습니다. 그러나 개발자 및 테스트 환경에서만도 커화 된 Oracle RDBMS 이미지를 사용 중일 수 있으며, 베어 메탈 프로덕션 서버용으로 예약 할 수 있습니다. (그러나 라이센스를 지불하는 것을 잊지 마십시오 ...).
• 작전 팀이 Docker에 익숙하지 않은 경우 실수로 모든 것을 죽이고 데이터 파일을 파괴하는 것이 조금 더 쉬울 수 있습니다.
• 당신은 매우 빠른 전용 SAN 스토리지 많은 양의 이미 큰 전용 금속 DB 머신을 가지고 있고, 다른 어쨌든 아무것도 실행하지 않으면, 단지 containerize하는 도커를 사용하여 아무 소용이 없을 것이다 사람들을 당신이되므로 결코 바로 그 때 다른 서버를 회전하지가 100GB 또는 심지어 TB의 데이터입니다. 결국 프로덕션 환경에서 Oracle과 같은 RDBMS는 모든 복제, 데이터 무결성, 다운 타임없는 페일 오버 등 측면에서 매우 발전했습니다. 이 인수는 단지 " RDBMS를 컨테이너화 할 필요 는 없다 "는 것입니다. "하지 말아야한다"는 말이 없습니다. 컨테이너를 통해 또는 상상할 수있는 다른 이유로 데이터베이스 소프트웨어 업그레이드를 롤아웃하기를 원할 수도 있습니다.

그래서 당신은 간다. 꼭 않는다 (영원히 감사 할 것입니다) 개발자 및 테스트 환경을위한 최소한, 당신의 DB를 dockerize. 생산, 그것은 취향에 내려 올 것이다, 그리고 거기에 적어도, 나는 또한 전문 DBA / 옵스 최상의 앉아 솔루션을 선호 - 그들은 베어 메탈 DB 서버 작업 수십 년의 경험이있는 경우, 모든 방법으로 그들을 신뢰를 계속합니다. 그러나 클라우드에 모든 IT를 보유한 신생 기업이라면 Docker 컨테이너는 전체 그림에서 양파의 한 부분입니다.

나는 이것에 대해 깊이 썼지 만 요약은 다음과 같습니다.

• 스플릿 브레인 방지 (두 개 이상의 마스터 노드 선택)를 해결해야합니다. 그렇게하지 않으면 치명적일 수 있습니다

• 한 인스턴스에서 데이터베이스를 종료하고 모든 데이터를 잃지 않고 다른 인스턴스를 가동 할 수있는 프로덕션 준비 공유 스토리지 솔루션이 없습니다.

데이터가 도커 컨테이너에 마운트되었다고 말할 때 "데이터베이스"가 도커 컨테이너에 마운트되었다고 말하는 것이 더 정확하지 않습니까? 컨테이너 외부에서 데이터를 유지하는 경우 데이터베이스를 컨테이너에 넣지 않는 "올바른"작업을 수행하는 것입니다.

물론, 외부에 저장 한 데이터를 관리 할 수 ​​있도록 컨테이너에 DBMS를 배치하여 시내로 이동합니다. 개인적으로 논리와 데이터를 명확하게 구분하기 때문에 좋은 디자인이라고 생각합니다. 그러나 일단 데이터를 컨테이너에 넣으면 잠재적으로 불이 붙습니다.

컨테이너 스토리지 드라이버가 먼 길을 왔지만 개인적으로 아직 데이터를 컨테이너에 얽매이지 않습니다.