Jak radzić sobie z trwałym magazynowaniem (np. Bazami danych) w Docker

Jak ludzie radzą sobie z trwałym przechowywaniem kontenerów Docker?

Obecnie używam tego podejścia: zbuduj obraz, np. Dla PostgreSQL, a następnie uruchom kontener za pomocą

docker run --volumes-from c0dbc34fd631 -d app_name/postgres

IMHO, który ma tę wadę, że nie wolno mi (przypadkowo) usuwać kontenera „c0dbc34fd631”.

Innym pomysłem byłoby zamontowanie woluminów hosta „-v” w kontenerze, jednak identyfikator użytkownika w kontenerze niekoniecznie odpowiada identyfikatorowi użytkownika z hosta, a następnie uprawnienia mogą zostać pomieszane.

Uwaga: Zamiast --volumes-from 'cryptic_id'ciebie możesz również użyć --volumes-from my-data-containergdzie my-data-containerjest nazwa przypisana do kontenera tylko danych, np. docker run --name my-data-container ...(Patrz zaakceptowana odpowiedź)

Docker 1.9.0 i nowsze wersje

Użyj interfejsu API woluminu

docker volume create --name hello
docker run -d -v hello:/container/path/for/volume container_image my_command

Oznacza to, że wzorzec kontenera zawierającego tylko dane musi zostać porzucony na rzecz nowych woluminów.

W rzeczywistości interfejs API woluminu jest tylko lepszym sposobem na osiągnięcie wzorca kontenera danych.

Jeśli utworzysz kontener za pomocą -v volume_name:/container/fs/pathDockera, automatycznie utworzy się nazwany wolumin, który może:

1. Bądź na liście poprzez docker volume ls
2. Być zidentyfikowanym poprzez docker volume inspect volume_name
3. Utworzono kopię zapasową jako normalny katalog
4. Utworzono kopię zapasową jak poprzednio przez --volumes-frompołączenie

Nowy interfejs API woluminu dodaje przydatne polecenie, które pozwala zidentyfikować wiszące woluminy:

docker volume ls -f dangling=true

A następnie usuń go poprzez jego nazwę:

docker volume rm <volume name>

Jak podkreśla @mpugach w komentarzach, możesz pozbyć się wszystkich wiszących woluminów za pomocą ładnego jednowierszowego:

docker volume rm $(docker volume ls -f dangling=true -q)
# Or using 1.13.x
docker volume prune

Docker 1.8.xi niższe

Podejście, które wydaje się działać najlepiej w przypadku produkcji, polega na użyciu kontenera zawierającego tylko dane .

Kontener tylko danych jest uruchamiany na obrazie barebone i właściwie nie robi nic poza ujawnieniem woluminu danych.

Następnie możesz uruchomić dowolny inny kontener, aby uzyskać dostęp do woluminów kontenera danych:

docker run --volumes-from data-container some-other-container command-to-execute

• Tutaj możesz uzyskać dobry obraz rozmieszczenia różnych pojemników.
• Tutaj jest dobry wgląd w działanie woluminów.

W tym poście na blogu znajduje się dobry opis tak zwanego kontenera jako wzorca objętości, który wyjaśnia główny punkt posiadania kontenerów zawierających wyłącznie dane .

Dokumentacja dokera ma teraz DEFINICJALNY opis kontenera jako wzorzec wolumenu / s .

Poniżej znajduje się procedura tworzenia kopii zapasowych / przywracania dla Docker 1.8.xi niższych.

UTWORZYĆ KOPIĘ ZAPASOWĄ:

sudo docker run --rm --volumes-from DATA -v $(pwd):/backup busybox tar cvf /backup/backup.tar /data

• --rm: wyjmij pojemnik po wyjściu
• --volumes-from DATA: dołącz do woluminów udostępnianych przez kontener DATA
• -v $ (pwd): / backup: bind podłącz bieżący katalog do kontenera; zapisać plik tar do
• busybox: mały, prostszy obraz - dobry do szybkiej konserwacji
• tar cvf /backup/backup.tar / data: tworzy nieskompresowany plik tar wszystkich plików w katalogu / data

PRZYWRACAĆ:

# 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

Oto fajny artykuł doskonałego Briana Goffa wyjaśniający, dlaczego warto używać tego samego obrazu dla kontenera i kontenera danych.

W Docker wersja 1.0 powiązanie podłączenia pliku lub katalogu na maszynie hosta można wykonać za pomocą podanego polecenia:

$ docker run -v /host:/container ...

Powyższy wolumin może być używany jako trwały magazyn na hoście z uruchomionym Dockerem.

Od Docker Compose 1.6 poprawiono obsługę woluminów danych w Docker Compose. Poniższy plik tworzenia utworzy obraz danych, który będzie trwał między ponownymi uruchomieniami (a nawet usunięciem) kontenerów nadrzędnych:

Oto ogłoszenie na blogu: Compose 1.6: Nowy plik Compose do definiowania sieci i woluminów

