Compose: Tambahkan `copy` ke konfigurasi yaml

Apa semantik dari copy sini? Apakah kita menyalin file dari host tempat docker-compose dijalankan ke dalam wadah yang baru dijalankan menggunakan docker cp ?

AFAIK _tidak ada cara saat ini untuk melakukan ini:

Lihat:

`` #! pesta
$ buruh pelabuhan cp -h

Penggunaan: docker cp [OPTIONS] CONTAINER: PATH HOSTDIR | -

Salin file / folder dari PATH di container ke HOSTDIR di host
menjalankan perintah. Gunakan '-' untuk menulis data sebagai file tar ke STDOUT.

--help = false Penggunaan cetak
``

Apa semantik salinan di sini? Apakah kita menyalin file dari host tempat docker-compose dijalankan ke dalam container yang baru dijalankan menggunakan docker cp?

Iya

AFAIK saat ini tidak ada cara untuk melakukan ini:

Saya melihat bahwa perintah docker cp tidak dapat melakukannya. Namun masih mungkin dengan mengakses data kontainer di sisi host (yang saya kirimkan jelek)

http://stackoverflow.com/a/24805696/210090

Ya, saya tidak akan menganjurkan kita melakukan ini sama sekali. Ini akan merusak banyak hal dan asumsi tentang Docker. Ini juga sangat bergantung pada driver penyimpanan yang digunakan. Docker dimaksudkan untuk menjadi agnostik. Saya pikir kami _harus_ solusi yang berbeda untuk masalah Anda :)

Sekarang setelah docker-1.8 menambahkan dukungan untuk penyalinan ke container melalui docker cp dan swarm-0.4.0-rc2 menambahkan dukungan untuk docker cp , akan sangat bagus untuk meninjau kembali masalah ini di tingkat penulisan. Berikut adalah kasus penggunaan (yang mencerminkan apa yang sebenarnya kita lakukan dalam produksi _almost_ sekarang):

File docker-compose.yml yang menyebutkan banyak kontainer dengan tag gambar yang dibangun CI (yaitu kami tidak menggunakan build: dalam produksi; mungkin kami bisa sekarang tetapi tidak berfungsi dengan baik dengan swarm di rilis sebelumnya) yang semuanya perlu, misalnya file konfigurasi hadoop statis yang dipetakan di mana sama persis dengan lingkungan penerapan. Saat ini, seseorang harus secara manual menyinkronkan direktori tempat docker-compose.yml berada ke jalur yang tepat di _each_ target docker-machine di swarm. Kemudian seseorang menambahkan setumpuk baris volume: .

