Docker 공식 포럼에서 가장 많은 답변을 받은 게시물 중 하나는 "데이터 컨테이너의 데이터 업그레이드"입니다.

공식 Docker 포럼 "데이터 컨테이너 내에서 데이터 업그레이드"에서 가장 많은 답변을 받은 게시물 중 하나

matlehmann
데이터가 담긴 컨테이너가 있고 볼륨( 예: /var/data의 영구 데이터) 컨테이너에는 다른 컨테이너의 소프트웨어에 대한 영구 데이터가 포함되어 있습니다.
소프트웨어의 새 버전의 경우 영구 데이터를 업그레이드해야 합니다(구조 또는 레이아웃 변경 등). 결과적으로 동일한 위치에 업그레이드된 데이터가 포함된 또 다른 데이터 컨테이너(/var/data)를 만들고 기존 데이터 컨테이너를 해당 데이터를 그대로 유지하고 싶습니다.
이렇게 하면 문제가 발생할 경우를 대비해 이전 데이터 컨테이너와 이전 버전의 소프트웨어를 사용할 수 있습니다.
그런데 어떻게 해야 하나요? 원하는 결과를 얻기 위해 필요한 단계가 나에게는 명확하지 않았습니다.
docker run -i -t --name temp --volumes-from data -v /upgraded image /upgrade_script.sh와 같은 명령을 실행하여 컨테이너를 업그레이드할 수 있습니다.
그러나 나중에 업그레이드된 이미지를 어떻게 복원합니까? 이전 데이터를 덮어쓰지 않고 데이터를 원래 위치로 복사하시겠습니까? docker run -i -t --volumes-from temp image cp /upgraded /var/data 를 실행하면 이전 데이터를 덮어씁니다. 업그레이드된 데이터를 위해 호스트 탑재 볼륨을 사용해야 합니까, 아니면 더 나은 솔루션이 있습니까?

sam
여기서는 일반적으로 직접 호스트 마운트 볼륨을 사용하는 것을 선호하며 데이터 컨테이너의 유용성을 찾는 데 어려움을 겪고 있습니다.
하지만...데이터 컨테이너를 커밋한 다음 이미지 등을 저장할 수 있나요? docker run -name some_pipe_storage some_container_which_generates_data
docker run --volumes-from some_pipe_storage Something_that_operates_on_data
구문이 상당히 번거롭습니다. 매우 강력하면서도 원시적입니다.



sven
은 볼륨 조인을 위한 관리 도구인 docker에 대해 흥미로운 작업을 진행하고 있습니다. 1.4를 향해 가고 있는 것 같습니다. 조사해 보겠습니다. (도커 볼륨 목록과 조작할 항목이 있을 것입니다.) 아마도 컨테이너에 backup_data 볼륨을 만든 다음 데이터와 backup_data에 연결하여 실행하려는 이미지의 데이터 마이그레이션을 실행할 것입니다. 아마도 그럴 것입니다. 그 첫 번째는 데이터를 backup_data에서 backup_data로 복사한 다음 데이터 마이그레이션을 수행한다는 것입니다.

그런 다음 각 데이터 백엔드에 연결된 기존 및 새 것을 실행할 수 있습니다(읽기 전용 백업을 첨부할 수도 있음).

이렇게 하면 사용하는 호스트에 관계없이 설치가 거의 동일해야 합니다. 직접 또는 데이터 컨테이너를 통해 스타일 표현.


matlehmann
귀하의 제안은 저의 첫 번째 아이디어 라인이지만, 그 과정 이후 경로에 따라 마이그레이션된 데이터와 원본 데이터가 다르기 때문에 기대에 미치지 못합니다. 호스트가 아닌 볼륨은 다른 경로에 다시 마운트할 수 없기 때문에 이를 변경할 방법이 없습니다. 데이터 컨테이너에서 볼륨으로의 경로는 정적입니다. "--volumes-from"에 의해 상속된 볼륨 컨테이너의 경우에도 마찬가지입니다. 도커 실행 호출마다 마운트 위치를 변경할 수 있기 때문에 호스트 볼륨에서는 다릅니다.

이러한 볼륨 관리 도구에 대해 이야기하는 것이 매우 필요하다고 생각합니다. 나에게는 이 데이터 컨테이너 도커 관용구가 해결 방법처럼 느껴집니다.

실례지만 제가 볼 수 없기 때문에 "docker commit은 굉장합니다"라고 말씀하신 건가요? 적어도 사용 사례가 있으면 말이죠. 내가 아는 한, 나에게 커밋된 Docker에는 컨테이너의 현재 상태에 대한 새로운 이미지가 포함되어 있습니다. 여기에는 영구 데이터를 제외하고 관심 있는 모든 OS 데이터가 포함됩니다.


스벤
오 크드. 당신 말이 맞습니다. 볼륨 경로는 현재 정적입니다. 따라서 한 단계가 필요합니다 1. /data에 기존 데이터 컨테이너가 있습니다

