stop/rm adalah cara yang benar. Data dalam volume bisa jadi penting, jadi kami ingin mempersulit penghapusannya secara tidak sengaja.

Kami mungkin dapat mendokumentasikannya sedikit lebih baik.

Kebijakan ini tampaknya melanggar praktik terbaik buruh pelabuhan, dan menyebabkan _tons_ sakit kepala saat memecahkan masalah mengapa membuat ulang kontainer mengalami kebocoran status. Ketika saya memberi tahu buruh pelabuhan untuk membuat ulang, itu tidak berarti "mempertahankan beberapa data di seluruh wadah berjalan tetapi memulai ulang proses di wadah". Artinya mengaspal bumi dan memulai kembali. Jika saya ingin menyimpan volume, saya akan secara eksplisit me-mount volume. Saya _never_ mengharapkan volume yang dipasang otomatis dalam bentuk apa pun untuk tetap ada di seluruh penampung yang berjalan.

Data yang bertahan di seluruh proses sebenarnya adalah satu-satunya alasan untuk menggunakan volume. Jika Anda tidak ingin data persisten mengapa Anda menaruhnya dalam volume?

Saya tidak sedang menyiapkan volume. docker-compose.yml tidak memiliki pengaturan volume dan saya tidak mengirimkan apapun ke docker-compose.yml untuk melampirkan volume apapun.

Perintah:

docker-compose up --force-recreate --abort-on-container-exit --build foo

docker-compose.yml:

version: '2'
services:
  foo:
    build:
      context: .
      dockerfile: src/integration/foo/Dockerfile
    ports:
      - "3306:3306"
      - "33060:33060"

Dockerfile:

FROM mysql:5.7

COPY schema/foo/migration.sql /data/db_schema.sql
COPY src/integration/foo/create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD true

EXPOSE 3306 33060

create_test_db.sh:

#!/bin/bash
set -e
mysql --no-defaults -u root -e "drop database if exists agent_state; create database foo"
mysql --no-defaults -u root foo < "/data/db_schema.sql"

Jika saya menjalankan perintah di atas, tulis beberapa hal ke DB, lalu SIG_INT, lalu jalankan kembali perintah tersebut, data yang saya masukkan ke DB tetap ada di sepanjang proses.

Itu masalah dengan image MySQL. Ini menciptakan volume di pangkalan
gambar. Anda dapat mengatasi masalah ini dengan menggunakan MySQL yang berbeda
gambar atau mungkin dengan memaksanya menggunakan jalur yang berbeda untuk data.

Pada 19 Okt 2016 18:36, "Micah Zoltu" [email protected] menulis:

Saya tidak sedang menyiapkan volume. Buruh pelabuhan-compose.yml saya tidak punya
volume setup dan saya tidak meneruskan apapun ke docker-compose.yml ke
lampirkan volume apa pun.

Perintah:

docker-compose up --force-rekreate --abort-on-container-exit --build foo

docker-compose.yml:

versi: '2'
jasa:
foo:
membangun:
konteks:.
dockerfile: src / integrasi / foo / Dockerfile
port:
- "3306: 3306"
- "33060: 33060"

Dockerfile:

DARI mysql: 5.7

SALIN skema / foo / migrasi.sql /data/db_schema.sql
SALIN src / integrasi / foo / create_test_db.sh /docker-entrypoint-initdb.d/create_test_db.sh
ENV MYSQL_ALLOW_EMPTY_PASSWORD benar

PAPARKAN 3306 33060

create_test_db.sh:

! / bin / bash

set -e
mysql --no-defaults -u root -e "jatuhkan database jika ada agent_state; buat database foo"
mysql --no-defaults -u root foo <"/data/db_schema.sql"

Jika saya menjalankan di atas, tulis beberapa hal ke DB, lalu SIG_INT, lalu jalankan
perintah lagi data yang saya masukkan ke dalam DB tetap ada selama proses.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/2127#issuecomment -254986952,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAa_RG_pJj0i-OSCfcBlG__8ToFDtGKMks5q1sWlgaJpZM4GHruC
.

Hmm, ini melanggar pemahaman saya tentang kontainer buruh pelabuhan. Bagaimana cara memasang volume tanpa saya menyediakan jalur pada host? Pemahaman saya adalah bahwa kontainer buruh pelabuhan bersifat sementara kecuali Anda secara eksplisit memasang volume?

Volume tidak membutuhkan jalur host. Ada tiga jenis volume:

• pemasangan mengikat host ( -v /host:/container )
• volume bernama ( -v name:/container , dibuat dengan docker volume create )
• volume anonim ( -v /container , atau VOLUME di dalam Dockerfile )