Mendukung docker cp akan memungkinkan penghapusan sinkronisasi file konfigurasi kustom dalam metode penerapan sistem kami dan memungkinkan kontrol yang lebih baik saat perubahan konfigurasi dimasukkan (karena siapa pun yang mengubah file yang disebutkan di baris volume: akan terpengaruh semua kontainer yang diterapkan sebelumnya (dan kapan pun implementasi internal membaca ulang konfigurasi tersebut, mungkin hanya setelah kontainer dimulai ulang, mungkin ketika berbagai alat di dalam kontainer mulai; yang mungkin tidak terduga) dan masa depan (yang diharapkan).

OTOH, (seperti yang disebutkan secara singkat di atas) mungkin kita harus menggunakan build: . Kelemahannya di sini adalah kita perlu menulis Dockerfile tambahan per jenis wadah penerapan. Satu untuk image yang dibuat CI dan yang kedua untuk injektor file konfigurasi statis. copy: dalam penulisan yang didukung oleh perubahan terbaru ke docker cp akan dengan rapi memungkinkan kita untuk menghindari semua duplikasi ini.

Sepertinya masih menggunakan volume adalah cara yang lebih baik untuk melakukan ini. Ini tidak harus berupa volume host, itu harus bekerja dengan wadah volume data.

Bedies docker-machine memiliki docker-machine scp yang dapat Anda lakukan dengan persiapan mesin; dan kemudian Anda dapat melakukan volume host dengan cara biasa seperti docker atau docker-compose

"Sepertinya masih menggunakan volume adalah cara yang lebih baik untuk melakukan ini. Tidak harus menjadi volume host, ia harus bekerja dengan wadah volume data."
Saya gagal untuk melihat bagaimana yang terbaik ketika targetnya adalah segerombolan orang. AFAICS, tidak ada cara untuk menyatakan bahwa wadah volume data harus ada di setiap node swarm yang memungkinkan.

Tidak bisakah Anda menerapkan kontainer volume data pada setiap node melalui swarm itu sendiri seperti yang Anda bisa dengan strategi penjadwalan ala kontainer lainnya?

"Bedies docker-machine memiliki docker-machine scp yang dapat Anda lakukan dengan persiapan mesin; dan kemudian Anda dapat melakukan volume host dengan cara normal baik dengan docker atau docker-compose"
Saya saat ini melakukan ini. Itu menyakitkan. Orang yang mengelola penerapan lupa memindahkan file konfigurasi. Jika itu didukung di docker-compose yml maka itu akan terjadi setiap kali sebuah kontainer dibuat ulang tanpa langkah manual.

"Tidak bisakah Anda menerapkan kontainer volume data pada setiap node melalui swarm itu sendiri seperti yang Anda bisa dengan strategi penjadwalan ala kontainer lainnya?"
Mungkin kita bisa tapi saya akui bahwa saya tidak melihat bagaimana dalam penskalaan.

"Tidak bisakah Anda menerapkan kontainer volume data pada setiap node melalui swarm itu sendiri seperti yang Anda bisa dengan strategi penjadwalan ala kontainer lainnya?"
Hmm, jika saya tahu bahwa gerombolan saya berukuran 10 node; dapatkah saya menskalakan wadah volume data menjadi ukuran 10 dengan kebijakan bahwa tidak ada dup yang diizinkan pada node mesin buruh pelabuhan tertentu? Masalahnya (kecuali saya melewatkan sesuatu) adalah bahwa misalnya kontainer yang perlu referensi volume data yang tidak memiliki cara untuk --volume-dari kontainer dengan indeks yang cocok. Teman-teman, saya telah melihat masalah ini selama 2 bulan sekarang. Hal terbaik yang bisa saya lakukan adalah membuat skrip yang menggunakan docker-machine scp . Tetapi ini adalah langkah manual setelah mengedit file konfigurasi dan sebelum docker-compose up . Ini juga mensyaratkan bahwa seseorang dapat menulis jalur yang tepat pada mesin target dari swarm sebagai root dari docker-compose.yml (yaitu baunya seperti hack besar).

Mungkin upaya saya di pabrik dapat membantu mengotomatiskan proses pemintalan mesin buruh pelabuhan dan komputer yang mengerumuni komputer dengan data yang "benar" siap digunakan? (_sekalipun masih dalam pengembangan awal dan saya menggunakannya untuk menggabungkan docker-machine dan docker-compose dalam satu setp_0.

copy adalah operasi, bukan bagian dari konfigurasi layanan, jadi tidak termasuk dalam file tulis.

Docker 1.9 menambahkan api volume baru, dan driver volume sudah ada. Volume benar-benar cara yang tepat untuk mendukung ini. Tidak mencoba menyalin file di sekitar.

Terima kasih untuk sarannya! tapi saya rasa ini tidak benar-benar cocok dengan desain compose sekarang.

copy adalah operasi, bukan bagian dari konfigurasi layanan, jadi tidak termasuk dalam file tulis.

Bagaimana jika seseorang hanya ingin menyalin file konfigurasi? (ke kawanan buruh pelabuhan, jadi volume_from tidak akan berfungsi)

Saya memiliki situasi yang persis sama, ingin menyalin file konfigurasi mysql, nginx, haproxy, dll. Kustom, kami memiliki cluster dalam produksi, dan alih-alih hanya menggunakan satu perintah salin untuk menyalin konfigurasi dari lokal ke jarak jauh

Saya harus menggunakan gambar, membangun, menarik setiap kali, sementara tidak perlu sama sekali dan hanya menyalin perintah akan menghemat banyak waktu penyebaran dan pengembangan

Ini sangat mengejutkan bagi saya bahwa lebih banyak orang tidak memiliki masalah dengan ini yang tidak dapat dituliskan. Apakah saya berpikir tentang buruh pelabuhan yang salah? Saya pikir solusi saya sekarang adalah menggunakan ansible untuk menyalin file konfigurasi ke host dan kemudian volume mount dari host ke wadah yang membutuhkannya

Menekan masalah yang sama. Saya menggunakan kembali Dockerfile untuk N layanan yang berbeda dan saya tidak ingin membuat N Dockerfile berbeda dengan perintah COPY mereka sendiri atau membuat volume hanya untuk itu.

Btw saya sedang menyelesaikannya dengan menjalankan lusinan baris perintah sed - http://unix.stackexchange.com/questions/112023/how-can-i-replace-a-string-in-a-files

Mungkin bukan solusi optimal tetapi berfungsi mengingat docker-compose tidak mendukung penyalinan file.

Btw pemasangan dan penyalinan tentu saja mungkin tetapi itu bertentangan dengan otomatisasi tawaran penulisan galangan - jika saya lebih suka melakukan semuanya secara manual, saya tidak akan menggunakan penulisan galat, bukan?

Semakin saya menggali Docker, semakin banyak perkakas ini yang bagus untuk "hello world" / "lihat seberapa cepat saya dapat memutar hal keren ini dengan \ shell \ commands \ like \ this \" di kasus penggunaan tipe mesin tunggal (termasuk docker-compose). Jika lebih dari itu, hal-hal mulai menjadi sangat rumit dan IMO sedikit berantakan di mana alat penyediaan tradisional dapat masuk dan menyelamatkan hari ketika digunakan dengan tepat.

Saya telah menemukan menggunakan Ansible untuk mengatur mesin dengan cara idempoten menjadi sangat mudah ketika saya memiliki volume khusus mesin, file dan file konfigurasi templated yang harus ada untuk image buruh pelabuhan untuk memulai. Kemudian pada akhirnya saya dapat menggunakan Ansible untuk menjalankan docker-compse atau bahkan menggunakan modul docker Ansible yang sintaksnya hampir sama dengan docker compose dengan beberapa fitur bonus tambahan yang bagus.

Pada akhirnya, pendekatan di atas memungkinkan semuanya untuk dituliskan, idempoten dan yang paling penting diperiksa ke dalam kontrol sumber.

@dnephin beberapa orang di atas menyarankan kasus penggunaan CP sebagai bagian dari konfigurasi, apakah masuk akal untuk meninjau kembali asumsi bahwa CP hanya untuk operasi dan bukan untuk konfigurasi.

Contoh sederhananya adalah membuat penampung, menyalin konfigurasi di tempat yang benar, memulai penampung setelah konfigurasi disalin.

Ini memungkinkan pembuatan gambar yang tidak menyematkan konfigurasi sebenarnya dan hanya menerapkan konfigurasi saat penampung dimulai.

Pasti akan sangat membantu. Saya bekerja dengan gambar postgres sebagai database back end sekarang dan saya tidak ingin membangunnya kembali, hanya untuk memperbarui skrip di folder /docker-entrypoint-initdb.d .

Mengapa kalian tidak membuka kembali masalah ini sampai fitur diterapkan atau solusi yang bisa diterapkan ditemukan yang disukai orang, karena tidak ada orang di sini yang menyukai opsi yang disarankan?

Masalah ini harus dibuka kembali, seperti yang disebutkan @ctindel .

+1 untuk membuka kembali masalah

1 untuk pembukaan juga.

1 untuk membuka kembali.

1 untuk membuka kembali.

1 untuk membuka kembali.

1 untuk membuka kembali.

1 untuk membuka kembali.

1 untuk membuka kembali.

Apa yang salah dengan volume hanya-baca?

myservice:
    image: foo/bar
    volume:
        - src:dest:ro

@michaelarnauts lihat ini .

👍 untuk membuka kembali

1 untuk membuka kembali.

1 untuk membuka kembali.

1 untuk membuka kembali

1 untuk membuka kembali

1 untuk membuka kembali

1 untuk membuka kembali

1 untuk membuka kembali

1 untuk membuka kembali

Inilah alasan saya untuk mengizinkan salinan di Tulis.

Saya memiliki aplikasi yang telah berjalan di banyak Container. Demi argumen, mari kita tetapkan bahwa mereka semua menjalankan Apache. Mereka semua memiliki definisi DocumentRoot yang menunjuk ke hal-hal seperti "/ var / www / partX". Dockerfile tidak tahu apa-apa tentang konten konfigurasi Apache, dan Compose menentukan referensi volume untuk / var / www / partX. Ini berfungsi dengan baik untuk pengembangan, karena saya dapat men-debug dan mengubah kode tanpa mengubah konten wadah.

Masalahnya adalah saat saya ingin menerapkan. Salah satu daya tarik utama tentang Docker adalah saya dapat menerapkan wadah yang merupakan semesta miliknya sendiri. Untuk mendapatkan semuanya di container, saya harus menyalin file, yang berarti saya harus memiliki definisi Dockerfile dan Compose yang terpisah dari apa yang saya gunakan untuk pengembangan. Pada proyek besar, ini berarti saya harus memelihara dua set file definisi, yang lebih memungkinkan terjadinya kesalahan.

Preferensi saya adalah mempertahankan satu set Dockerfiles, dan melakukan orkestrasi pada file Compose. Tulis akan menjadi tempat yang saya tentukan jika saya akan menyiapkan / var / www / partX sebagai volume bersama atau jika saya menyalin file ke dalam container.

Menerapkan dengan volume bersama sepertinya sekaleng worm. Jika saya memperbarui versi yang sudah ada dalam produksi yang bergantung pada volume bersama, saya tidak dapat memperbarui volume bersama itu tanpa menyiapkan jendela pemeliharaan atau membuat skema untuk membuat versi volume bersama saya. Saya sangat erat menggabungkan kontainer dengan file eksternal, dan jika saya memperkenalkan jenis kerumitan itu, saya meniadakan beberapa manfaat menggunakan Docker.

Sepertinya saya bisa mengubah skrip pada definisi Dockerfile untuk menyalin file secara bersyarat, tetapi tampaknya lebih "logis" menangani semua logika Docker saya di dunia Docker, dan Compose sepertinya tempat yang logis untuk melakukannya.

1 untuk membuka kembali.

+1. Akan sangat membantu untuk menyalin file konfigurasi dalam file docker-compose.yml daripada Dockerfile .

+1. Baru saja menabraknya mencoba menyediakan file konfigurasi untuk layanan tersebut. Volume hanya-baca sepertinya merupakan opsi, tetapi lebih suka menyalinnya.

Cukup memasang volume dapat melakukan trik:

version: '2'
services:
  foobar:
    image: 'postgres:9.6-alpine'
    volumes:
      - './docker/schemas/foobar:/docker-entrypoint-initdb.d'

@raszi - Yah, konfigurasi yang dipasang adalah arah yang akan kita tuju untuk saat ini. Salah satu hal yang sangat saya sukai tentang Docker adalah gagasan tentang wadah mandiri tempat saya dapat menjalankan tes integrasi, tanpa memperhatikan ketergantungan eksternal (seperti konfigurasi tertaut). Jika saya melakukan penerapan biru / hijau atau A / B, dan ada perbedaan dalam konfigurasi yang digunakan oleh berbagai versi penampung, hal-hal dapat menjadi sedikit rapuh. Saya bisa menyiasati ini dengan melakukan hal-hal seperti membuat versi file konfigurasi dalam volume bersama dari setiap lingkungan saya, tetapi tampaknya lebih kompleks atau rapuh daripada yang seharusnya.

"Kontainer Docker membungkus perangkat lunak dalam sistem file lengkap yang berisi semua yang diperlukan untuk menjalankan: kode, runtime, alat sistem, pustaka sistem - apa pun yang dapat diinstal di server. Ini menjamin bahwa perangkat lunak akan selalu berjalan sama, terlepas dari lingkungannya. " Bagi saya, idealnya mencakup konfigurasi. Compose adalah semacam melakukan "build / compile and run", saya rasa beberapa dari kita di sini berharap Compose bisa melakukan "build / compile, link and run". Ini bukan cara kerjanya hari ini, dan saya dapat memahami kurangnya antusiasme untuk menempuh rute itu, tapi hei, ini forum, tidak ada salahnya untuk bertanya;)

Saya setuju, akan sangat menyenangkan memiliki fitur ini. Saya baru saja memposting solusi saya untuk membantu orang lain.

1 untuk membuka kembali.

+1

1 untuk membuka kembali atau solusi berbeda tanpa volume.

Saat ini menggunakan variabel Lingkungan di docker-compose.yml dan j2 di docker-entrypoint.sh untuk menguraikannya ke file konfigurasi sebelum menjalankan aplikasi utama container. Berfungsi untuk saya, meskipun ini adalah gambar khusus dan tidak dapat digunakan di luar kotak dengan gambar lengkap yang sudah tersedia.

+1

+1

+1

+1

+1

+1

+1

+1

+1

1 untuk membuka kembali

Untuk menambahkan kemungkinan memiliki file yaml berbeda untuk setiap penampung alih-alih konfigurasi berdasarkan variabel lingkungan

+1 fitur yang sangat dibutuhkan

+1, senang memiliki fitur!

+1

+1

+1

+1

+1 dibuka kembali. Dibookmark

+1 ini adalah fitur yang sangat dibutuhkan.

Jika ada cara untuk menandai volume bersama sebagai lapisan, sehingga volume tetap RO tetapi penulisan diterapkan ke lapisan di atas, saya akan hidup bahagia tanpa perintah copy . Saya ingin membagikan, misalnya, artefak build yang diekstrak, tetapi layanan menulis ke direktori itu (log atau file PID, dll.).

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 Untuk membuka kembali karena ini akan menjadi fitur yang sangat berguna

Mungkin fitur template https://github.com/jwilder/dockerize dapat membantu sebagian dari Anda

+1

+1

+1

+1

+1

+1 untuk membuka kembali masalah tersebut

+1

Gunakan rahasia buruh pelabuhan, dalam contoh ini rahasia digunakan dengan gambar nginx untuk menyalin sertifikat server dan file konfigurasi
https://docs.docker.com/engine/swarm/secrets/#intermediate -example-use-secret-with-a-nginx-service

Itu poin yang bagus. Sejujurnya, karena kita sudah memiliki rahasia, kita seharusnya memiliki salinan, sebagaimana rahasia, dengan cara tertentu, hanya jenis file tertentu yang akan Anda salin. Yaitu, yang disediakan dengan lebih hati-hati, yang tidak kita perlukan untuk file konfigurasi.

Ini mengalahkan host yang memasang volume untuk setiap file konfigurasi yang ingin Anda sertakan.

Seperti dikatakan di atas:

...
volume:
- ./nginx/default.conf:/etc/nginx/conf.d/default. conf: ro
- ./nginx/nginx.conf:/etc/nginx/nginx. conf: ro
...

Alasan mengapa menyalin lebih baik, a) di lingkungan swarm, di mana host sebenarnya adalah mesin yang terpisah, Anda tidak harus memiliki file yang sama persis di tempat yang sama di setiap mesin. b) Salinan juga dapat dibatasi ke folder tempat pembuatan, sedangkan pemasangan host memerlukan jalur absolut. c) Saya pikir tujuan buruh pelabuhan adalah untuk meminimalkan jumlah tempat yang dibobol oleh aplikasi yang ada di dalam host. Pemasangan host, bahkan ketika dikonfigurasi sebagai hanya-baca, membuat tanggung jawab pada host untuk memiliki dan menyimpan file. Kita tidak harus menggunakan pemasangan host untuk menyelesaikan masalah sederhana ini.

