Docker에서 영구 스토리지(예: 데이터베이스)를 처리하는 방법
도커 컨테이너에 대한 영구 저장을 사람들은 어떻게 처리합니까?
저는 현재 이 접근법을 사용하고 있습니다. 예를 들어 Postgre의 경우 이미지를 빌드합니다.SQL, 다음으로 컨테이너를 시작합니다.
docker run --volumes-from c0dbc34fd631 -d app_name/postgres
IMHO는 컨테이너 "c0dbc34fd631"을 (우연히) 삭제해서는 안 된다는 단점이 있습니다.
다른 아이디어는 호스트 볼륨 "-v"를 컨테이너에 마운트하는 것입니다. 그러나 컨테이너 내의 userid가 호스트의 userid와 반드시 일치하지는 않으므로 권한이 엉망이 될 수 있습니다.
: --volumes-from 'cryptic_id'사용할 수도 있습니다.--volumes-from my-data-containermy-data-container는 데이터 입니다)에입니다.docker run --name my-data-container ...조)
도커 1.9.0 이상
볼륨 API 사용
docker volume create --name hello
docker run -d -v hello:/container/path/for/volume container_image my_command
즉, 데이터 전용 컨테이너 패턴은 새 볼륨을 위해 폐기해야 합니다.
실제로 볼륨 API는 데이터 컨테이너 패턴을 달성하기 위한 더 나은 방법일 뿐입니다.
-v volume_name:/container/fs/path도커는 다음을 수행할 수 있는 명명된 볼륨을 자동으로 생성합니다.
- 다음을 통해 목록에 표시됩니다.
docker volume ls - 합니다를 합니다.
docker volume inspect volume_name - 일반 디렉터리로 백업됨
- A
--volumes-from
새 volume API를 사용하면 dangling volume을 식별할 수 있는 유용한 명령어가 추가됩니다.
docker volume ls -f dangling=true
그런 다음 이름을 통해 제거합니다.
docker volume rm <volume name>
@mpugach가 댓글에 밑줄을 긋는 것처럼, 멋진 원라이너로 모든 엉성한 볼륨을 제거할 수 있습니다.
docker volume rm $(docker volume ls -f dangling=true -q)
# Or using 1.13.x
docker volume prune
도커 1.8.x 이하
생산에 가장 적합한 것으로 보이는 접근 방식은 데이터 전용 컨테이너를 사용하는 것입니다.
데이터 전용 컨테이너는 베어본 이미지에서 실행되며 실제로는 데이터 볼륨을 노출하는 것 외에는 아무것도 수행하지 않습니다.
그런 다음 다른 컨테이너를 실행하여 데이터 컨테이너 볼륨에 액세스할 수 있습니다.
docker run --volumes-from data-container some-other-container command-to-execute
이 블로그 게시물에는 이른바 컨테이너를 볼륨 패턴으로 설명하는 좋은 설명이 있는데, 이것은 데이터만 컨테이너를 가지는 것의 요점을 명확하게 해줍니다.
도커 문서에는 이제 컨테이너에 대한 최종 설명이 볼륨/s 패턴으로 표시됩니다.
다음은 도커 1.8.x 이하의 백업/복원 절차입니다.
백업:
sudo docker run --rm --volumes-from DATA -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data
- --rm: 컨테이너가 종료되면 컨테이너를 제거합니다.
- --volumes-from DATA: DATA 컨테이너에서 공유하는 볼륨에 연결
- -v($pwd):/backup: 현재 디렉터리를 컨테이너에 bind 마운트; tar 파일을 쓸 때
- busy box: 작고 단순한 이미지 - 빠른 유지 보수에 적합
- tarcvf /backup/backup.tar /data: /data 디렉토리에 있는 모든 파일의 압축되지 않은 tar 파일을 만듭니다.
복원:
# Create a new data container
$ sudo docker run -v /data -name DATA2 busybox true
# untar the backup files into the new container᾿s data volume
$ sudo docker run --rm --volumes-from DATA2 -v $(pwd):/backup busybox tar xvf /backup/backup.tar
data/
data/sven.txt
# Compare to the original container
$ sudo docker run --rm --volumes-from DATA -v `pwd`:/backup busybox ls /data
sven.txt
컨테이너와 데이터 컨테이너에 동일한 이미지를 사용하는 것이 좋은 이유를 설명하는 훌륭한 Brian Goff의 멋진 기사입니다.
도커 릴리스 v1.0에서는 호스트 시스템의 파일 또는 디렉토리 양을 다음 명령으로 바인딩할 수 있습니다.
$ docker run -v /host:/container ...
위 볼륨은 도커를 실행하는 호스트의 영구 저장소로 사용될 수 있습니다.
도커 컴포지트 1.6 이후에는 도커 컴포지트에서 데이터 볼륨에 대한 지원이 개선되었습니다.다음 합성 파일은 상위 컨테이너의 재시작(또는 제거) 사이에 지속되는 데이터 이미지를 만듭니다.
블로그 공지사항: Compose 1.6: 네트워크와 볼륨을 정의하기 위한 새로운 Composite 파일
다음은 작성 파일의 예입니다.
version: "2"
services:
db:
restart: on-failure:10
image: postgres:9.4
volumes:
- "db-data:/var/lib/postgresql/data"
web:
restart: on-failure:10
build: .
command: gunicorn mypythonapp.wsgi:application -b :8000 --reload
volumes:
- .:/code
ports:
- "8000:8000"
links:
- db
volumes:
db-data:
제가 알기로는 다음과 같습니다.됩니다()db_data재시작 사이에 지속됩니다.
:docker volume ls다음 목록에 있는 볼륨을 확인할 수 있습니다.
local mypthonapp_db-data
...
데이터 볼륨에 대한 자세한 내용을 확인할 수 있습니다.
docker volume inspect mypthonapp_db-data
[
{
"Name": "mypthonapp_db-data",
"Driver": "local",
"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/mypthonapp_db-data/_data"
}
]
일부 테스트:
# Start the containers
docker-compose up -d
# .. input some data into the database
docker-compose run --rm web python manage.py migrate
docker-compose run --rm web python manage.py createsuperuser
...
# Stop and remove the containers:
docker-compose stop
docker-compose rm -f
# Start it back up again
docker-compose up -d
# Verify the data is still there
...
(it is)
# Stop and remove with the -v (volumes) tag:
docker-compose stop
docker=compose rm -f -v
# Up again ..
docker-compose up -d
# Check the data is still there:
...
(it is).
주의:
에서 할 수도 .
volumes를 들어 block에 할 수 예를 들어 db_data에 대해 Flocker 드라이버를 지정할 수 있습니다.volumes: db-data: driver: flocker- 도커 스웜(Docker Swarm)과 도커 컴포지트(Docker Composition)의 통합을 개선하고 (아마도 플로커를 도커 에코 시스템에 통합하기 시작할 것입니다), 저는 이 접근 방식이 점점 더 강력해질 것이라고 생각합니다.
면책 사항:이 접근 방식은 유망하고, 저는 개발 환경에서 성공적으로 사용하고 있습니다.저는 아직 이것을 생산에 사용하는 것이 두렵습니다!
선택한 답변의 업데이트 5부터 명확하지 않은 경우, Docker 1.9 기준으로 특정 컨테이너와 연관되지 않고 존재할 수 있는 볼륨을 생성할 수 있으므로 "데이터 전용 컨테이너" 패턴이 더 이상 사용되지 않습니다.
도커 1.9.0?#17798에서 더 이상 사용되지 않는 데이터 전용 컨테이너를 참조하십시오.
도커 유지 관리자들은 데이터 전용 컨테이너 패턴이 약간의 디자인 냄새가 난다는 것을 깨닫고 볼륨을 관련 컨테이너 없이 존재할 수 있는 별도의 개체로 만들기로 결정했다고 생각합니다.
Docker Composition을 사용하는 경우 다음과 같이 이름이 지정된 볼륨을 첨부하기만 하면 됩니다.
version: '2'
services:
db:
image: mysql:5.6
volumes:
- db_data:/var/lib/mysql:rw
environment:
MYSQL_ROOT_PASSWORD: root
volumes:
db_data:
이 작업은 여전히 Docker의 일부이므로 작업이 필요하지만, 볼륨 명령과 함께 볼륨을 Docker 파일에 넣어야 다른 컨테이너에서 볼륨을 복사할 필요가 없습니다.
그러면 컨테이너 간 상호 의존성이 낮아지기 때문에 다른 컨테이너에 영향을 미칠까 봐 걱정할 필요가 없습니다.
@tomm솝의 대답은 훌륭하며, 데이터 전용 컨테이너를 사용하는 몇 가지 메커니즘에 대해 설명합니다.그러나 처음에는 볼륨을 호스트에 바인딩할 수 있을 때 데이터 컨테이너가 우스꽝스럽다고 생각했지만, 이제는 데이터 전용 컨테이너가 꽤 깔끔하다는 것을 알게 된 사람으로서, 이 주제에 대해 자신의 블로그 게시물을 제안할 수 있습니다.도커 데이터 컨테이너(볼륨!)가 좋은 이유
참고 항목: "Docker 공유 볼륨에 대한 권한을 관리하는 가장 좋은 방법은 무엇입니까?"라는 질문에 대한 제 답변을 참조하십시오. 데이터 컨테이너를 사용하여 호스트와의 권한 및 uid/gid 매핑과 같은 문제를 방지하는 방법에 대한 예입니다.
OP의 원래 우려 사항 중 하나를 해결하기 위해: 데이터 컨테이너를 삭제해서는 안 됩니다., 즉륨,다를 한--volumes-from 및 한한다고 볼 수 . ())rm -fr / 데이터는 안전합니다.하여 항상 데이터 할 수 .--volumes-from해당 볼륨에 대한 참조가 있는 모든 컨테이너.
그래도 언제나 그렇듯이 백업을 하세요!
업데이트: 이제 도커에는 컨테이너와 독립적으로 관리할 수 있는 볼륨이 있으므로 관리가 더욱 쉬워졌습니다.
사용자의 요구에 따라 영구 데이터를 관리하는 몇 가지 수준이 있습니다.
- 호스트에 저장
- 깃발을 사용합니다.
-v host-path:container-path컨테이너 디렉토리 데이터를 호스트 디렉토리에 유지합니다. - 백업/복원은 동일한 디렉토리에 마운트된 백업/복원 컨테이너(예: tutumcloud/dockup)를 실행하여 수행됩니다.
- 깃발을 사용합니다.
- 데이터 컨테이너를 생성하고 해당 볼륨을 애플리케이션 컨테이너에 마운트
- ,
--volumes-from해당 데이터를 응용프로그램 컨테이너에 마운트할 수 있습니다. - 위 솔루션과 동일하게 백업/복원합니다.
- ,
- 외부/타사 서비스를 지원하는 도커 볼륨 플러그인 사용
볼륨을 이동하려면 플로커도 살펴봐야 합니다.
README에서:
플로커는 데이터 볼륨 관리자이자 멀티 호스트 도커 클러스터 관리 도구입니다.이 기능을 사용하면 Linux에서 ZFS의 기능을 활용하여 상태 비저장 애플리케이션에 사용하는 것과 동일한 도구를 사용하여 데이터를 제어할 수 있습니다.
즉, 데이터베이스, 대기열 및 키 값 저장소를 도커에서 실행하고 애플리케이션의 나머지 부분만큼 쉽게 이동할 수 있습니다.
시나리오에 따라 다르겠지만(이는 실제 운영 환경에 적합하지 않습니다), 다음과 같은 한 가지 방법이 있습니다.
이것의 요점은 데이터 지속성을 위해 호스트의 디렉토리를 사용하는 것입니다.
저는 최근에 잠재적인 해결책과 그 방법을 보여주는 어플리케이션에 대해 썼습니다.개발 및 생산 과정에서 상당히 효율적이라고 생각합니다.도움이 되거나 아이디어를 불러일으키기를 바랍니다.
레포: https://github.com/LevInteractive/docker-nodejs-example
기사: http://lev-interactive.com/2015/03/30/docker-load-balanced-mongodb-persistence/
Postgre의 데이터를 유지하기 위해 호스트에서 미리 정의된 디렉토리를 사용하고 있습니다.SQL. 또한 이렇게 하면 기존 Postgre를 쉽게 마이그레이션할 수 있습니다.SQL을 도커 컨테이너에 설치: https://crondev.com/persistent-postgresql-inside-docker/
데이터베이스 데이터를 보존하거나 저장하려면 Docker-compose.yml이 Docker 파일을 사용하려면 다음과 같이 표시되어야 합니다.
version: '3.1'
services:
php:
build:
context: .
dockerfile: Dockerfile
ports:
- 80:80
volumes:
- ./src:/var/www/html/
db:
image: mysql
command: --default-authentication-plugin=mysql_native_password
restart: always
environment:
MYSQL_ROOT_PASSWORD: example
volumes:
- mysql-data:/var/lib/mysql
adminer:
image: adminer
restart: always
ports:
- 8080:8080
volumes:
mysql-data:
Docker-composite.yml을 사용하면 Docker 파일 대신 이미지를 사용할 수 있습니다.
version: '3.1'
services:
php:
image: php:7.4-apache
ports:
- 80:80
volumes:
- ./src:/var/www/html/
db:
image: mysql
command: --default-authentication-plugin=mysql_native_password
restart: always
environment:
MYSQL_ROOT_PASSWORD: example
volumes:
- mysql-data:/var/lib/mysql
adminer:
image: adminer
restart: always
ports:
- 8080:8080
volumes:
만약 당신이 mysql의 데이터를 저장하거나 보존하기를 원한다면, 당신의 도커에 두 줄을 추가하는 것을 기억해야 합니다 - compose.yml.
volumes:
- mysql-data:/var/lib/mysql
그리고.
volumes:
mysql-data:
그 후 이 명령을 사용합니다.
docker-compose up -d
이제 데이터가 영구적으로 유지되고 이 명령을 사용해도 삭제되지 않습니다.
docker-compose down
extra:- 하지만 모든 데이터를 삭제하려면 다음을 사용합니다.
docker-compose down -v
또한 이 명령을 사용하여 데이터베이스 데이터 목록을 확인할 수 있습니다.
docker volume ls
DRIVER VOLUME NAME
local 35c819179d883cf8a4355ae2ce391844fcaa534cb71dc9a3fd5c6a4ed862b0d4
local 133db2cc48919575fc35457d104cb126b1e7eb3792b8e69249c1cfd20826aac4
local 483d7b8fe09d9e96b483295c6e7e4a9d58443b2321e0862818159ba8cf0e1d39
local 725aa19ad0e864688788576c5f46e1f62dfc8cdf154f243d68fa186da04bc5ec
local de265ce8fc271fc0ae49850650f9d3bf0492b6f58162698c26fce35694e6231c
local phphelloworld_mysql-data
나의 해결책은 새로운 것을 활용하는 것입니다.docker cp, 실행 중이든 아니든 상관없이 컨테이너에서 데이터를 복사할 수 있으며, 데이터베이스 응용프로그램이 컨테이너 내부에서 데이터베이스 파일을 생성하는 위치와 정확히 동일한 위치에 호스트 볼륨을 공유할 수 있습니다.이 이중 솔루션은 원래 데이터베이스 컨테이너에서 바로 데이터 전용 컨테이너 없이 작동합니다.
그래서 제 systemdinit 스크립트는 데이터베이스를 호스트의 아카이브에 백업하는 작업을 수행합니다.파일을 다시 쓰지 않기 위해 파일 이름에 타임스탬프를 넣었습니다.
Exec StartPre에서 실행 중입니다.
ExecStartPre=-/usr/bin/docker cp lanti-debian-mariadb:/var/lib/mysql /home/core/sql
ExecStartPre=-/bin/bash -c '/usr/bin/tar -zcvf /home/core/sql/sqlbackup_$$(date +%%Y-%%m-%%d_%%H-%%M-%%S)_ExecStartPre.tar.gz /home/core/sql/mysql --remove-files'
Exec StopPost에서도 동일한 작업을 수행하고 있습니다.
ExecStopPost=-/usr/bin/docker cp lanti-debian-mariadb:/var/lib/mysql /home/core/sql
ExecStopPost=-/bin/bash -c 'tar -zcvf /home/core/sql/sqlbackup_$$(date +%%Y-%%m-%%d_%%H-%%M-%%S)_ExecStopPost.tar.gz /home/core/sql/mysql --remove-files'
또한 호스트의 폴더를 볼륨으로 데이터베이스가 저장된 정확히 동일한 위치에 노출했습니다.
mariadb:
build: ./mariadb
volumes:
- $HOME/server/mysql/:/var/lib/mysql/:rw
VM에서 잘 작동합니다(나 자신을 위한 LEMP 스택 구축 중). https://github.com/DJviolin/LEMP
하지만 실제로 목숨이 달려 있는데도 이것이 "방탄" 솔루션인지는 모르겠습니다(예: 몇 밀리초 안에 트랜잭션이 있는 웹샵).
이 공식 Docker 키노트 비디오에서 20분 20초 후에 발표자는 데이터베이스로 동일한 작업을 수행합니다.
"데이터베이스의 경우 볼륨이 있기 때문에 데이터베이스 컨테이너가 중단되었을 때 데이터베이스가 오르내릴 때 데이터가 손실되지 않도록 할 수 있습니다."
도커 컨테이너 관리 및 스케줄링 도구인 Kubernetes의 PVC(Persistent Volume Claim)를 사용합니다.
이 목적을 위해 Kubernetes를 사용하는 장점은 다음과 같습니다.
- NFS나 다른 스토리지와 같은 모든 스토리지를 사용할 수 있으며 노드가 다운된 경우에도 스토리지를 사용할 필요가 없습니다.
- 또한 이러한 볼륨의 데이터는 컨테이너 자체가 파괴된 후에도 보존되도록 구성할 수 있으므로 필요한 경우 다른 컨테이너에서 회수할 수 있습니다.
언급URL : https://stackoverflow.com/questions/18496940/how-to-deal-with-persistent-storage-e-g-databases-in-docker
'programing' 카테고리의 다른 글
| XPath에서 대소문자를 구분하지 않는 일치? (0) | 2023.10.04 |
|---|---|
| PowerShell의 정규식 일치 (0) | 2023.10.04 |
| phphmyadmin에서 트리거를 만드는 중 오류 발생 (0) | 2023.10.04 |
| CSS에 높이가 설정되지 않은 div의 높이를 가져옵니다. (0) | 2023.10.04 |
| 서명되지 않은 int에 대해 음의 이중으로 주조하는 동작이 C 표준에 정의되어 있습니까?ARM 대 x86의 다른 동작 (0) | 2023.10.04 |