2. /migration에 있는 임시 데이터 컨테이너로 마이그레이션합니다(원본 설치가 있는 경우)

3./ migration 데이터를 다음으로 마이그레이션합니다. 새로 업그레이드된 데이터 컨테이너/데이터(두 번째 마이그레이션 이미지에는 원래 데이터 용량을 설치할 필요가 없습니다. @cpuguy83이 새 도구 스마일
WRT docker commit - 커밋할 때, 모든 것을 포함하는 단일 이미지 레이어를 만드는 것이 아니라, 컨테이너의 모든 변경 사항을 포함하는 새 이미지 레이어를 만드는 것입니다(이미지 컨테이너가 시작될 때 사용됨). 따라서 영구 데이터를 볼륨하는 컨테이너 대신 로그와 같은 것을 롤오프하면 docker를 사용하여 영구 데이터의 스냅샷/백업을 커밋할 수 있습니다. 그리고 docker 내보내기를 사용하면 해당 레이어를 저장할 수 있습니다.

cpuguy83
예, 저는 "커밋"에 의존하지 않을 것입니다. " 이미지를 평면화하지 않는 한 커밋은 127개로 제한됩니다.
@matlehmann github.com/cpuguy83/docker-volumes 참조
완벽한 솔루션은 아니지만 그 동안은 꽤 잘 작동합니다

matlehmann
@Sven 답변과 추가 정보에 감사드립니다. "/data에 설치된 새로 업그레이드된 데이터 컨테이너로 데이터를 마이그레이션하는 중(두 번째 마이그레이션 이미지는 원래 데이터 용량을 설치할 필요가 없습니다.")의 3단계를 현재 그대로 이해하지 못합니다(docker1.2 및 ( 특별한 볼륨 명령 없음), 다른 컨테이너의 볼륨이 있는 컨테이너를 가질 수 있는 방법을 모르겠습니다. 일부는 마운트되고 일부는 마운트되지 않습니다. 내가 본 바에 따르면 전부 또는 아무것도 아니거나 "- - 볼륨-from other_container"인지 여부. 따라서 2단계에서 마이그레이션된 컨테이너에 원본 데이터가 마운트된 경우 3단계의 컨테이너도 마운트되었으므로 /mifrated에서 /data로 복사 작업을 수행하면 원본 데이터를 덮어쓰게 됩니다. 뭔가 잃어버렸나요?
팁 감사합니다. 좀 더 생각해서 준비해야겠어요

matlehmann
@keeb 좋은 모드인데. 내가 아는 한, 이것은 내가 말하는 문제를 해결하지 못합니다. 이러한 모든 "파이프" 컨테이너는 주어진 시점에서 다른 컨테이너를 생성하지 못한 채 여전히 "some_pipe_storage"의 볼륨으로 끝나게 됩니다. 경로를 변경합니다. 하지만 제가 요점을 놓치고 있는 것 같습니다.

sven
흠, 그렇게 할 수 있는지 살펴보겠습니다. 설명은 다음과 같습니다.
누군가 Docker 이미지 webappv10, webappv11, webapp_migratorv10_to_v11을 생성했다고 가정합니다.
처음에는 1.0 기반 시스템을 실행하게 됩니다.
docker run -v /data --name datav10 busybox true
docker run -p 80:80 --volumes-from datav10 --name webv10 webappv10
그런 다음 업그레이드하고 데이터에 업그레이드를 요청하면 2단계를 수행하게 됩니다. 디렉터리)
docker run -v /migration --name datav10-to-v11 busybox true
docker run --volumes-from datav10-to-v11 --volumes-from datav10 - -name migration webapp_migratorv10_to_v11
그런 다음 3단계, 복사된 데이터를 새 데이터 컨테이너로 마이그레이션하고
docker run -v /data --volumes-from datav10-to -v11 --name datav11 busybox cp -를 사용하여 /data 디렉터리의 데이터를 준비합니다. r /migration /data
그런 다음 버전 1.1 웹 애플리케이션 실행
docker run -p 80:80 --volumes-from datav11 --name webv11 webappv11
및 추가 정보를 위해 스크립트를 작성하는 것이 좋습니다. 모두.
datav10에서 V11 볼륨 컨테이너 단계 증가로 업데이트하는 것은 아래 논의 때문입니다.

matlehmann
@sven 자세한 답변에 다시 한번 감사드립니다. 귀하의 생각과 시간에 감사드립니다.
그러나 설명하신 절차는 작동하지 않습니다. 볼륨이 "--volumes-from"과 동일한 경로를 상속한다는 가정을 뒤집는 "-v"를 사용하여 볼륨을 호출합니다. 확인하기 위해 다시 테스트했지만 이것이 사실이 아닙니다. docker run -v / data --volumes-from migration --name datav11 busybox cp -r /migration /data는 귀하가 좋아하는 데이터 컨테이너인 datav10