Saya pikir menyalin dapat dimodelkan mirip dengan proses docker build , di mana Dockerfile biasanya dikirim dalam repositori git, bersama dengan semua file yang perlu dikirim ke konteks build. Dockerfile tidak diizinkan untuk mengirim apapun yang ada di luar struktur direktorinya, bahkan jika terhubung dengan benar. Kita bisa memiliki hal serupa dengan compose, di mana src dibatasi ke direktori (dan yang di bawah) dari docker-compose.yml . Pada dasarnya, alur kerjanya adalah, docker-compose membuat wadah, dan kemudian untuk setiap pasangan src:dst , temukan src bawah direktori saat ini, dan salin ke wadah yang belum dimulai, lalu mulai wadahnya.

Saat ini, menghindari pemasangan host dapat dilakukan dengan menambahkan tambahan Dockerfiles dan membuat file conf menjadi gambar yang diubah, tetapi ini tampaknya berlebihan bagi saya, karena ini melibatkan pemberian tag ulang pada gambar baru, atau memaksa pengguna untuk menggunakan atribut docker-compose build daripada atribut yang lebih disukai (IMO) image . Jika Anda sudah menggunakan atribut build dalam definisi layanan Anda, dan Anda ingin melakukannya dengan cara ini, Anda terpaksa mencemari pembuat gambar agnostik Anda dengan file konfigurasi yang sangat beropini yang seharusnya menjadi milik penulisan dan proses penerapan.