Oto przykładowy plik tworzenia:

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:

O ile rozumiem: utworzy to kontener woluminu danych ( db_data), który będzie trwał między restartami.

Jeśli uruchomisz: docker volume lspowinieneś zobaczyć swój wolumin na liście:

local               mypthonapp_db-data
...

Możesz uzyskać więcej szczegółowych informacji na temat objętości danych:

docker volume inspect mypthonapp_db-data
[
  {
    "Name": "mypthonapp_db-data",
    "Driver": "local",
    "Mountpoint": "/mnt/sda1/var/lib/docker/volumes/mypthonapp_db-data/_data"
  }
]

Niektóre testy:

# 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).

Uwagi:

• W volumesbloku można również określić różne sterowniki . Na przykład można określić sterownik Flocker dla danych db_data:

  volumes:
    db-data:
      driver: flocker
  

• Ponieważ poprawiają integrację między Docker Swarm i Docker Compose (i być może zaczynają integrować Flocker z ekosystemem Docker (słyszałem plotki, że Docker kupił Flocker), myślę, że to podejście powinno stać się coraz silniejsze.

Oświadczenie: To podejście jest obiecujące i używam go z powodzeniem w środowisku programistycznym. Obawiałbym się wykorzystać to jeszcze w produkcji!

W przypadku, gdy nie jest jasne z aktualizacji 5 wybranej odpowiedzi, począwszy od Docker 1.9, można tworzyć woluminy, które mogą istnieć bez powiązania z konkretnym kontenerem, dzięki czemu wzorzec „kontenera tylko danych” staje się nieaktualny.

Zobacz Kontenery tylko z danymi przestarzałe w programie dokującym 1.9.0? # 17798 .

Wydaje mi się, że opiekunowie Dockera zdali sobie sprawę, że wzorzec kontenera obejmujący tylko dane był nieco zapachowym zapachem projektu i postanowili uczynić woluminy osobnym bytem, ​​który może istnieć bez powiązanego kontenera.

Chociaż jest to nadal część Dockera, która wymaga trochę pracy , powinieneś umieścić wolumin w Dockerfile z instrukcją VOLUME , abyś nie musiał kopiować woluminów z innego kontenera.

To sprawi, że twoje pojemniki będą mniej zależne od siebie i nie będziesz musiał się martwić, że usunięcie jednego pojemnika wpłynie na inny.

Korzystając z Docker Compose , po prostu dołącz nazwany wolumin, na przykład:

version: '2'
services:
  db:
    image: mysql:5.6
    volumes:
      - db_data:/var/lib/mysql:rw
    environment:
      MYSQL_ROOT_PASSWORD: root
volumes:
  db_data:

Odpowiedź @ tommasop jest dobra i wyjaśnia niektóre mechanizmy korzystania z kontenerów zawierających tylko dane. Ale ponieważ ktoś, kto początkowo myślał, że pojemniki z danymi są głupie, gdy można po prostu powiązać, zamontuje wolumin na hoście (jak sugeruje kilka innych odpowiedzi), ale teraz zdaje sobie sprawę, że w rzeczywistości pojemniki tylko z danymi są całkiem fajne, mogę zasugerować własny post na blogu na ten temat: Dlaczego pojemniki danych Docker (woluminy!) są dobre

Zobacz także: moja odpowiedź na pytanie „ Jaki jest (najlepszy) sposób zarządzania uprawnieniami do udostępnionych woluminów Docker? ”, Na przykład, jak używać kontenerów danych, aby uniknąć problemów takich jak uprawnienia i mapowanie UID / GID z hostem.

Aby rozwiązać jedną z pierwotnych obaw PO: nie można usunąć kontenera danych. Nawet jeśli kontener danych zostanie usunięty, same dane nie zostaną utracone, dopóki jakikolwiek kontener będzie miał odniesienie do tego woluminu, tj. Do dowolnego kontenera, przez który zamontowano wolumin --volumes-from. Tak więc, chyba że wszystkie powiązane kontenery zostaną zatrzymane i usunięte (można uznać to za ekwiwalent przypadku rm -fr /) dane są bezpieczne. Zawsze możesz odtworzyć kontener danych, wykonując --volumes-fromdowolny kontener, który ma odniesienie do tego woluminu.

Jak zawsze rób jednak kopie zapasowe!

AKTUALIZACJA: Docker ma teraz woluminy, którymi można zarządzać niezależnie od kontenerów, co dodatkowo ułatwia zarządzanie.

Istnieje kilka poziomów zarządzania trwałymi danymi, w zależności od potrzeb:

• Zapisz go na swoim hoście
  • Użyj flagi, -v host-path:container-pathaby utrwalić dane katalogu kontenera w katalogu hosta.
  • Tworzenie kopii zapasowych / przywracanie odbywa się przez uruchomienie kontenera kopii zapasowych / przywracania (takiego jak tutumcloud / dockup) podłączonego do tego samego katalogu.
• Utwórz kontener danych i podłącz jego woluminy do kontenera aplikacji
  • Utwórz kontener, który eksportuje wolumin danych, użyj --volumes-fromdo zamontowania tych danych w kontenerze aplikacji.
  • Wykonaj kopię zapasową / przywróć tak samo jak powyższe rozwiązanie.
• Użyj wtyczki woluminu Docker, która wspiera usługę zewnętrzną / zewnętrzną
  • Wtyczki woluminów Docker umożliwiają dostęp do źródła danych z dowolnego miejsca - NFS, AWS (S3, EFS i EBS)
  • W zależności od wtyczki / usługi możesz dołączyć jeden lub wiele kontenerów do jednego woluminu.
  • W zależności od usługi kopie zapasowe / przywracania mogą być dla Ciebie zautomatyzowane.
  • Chociaż może to być kłopotliwe, aby to zrobić ręcznie, niektóre rozwiązania w zakresie aranżacji - takie jak Rancher - sprawiają, że jest on upieczony i prosty w użyciu.
  • Konwój jest najłatwiejszym rozwiązaniem do wykonania tego ręcznie.

Jeśli chcesz przenosić woluminy, powinieneś również spojrzeć na Flockera .

Z README:

Flocker to menedżer woluminów danych i narzędzie do zarządzania klastrami Docker dla wielu hostów. Dzięki niemu możesz kontrolować swoje dane za pomocą tych samych narzędzi, których używasz w bezpaństwowych aplikacjach, wykorzystując moc ZFS w systemie Linux.

Oznacza to, że możesz uruchamiać swoje bazy danych, kolejki i sklepy z kluczowymi wartościami w Docker i przenosić je tak łatwo, jak resztę aplikacji.

To zależy od twojego scenariusza (nie jest to tak naprawdę odpowiednie dla środowiska produkcyjnego), ale jest jeden sposób:

Tworzenie kontenera dokującego MySQL

Jego istotą jest użycie katalogu na hoście w celu utrwalenia danych.

Niedawno pisałem o potencjalnym rozwiązaniu i aplikacji demonstrującej tę technikę. Uważam, że jest dość wydajny podczas opracowywania i produkcji. Mam nadzieję, że to pomaga lub podsyca pewne pomysły.

Repo: https://github.com/LevInteractive/docker-nodejs-example
Artykuł: http://lev-interactive.com/2015/03/30/docker-load-balanced-mongodb-persistence/

Po prostu używam predefiniowanego katalogu na hoście, aby utrwalić dane dla PostgreSQL. W ten sposób można również łatwo migrować istniejące instalacje PostgreSQL do kontenerów Docker: https://crondev.com/persistent-postgresql-inside-docker/

Moim rozwiązaniem jest skorzystanie z nowego docker cp, który jest teraz w stanie kopiować dane z kontenerów, bez względu na to, czy jest uruchomiony, czy nie i udostępniać wolumin hosta dokładnie w tej samej lokalizacji, w której aplikacja bazy danych tworzy swoje pliki bazy danych w kontenerze . To podwójne rozwiązanie działa bez kontenera tylko danych, prosto z oryginalnego kontenera bazy danych.

Tak więc mój systemowy skrypt startowy wykonuje kopię zapasową bazy danych w archiwum na hoście. W nazwie pliku umieściłem znacznik czasu, aby nigdy nie przepisywać pliku.

Robi to na ExecStartPre:

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'

I robi to samo na ExecStopPost:

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'

Dodatkowo odsłoniłem folder z hosta jako wolumin dokładnie w tej samej lokalizacji, w której przechowywana jest baza danych:

mariadb:
  build: ./mariadb
  volumes:
    - $HOME/server/mysql/:/var/lib/mysql/:rw

Działa świetnie na mojej maszynie wirtualnej (buduję stos LEMP dla siebie): https://github.com/DJviolin/LEMP

Ale po prostu nie wiem, czy jest to „kuloodporne” rozwiązanie, gdy twoje życie zależy od niego (na przykład sklep internetowy z transakcjami w każdej możliwej milisekundie)?

Po 20 min. 20 sek. Od tego oficjalnego filmu przewodniego Dockera prezenter robi to samo z bazą danych:

Rozpoczęcie pracy z Dockerem

„W przypadku bazy danych mamy wolumin, dzięki czemu możemy się upewnić, że gdy baza danych będzie rosła i spadała, nie tracimy danych, gdy kontener bazy danych zatrzyma się”.

Użyj trwałej deklaracji wolumenu (PVC) z Kubernetes, która jest narzędziem do zarządzania i planowania kontenerów Docker:

Trwałe objętości

Zalety korzystania z Kubernetes w tym celu:

• Możesz użyć dowolnego magazynu, takiego jak NFS lub inny, i nawet gdy węzeł nie działa, nie musi to być.
• Ponadto dane w takich woluminach można skonfigurować tak, aby były przechowywane nawet po zniszczeniu samego kontenera - aby w razie potrzeby można je było odzyskać z innego kontenera.