sam
을 덮어씁니다. 특별한 이유로 간단한 볼륨으로 되어 있습니다(예: 느낌에 따라 이해하기 쉬움/처리)

sven
자세히 설명하는 단계가 헷갈립니다. /data dils 문. 버퍼를 마이그레이션한 다음 이를 새 데이터 v11 컨테이너에 복사합니다.
@sam - 마운트된 볼륨과 볼륨 컨테이너 사이에 약간의 개념적 차이가 있습니다. 여전히 동일한 3단계를 수행합니다. 가장 큰 차이점은 바인딩 마운트가 로컬에서만 작동하고 이를 위한 디스크 공간이 있다고 가정한다는 것입니다(제가 한 것은 아닙니다). 반면 볼륨 컨테이너 방법은 Docker 데이터 파티션이 크다고 가정합니다. Docker 컨테이너를 실행하기에 충분하며 docker run -v /data ... 줄을 docker run -v /local/data ...로 변경한 다음 바인드 마운트를 사용하면 로컬 원격과 동일하게 작동합니다.

matlehmann@SAM을 대신하여 바인드 마운트 이제 바인드 마운트 바인드 마운트 사용으로 전환합니다(또는 공식 용어는 "-v /host:/container"입니다). 이 스레드에 나열된 단점 때문에 데이터 컨테이너를 사용하는 대신 인터넷 전체에서 사용되고 권장되는 관용구 때문에 데이터 컨테이너를 사용하기 시작했습니다.

matlehmann@sven
?"datav10" has ?"/data" (-v /data를 통해)

?"migration" has ?"/ data"(datav10의 --volumes를 통해)?"/migration"(`-v /migration'을 통해)

?"datav11"에는 ?"/data"( -v /data를 통해)?"/migration"(마이그레이션에서 --volumes를 통해)
?"/data"(-volumes -from 마이그레이션을 통해)

따라서 두 개의 볼륨이 정의된 "/data" 컨테이너 "datav11"이 있습니다. 제게는 --volumes-from win one 처럼 보입니다.

sam @sven AUFS에 데이터를 저장하는 이유를 알아내려고 하는 것 같은데, 이 문제에 사용하기에는 파일 시스템이 잘못된 것 같습니다. . BTRFS는 괜찮겠지만, 로그 파일, 사용된 Postgres 데이터베이스 등에 대한 auf의 이상한 선택처럼 보입니다. 데이터 컨테이너의 메커니즘을 오해하고 있습니까?

@matlehmann 우리는 "볼륨"을 광범위하게 사용합니다.
모든 로그의 간편한 순환과 지속성을 위해 호스트 탑재 볼륨을 기성 컨테이너에 저장합니다. (컨테이너에서 스트리밍하는 또 다른 옵션이 있지만 메커니즘은 간단하지 않습니다. NGINX 컨테이너를 생각해 보세요. 로그를 사용합니까?)
마운트된 GlusterFS 볼륨에 일부 구성을 저장하므로 우리는 무엇을 해야 할까요?

matlehmann
@sven 이것은 다른 스레드의 주제가 될 것입니다. 귀하의 GlusterFS 설정에 대해 듣고 싶습니다. GlusterFS 내에서 대표 볼륨으로 사용할 수 있는 즉시 사용 가능한 이미지가 있습니까? 아니면 어떻게 수행합니까?

sam
@supermathie는 GlusterFS 설정에 대한 세부 정보에 가장 적합하지만 모든 설정에 대해 매우 전통적인 방식이며 신뢰할 수 있는 Docker 컨테이너를 사용하지 않습니다. Gluster의 전원을 켭니다.

sven
OH(*&^ 맞아요.
한 단계 삭제한 게 너무 똑똑한 줄 알았어요.
/ migration을 옮겨야 해요. 마지막 단계에서 발견한 문제를 방지하기 위해 폴더를 소유합니다.
이를 반영하기 위해 1단계 예제 단계를 업데이트했습니다.

sven

예, 몇 가지 내용이 있습니다. 해결해야 할 파일 시스템 - 내 도커는 대부분 BTRFS를 실행합니다. 바인딩을 사용하면 설치도 작동할 것 같습니다. 하지만 여전히 연결을 수행한 다음 위와 동일한 프로세스를 사용할 것입니다.

matlehmann

@sven 이건 시도해본 적이 없지만, 어색한 크레이지 치킨 댄스지만 효과가 있을 수도 있습니다..롤 주문을 간절히 기다리고 있습니다.

스벤

네, 어설픈 치킨에 집중하고 있어요~ 저 버전도 기대하고, 맛있게 먹을 닭다리 구이

이 기사는 Docker 공식 포럼에서 번역되었습니다:

https://forums.docker.com/t/upgrade-data-within-data -container/205/20 이상은 Docker 공식 포럼에서 가장 많은 답변을 받은 게시물 중 하나인 "Upgrading Data in Data Containers" 관련 내용을 소개하고 있으며, PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.