Compose: Docker Compose mount bernama volume sebagai 'root' secara eksklusif

Saya tidak berpikir ini didukung oleh mesin buruh pelabuhan, jadi tidak mungkin kami dapat mendukungnya di Compose sampai ditambahkan ke API. Namun saya rasa tidak perlu menambahkan fitur ini. Anda selalu dapat chown file ke pengguna yang benar:

version: '2'
services:
  web:
    image: alpine:3.3
    volumes: ['random:/path']

volumes:
  random:

$ docker-compose run web sh
/ # touch /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 root     root             0 Apr  5 16:11 foo
/ # chown postgres:postgres /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo
/ # 

$ docker-compose run web sh
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo

Masalah yang Anda hadapi adalah tentang menginisialisasi volume bernama. Ini memang bukan sesuatu yang ditangani oleh Compose (karena agak di luar cakupan), tetapi Anda dapat dengan mudah menggunakan docker cli untuk menginisialisasi volume bernama sebelum menjalankan docker-compose up .

Saya memang tidak yakin apakah ini masalah Docker atau Compose, maaf jika saya salah memasukkannya.
Apakah ini paket di Docker API, haruskah saya mengajukan masalah di sana?

Saya memahami kemungkinan masuk secara manual ke dalam wadah dan chown -ing volume ke pengguna 'postgres'. Tetapi masalahnya, dalam kasus saya, saya menggunakan Compose sehingga saya dapat segera membuat instance wadah baru untuk klien baru ( docker-compose -p client_name up ) dan Compose akan membuat jaringan khusus client_name_default , itu akan membuat wadah dengan nama client_name _appserver_1 dan client_name _server-postgresql_1 dan _yang lebih penting_, itu akan membuat volume client_name_db-data . Semua itu tidak perlu saya lakukan secara manual, sehingga bisa dijalankan oleh script yang menangani pendaftaran klien.

Dengan solusi yang Anda jelaskan (_manual_ "logging" di wadah dengan sh dan chown -ing label volume), saya tidak dapat memiliki prosedur sederhana untuk menambahkan klien baru, dan ini harus dirawat dengan tangan.

Inilah mengapa saya pikir fitur ini harus diterapkan. Di Docker API, kita dapat menentukan izin ro atau rw (untuk read-only atau read-write) saat memasang volume, saya pikir kita harus dapat menentukan user:group .

Bagaimana menurut Anda, apakah permintaan saya masuk akal?

Sebenarnya saya datang ke sini dengan berita, sepertinya apa yang saya coba capai dapat dilakukan, tetapi saya tidak tahu apakah ini fitur atau bug. Inilah mengapa saya berubah:

Di Dockerfile saya, _sebelum mengubah ke pengguna 'postgres'_ saya menambahkan ini:

# ...
RUN    mkdir /volume_data
RUN   chown postgres:postgres /volume_data

USER postgres
# ...

Apa yang dilakukan adalah membuat direktori /volume_data dan mengubah izinnya sehingga 'postgres' pengguna dapat menulis di atasnya.
Ini adalah bagian Dockerfile .

Sekarang saya belum mengubah apa pun di docker-compose.yml : jadi docker-compose masih membuat Volume Bernama directory_name_db-data dan memasangnya ke /volume_data dan izin tetap ada! .
Yang berarti bahwa sekarang, Volume Bernama saya terpasang di direktori _pre-existing_ /volume_data dengan izin yang dipertahankan, sehingga 'postgres' dapat menulis ke sana.

Jadi apakah ini perilaku yang dimaksudkan atau pelanggaran keamanan? (Itu memang melayani saya dalam kasus ini!)

Saya percaya ini ditambahkan di Docker 1.10.x sehingga volume bernama akan diinisialisasi dari wadah pertama yang menggunakannya. Saya pikir itu perilaku yang diharapkan.

Saya juga melakukan volume bernama dengan kepemilikan diatur di Dockerfile dan dalam penulisan saya menambahkan user: postgres sehingga bahkan PID 1 dimiliki oleh pengguna non-root.

Docker-compose untuk volumes memiliki driver_opts untuk memberikan opsi.
Akan sangat bagus untuk melihat opsi seperti chmod , chown bahkan untuk driver local .
Dan terutama saya ingin itu juga akan diterapkan untuk direktori Host yang dibuat secara lokal jika tidak ada di awal.

Terkait (sampai batas tertentu) https://github.com/moby/moby/pull/28499