1 untuk fitur copy penulisan buruh pelabuhan

+1

+1

+1

1 untuk menyalin.

1 untuk fitur copy penulisan buruh pelabuhan. Saya pikir argumen yang mendukung di atas menarik.

1 untuk menyalin

1 untuk menyalin.

Meskipun dalam POV saya. Ini bisa menjadi berguna tetapi juga bisa menjadi di luar kendali atau disalahgunakan untuk banyak pengguna dan bahkan dapat membuat volume menjadi usang. Jika Anda hanya membutuhkan file untuk dimasukkan ke dalam wadah terutama untuk swarm maka Anda dapat menggunakan konfigurasi atau rahasia; Tetapi untuk kasus saya seperti meletakkan folder statis dalam wadah nginx, saya harus menggunakan multi-tahap build di Dockerfile saya untuk meletakkan folder statis tersebut di wadah yang membutuhkan banyak proses sebelum tujuan saya tercapai. Jadi saya pikir menambahkan opsi salin bisa sangat berguna

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

1 untuk membuka kembali

+1

1 untuk membuka kembali

Bukankah fitur yang beroperasi pada volume setelah container (atau dirinya sendiri) mencapai status kerja tertentu?
Ini bisa berupa bendera seperti hanya baca, tetapi hanya salinan ! Kemudian Anda akan memiliki pipa / sintaks operasi volume reguler dengan fungsionalitas tambahan untuk menghapus tautan setelah status sinkronisasi tercapai di dalam penampung ...

