วิธีจัดการกับที่จัดเก็บข้อมูลถาวร (เช่นฐานข้อมูล) ใน Docker

ผู้คนจัดการกับที่เก็บข้อมูลถาวรสำหรับคอนเทนเนอร์ Docker ของคุณอย่างไร

ขณะนี้ฉันใช้วิธีนี้: สร้างภาพเช่นสำหรับ PostgreSQL แล้วเริ่มคอนเทนเนอร์ด้วย

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

IMHO ที่มีข้อเสียคือฉันต้องไม่ลบคอนเทนเนอร์ (c0dbc34fd631 "โดยบังเอิญ) (โดยไม่ได้ตั้งใจ)

แนวคิดอื่นคือการเมานต์ไดรฟ์ข้อมูลโฮสต์ "-v" ลงในคอนเทนเนอร์อย่างไรก็ตามหมายเลขผู้ใช้ภายในคอนเทนเนอร์ไม่จำเป็นต้องตรงกับหมายเลขผู้ใช้จากโฮสต์และจากนั้นสิทธิ์อาจยุ่งเหยิง

หมายเหตุ: แทนที่จะ--volumes-from 'cryptic_id'คุณยังสามารถใช้--volumes-from my-data-containerที่my-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 นั้นเป็นวิธีที่ดีกว่าในการบรรลุรูปแบบของ data-container

หากคุณสร้างคอนเทนเนอร์ด้วย-v volume_name:/container/fs/pathDocker จะสร้างวอลลุ่มที่ตั้งชื่อโดยอัตโนมัติสำหรับคุณที่สามารถ:

1. ถูกลงรายการผ่าน docker volume ls
2. ถูกระบุผ่าน docker volume inspect volume_name
3. สำรองข้อมูลเป็นไดเรกทอรีปกติ
4. สำรองข้อมูลเหมือนก่อนผ่านการ--volumes-fromเชื่อมต่อ

API ปริมาณใหม่เพิ่มคำสั่งที่มีประโยชน์ที่ช่วยให้คุณระบุห้อยปริมาณ:

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

• ที่นี่คุณจะได้รับภาพรวมของวิธีการจัดเรียงตู้คอนเทนเนอร์ที่แตกต่างกัน
• ที่นี่มีข้อมูลเชิงลึกที่ดีเกี่ยวกับปริมาณการทำงาน

ในโพสต์บล็อกนี้มีคำอธิบายที่ดีของสิ่งที่เรียกว่าภาชนะที่เป็นรูปแบบไดรฟ์ซึ่งชี้แจงจุดหลักของการมีข้อมูลที่ภาชนะเท่านั้น

เอกสารนักเทียบท่าตอนนี้มีคำอธิบาย DEFINITIVE ของคอนเทนเนอร์เป็นรูปแบบโวลุ่ม / s

ต่อไปนี้เป็นขั้นตอนการสำรอง / กู้คืนสำหรับ Docker 1.8.x และต่ำกว่า

สำรอง:

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

• --rm: ลบคอนเทนเนอร์เมื่อออก
• - ปริมาณ - จากข้อมูล: แนบกับไดรฟ์ข้อมูลที่ใช้ร่วมกันโดยภาชนะข้อมูล
• -v $ (pwd): / backup: ผูกติดไดเรกทอรีปัจจุบันลงในภาชนะ; เพื่อเขียนไฟล์ tar ไปยัง
• busybox: ภาพขนาดเล็กที่เรียบง่าย - ดีสำหรับการบำรุงรักษาอย่างรวดเร็ว
• tar cvf /backup/backup.tar / data: สร้างไฟล์ tar ที่ไม่มีการบีบอัดของไฟล์ทั้งหมดในไดเร็กทอรี / data

เรียกคืน:

# 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 ที่ยอดเยี่ยมอธิบายว่าทำไมการใช้อิมเมจเดียวกันสำหรับคอนเทนเนอร์และที่เก็บข้อมูล

ในDocker รีลีส v1.0 การเชื่อมเมาท์ของไฟล์หรือไดเร็กทอรีบนเครื่องโฮสต์สามารถทำได้โดยคำสั่งที่กำหนด:

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

โวลุ่มดังกล่าวสามารถใช้เป็นที่เก็บข้อมูลถาวรบนโฮสต์ที่ใช้ Docker

ในฐานะของ Docker Compose 1.6 ขณะนี้มีการปรับปรุงการรองรับปริมาณข้อมูลใน Docker Compose ไฟล์เขียนต่อไปนี้จะสร้างภาพข้อมูลซึ่งจะคงอยู่ระหว่างการรีสตาร์ท (หรือลบออก) ของคอนเทนเนอร์หลัก:

นี่คือการประกาศบล็อก: เขียน 1.6: ไฟล์เขียนใหม่สำหรับการกำหนดเครือข่ายและปริมาณ

นี่คือตัวอย่างไฟล์เขียน:

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:

เท่าที่ฉันเข้าใจ: สิ่งนี้จะสร้าง data volume container ( 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บล็อก ตัวอย่างเช่นคุณสามารถระบุไดรเวอร์ Flocker สำหรับ db_data:

  volumes:
    db-data:
      driver: flocker
  

• เมื่อพวกเขาปรับปรุงการรวมระหว่าง Docker Swarm และ Docker Compose (และอาจเริ่มรวม Flocker เข้ากับระบบนิเวศของ Docker (ฉันได้ยินข่าวลือว่า Docker ซื้อ Flocker) ฉันคิดว่าวิธีการนี้ควรมีประสิทธิภาพมากขึ้น

คำเตือน:วิธีการนี้มีแนวโน้มและฉันใช้มันประสบความสำเร็จในสภาพแวดล้อมการพัฒนา ฉันจะกลัวที่จะใช้สิ่งนี้ในการผลิตเพียงแค่!

ในกรณีที่ไม่ชัดเจนจากการอัพเดต 5 ของคำตอบที่เลือกในฐานะของ Docker 1.9 คุณสามารถสร้างไดรฟ์ที่มีอยู่ได้โดยไม่ต้องเชื่อมโยงกับคอนเทนเนอร์ที่เฉพาะเจาะจงจึงทำให้รูปแบบ "data-only container" ล้าสมัย

ดูที่บรรจุข้อมูลเท่านั้นล้าสมัยกับ docker 1.9.0 หรือไม่ # 17798

ฉันคิดว่าผู้ดูแล Docker รู้ว่ารูปแบบของข้อมูลอย่างเดียวนั้นเป็นกลิ่นของการออกแบบเพียงเล็กน้อยและตัดสินใจที่จะทำให้ไดรฟ์ข้อมูลแยกต่างหากเอนทิตีที่สามารถมีอยู่ได้หากไม่มีคอนเทนเนอร์ที่เกี่ยวข้อง

ในขณะที่ยังคงเป็นส่วนหนึ่งของ Docker ที่ต้องการงานบางอย่างคุณควรใส่วอลลุ่มใน Dockerfile ด้วยคำสั่ง VOLUMEดังนั้นคุณไม่จำเป็นต้องคัดลอกโวลุ่มจากคอนเทนเนอร์อื่น

สิ่งนี้จะทำให้คอนเทนเนอร์ของคุณพึ่งพาน้อยลงและคุณไม่ต้องกังวลเกี่ยวกับการลบคอนเทนเนอร์หนึ่งที่มีผลต่ออีก

เมื่อใช้Docker Composeให้แนบวอลลุ่มที่ตั้งชื่อไว้เช่น:

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

@ คำตอบของ tommasop เป็นสิ่งที่ดีและอธิบายกลไกบางอย่างของการใช้ภาชนะบรรจุข้อมูลอย่างเดียว แต่ในฐานะคนที่คิดว่าในตอนแรกภาชนะบรรจุข้อมูลนั้นงี่เง่าเมื่อใครคนหนึ่งสามารถผูกไดรฟ์ข้อมูลกับโฮสต์ (ตามที่แนะนำโดยคำตอบอื่น ๆ อีกหลายข้อ) แต่ตอนนี้ตระหนักว่าในความเป็นจริงแล้ว บล็อกโพสต์ในหัวข้อนี้: ทำไม Docker Data Containers (Volumes!) ถึงดี

โปรดดูเพิ่มเติมที่: คำตอบของฉันสำหรับคำถาม " เป็นวิธีที่ดีที่สุดในการจัดการสิทธิ์สำหรับไดรฟ์ข้อมูลที่แชร์กับ Docker อย่างไรตัวอย่างของวิธีการใช้คอนเทนเนอร์ข้อมูลเพื่อหลีกเลี่ยงปัญหาต่างๆ

วิธีแก้ปัญหาข้อกังวลดั้งเดิมของ OP: ต้องไม่ลบที่เก็บข้อมูล แม้ว่าที่เก็บข้อมูลถูกลบข้อมูลที่ตัวเองจะไม่สูญหายตราบเท่าที่ภาชนะใดที่มีการอ้างอิงถึงปริมาณที่เช่นภาชนะใด ๆ --volumes-fromที่ติดตั้งไดรฟ์ผ่าน ดังนั้นถ้าคอนเทนเนอร์ที่เกี่ยวข้องทั้งหมดถูกหยุดและลบ (ใครสามารถพิจารณาสิ่งนี้เทียบเท่ากับอุบัติเหตุrm -fr /) ข้อมูลมีความปลอดภัย คุณสามารถสร้างที่เก็บข้อมูลใหม่ได้ตลอดเวลาโดยทำที่--volumes-fromเก็บใด ๆ ที่มีการอ้างอิงถึงปริมาณนั้น

เช่นเคยทำการสำรองข้อมูล!

UPDATE: ตอนนี้นักเทียบท่ามีปริมาณที่สามารถจัดการได้โดยอิสระจากตู้สินค้าซึ่งช่วยให้จัดการได้ง่ายขึ้น

มีหลายระดับของการจัดการข้อมูลถาวรขึ้นอยู่กับความต้องการของคุณ:

• เก็บไว้ในโฮสต์ของคุณ
  • ใช้แฟล็ก-v host-path:container-pathเพื่อยืนยันข้อมูลไดเร็กทอรีคอนเทนเนอร์ไปยังโฮสต์ไดเร็กทอรี
  • การสำรองข้อมูล / คืนค่าเกิดขึ้นโดยการเรียกใช้การสำรองข้อมูล / คืนค่าคอนเทนเนอร์ (เช่น tutumcloud / dockup) ซึ่งติดตั้งอยู่ในไดเรกทอรีเดียวกัน
• สร้าง data container และเมานต์วอลุ่มไปยัง container application ของคุณ
  • สร้างคอนเทนเนอร์ที่ส่งออกโวลุ่มข้อมูลใช้--volumes-fromเพื่อเมาท์ข้อมูลนั้นลงในคอนเทนเนอร์แอปพลิเคชันของคุณ
  • สำรองข้อมูล / คืนค่าเช่นเดียวกับโซลูชันด้านบน
• ใช้ปลั๊กอินระดับเสียงของนักเทียบท่าที่สำรองบริการภายนอก / บุคคลที่สาม
  • ปลั๊กอินระดับเสียงของนักเทียบท่าช่วยให้แหล่งข้อมูลของคุณมาจากที่ใดก็ได้ - NFS, AWS (S3, EFS และ EBS)
  • ขึ้นอยู่กับปลั๊กอิน / บริการคุณสามารถแนบคอนเทนเนอร์เดียวหรือหลายคอนเทนเนอร์กับวอลุ่มเดียว
  • การสำรองข้อมูล / คืนค่าอาจเป็นไปโดยอัตโนมัติสำหรับคุณทั้งนี้ขึ้นอยู่กับบริการ
  • แม้ว่าจะยุ่งยากในการทำด้วยตนเอง แต่วิธีการแก้ปัญหาบางอย่างเช่นRancherมีวิธีการอบและใช้งานง่าย
  • Convoyเป็นวิธีแก้ปัญหาที่ง่ายที่สุดสำหรับการทำสิ่งนี้ด้วยตนเอง

หากคุณต้องการที่จะย้ายไดรฟ์ของคุณรอบ ๆ ตัวคุณควรดูที่Flocker

จาก README:

Flocker เป็นเครื่องมือจัดการปริมาณข้อมูลและเครื่องมือการจัดการคลัสเตอร์หลายโฮสต์ Docker ด้วยคุณสามารถควบคุมข้อมูลของคุณโดยใช้เครื่องมือเดียวกับที่คุณใช้สำหรับแอปพลิเคชันไร้สัญชาติของคุณโดยการควบคุมพลังของ ZFS บน Linux

ซึ่งหมายความว่าคุณสามารถเรียกใช้ฐานข้อมูลคิวและร้านค้าคีย์ - ค่าใน Docker และย้ายไปมาได้อย่างง่ายดายเหมือนกับส่วนที่เหลือของแอปพลิเคชันของคุณ

ขึ้นอยู่กับสถานการณ์ของคุณ (ซึ่งไม่เหมาะกับสภาพแวดล้อมการผลิตจริง ๆ ) แต่นี่เป็นวิธีหนึ่ง:

สร้าง MySQL Docker Container

ส่วนสำคัญของมันนี้คือการใช้ไดเรกทอรีบนโฮสต์ของคุณสำหรับการเก็บรักษาข้อมูล

ฉันเพิ่งเขียนเกี่ยวกับวิธีแก้ปัญหาที่มีศักยภาพและแอปพลิเคชันที่แสดงให้เห็นถึงเทคนิค ฉันคิดว่ามันค่อนข้างมีประสิทธิภาพในระหว่างการพัฒนาและในการผลิต หวังว่ามันจะช่วยหรือจุดประกายความคิดบางอย่าง

Repo: https://github.com/LevInteractive/docker-nodejs-example
บทความ: http://lev-interactive.com/2015/03/30/docker-load- บาลานซ์-mongodb-persistence/

ฉันแค่ใช้ไดเรกทอรีที่กำหนดไว้ล่วงหน้าในโฮสต์เพื่อเก็บข้อมูลสำหรับ PostgreSQL นอกจากนี้วิธีนี้ยังสามารถโยกย้ายการติดตั้ง PostgreSQL ที่มีอยู่ไปยังคอนเทนเนอร์ Docker ได้อย่างง่ายดาย: https://crondev.com/persistent-postgresql-inside-docker/

โซลูชันของฉันคือการใช้ประโยชน์ใหม่docker cpซึ่งขณะนี้สามารถคัดลอกข้อมูลจากคอนเทนเนอร์ไม่ว่าจะทำงานอยู่หรือไม่และแชร์โฮสต์โฮสต์ไปยังตำแหน่งเดียวกันกับที่แอปพลิเคชันฐานข้อมูลกำลังสร้างไฟล์ฐานข้อมูลภายในคอนเทนเนอร์ . โซลูชันสองตัวนี้ทำงานโดยไม่มีที่เก็บข้อมูลอย่างเดียวตรงจากที่เก็บฐานข้อมูลดั้งเดิม

ดังนั้นสคริปต์ systemd init ของฉันกำลังทำหน้าที่สำรองข้อมูลฐานข้อมูลลงในไฟล์เก็บถาวรบนโฮสต์ ฉันวางเวลาลงในชื่อไฟล์เพื่อไม่ให้เขียนไฟล์ซ้ำ

มันทำมันบน 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'

และมันก็ทำแบบเดียวกันกับ 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'

รวมทั้งฉันได้เปิดโฟลเดอร์จากโฮสต์เป็นไดรฟ์ข้อมูลไปยังตำแหน่งเดียวกันที่เก็บฐานข้อมูล:

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

มันใช้งานได้ดีกับ VM ของฉัน (ฉันสร้าง LEMP stack สำหรับตัวฉันเอง): https://github.com/DJviolin/LEMP

แต่ฉันก็ไม่รู้ว่ามันเป็นคำตอบที่ "กระสุน" หรือไม่เมื่อชีวิตของคุณขึ้นอยู่กับมัน (ตัวอย่างเช่นเว็บช็อปที่มีการทำธุรกรรมในเวลาไม่กี่วินาทีที่เป็นไปได้)

ที่ 20 นาที 20 วินาทีจากวิดีโอปราศรัย Docker อย่างเป็นทางการผู้นำเสนอทำสิ่งเดียวกันกับฐานข้อมูล:

เริ่มต้นกับนักเทียบท่า

"สำหรับฐานข้อมูลเรามีโวลุ่มดังนั้นเราจึงมั่นใจได้ว่าเมื่อฐานข้อมูลขึ้นและลงเราจะไม่สูญเสียข้อมูลเมื่อคอนเทนเนอร์ฐานข้อมูลหยุดทำงาน"

ใช้ Persistent Volume Claim (PVC) จาก Kubernetes ซึ่งเป็นเครื่องมือจัดการและกำหนดเวลาของ Docker container:

เล่มถาวร

ข้อดีของการใช้ Kubernetes สำหรับจุดประสงค์นี้คือ:

• คุณสามารถใช้ที่เก็บข้อมูลใด ๆ เช่น NFS หรือที่เก็บข้อมูลอื่น ๆ และแม้ว่าโหนดจะไม่ทำงานที่จัดเก็บข้อมูลก็ไม่จำเป็นต้องเป็น
• ยิ่งไปกว่านั้นข้อมูลในวอลุ่มดังกล่าวสามารถกำหนดค่าให้เก็บรักษาได้แม้หลังจากที่ตัวคอนเทนเนอร์ถูกทำลาย - เพื่อให้สามารถเรียกคืนได้หากจำเป็นโดยคอนเทนเนอร์อื่น