Gambar mysql menggunakan volume anonim. Saat runtime, Anda dapat memberi tahu container untuk menggunakan volume yang berbeda untuk jalur tersebut di container, tetapi jika tidak, volume anonim masih ada.

Volume anonim tidak bagus. Mereka adalah yang tertua dari ketiganya, dan sebagian besar perilakunya adalah barang warisan yang hanya disimpan untuk alasan kompatibilitas mundur.

Setidaknya beberapa opsi baris perintah a la "--recreate-volumes" akan bagus ...

Oke, teman-teman, inilah kasus yang perlu dipikirkan:

1) Saya ingin memasang ulang direktori publik Rails saya ke wadah nginx, sehingga beberapa hal statis dapat dilayani oleh nginx secara langsung.
2) Saya menetapkan volume "anonim" (bukan terpasang di host, tidak bernama) ke / usr / local / app / app / public, dan membagikannya ke nginx melalui "volumes_from"
3) konten "publik" sering diubah pada build gambar - tidak hanya file tingkat atas tetapi beberapa file di subdirektori (ini penting)

Saat ini, jika saya membuat ulang container, saya akan mendapatkan versi lama "publik" - konten dalam gambar diabaikan begitu saja. Ya, Docker seharusnya menyalin file yang hilang ke volume anonim, tetapi karena berbagai alasan hal itu tidak selalu terjadi (saya curiga, tidak ada pemeriksaan mendalam pada struktur subdirektori).

Jadi, saya dipaksa untuk melakukan urutan "stop-rm-up" (tidak nyaman dalam produksi), atau menggunakan direktori terpisah sebagai volume bersama, dan secara eksplisit memanggil 'rsync' pada wadah aplikasi mulai mengisi / memperbaruinya.

Jika ada cara untuk membiarkan volume anonim mengikuti penampung induk, itu akan menjadi perbaikan besar.

Jangan gunakan volume untuk kode (atau aset statis). Volume adalah untuk data yang ingin Anda pertahankan di antara penerapan, yang berlawanan dengan yang Anda inginkan di sini. Buat gambar nginx dengan aset statis, atau buat proxy beberapa penampung server web yang memuatnya.

Terima kasih untuk sudut pandangnya! Saya belum berpikir dari sudut pandang ini.

Ini tampaknya menjadi salah satu masalah konseptual dengan (masih berkembang) arsitektur Docker. Kami melihat evolusi konsep volume data sejauh ini (misalnya dari "wadah data" menjadi "volume bernama") dan mungkin belum selesai.

Jika Anda akan melihat di https://docs.docker.com/engine/tutorials/dockervolumes/#/data -volumes, Anda akan melihat bahwa manfaat yang paling dijelaskan (melewati AUFS, berbagi) tidak selalu terhubung ke persistensi data ( volume yang awalnya dirancang untuk).

Jadi, tidak mengherankan jika orang (termasuk saya) mencoba menggunakan volume dalam berbagai cara di luar tujuan aslinya. Misalnya untuk membagikan data singkat atau data yang dikontrol gambar dari satu penampung ke penampung lainnya, tanpa banyak penyalinan eksplisit.

Mungkin suatu hari nanti kita akan menemukan cara standar yang konsisten untuk melakukannya. :) Sejauh ini, dimungkinkan untuk menggunakan beberapa solusi yang cukup sederhana yang dijelaskan di atas. Tidak ideal, tetapi dapat diterima, selama ekspektasi arsitektur ditetapkan dengan benar.

Sekali lagi, terima kasih atas tanggapan, klarifikasi, dan kerja hebat yang Anda lakukan!

Saya mengalami masalah ini hari ini, terima kasih atas penjelasan yang bagus di sini semuanya, telah membantu saya memahami masalahnya.

Titik utama kebingungan bagi saya adalah memahami bahwa tag VOLUME dalam file dok menyebabkan volume anonim yang konsisten dibuat. Saya mungkin telah melewatkannya di dokumentasi tetapi tidak dapat menemukan menyebutkannya.

@fahrizal

Seperti yang disebutkan @ hleb-rubanau. Menjalankan wadah tunggal dengan Rails dan Nginx adalah solusinya? (Seperti ini: https://docs.docker.com/engine/admin/multi-service_container/?)

Haruskah saya melanggar praktik terbaik ("Setiap penampung seharusnya hanya memiliki satu masalah
") hanya untuk menyajikan aset? :(

Bagi mereka yang tertarik, saya berakhir dengan yang berikut:

1) Dalam pengaturan saya, saya selalu menggunakan volume yang dipasang di-bind (alias dipasang di host) sekarang. Volume anonim dan bernama memiliki terlalu banyak logika khusus / tidak jelas / bersyarat / tidak konsisten / impicit untuk dipertimbangkan. Ya, mudah untuk memahami secara spesifik siklus hidup dan pengelolaan setiap jenis, tetapi saya merasa lebih mudah bagi saya untuk memikirkan arsitektur ketika saya tidak mengkhawatirkan semua perbedaan yang tidak relevan tersebut. Untuk FS Gluster terdistribusi berfungsi dengan baik (masih diikat dari perspektif Docker).

2) Volume bersama adalah satu yang dipasang di-bind, dan ini bukan direktori tempat aset disimpan dalam gambar. Pada awalnya (di entrypoint) saya menjalankan rsync lokal, sehingga aset dari direktori gambar disalin / disinkronkan ke jalur penyimpanan bersama yang dipasang di bind.