1 untuk membuka kembali. Pemasangan volume tidak selalu menjadi pilihan. Itulah mengapa saya memposting di sini hari ini. Saya perlu memodifikasi sejumlah besar wadah dengan tangan untuk menyalin file karena skenario unik di mana pemasangan volume dilarang.

+!

+1

1 untuk fitur copy penulisan buruh pelabuhan

+1

+1

Saya mulai berpikir ini tidak ada gunanya. Docker hanya menambahkan fitur di sekitar kasus penggunaan tertentu yang mereka buat untuk buruh pelabuhan - ini adalah salah satu fitur di luar kasus penggunaan mereka sehingga mereka mungkin tidak akan pernah menambahkannya.

+1

@stuaxo Hanya karena banyak orang meminta footgun , tidak berarti kita harus menerapkannya secara otomatis.

Dalam kasus ini, file yang diperlukan oleh layanan untuk dijalankan harus dimasukkan ke dalam build (dideklarasikan dalam Dockerfile), tersedia melalui volume, atau (dalam kasus docker stack / mode Swarm) ada sebagai konfigurasi atau benda rahasia. Menyalin file ke beberapa tujuan yang berpotensi pada saat runtime lambat, rawan kesalahan, dan tidak tahan terhadap kegagalan.

Cheers, maaf jika yang dianggap pemarah.
Ketika Anda mengatakan "menjalankan layanan" Saya kira yang Anda maksud adalah hal yang berjalan lama seperti layanan web, Docker telah mencakupnya dengan baik.