Apakah seseorang sudah membuka masalah pada proyek Moby?

Jawaban dari @dnephin tidak berfungsi. Masalahnya adalah karena kita menjalankan container sebagai pengguna standar, perintah chown atau chmod gagal, volume dimiliki oleh root, pengguna standar tidak dapat mengubah izin.

@jcberthon metode yang disarankan adalah menjalankan wadah dengan root sebagai pengguna awal dan kemudian menggunakan perintah USER SETELAH chown/chmod sehingga pada dasarnya "menjatuhkan hak istimewa".

Tidak apa-apa jika Anda mengendalikan gambar Docker tetapi jika Anda menggunakan gambar yang ada, itu sebenarnya bukan pilihan.

@dragon788 dan @micheljung , saya memecahkan masalah saya.

Sebenarnya masalah sebenarnya adalah bahwa saya Dockerfile saya, saya mendeklarasikan VOLUME dan kemudian saya mengubah kepemilikan dan izin file dalam volume itu. Perubahan itu hilang. Dengan hanya memindahkan deklarasi VOLUME ke akhir Dockerfile (atau menghapusnya, karena ini opsional), masalah saya terpecahkan. Izinnya benar.

Jadi kesalahannya adalah:

FROM blabla
RUN do stuff
VOLUME /vol
RUN useradd foo && chown -R foo /vol
USER foo
CMD ["blabla.sh"]

chown dalam contoh Dockerfile di atas hilang selama build karena kami mendeklarasikan VOLUME sebelumnya. Saat menjalankan wadah, dockerd menyalin dalam volume bernama konten /vol sebelum deklarasi VOLUME (jadi dengan izin root). Oleh karena itu proses yang berjalan tidak dapat mengubah atau mengubah izin, sehingga memaksa chown di skrip blabla.sh pun tidak dapat berfungsi.

Dengan mengubah file menjadi:

FROM blabla
RUN do stuff
RUN useradd foo && chown -R foo /vol
USER foo
VOLUME /vol
CMD ["blabla.sh"]

Masalah terpecahkan.

@jcberthon dapatkah Anda membagikan bagaimana Anda mengikat volume /vol Anda dengan sistem Host di docker-compose.yml Anda?

Saya bekerja dengan Docker di Fedora (jadi, SELinux diaktifkan) dan tidak ada metode yang disebutkan di atas yang berfungsi untuk saya. Idealnya, saya ingin menjalankan aplikasi di Wadah saya di bawah konteks pengguna (tanpa root) tetapi masalah Volume ini adalah penghalang untuk itu.

Satu-satunya solusi yang berhasil bagi saya adalah menghilangkan pengguna aplikasi saya dan menjalankan/memiliki semuanya sebagai pengguna root.

Hai @renanwilliam dan @egee-irl

Saya telah menggunakan solusi yang disebutkan di atas pada beberapa OS termasuk. Fedora 26 dan CentOS 7 keduanya dengan SELinux yang ditegakkan, Ubuntu 16.04, 17.10 dan Raspbian 9 ketiganya dengan AppArmor diaktifkan (dengan campuran platform amd64 dan armhf).

Jadi seperti yang saya katakan, saya sekarang telah memindahkan deklarasi VOLUME ... di akhir Dockerfile saya, tetapi Anda dapat menghapusnya bersama-sama, itu tidak diperlukan. Apa yang saya juga biasanya lakukan adalah memperbaiki userid saat membuat pengguna di Dockerfile (misalnya useradd -u 8002 -o foo ). Lalu saya cukup menggunakan kembali UID itu di Host untuk memberikan izin yang tepat ke folder.

Jadi langkah selanjutnya adalah membuat "liontin" dari direktori /vol pada Host, misalkan itu /opt/mycontainer1/vol , jadi itu

$ sudo mkdir -p /opt/mycontainer1/vol
$ sudo chown -R 8002 /opt/mycontainer1/vol
$ sudo chmod 0750 /opt/mycontainer1/vol

Kemudian ketika menjalankan container sebagai user foo, ia akan dapat menulis ke direktori /opt/mycontainer1/vol . Sesuatu seperti:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol mycontainer1-img