Terima kasih @ hleb-rubanau

Bagaimanapun, saya tidak yakin apakah beberapa alat orkestrasi seperti RancherOS mendukung konfigurasi volume tersebut atau merupakan cara yang tepat untuk menskalakan. Pada akhirnya, lebih sulit menyebarkan dengan buruh pelabuhan ...

Saya lebih suka menggunakan volume anonim dan membersihkan anak yatim di beberapa titik.

Ini adalah tumpukan rel produksi saya: https://github.com/brunocascio/AR-MTB/blob/master/docker-compose.prod.yml

Hal ini juga membuat saya kebingungan dalam jumlah _large_ ketika saya menguji gambar jenkins / jenkins dan tidak menghargai perubahan saya dari file di / usr / share / jenkins / ref karena sudah menyalinnya.

Itu adalah pengalaman pengguna yang sangat tidak terduga - docker compose membuat volume "tersembunyi" untuk semua maksud dan tujuan. Jika Anda menggunakan normal docker run maka Anda mendapatkan volume baru setiap kali. Ini adalah volume tersembunyi dalam arti bahwa tidak ada di docker-compose up membicarakannya, jadi kecuali Anda tahu secara rinci apa yang dilakukan gambar itu, Anda harus menggali.

Paling tidak _very_ kita harus mencetak pesan yang mengatakan "tidak membuat ulang volume x" sehingga orang lain di masa mendatang tidak perlu membuang waktu untuk bertanya-tanya apa yang terjadi.

Hai @dephin ,

Saya menelepon sudo rm -rf /var/lib/docker/volumes/aa_dbdatavol dan sekarang saya tidak bisa lagi docker-compose up postgres saya docker-compose .

Mendapatkan kesalahan ini

Membuat jaringan "aa_default" dengan driver default
Membuat aa_postgres_1
EROR: untuk postgres Tidak dapat membuat wadah untuk layanan postgres: tidak ada file atau direktori seperti itu
EROR: Terjadi kesalahan saat membuka proyek.
Respons kesalahan dari daemon: Tidak ada penampung seperti itu: aa_postgres_1

Karena Anda mungkin memiliki ide untuk menyiasatinya, silakan berbagi. Terima kasih!

https://github.com/docker/compose/issues/2127#issuecomment -347152650

Hanya membuat ulang folder akan memperbaiki masalah saya.
/var/lib/docker/volumes/aa_dbdatavol/_data

Terima kasih banyak kepada @dnephin , jawaban Anda bekerja dengan sempurna, pertama kali. Muchos gracias.

@dnephin berkata:

Data yang bertahan di seluruh proses sebenarnya adalah satu-satunya alasan untuk menggunakan volume. Jika Anda tidak ingin data persisten mengapa Anda menaruhnya dalam volume?

untuk berbagi file antar kontainer. Apakah ada cara yang lebih baik untuk melakukannya tanpa menggunakan volume?

Apa yang Anda maksud dengan "berbagi file"?

Apakah Anda mengharapkan bahwa satu penampung akan menulis ke sebuah file, dan penampung lainnya akan melihat penulisan tersebut? Sistem file umumnya bukan antarmuka yang baik antara dua layanan, tetapi jika demikian, Anda dapat meminta salah satu layanan "mengelola" sistem file dengan menulis pembaruan ke volume.

Jika "berbagi" hanya dua wadah kebetulan membaca beberapa file yang sama maka tidak perlu volume. Tambahkan file ke kedua wadah dengan COPY .

Saya menggunakan Docker version 18.06.1-ce, build e68fc7a dan saya dapat menggunakan perintah berikut untuk membuat ulang volume anonim:

docker-compose up -d --build --force-recreate --renew-anon-volumes db

Tampaknya bendera --renew-anon-volumes baru saja ditambahkan

Saya menggunakan Docker version 18.06.1-ce, build e68fc7a dan saya dapat menggunakan perintah berikut untuk membuat ulang volume anonim:

docker-compose up -d --build --force-recreate --renew-anon-volumes db

Tampaknya bendera --renew-anon-volumes baru saja ditambahkan

Terima kasih telah mengizinkan opsi ini.