현재 일부 서버 및 앱을 coreOS 환경으로 마이그레이션 하려고 합니다. 여기서 볼 수있는 문제 중 하나는 coreOS가 컨테이너를 새 시스템으로 옮길 때 Docker 볼륨을 처리하지 않으므로 영구 데이터를 관리하는 것입니다. 일부 연구 결과 , 모든 문제를 해결할 수있는 클러스터 파일 시스템 인 glusterFS 를 발견 했습니다 .
내 현재 아이디어는 다음과 같습니다 /mnt/gluster. 예를 들어 각 coreOS 시스템에서 권한있는 컨테이너로 실행되고 스토리지를 노출하는 glusterFS 컨테이너가 있습니다. 내 Dockerfile모든 볼륨을이 경로에 마운트하도록 지정합니다.
다음으로 고려해야 할 것은 어떤 컨테이너가 자체 볼륨을 얻어야하고 어떤 컨테이너가 공유해야하는지였습니다. 예를 들어, 모든 mysql컨테이너는 자체적으로 복제를 처리 할 수 있으므로 자체 볼륨을 갖게됩니다. 나는 그걸 엉망으로 만들고 싶지 않습니다. 동일한 웹 사이트를 제공하는 웹 서버는 "사용자가 업로드 한 이미지"등과 같은 데이터를 복제 할 수 없으므로 동일한 볼륨을 올바르게 사용합니다.
아무도 이와 같은 것을 시도했거나 내가 놓친 것이 있습니까?
1
나는 이것으로 개념 증명을 해왔고 그것이 효과가 있다고 말할 수 있지만 Gluster로 뛰어 들기 전에 튜닝 프로파일을 이해해야합니다. Gluster가 디스크 대기 시간에 민감한 방식 (예 : etcd)으로 인해 파일 복제 보장이라는 이름으로 응용 프로그램을 인위적으로 느리게 만들 수 있습니다.
—
Brian Redbeard
도커 컨테이너에 연결된 볼륨을 관리하는 도구를 개발 중입니다. "flocker"라고하며 여기에서 github repo를 볼 수 있습니다 : github.com/clusterhq/flocker 현재 ZFS 용 스토리지 백엔드는 스냅 샷 기능을 사용하여 훨씬 쉽게 데이터를 마이그레이션 할 수 있지만 다른 스토리지 백엔드도 계획하고 있습니다. (일반 블록 장치 백엔드와 같은) GlusterFS를 사용하여 도커 볼륨을 마운트하는 것이 좋은 아이디어라고 말할 수는 없지만 전반적인 디자인 패턴을 보증 할 수 있습니다. 즉 "something"을 사용하여 도커 컨테이너에서 생성 된 상태를
—
고려할 수 있습니다.
답변 주셔서 감사합니다. 나는 이미 flocker를 보았고 매우 유망한 것으로 보입니다. coreos 지원 또는 프로덕션 준비 버전 1.0에 대한 대략적인 날짜가 있습니까?
—
Martin
OpenStack이있는 볼륨에 glusterfs를 사용했는데 이전에는 수행중인 작업과 비슷한 설정이 있었고 훌륭했습니다.
—
Ethode
@Martin We (ClusterHQ에서 근무)는 Amazon EBS를 활용하여 Flocker에서 CoreOS를 개발하고 있습니다. coreos.com/blog/Flocker-on-CoreOS-Linux
—
Stephen Nguyen