Pada host berbasis SELinux, Anda mungkin ingin menambahkan opsi :z :Z untuk volume sehingga Docker akan menandai folder dengan tepat. Perbedaan antara z dan Z adalah bahwa huruf kecil z akan menandai volume sehingga berpotensi semua wadah dari host ini dapat diizinkan oleh SELinux untuk mengakses direktori itu (tapi jelas hanya jika Anda mengikat mount ke wadah lain), sedangkan huruf besar Z akan menandainya sehingga hanya wadah tertentu yang dapat mengakses direktori. Jadi di Fedora dengan SELinux Anda mungkin ingin mencoba:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol:Z mycontainer1-img

Pembaruan : Anda dapat memeriksa repo saya di sini https://github.com/jcberthon/unifi-docker Saya menggunakan metode ini dan menjelaskan cara mengonfigurasi Host dan menjalankan wadah Anda. Saya harap ini dapat membantu memecahkan masalah Anda lebih lanjut.

Btw, saya minta maaf @renanwilliam atas keterlambatan yang lama dalam membalas Anda. Saya tidak punya banyak waktu luang akhir tahun ini ...

Jadi, singkat cerita untuk yang tidak sabar:

RUN mkdir /volume_data
RUN chown postgres:postgres /volume_data

Membuat direktori volume sebelumnya dan chown menyelesaikannya, karena volume akan mempertahankan izin dari direktori yang sudah ada sebelumnya.

Ini adalah pekerjaan yang buruk karena tidak jelas (Melakukan chown di Dockerfile dan kemudian mewarisi kepemilikan itu selama pemasangan). Mengekspos kontrol pemilik dan grup di docker-compose dan docker CLI akan menjadi jalur yang paling tidak mengejutkan untuk perintah gaya unix.

@villasv

Tip kecil: gabungkan 2 RUN ... menjadi satu, ini menghindari pembuatan lapisan tambahan dan merupakan praktik terbaik. Jadi 2 baris Anda seharusnya

RUN mkdir /volume_data && chown postgres:postgres /volume_data

Tetapi berhati-hatilah (seperti yang saya sebutkan dalam komentar di atas) bahwa Anda perlu melakukan perintah RUN ... sebelum mendeklarasikan volume (atau sebenarnya tidak mendeklarasikan volume) menggunakan VOLUME ... . Jika Anda (seperti yang saya lakukan) perubahan kepemilikan setelah menyatakan volume, maka perubahan tersebut tidak dicatat dan hilang.

@colbygk itu memang berguna, tapi bukan itu cara kerja Linux. Docker menggunakan ruang nama pemasangan Linux untuk membuat hierarki direktori tunggal yang berbeda ( / dan subfolder), tetapi AFAIK tidak ada pemetaan pengguna/grup atau izin yang ditimpa saat ini di ruang nama pemasangan Linux. "Tunggangan" di dalam wadah (dan itu termasuk volume pengikat-mount) ada di sistem file di Host (kecuali jika Anda menggunakan beberapa plugin volume Docker lainnya tentu saja), dan sistem file ini menghormati lapisan VFS Linux yang melakukan semua pemeriksaan izin file. Bahkan mungkin ada pada host beberapa MAC (misalnya SELinux, AppArmor, dll.) yang dapat mengganggu wadah yang mengakses file di dalam wadah. Sebenarnya jika Anda melakukannya chroot , Anda dapat mengalami masalah serupa karena Anda dapat mengikat folder mount di dalam chroot, Anda juga memiliki masalah bahwa proses yang berjalan dalam lingkungan chroot mungkin memiliki UID/GID efektif yang salah untuk mengakses file di pengikat-mount.

Aturan Linux sederhana (dan sebenarnya Unix juga) berlaku untuk container. Triknya adalah untuk melihat dan memahami kemungkinan dan batasan ruang nama Linux saat ini, dan kemudian menjadi lebih jelas bagaimana memecahkan masalah seperti masalah ini. Saya menyelesaikannya sepenuhnya menggunakan perintah Unix klasik.

@jcberthon Terima kasih atas tanggapan Anda yang bijaksana:

Saya berpendapat bahwa ini harus menjadi masalah yang didorong ke dalam lapisan plugin seperti yang Anda sarankan dan karena itu dapat menjadi bagian dari plugin penangan volume generik yang dikirimkan bersama Docker. Tampaknya sangat uncloud/wadah seperti saya untuk memaksa sumber daya eksternal (eksternal ke wadah tertentu) untuk mematuhi pada dasarnya hubungan statis yang didefinisikan dalam gambar wadah berasal.