Dockers layering dan caching berguna untuk hal-hal lain;

Saya memasukkan blog WordPress lama saya ke buruh pelabuhan, tetapi hanya menjalankannya kadang-kadang selama beberapa menit sehingga saya dapat mengekspor data atau memeriksa seperti apa tampilan posting di sana.

Ini membutuhkan sedikit pekerjaan untuk menggunakan docker compose untuk memisahkan MySQL dan Apache, tetapi saya tidak akan peduli jika semuanya berasap bersama.

Caching Dockers menyenangkan saat bereksperimen dengan membangun perpustakaan desktop seperti Kairo. Sebagian besar hal yang saya coba lakukan saya lupa detailnya, tetapi lebih pada sisi membangun sesuatu daripada apa pun yang berkaitan dengan menjalankan layanan.

+1 salinan buruh pelabuhan perlu ditambahkan. Ini memungkinkan aliran file konfigurasi dan pembaruan ke container yang lebih mudah.

Gunakan docker cp dan docker config

Pada hari Jumat, 2 Mar 2018 pukul 21:19 James Hahn [email protected] menulis:

+1 salinan buruh pelabuhan perlu ditambahkan. Ini memungkinkan aliran yang lebih mudah
file konfigurasi dan update ke container.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/1664#issuecomment-370055493 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABOv-q5VO9n9HDvBP6YJ1BCePz5tGu-pks5tabdrgaJpZM4FTTPg
.

>

James Mills / prologic

E: [email protected]
W: prologic.shortcircuit.net.au

1 untuk salinan penulisan buruh pelabuhan. Idenya adalah memiliki salinan hanya untuk file seperti yang dijelaskan di sini

+1

+1

Dalam kasus ini, file yang diperlukan oleh layanan untuk dijalankan harus dimasukkan ke dalam build (dideklarasikan di Dockerfile), tersedia melalui volume, atau (dalam kasus mode tumpukan / Swarm buruh pelabuhan) ada sebagai config atau objek rahasia. Menyalin file ke beberapa tujuan yang berpotensi pada saat runtime lambat, rawan kesalahan, dan tidak tahan terhadap kegagalan.

Kecuali dalam banyak kasus yang Anda inginkan hanyalah memperbarui satu file konfigurasi, dalam hal ini memanggang gambar Anda sendiri dari gambar resmi standar adalah praktik yang buruk dan menimbulkan banyak hutang teknis untuk masa mendatang, volume berlebihan X10 dan Anda tidak melakukannya. ingin atau membutuhkan file untuk tetap disinkronkan belum lagi masalah harus berurusan dengan seluruh folder dan bukan hanya satu file di lokasi default, dan Anda perlu memperbarui file sistem tidak hanya mendapatkan pengaturan konfigurasi.

Saya memahami kekhawatiran Anda, tetapi hanya memberi tahu semua orang bahwa kebutuhan mereka tidak nyata hanya akan membuat orang menjauh dari proyek Anda dan komunitas yang ingin menggunakannya dan mendukung pekerjaan Anda. Kami ingin bekerja sama dengan Anda di sini untuk menemukan solusi yang berhasil, tetapi yang ingin Anda katakan hanyalah bahwa kami tidak membutuhkan apa yang menurut kami kami butuhkan.

Wow, saya tidak percaya ini belum dilakukan. Saya pikir fungsi dasar ini sudah ada di docker-compose sekarang. Oh, keindahan proyek OSS ...

Memecahkannya dengan docker-compose --force-recreate --rebuild , itu menyalin file baru jika mereka telah berubah (atau sepertinya begitu). Tidak ideal tapi berhasil.

+1

+1

+1

+1

+1 Ini adalah kunci rendah yang membuat saya gila, sepertinya konyol harus memasang volume hanya untuk satu file konfigurasi.

+1

Kami memiliki cara untuk menambahkan file ke wadah menggunakan buruh pelabuhan menulis dengan volume. Saya perhatikan bahwa dokumentasi Compose memiliki pengaturan configs sekarang, jadi kita juga dapat menambahkan file tunggal.

https://docs.docker.com/compose/compose-file/#configs

Namun, yang saya yakini orang inginkan adalah cara untuk menggabungkan file dari host ke direktori dalam wadah dengan preferensi overwrite if exists , cara yang Anda harapkan salinannya bekerja.

Aneh bagi saya bahwa konfigurasi volumes di file compose memiliki opsi nocopy :

https://docs.docker.com/compose/compose-file/#volumes

volumes:
  - type: volume
  source: mydata
  target: /data
  volume:
    nocopy: true

Yang dijelaskan seperti ini:
volume: configure additional volume options
nocopy: flag to disable copying of data from a container when a volume is created

Jadi menonaktifkan persis apa yang diinginkan?

Kasus penggunaan yang saya inginkan adalah aplikasi web untuk pengembangan. Saya ingin gambar berisi semua yang dibutuhkan untuk melayani situs web termasuk situs web default untuk ditayangkan, tetapi memiliki opsi untuk menggabungkan / menimpa file-file itu dengan status kerja situs web saat ini tanpa konfigurasi lain (kunci) selain memiliki file di tempat yang tepat untuk tuan rumah. File yang, saat disalin ke penampung, bersifat efemeral. Artinya tidak dalam jaringan berbagi.

Contoh kerangka kerja yang akan mendapatkan keuntungan dari itu adalah sesuatu seperti Laravel. Di mana saya membuat gambar yang akan mampu melayani halaman splash Laravel tanpa konfigurasi lain (volume, jaringan berbagi, dll), tetapi file penulisan ditulis untuk menyalin file dari host ke root Laravel penampung sehingga mereka dapat ditimpa.