Ada contoh lain dari jenis pemetaan uid/gid yang tepat ini yang terjadi di area "unix" serupa lainnya:

• http://man7.org/linux/man-pages/man5/nfsidmap.5.html
• http://wiki.lustre.org/UID/GID_Mapping
• https://docs.Oracle.com/cd/E19120-01/open.solaris/820-2429/mapusergroupidentities/index.html
• https://github.com/zfsonlinux/zfs/issues/4177

Mohon koreksi saya jika saya salah; https://github.com/zfsonlinux/zfs/issues/4177 tampaknya berasal dari "pemimpin LXC/LXD" sebagai masalah yang terkait dengan ZFS di linux yang tidak memberikan informasi UID/GID dengan benar untuk memungkinkan pemetaannya menjadi container dengan cara yang _exact_ seperti yang kita bahas di sini. Melihat dari dekat https://github.com/zfsonlinux/zfs/issues/4177 tampaknya tipe volume zfs sebenarnya sudah dapat mendukung pemetaan uid/gid ini antara ruang nama, tetapi tidak mengekspos kontrol untuk melakukannya.

kebanyakan orang menggunakan Docker adalah untuk dev / CI, kami menggunakan gambar "generik" seperti php/nginx (runner) atau gradle/python (builder) sehingga solusi yang baik akan:

1. tidak perlu membuat/mengedit Dockerfile untuk mengganti gambar
2. gunakan sintaks sederhana dalam file yml docker-compose

Karena kita dapat dengan mudah memutuskan izin Menulis volume (X:X:OPTION_READ_WRITE), bagaimana dengan menambahkan dengan cara yang sama, pemiliknya?

SOURCE:TARGET:RW:OWNER

Saya mempunyai masalah yang sama. Mungkin ada praktik terbaik, dan metode saya adalah _not_ it:

version: '3.5'
services:
    something:
        image: someimage
        user: '1000'
        expose:
            - 8080
        volumes:
            - dev:/app

volumes:
    dev:

Ini menyebabkan EACCES: permission denied, access '/app' .

Bagaimana kita harus melakukan ini? Yaitu menentukan volume baru dan dapat mengaksesnya dengan pengguna non-root?

Hai @Redsandro

Akan lebih baik Anda mengatur someimage Docker image UID ke 1000 untuk /app . Atau jika Anda tidak dapat mengontrolnya, Anda harus menggunakan untuk user: ... dalam file penulisan Anda UID atau GID yang dimaksudkan oleh pembuat gambar.

Tentu saja jika pembuat gambar menggunakan UID 0 dan Anda tidak ingin menjalankan layanan sebagai root (dan dapat dijalankan sebagai pengguna yang tidak memiliki hak istimewa), maka ajukan masalah kepada pembuat gambar Docker.

@Redsandro Periksa solusi dari: Docker dan --userns-remap, bagaimana cara mengelola izin volume untuk berbagi data antara Host dan wadah?

karena ini bukan sesuatu untuk dikelola oleh buruh pelabuhan, Anda dapat membuat wadah lain untuk menyediakan volume Anda tepat sebelum wadah terkait mulai, misalnya menggunakan https://hub.docker.com/r/hasnat/volumes-provisioner

version: '2'
services:
  volumes-provisioner:
    image: hasnat/volumes-provisioner
    environment:
      PROVISION_DIRECTORIES: "65534:65534:0755:/var/data/prometheus/data"
    volumes:
      - "/var/data:/var/data"

  prometheus:
    image: prom/prometheus:v2.3.2
    ports:
      - "9090:9090"
    depends_on:
      - volumes-provisioner
    volumes:
      - "/var/data/prometheus/data:/prometheus/data"

Saya tidak mengerti mengapa Docker tidak memperbaiki yang ini, saya setuju kita dapat meretasnya untuk tujuan pengembangan, tetapi dalam produksi, tidak mungkin!

IMHO podman dapat dijalankan sebagai pengguna (tidak sini ) dan mungkin akan menyelesaikan ini. Seseorang juga mengerjakan solusi penulisan dan Podman API sengaja kompatibel dengan Docker di sebagian besar bagian.

[podman] mungkin membantu beberapa orang di sini, karena sebagian besar kompatibel dengan Docker.

Sangat setuju, sayangnya podman tidak berfungsi di Mac

Sangat setuju, sayangnya podman tidak berfungsi di Mac