Menggunakan berbagi jaringan untuk ini adalah pemeliharaan ekstra untuk lingkungan singkat (pengembangan tidak selalu konstan). Menggunakan volume mount untuknya, dengan kerangka kerja seperti Laravel, membutuhkan pembuatan aplikasi dalam volume itu yang berarti menginstal PHP dan komposer pada host atau membagikan lokasi pada host tempat aplikasi akan dibuat. Keduanya menciptakan lebih banyak perawatan.

Edit:

Setelah pengujian, tampaknya saat Anda memasang volume, file yang ada pada gambar di lokasi itu disalin ke volume yang persisten dengan preferensi ke konten asli volume. Artinya itu tidak menimpa.

Saya benar-benar berpikir ini adalah solusi untuk hasil yang diinginkan.

Hai teman-teman, FYI saja, lebih baik memberikan reaksi yang disukai untuk pesan teratas tentang masalah ini daripada menambahkan komentar "+1", karena masalah dapat diurutkan berdasarkan berapa banyak reaksi yang mereka terima.

+1

+1 Silakan tim Docker, pertimbangkan komunitas Anda.

@ shin- Masalahnya sekarang adalah fitur volume tidak memungkinkan untuk menyambungkan satu file konfigurasi dari volume eksternal ke dalam wadah.

Misalkan saya ingin memasang file konfigurasi nginx ke /etc/something/whatever.conf tanpa menghapus semua yang ada di folder itu. Anda tidak dapat membuat volume bernama untuk satu file (lihat moby / moby # 30310), dan Anda juga tidak dapat membuat volume direktori yang berisi satu file, lalu pasang file tersebut ke dalam wadah (lihat moby / moby # 32582).

Satu-satunya pilihan yang tersisa adalah mencemari lokasi tetap di host Docker Anda yang sebenarnya dengan file konfigurasi dan kemudian mengikatnya. Ini tentu saja akan hancur jika Anda ingin berpindah-pindah antara host Docker, atau bekerja dengan Docker host yang tidak memiliki akses sistem file (misalnya CI online), atau bahkan hanya menjalankan beberapa stack secara paralel.

Sesuatu harus diberikan di sini, baik fitur volume di Docker perlu diubah sehingga kita benar-benar dapat menggunakannya untuk menyelesaikan menyuntikkan file konfigurasi ke tumpukan kita, atau kita perlu mengatasinya dalam menulis menggunakan sesuatu seperti copy config opsi.

FWIW Saya tidak lagi menjadi pengelola Penulisan, tetapi menurut saya kasus penggunaan tersebut paling baik disajikan dengan memasukkan file konfigurasi pada waktu pembuatan menggunakan Dockerfile.

@ shin- Sayangnya file konfigurasi tidak diketahui pada waktu pembuatan, gambar disiapkan di server CI jauh sebelum kita tahu di mana kita akan menerapkannya dan dalam konfigurasi apa.

Saya bersama @masaeedu , saya memahami konsep ideal tentang menjaga fungsi tulis agar tidak merayap dan oleh karena itu tidak ingin menambahkan fitur ini, tetapi dalam kehidupan nyata, hilangnya fitur ini SANGAT mengurangi keadaan di mana penulisan dapat digunakan tanpa

A) harus menggabungkan beberapa jenis skrip mengerikan yang bekerja untuk mempertahankan wadah yang dimaksud (hal yang paling menulis dimaksudkan untuk membantu menstandarisasi dan mencegah kita dari keharusan melakukannya),

B) harus menambahkan beberapa alat lain yang menangani semua konfigurasi kami (yang sementara bisa diterapkan menambahkan sejumlah besar overhead untuk proyek kecil hingga menengah yang benar-benar hanya perlu menyalin .conf dan .env tertentu ke setiap penampung, sesuatu yang Anda tidak ingin lakukan pada waktu pembuatan gambar, itu sama dengan mengatakan bahwa daripada perangkat lunak Anda memiliki file konfigurasi, Anda harus memasukkan semua opsi Anda ke dalam C ++, itu mengarah ke lusinan gambar tambahan yang harus dipertahankan), atau

C) harus mempertahankan gambar terpisah untuk setiap konfigurasi yang mungkin dari perangkat lunak tertentu yang kami perlukan / buat gambar khusus setiap kali kami harus membuat perubahan konfigurasi kecil .... yang keduanya tidak dapat dijalankan di dunia nyata perangkat lunak produksi, dan juga tidak memungkinkan untuk memiliki jenis QA yang kuat dan jalur pengujian yang kami butuhkan untuk perangkat lunak produksi.