Saya bukan pengguna OS/X lagi tetapi saya baru saja melihat ada _experimental_ podman dmg .

Saya kira beberapa ekosistem serupa mungkin berkembang dalam waktu dekat karena dimungkinkan untuk mengakses podman programmatic atau bahkan podman-compose .

Ini terutama menjadi masalah ketika pengguna tanpa hak sudo pada cluster bersama secara tidak sengaja membuat beberapa folder yang dimiliki oleh root melalui docker-compose dan kemudian mereka bahkan tidak dapat menghapus folder itu sendiri.

Saya mengalami masalah ini juga. Kami mencoba menggunakan buruh pelabuhan di buruh pelabuhan seperti yang dipandu dalam posting jpetazzo .

Kami ingin memulai wadah ini dari file komposisi buruh pelabuhan dan dapat memasang soket buruh pelabuhan dari mesin Host ke mesin kontainer di bawah grup buruh pelabuhan. Ini agar kita dapat menggunakan pengguna lain selain root untuk menjalankan buruh pelabuhan dari dalam wadah.

Saat ini, karena saya tidak dapat menentukan kepemilikan & izin file bind mount, ini tidak dapat dicapai.

Masukkan dua sen saya di sini:

Untuk solusi "asli" komposisi buruh pelabuhan, saya melakukan ini, karena kebanyakan orang sudah memiliki alpine di perpustakaan gambar mereka:

volumes:
  media:
services:
  mediainit:
    image: alpine
    entrypoint: /bin/sh -c "chown -v nobody:nogroup /mnt/media && chmod -v 777 /mnt/media"
    container_name: mediainit
    restart: "no"
    volumes: 
      - "media:/mnt/media"

Tentu saja bukan metode yang paling aman, tetapi hanya wadah yang diberikan hak istimewa ke wadah yang akan melihatnya, jadi itu bukan masalah besar, tetapi Anda dapat dengan mudah membuatnya chown user:user atau melakukan setacl fanciness jika kernel Anda mendukung dia.

EDIT: Sepertinya Anda harus chown folder terlebih dahulu sebelum chmod atau tidak 'menempel', setidaknya dalam pengujian saya.

kepemilikan volume tidak di bawah kendali docker-compose, jadi diskusi ini harus dilakukan di bawah repo proyek moby.

Beberapa catatan untuk orang yang mencari solusi di sini:
Volume Docker, saat pertama kali digunakan oleh sebuah wadah, dapatkan konten dan izin awalnya yang diwarisi dari wadah tersebut. Yang berarti Anda dapat mengonfigurasi gambar Anda seperti ini:

#Dockerfile
FROM alpine
RUN addgroup -S nicolas && adduser -S nicolas -G nicolas
RUN mkdir /foo && chown nicolas:nicolas /foo  
# empty, but owned by `nicolas`. Could also have some initial content
VOLUME /foo  
USER nicolas

Gambar seperti itu, ketika dijalankan tanpa volume eksplisit (yang akan dibuat dengan sengaja dengan ID acak) atau dengan volume bernama yang belum ada, akan "menyebarkan" izin ke volume:

➜  docker run --rm -it -v some_new_volume:/foo myimage
/ $ ls -al /foo
total 8
drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
drwxr-xr-x    1 root     root          4096 Oct 18 08:30 ..

Hal yang sama berlaku saat menggunakan volume yang dideklarasikan dalam file penulisan:

#docker-compose.yml
version: "3"
services:
  web:
    image: myimage
    command: ls -al /foo
    volumes:
      - db-data:/foo
volumes:
    db-data:

➜  docker-compose up
Creating volume "toto_db-data" with default driver
Creating toto_web_1 ... done
Attaching to toto_web_1
web_1  | total 8
web_1  | drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
web_1  | drwxr-xr-x    1 root     root          4096 Oct 18 08:37 ..
toto_web_1 exited with code 0

Ini tidak akan berfungsi jika Anda memasang kembali volume yang telah digunakan oleh wadah lain. Mengubah kepemilikan volume, atau mengendalikan ini pada waktu pembuatan harus diterapkan oleh mesin, atau oleh driver volume dengan beberapa opsi khusus. Jika tidak, Anda harus mengandalkan beberapa trik chown seperti yang disarankan ^.

Semoga ini membantu.
Saya menutup masalah ini karena penulisan tidak memiliki kontrol pada pembuatan volume tetapi API mesin yang terbuka.