Jika kita melakukan ini, saya lebih menyukai opsi RUNP, daripada memiliki
semua kontainer berjalan dalam mode -privileged.

Pada Rabu, 18 Sep 2013 pukul 13:07, Benjamin Podszun
[email protected] menulis :

Saat ini sepertinya tidak ada cara untuk menjalankan operasi istimewa di luar
docker run -istimewa.

Itu berarti saya tidak dapat melakukan hal yang sama di Dockerfile. Baru-baru ini saya
masalah: Saya ingin menjalankan fuse (untuk encfs) di dalam wadah. Menginstal
fuse sudah berantakan dengan peretasan dan solusi yang buruk (lihat [1] dan [2]),
karena mknod gagal/tidak didukung tanpa langkah pembuatan yang diistimewakan.

Satu-satunya solusi saat ini adalah melakukan penginstalan secara manual, menggunakan
jalankan -privileged, dan buat 'gambar dasar sekering' baru. Yang artinya aku
tidak dapat menggambarkan seluruh wadah, dari gambar dasar resmi hingga selesai,
dalam satu file Docker.

Oleh karena itu saya menyarankan untuk menambahkan juga

• bangunan buruh pelabuhan - hak istimewa
  ini harus melakukan hal yang sama seperti run -privileged, yaitu menghapus semua
  batasan topi

atau

• perintah RUNP di Dockerfile
  ini harus .. yah .. LARI, tetapi dengan _P_rivileges

Saya mencoba mencari sumbernya, tetapi saya tidak berguna dengan go dan tidak dapat menemukan
titik masuk yang layak untuk melampirkan bukti konsep, sayangnya. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (komentar) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916
.

Victor VIEUX
http://vvieux.com

Sebenarnya, kita mungkin harus melakukan keduanya — yaitu, RUNP + memerlukan "-privileged"
bendera.

Jika kita hanya mengandalkan RUNP (tanpa memerlukan "-privileged"), maka kita akan
harus bertanya-tanya kapan kita melakukan build "apakah build ini aman?".
Jika kita hanya mengandalkan "-privileged", kita kehilangan informasi (dalam
Dockerfile) bahwa "tindakan ini memerlukan hak istimewa yang diperluas".

Saya pikir kombinasi keduanya adalah cara yang paling aman.

Pada Rabu, 18 Sep 2013 jam 04:07, Benjamin Podszun
[email protected] menulis :

Saat ini sepertinya tidak ada cara untuk menjalankan operasi istimewa di luar
docker run -istimewa.

Itu berarti saya tidak dapat melakukan hal yang sama di Dockerfile. Baru-baru ini saya
masalah: Saya ingin menjalankan fuse (untuk encfs) di dalam wadah. Menginstal
fuse sudah berantakan dengan peretasan dan solusi yang buruk (lihat [1] dan [2]),
karena mknod gagal/tidak didukung tanpa langkah pembuatan yang diistimewakan.

Satu-satunya solusi saat ini adalah melakukan penginstalan secara manual, menggunakan
jalankan -privileged, dan buat 'gambar dasar sekering' baru. Yang artinya aku
tidak dapat menggambarkan seluruh wadah, dari gambar dasar resmi hingga selesai,
dalam satu file Docker.

Oleh karena itu saya menyarankan untuk menambahkan juga

• bangunan buruh pelabuhan - hak istimewa
  ini harus melakukan hal yang sama seperti run -privileged, yaitu menghapus semua
  batasan topi

atau

• perintah RUNP di Dockerfile
  ini harus .. yah .. LARI, tetapi dengan _P_rivileges

Saya mencoba mencari sumbernya, tetapi saya tidak berguna dengan go dan tidak dapat menemukan
titik masuk yang layak untuk melampirkan bukti konsep, sayangnya. :(

1: https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (komentar) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916
.

@jpetazzo https://twitter.com/jpetazzo
Posting blog terbaru: http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Kedengarannya masuk akal. Bagi saya fitur ini (mampu membuat node perangkat) membuat atau menghancurkan kemampuan untuk membuat penerapan di Docker. Jika saya dapat membantu (sebagian besar pengujian, saya mencoba melihat sumbernya tetapi gagal sejauh ini. Tampaknya perintah yang tersedia di buildfile ditemukan melalui refleksi, saya menambahkan perintah runp yang mengatur config.privileged menjadi true, tetapi sejauh ini saya Saya tidak dapat membangun dan menguji -> macet) Saya dengan senang hati akan menginvestasikan waktu.

Saya akan menyarankan RUNP + build -privileged .

_menyalakan beberapa sinyal asap untuk menarik perhatian @shykes , @crosbymichael_

... Dan kemudian kita harus menemukan seseorang untuk menerapkannya, tentu saja
Apakah itu sesuatu yang ingin Anda coba (dengan panduan dan umpan balik yang sesuai dari tim inti, tentu saja)?

Jika bagian terakhir ditujukan pada saya: Tentu, mengapa tidak. Saya sudah mengotak-atik kode go (bukan bahasa yang saya kenal, tetapi lihat di atas: Saya tetap mencoba mencari tahu apa yang terjadi).

Dengan beberapa petunjuk/seseorang untuk melakukan ping untuk beberapa pertanyaan, saya pasti akan mencobanya.

Saya tidak dijual di RUNP atau build -privileged.

saya

Umumnya saya tidak suka apa pun yang memperkenalkan kemungkinan build yang berbeda dari input yang sama. Itu sebabnya Anda tidak bisa meneruskan argumen atau variabel env ke build.

Secara khusus saya tidak suka memperkenalkan dependensi pada "hak istimewa" di semua tempat, karena ini menunjukkan serangkaian kemampuan yang a) sangat besar dan b) tidak ditentukan atau ditentukan dengan jelas. Tidak apa-apa sebagai mekanisme kasar bagi sysadmin untuk mem-bypass keamanan dengan cara semua-atau-tidak sama sekali - "escape hatch" ketika lingkungan eksekusi buruh pelabuhan standar tidak cukup. Ini mirip dengan cara mengikat-mount dan custom lxc-conf.

—
@solomonstre
@getdocker

Pada Jum, 20 Sep 2013 jam 15:18, Benjamin Podszun
[email protected] menulis:

Jika bagian terakhir ditujukan pada saya: Tentu, mengapa tidak. Saya sudah mengotak-atik kode go (bukan bahasa yang saya kenal, tetapi lihat di atas: Saya tetap mencoba mencari tahu apa yang terjadi).

Dengan beberapa petunjuk/seseorang untuk melakukan ping untuk beberapa pertanyaan, saya pasti akan mencobanya.

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -24844868

Nah, apakah Anda setuju bahwa membangun citra buruh pelabuhan yang - misalnya - dapat menjalankan fuse?
Untuk itu kita perlu mknod.

Cara saya melihatnya, tidak mungkin build ini bisa berbeda tergantung pada parameter: Build akan berfungsi (caps tidak / kurang dibatasi dari sekarang) atau gagal (status quo). Ada sedikit atau tidak ada risiko 'versi' berbeda dari file build yang sama, bukan?

Saya mengalami masalah ini sekarang. Untuk membangun gambar yang saya butuhkan, saya harus melakukan serangkaian langkah run -privileged + langkah commit , daripada build dalam file Docker. Idealnya, akan menyenangkan untuk mengekspresikan langkah-langkah pembuatan gambar di Dockerfile.

Apakah ini juga terkait dengan operasi mknod?
Jika Anda dapat menjelaskan dengan tepat tindakan yang memerlukan mode istimewa di
kasus Anda, itu akan sangat membantu!
Terima kasih,

Hai @jpetazzo , dari milis, inilah masalah yang saya hadapi: https://groups.google.com/forum/#!topic/docker -user/1pFhqlfbqQI

Saya mencoba mount a fs yang saya buat (dibuat untuk mengatasi aufs dan sesuatu tentang journal ) di dalam wadah. Perintah spesifik yang saya jalankan adalah mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , di mana /db/disk-image dibuat dengan dd if=/dev/zero of=disk-image count=409600 dan home/db2inst1 adalah tempat saya mencoba memulai db2.

Jika saya mengerti dengan benar, selama proses instalasi, Anda memerlukan direktori non-AUFS — atau lebih tepatnya, sesuatu yang mendukung O_DIRECT . Jika itu masalahnya, Docker 0.7 harus menyelesaikan masalah, karena ia akan menggunakan ext4 (dan snapshot tingkat blok) alih-alih AUFS.

+1 untuk ini juga.

Menginstal paket yang memerlukan perubahan pada pengaturan memori dan konfigurasi kernel (misalnya Vertica DB, WebSphere MQ) hanya dapat dilakukan dalam mode istimewa.

Mari kita coba pisahkan masalah saat menjalankan/membangun dengan "hak istimewa": itu bisa diperlukan hanya selama build, hanya selama eksekusi melalui docker run atau keduanya.

Seharusnya memungkinkan untuk mengizinkan bangunan melakukan sesuatu yang memerlukan sedikit lebih banyak izin untuk satu langkah (atau lebih) jika itu perlu. Saya membutuhkan ini untuk sebuah proyek dan harus mengonversi setengah dari Dockerfile ke skrip Shell yang memanggil build dan terus membangun sesuatu dalam mode istimewa, jadi memiliki build "hak istimewa" akan berguna.

Namun, kita tidak boleh turun ke mode istimewa secara default hanya agar kita dapat menggunakan sysctl untuk mengubah beberapa pengaturan. Ini harus dilakukan melalui konfigurasi gambar atau melalui argumen baris perintah untuk diteruskan ke docker run .

Benar. @orikremer , apakah Anda memiliki detail tentang parameter yang coba diubah Vertica DB dan WebSphere MQ?

Jika itu ada di /sys atau /proc, solusi terbaik mungkin adalah meletakkan beberapa tiruan di sana, daripada beralih ke mode istimewa (karena perubahan tidak akan bertahan).

Dalam jangka panjang, sistem file tiruan mungkin menangkap perubahan dan mengonversinya ke arahan Dockerfile, menginstruksikan runtime bahwa "hei, wadah ini membutuhkan tweak ini atau itu".

@jpetazzo Sudah beberapa hari sejak saya membuat gambar. AFAIR Vertica mengeluh bahwa memorinya tidak cukup dan keduanya mencoba mengubah file yang terbuka maksimal.
Saya akan mencoba membuat ulang gambar menggunakan Dockerfile dan melaporkan kembali.

Memperhatikan masalah #2080 karena terkait.

@jpetazzo mulai membuat ulang gambar tanpa -istimewa. Dua masalah sejauh ini:

• nice di limit.conf: Vertica menambahkan "dbadmin - nice 0" ke /etc/security/limits.conf. Saat mencoba beralih ke pengguna itu saat menjalankan dalam wadah yang tidak memiliki hak istimewa, saya mendapatkan kesalahan "tidak dapat membuka sesi". Dalam sakelar wadah yang diistimewakan, pengguna bekerja tanpa kesalahan.
• max open files: karena max yang dibutuhkan dalam container lebih tinggi dari yang ada di host, saya harus mengubah /etc/init/docker.conf pada host dan mengatur "limit nofile" dan kemudian ulimit -n di container. Apakah itu pendekatan yang benar?

Saat mencoba beralih ke pengguna itu,

Bagaimana peralihan itu terjadi? Saya tidak mengerti bagaimana -privileged akan membantu peralihan pengguna; Saya mungkin kehilangan sesuatu di sini :-)

file terbuka maksimal

Jika saya mengerti dengan benar, penginstal Vertikal mencoba mengatur jumlah maksimum file yang terbuka ke angka yang sangat tinggi, dan itu hanya berfungsi jika Docker dimulai dengan angka _or_ yang tinggi dengan flag -privileged ; Baik?

beralih pengguna - su dbadmin gagal dengan kesalahan itu.
Saya dapat mereproduksi dengan:

• tarik gambar baru (centos-6.4-x86_64) dan jalankan tanpa hak istimewa
• pengguna tambahkan pengguna tes
• edit /etc/security/limits.conf, tambahkan "testuser - nice 0"
• coba su testuser --> seharusnya gagal dengan "tidak dapat membuka sesi"
  Dalam wadah -privileged su testuser berfungsi dengan baik.

file terbuka maks - benar. penginstal mencoba menyetel ke angka yang lebih tinggi dari yang dimiliki host. Hanya dengan meningkatkan pengaturan host atau memulai -privileged ini berhasil.

Saya baru saja mencoba dengan Dockerfile berikut:

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

Dan itu bekerja dengan baik. Apa nama persis dari gambar yang Anda gunakan?
(Saya mencoba centos-6.4-x86_64 tetapi sepertinya saya tidak bisa menariknya!)

@lukewpatterson Bisakah Anda membagikan bagaimana Anda membuat sistem file loop bekerja di dalam wadah Anda?

@jpetazzo Menjalankan file buruh pelabuhan ini

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

gagal dengan:

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

Saya mengaktifkan debugging untuk modul PAM (dengan menambahkan debug ke baris pam_limits.so di /etc/pam.d/system-auth ), menginstal syslog , mencoba su lagi, dan inilah yang saya temukan di /var/log/secure :

7 Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): membaca pengaturan dari '/etc/security/limits.conf'
7 Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: processing - nice 0 untuk USER
7 Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): membaca pengaturan dari '/etc/security/limits.d/90-nproc.conf'
7 Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: memproses soft nproc 1024 untuk DEFAULT
7 Okt 14:12:23 8be1e7bc5590 su: pam_limits(su:session): Tidak dapat menetapkan batas untuk 'bagus': Operasi tidak diizinkan

Kemudian saya strace d proses su , dan menemukan bahwa panggilan sistem berikut gagal:

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

Ini, pada gilirannya, menyebabkan modul pam_limits melaporkan kegagalan; dan ini mencegah su untuk melanjutkan.
Menariknya, di Ubuntu, pam_limits tidak diaktifkan untuk su secara default; dan bahkan jika Anda mengaktifkannya, panggilan setrlimit gagal, tetapi su berlanjut dan tetap berfungsi.
Mungkin terkait dengan kode audit, saya tidak yakin.

Sekarang, mengapa setrlimit gagal? Karena container tidak memiliki kemampuan sys_resource , yang diperlukan untuk menaikkan batasan apa pun.

Saya pikir saya hanya akan mengomentari arahan limits.conf .
(Omong-omong, itu praktik yang buruk untuk menambahkan barang langsung ke limits.conf ; itu harus pergi ke file terpisah di limits.d , saya pikir.)

Catatan: karena Anda telah meningkatkan batas jumlah file yang terbuka untuk Docker, Anda juga dapat menaikkan batas untuk prioritas maksimal; yang harus bekerja juga!

Saya harap ini membantu.

Di Dockerfile itu, Anda memiliki baris berikut dengan sendirinya:

RUN su testuser

Tidak ada perintah untuk melakukan ini (dan itu tidak akan menerapkan Shell yang dihasilkan ke perintah RUN berikutnya), jadi saya tidak akan terkejut jika itu benar-benar gagal dalam mencoba membuka Shell dan tidak berada di tempat yang interaktif sehingga melakukannya masuk akal (karena docker build bukanlah proses interaktif). Saya tidak punya waktu sekarang untuk mengonfirmasi, tetapi mungkin patut dicoba dengan perintah aktual yang diteruskan ke su .

@jpetazzo Terima kasih atas deskripsi detailnya. Saya akan mencoba meningkatkan prioritas maksimal untuk Docker dan melihat apakah itu membantu.

(Omong-omong, adalah praktik yang buruk untuk menambahkan hal-hal langsung ke limit.conf; itu harus pergi ke file terpisah di limit.d, saya pikir.)

Setuju, tetapi karena ini adalah kode penginstal Vertica yang meletakkannya di sana, saya mencoba mengatasinya.

@tianon Hal yang sama terjadi jika saya menjalankan ini di shell interaktif (/bin/bash).

Maaf, saya pikir itu masih patut dicoba.

Poin tentang baris itu tidak masuk akal di Dockerfile masih berlaku. Anda mungkin menginginkan sesuatu yang lebih seperti ini (setelah Anda mengetahui masalah batasan):

RUN su testuser -c 'echo test > ~/test.txt'

@tianon Anda benar, itu tidak masuk akal. Itu hanya untuk menunjukkan bahwa su itu sendiri gagal.

Untuk kembali ke diskusi awal: Saya yakin tidak masalah dari sudut pandang keamanan (dan berguna!) untuk mengizinkan kemampuan setfcap dan mknod dalam proses pembuatan (dan mungkin dalam eksekusi kontainer biasa sebagai dengan baik). Apakah ada yang melihat masalah yang bisa berasal dari itu?

@jpetazzo Justru sebaliknya! Itu akan memecahkan banyak masalah yang saya hadapi. Saya pikir ini diperlukan untuk orang yang ingin menjalankan wadah Docker yang bertindak/terlihat lebih seperti mesin nyata.

OKE! Jika Anda setuju, saya akan menutup masalah ini demi #2191, "Aktifkan kemampuan mknod dan setfcap di semua wadah" lalu :-)

Apakah kita tahu tentang skenario seperti itu?

Pada hari Minggu, 13 Oktober 2013 pukul 12:22, unclejack [email protected] :

2191 https://github.com/dotcloud/docker/issues/2191 tidak menyelesaikan ini

masalah untuk semua skenario yang membutuhkan docker build -privileged.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

@jpetazzo https://twitter.com/jpetazzo
Postingan blog terbaru:
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Ini diperlukan ketika Anda ingin menggunakan Dockerfile untuk membangun citra sistem operasi.

Saya telah menghapus komentar saya secara tidak sengaja saat mengeditnya.

Silakan lihat bagaimana ini akan terlihat tanpa melakukan semuanya di Dockerfile:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

Ini hanya memaksa saya untuk mengatasi kekurangan runp di Dockerfile atau docker build -privileged , sehingga membuat Dockerfiles tidak berguna dan memaksa saya menulis alat untuk menduplikasi fungsionalitas seperti Dockerfile.

Jelas, Dockerfile akan jauh lebih berguna dengan runp atau docker build -privileged :
contoh run:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

docker build -privileged contoh:

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : maaf, pertanyaan saya tidak cukup akurat!
Yang saya maksud adalah "izin mana yang Anda butuhkan sebenarnya (di atas mknod dan setfcap)?"

@jpetazzo Sulit untuk mengatakan, saya harus mengaudit ini entah bagaimana untuk mencari tahu apa yang dibutuhkan. Memasang sistem file, menggunakan perangkat blok yang dipasang di loopback dan beberapa hal lainnya.

Setidaknya ada tiga kebutuhan terpisah dalam hal membangun gambar: izin yang diperlukan selama docker build , izin yang diperlukan saat menjalankan wadah dengan buruh pelabuhan dan kebutuhan runtime untuk proses selama membangun, menjalankan atau keduanya (seperti sysctls dan lainnya) .

Saya pikir memiliki docker build -privileged (atau runp untuk menggunakan -privileged mode hanya untuk perintah yang benar-benar membutuhkannya) akan berguna.

Ah, tunggangan pasti yang besar. Itu adalah kasus penggunaan yang sangat valid, dan kami _mungkin_ tidak ingin mengizinkannya dalam kasus umum. Saya membuka kembali masalah ini.

@jpetazzo RE: Modul PAM (saya juga menginstal Vertica) apakah Anda menyarankan untuk mengkompilasi ulang buruh pelabuhan setelah mengeluarkan sys_resource dari lxc.cap.drop?

Mungkin beberapa batasan ini dapat diatur melalui file docker.conf?

Harus dipertimbangkan bahwa Docker sendiri mungkin berjalan dalam serangkaian kemampuan terbatas di mana hak istimewa ini mungkin tidak tersedia untuk didelegasikan Docker ke wadahnya. Itu akan benar terutama dalam skenario Docker bersarang yang harus mengeluarkan tanah #2080 - ini mungkin memungkinkan Docker bersarang yang tidak memiliki hak istimewa.

Bukannya ini mengubah apa pun, kecuali bahwa solusi seperti 'runp' atau '-priviledged' mungkin tidak dijamin sukses di semua lingkungan Docker. Itu harus dipertimbangkan saat menambahkan perintah tersebut dan saat mendokumentasikannya.

@ramarnat @jpetazzo hanya untuk menutup loop pada pemasangan Vertica dan masalah level yang bagus,
Saya memang mencoba untuk menetapkan batas Nice di docker.conf tetapi itu tidak berhasil untuk saya dan saya terpaksa menjalankan bash privilege dan menginstalnya secara manual.

@orikremer @jpetazzo Saya dapat menjalankan instalasi dengan menghapus sys_resource dari lxc_template.go, dan mengkompilasi ulang buruh pelabuhan. Saya dapat mengajukan permintaan tarik di luar sana, tetapi saya akan menunggu pendapat orang lain tentang implikasi keamanan dari menghapusnya dari konfigurasi lxc.

@ramarnat : tergantung pada skenario, beberapa orang akan berpikir bahwa menghapus sys_resource baik-baik saja; untuk beberapa orang lain, itu akan menjadi masalah.

Kemungkinannya adalah meningkatkan batas dasar ke sesuatu yang lebih tinggi (deskriptor file juga merupakan masalah untuk Pencarian Elastis). Ini seperti menyatakan "runtime Docker minimal harus dapat menangani 1.000.000 deskriptor file". Jika Docker tidak dapat menaikkan batas saat dimulai, itu akan mengeluarkan peringatan dan melanjutkan (seperti yang terjadi pada grup pengontrol memori/swap).

Ini tidak memperbaiki skenario mount/loop (saya masih tidur yang ini).

@jpetazzo mungkin menyediakan cara untuk mengganti nilai kode keras di lxc_template.go. Sudah ada sesuatu untuk skenario dengan baris perintah -lxc_conf, tetapi itu tidak berfungsi untuk sifat .drop dari arahan konfigurasi lxc ini - saya mencoba!

Yah, itu kemungkinan, tapi itu juga cara yang baik untuk mematahkan kompatibilitas masa depan di berbagai sistem containerization :-) Kita akan melihat apakah kita tidak dapat menemukan sesuatu yang lebih baik.

Bisakah kita memasukkan /dev/loop* ke daftar putih dalam mode non-istimewa? Saya kira masalahnya adalah itu mungkin memberi saya akses ke file yang dipasang di loop wadah lain, atau bahkan host ...

@solomonstre
@buruh pelabuhan

Pada Kam, 17 Okt 2013 pukul 18.09, Jérôme Petazzoni
[email protected] menulis:

Yah, itu kemungkinan, tapi itu juga cara yang baik untuk mematahkan kompatibilitas masa depan di berbagai sistem containerization :-) Kita akan melihat apakah kita tidak dapat menemukan sesuatu yang lebih baik.

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo Itu benar, tapi saya pikir buruh pelabuhan akan memerlukan cara standar untuk mengesampingkan konfigurasi sistem penampung yang mendasarinya jika diizinkan - kembali ke pertimbangan hak istimewa build, saya kira!

@solomonstre Intinya adalah harus ada cara untuk mengizinkan docker build untuk membangun dalam mode istimewa. Mengizinkan akses ke /dev/loop* tidak akan membantu saya dengan kasus penggunaan khusus saya.

@solomonstre : daftar putih /dev/loop adalah, IMHO, tidak boleh, karena dengan cabang DM, itu akan memberikan akses baca/tulis ke semuanya (karena perilaku default cabang DM adalah menggunakan perangkat loop untuk menyimpan kolam renang).

Saya mengerti bahwa beberapa build akan memerlukan perangkat loop, mount, dan hal-hal lain. Mari kita tinjau pilihan kita:

1. docker build -privileged
   Nyaman, tetapi menarik garis antara "build normal" dan "build istimewa". Jika Anda kebetulan memiliki gambar yang sangat berguna yang membutuhkan pembangun yang memiliki hak istimewa, akan sulit untuk membangunnya di pembangun publik. Misalnya, jika seseorang memulai layanan untuk mengotomatisasi build, mereka mungkin tidak akan menawarkan build yang diistimewakan (atau mereka harus menggunakan perlindungan ekstra).
2. Rileks izin sedikit di builder
   Ini berarti (setidaknya) mengaktifkan cap_sysadmin (ini membuat saya paranoid sedikit gemetar), dan mungkin memberikan satu atau dua perangkat loop ke setiap pembuat. Ini akan membatasi jumlah total pembangun yang berjalan secara paralel; tapi itu bukan masalah besar karena build seharusnya cepat, dan yang lebih penting, proses aktif. IE jika Anda memiliki 50 build yang berjalan secara paralel, kecuali Anda memiliki mesin dengan subsistem I/O kickass, build tersebut tidak akan banyak berkembang.
3. Bungkus build di dalam lapisan virtualisasi/isolasi lain.
   Alih-alih menjalankan build langsung di dalam Docker, jalankan sesuatu seperti QEMU-in -Docker, atau UML-in-Docker. Ini adalah solusi keren dari sudut pandang pengembang Docker, karena ini berarti tidak ada pekerjaan tambahan; ini adalah solusi yang buruk dari sudut pandang pengguna DOcker, karena ini berarti berurusan dengan lapisan kompleksitas lainnya.

Saya ingin tahu apakah solusi yang tepat adalah mengizinkan docker build -privileged`, dan pada saat yang sama, pikirkan tentang kait yang memungkinkan implementasi transparan opsi 3. Misalkan saya adalah "penyedia pembangunan buruh pelabuhan": if seseorang meminta build yang diistimewakan, yang harus saya lakukan adalah memasukkan sesuatu di suatu tempat untuk menjalankan proses build mereka dalam lingkungan sandbox (QEMU dan UML adalah kandidat yang jelas, tetapi yang lain mungkin juga berfungsi; itu hanya contoh yang mudah).

apa yang kalian pikirkan?

@backjlack , bolehkah saya bertanya bagaimana Anda menggunakan wadah itu setelah dibuat? Apa
terjadi ketika Anda "menjalankan buruh pelabuhan" dengan tepat, apa aplikasinya? Hanya
mencoba memahami kasus penggunaan untuk ini.

Pada Jum, 18 Okt 2013 jam 09:59, Jérôme Petazzoni
[email protected] menulis :

@solomonstre https://github.com/solomonstre : daftar putih /dev/loop adalah,
IMHO, tidak-tidak, karena dengan cabang DM, itu akan memberikan baca/tulis
akses ke semuanya (karena perilaku default cabang DM adalah menggunakan
perangkat loop untuk menyimpan kumpulan).

Saya mengerti bahwa beberapa build akan memerlukan perangkat loop, mount, dan lainnya
hal-hal. Mari kita tinjau pilihan kita:

1. docker build -privileged Nyaman, tetapi menarik garis antara
   "build normal" dan "build istimewa". Jika Anda memiliki sangat
   gambar berguna yang membutuhkan pembangun istimewa, akan sulit untuk
   membangunnya di pembangun publik. Misalnya jika seseorang memulai layanan untuk mengotomatisasi
   build, mereka mungkin tidak akan menawarkan build istimewa (atau mereka akan memiliki
   untuk menggunakan perlindungan ekstra).
2. Rileks izin sedikit di pembangun Ini berarti (setidaknya)
   mengaktifkan cap_sysadmin (ini membuat saya sedikit paranoid), dan mungkin
   memberikan satu atau dua perangkat loop ke setiap pembuat. Ini akan membatasi total
   jumlah pembangun yang berjalan secara paralel; tapi itu bukan masalah besar karena
   build seharusnya cepat, dan yang lebih penting, proses aktif.
   IE jika Anda memiliki 50 build yang berjalan secara paralel, kecuali jika Anda memiliki mesin
   dengan subsistem I/O kickass, build itu tidak akan banyak berkembang.
3. Bungkus build di dalam lapisan virtualisasi/isolasi lain.
   Alih-alih menjalankan build langsung di dalam Docker, jalankan sesuatu seperti
   QEMU-in-Docker, atau UML-in-Docker. Ini adalah solusi keren dari Docker
   sudut pandang pengembang, karena itu berarti tidak ada pekerjaan tambahan; ini miskin
   solusi dari sudut pandang pengguna DOcker, karena itu berarti berurusan dengan
   lapisan kompleksitas lainnya.

Saya ingin tahu apakah solusi yang tepat adalah mengizinkan docker build-privileged`,
dan pada saat yang sama, pikirkan tentang kait yang memungkinkan transparan
implementasi opsi 3. Misalkan saya adalah "penyedia pembangunan buruh pelabuhan": jika
seseorang meminta bangunan istimewa, yang harus saya lakukan adalah memasukkan
sesuatu di suatu tempat untuk menjalankan proses pembuatan mereka dalam kotak pasir
lingkungan (QEMU dan UML adalah kandidat yang jelas, tetapi yang lain mungkin berhasil
juga; mereka hanya contoh yang mudah).

apa yang kalian pikirkan?

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - Saya ingin melihat kemampuan mknode untuk menginstal sekering (untuk memasang ember S3) atau kemampuan untuk menjalankan proses istimewa di Dockerfiles. Belum yakin apa solusi terbaiknya.

+1. ada pembaruan tentang masalah ini?

+1
Pada 17 November 2013 23:31, "yukw777" [email protected] menulis:

+1. ada pembaruan tentang masalah ini?

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

Saya juga mengalami masalah Fuse dalam mencoba menginstal Java dan saya tertarik dengan solusinya. Saya mencoba solusi yang disarankan di sini https://Gist.github.com/henrik-muehe/6155333 tetapi tidak berhasil untuk saya di buruh pelabuhan di Raspberry Pi.

@jpetazzo : Saya suka strategi keseluruhan penerapan flag -privileged sambil secara bersamaan menjelajahi solusi jangka panjang. Untuk itu, saya telah mengajukan permintaan tarik untuk mengimplementasikan fitur ini. Perhatikan bahwa sampai sekarang, itu tidak mengimplementasikan perintah "RUNP" seperti yang dibahas sebelumnya di utas ini.

(Biarkan saya "melintasi posting" ini, karena orang mungkin berakhir di sini mencari solusi)

Jika Anda tidak benar-benar menggunakan file perangkat (tetapi itu hanya bagian dari skrip post-inst seperti pada paket fuse), Anda dapat melakukan:

fakeroot apt-get ...

atau:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

Saya yakin itu bermaksud baik, tetapi komentar pertama/laporan saya sudah menyertakan dua solusi.
Agar adil, Anda menambahkan yang baru ke daftar, tetapi masalahnya bukan 'Tidak dapat menginstal sekering' dan membaca posting pertama akan membantu orang-orang yang hanya membutuhkan paket untuk menginstal apa pun yang terjadi.

Masalah sebenarnya adalah 'Saya perlu memanggil mknod' (atau lebih umum: Saya membutuhkan operasi istimewa yang sejauh ini gagal).

@jpetazzo Ini bisa memperbaikinya, kan? https://lwn.net/Articles/564977/ - Sampai saat itu, saya akan memilih 3) karena mengisolasi akses perangkat _is_ lapisan kompleksitas lain dan harus dikelola di suatu tempat.

Saya juga tidak setuju bahwa pemasangan loop atau sekering adalah fitur yang diperlukan. Rasanya gila untuk memberikan wadah yang digunakan izin root ruang untuk memasang sistem file yang (sekering: implementasi berjalan, loop: file gambar) di ruang pengguna.

Jika Anda perlu memasang gambar sistem file atau fuse fs, Anda dapat memasangnya di luar wadah dan menggunakannya sebagai pemasangan volume/ikatan. Meskipun itu mungkin fitur yang bagus untuk mendukung dan mengelola sistem file jarak jauh di buruh pelabuhan itu sendiri. Mungkin file docker MOUNT/mount-point.

@discordianfish 3) cukup banyak bukan solusi.

akankah #2979 membantu masalah ini?

Saya sedang menunggu resolusi untuk ini juga, tetapi bukan karena mknod. Kami menjalankan kontainer centos dengan rpms yang menetapkan batas untuk pengguna yang menggunakan /etc/security/limits.d/ dan saat ini saya menggunakan solusi palu godam yang terdiri dari:

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

di bagian atas Dockerfile saya. (Kami hanya membuat prototipe, jangan khawatir :))

Hai @jpetazzo Saya mencoba kedua opsi yang Anda sarankan. Saya mencoba membuat gambar "Oracle_xe" menggunakan

sudo docker build - privilege -t Oracle_xe karena di Dockerfile saya, saya ingin menjalankan 2 perintah ini

JALANKAN mount -o remount,size=3G /dev/shm
RUN mount -a

Tapi itu tidak berhasil, saya tidak tahu apakah sintaks yang saya gunakan salah, kesalahan yang saya dapatkan adalah
bendera disediakan tetapi tidak ditentukan: -hak istimewa

Saya juga mencoba pilihan kedua untuk menggunakan RUNP tetapi itu juga tidak berhasil, ketika saya membangun gambar itu melewatkan langkah itu dengan mengatakan

Melewati instruksi RUNP yang tidak diketahui. Saya dapat mengirimi Anda Dockerfile yang saya coba buat. Tolong bantu saya memecahkan masalah ini.

Terima kasih.

Saya pikir baik RUNP maupun "build --privileged" tidak diterapkan.
Jika memungkinkan, jangan ragu untuk membagikan Dockerfile; itu bisa berguna jadi
kami dapat memberi Anda solusi "paling tidak buruk" :-)

Pada hari Rabu, 9 April 2014 pukul 07.44, Manoj7 [email protected] menulis:

Hai jpetazzo Saya mencoba kedua opsi yang Anda sarankan. Saya mencoba membangun
gambar "Oracle_xe" menggunakan

sudo docker build - privilege -t Oracle_xe karena di Dockerfile saya
ingin menjalankan 2 perintah ini

JALANKAN mount -o remount,size=3G /dev/shm
RUN mount -a

Tetapi saya tidak berhasil, saya tidak tahu apakah sintaks yang saya gunakan adalah
salah. Saya juga mencoba pilihan kedua untuk menggunakan RUNP tetapi itu juga tidak
bekerja, ketika saya membangun gambar itu melewatkan langkah itu dengan mengatakan
Melewati instruksi RUNP yang tidak diketahui. Saya dapat mengirimi Anda Dockerfile seperti saya
mencoba untuk membangun. Tolong bantu saya memecahkan masalah ini.

Terima kasih.

Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

@jpetazzo https://twitter.com/jpetazzo
Postingan blog terbaru:
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Hai @jpetazzo , saya ingin melakukan "RUN Sudo umount /etc/hosts" di Dockerfile saya - apakah ada solusi "paling tidak lebih buruk" untuk ini? ;)

@jpetazzo

Dockerfile yang saya gunakan untuk membuat gambar Oracle_xe

Dari *

PEMELIHARA * * * * * * *

TAMBAHKAN Oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/Oracle/xe/Oracle-xe-11.2.0-1.0.x86_64.rpm.zip
JALANKAN mount -o remount,size=3G /dev/shm
RUN mount -a
JALANKAN cd /appl/Oracle/xe && unzip oracle-xe-11.2.0-1.0.x86_64.rpm.zip
JALANKAN cd /appl/Oracle/xe/Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
JALANKAN cd /appl/Oracle/xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/Oracle/product/11.2.0/xe
ENV ORACLE_SID XE

Hal pertama yang saya coba adalah

sudo docker build -privileged -t oracle_xe .

Ini tidak berhasil dan kemudian saya mencoba menggunakan RUNP
RUNP mount -o remount,size=3G /dev/shm
RUNP mount -a
ini juga tidak berhasil, dua langkah ini dilewati.

@gatoravi : sayangnya, melepas /etc/hosts tidak akan bekerja dengan mudah. Mengapa Anda perlu melakukan itu? (Saya mengerti bahwa Anda dapat memiliki alasan yang sangat valid, tetapi saya ingin mendengar mereka memberi Anda solusi terbaik...)

@Bhagat7 : benar! Pertanyaan: apakah Anda memerlukan /dev/shm yang lebih besar saat run time _and_ install time, atau hanya run time? Jika pada waktu build, langkah mana yang gagal dan bagaimana caranya?

@jpetazzo Saya ingin menambahkan alamat IP dan baru ke /etc/hosts sebagai bagian dari proses pembuatan alat saya.
Sesuatu seperti echo $IP $HOST >> /etc/hosts.

Saya dapat melakukan ini dengan baik jika saya menggunakan docker run --privileged dan kemudian melakukan sudo umount \etc\hosts tetapi sepertinya saya tidak dapat melakukan itu menggunakan docker commit maka saya harus mengulangi umount langkah setiap kali secara manual ketika saya menjalankan sebuah wadah.

Saya ingin membuat \etc\hosts dapat ditulis dan membuatnya persisten, sepertinya tidak dapat menemukan cara melakukannya dengan docker commit atau dengan Dockerfile.

@jpetazzo

Saya punya masalah ini

konfigurasi bash-4.1#/etc/init.d/Oracle-xe
Tentukan port HTTP yang akan digunakan untuk Oracle Application Express [8080]:

Tentukan port yang akan digunakan untuk pendengar database [1521]: 1521

Tentukan kata sandi yang akan digunakan untuk akun database. Perhatikan bahwa sama
password akan digunakan untuk SYS dan SYSTEM. Oracle merekomendasikan penggunaan
password yang berbeda untuk setiap akun database. Ini bisa dilakukan setelah
konfigurasi awal:
Konfirmasi kata sandi:

Apakah Anda ingin Oracle Database 11g Express Edition dimulai saat boot (y/n) [y]:y

Memulai Oracle Net Listener...Selesai
Mengonfigurasi basis data...Selesai
Memulai instans Oracle Database 11g Express Edition...Selesai
Instalasi berhasil diselesaikan.
bash-4.1#cd /u01/app/Oracle/product/11.2.0/xe/bin
base-4.1#sqlplus
Masukkan Nama Pengguna: sistem
Masukkan Kata Sandi: * **
Tapi saya mendapatkan kesalahan ini
ORA-01034: ORACLE tidak tersedia
ORA-27101: ranah memori bersama tidak ada
Kesalahan Linux-x86_64: 2: Tidak ada file atau direktori seperti itu
ID Proses: 0
ID sesi: 0 Nomor seri: 0
df -h di dalam wadah dikembalikan
Ukuran Sistem File yang Digunakan Tersedia Penggunaan% Dipasang di
tmpfs 64M 0 64M 0% /dev/shm

Jadi ketika saya meningkatkan ukuran tmpfs ke 3G saya tidak mendapatkan kesalahan ini. Saya mengatasinya dengan menjalankan wadah sebagai
sudo docker run -privileged -i -t Oracle_xe /bin/bash. Saya menjalankan 2 perintah mount di dalam wadah. Tetapi saya tidak ingin melakukannya seperti itu, sebaliknya saya ingin meletakkannya di Dockerfile saya dan membangunnya.

@gatoravi : Oke, mengerti. Dua pertanyaan lagi: apakah Anda memerlukan host tambahan di /etc/hosts selama build, atau hanya saat dijalankan? Dan mengapa Anda membutuhkannya?

@ Bhagat7 : Maaf, saya belum punya solusi elegan untuk ini :-( Saya menyarankan untuk memiliki dua Dockerfiles:

• yang pertama melakukan semua langkah (kecuali yang membutuhkan /dev/shm yang lebih besar), dan mendefinisikan CMD yang akan memeriksa apakah wadah berjalan dalam mode istimewa, pasang /dev/shm yang lebih besar, dan jalankan yang khusus memerintah;
• Dockerfile kedua untuk melakukan langkah lebih lanjut (kecuali jika Anda juga membutuhkan /dev/shm saat runtime, maka untuk saat ini Anda memerlukan hal yang diistimewakan).

@jpetazzo Kami ingin memberi pengguna kami gambar(/ wadah) dengan /etc/hosts/ yang dapat diedit sehingga mereka dapat membuat kode kami yang memodifikasi file itu :) Mengenai mengapa kami perlu menambahkan host, saya' Saya tidak begitu yakin untuk jujur, kami melakukannya sebagai bagian dari instalasi kami untuk membantu mengarahkan nama host tertentu ke alamat IP.

@ Bhagat7 Saya bisa menjalankan Oracle XE dalam wadah buruh pelabuhan 0.9 menggunakan kombinasi:

1. https://github.com/wnameless/docker-Oracle-xe-11g
   dan
2. pada tuan rumah...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters Terima kasih banyak telah menjawab. Saya pikir Anda membangun Oracle XE di atas Ubuntu. Tapi saya mencoba membangunnya di Centos.

@jpetazzo Terima kasih banyak atas sarannya

Halo kawan-kawan,

Saya menggunakan google-chrome yang perlu menulis ke /dev/shm yang tampaknya biasanya 777 dan 755 di sini. Saya mencoba menambahkan konfigurasi khusus ke /etc/fstab tetapi tidak dapat menjalankan mout -a untuk menerapkan modifikasi pada file build. Tentu saja saya mencoba chmod atau chown tetapi tidak dapat melakukannya juga di build.

Jika saya menggunakan perintah saya saat login dalam mode --privileged , semuanya baik-baik saja. Tetapi saya perlu, seperti yang dijelaskan orang lain, untuk melakukan ini di build.

Ada saran?

Terima kasih.

@tomav masalah izin "/ dev/shm" sebenarnya #5126, yang diperbaiki di #5131 dan sudah digabung menjadi master (dan akan ada di rilis berikutnya)

Terima kasih @tianon.

hari ini saya punya ide ini: saya ingin wadah yang mengelola volume data saya. mudah, tetapi karena saya menggunakan vps, saya ingin volume itu dienkripsi, tetapi disediakan untuk wadah lain seperti biasa dengan jelas. intinya adalah, hanya untuk tidak memiliki data yang jelas pada disk virtual dan cara cepat untuk menghancurkan dengan menghapus kunci.

saya mengikuti beberapa langkah yang didokumentasikan dengan indah dalam artikel ini tentang membuat cryptfs untuk memasukkan wadah: https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

perhatikan, bahwa saya _not_ mencoba melakukan itu, tetapi sebenarnya memiliki wadah dengan cryptfs yang terpasang:
jadi sistem file terenkripsi harus dibuat, dipasang, diformat selama pembuatan melalui buruh pelabuhan.

yang gagal:

• ketika saya mencoba menemukan perangkat loop:

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• anehnya dockerfile yang sama persis _sometimes_ berhasil menemukan perangkat loop, lalu:

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

apakah sudah ada cara untuk mengatasinya? (selain memindahkan langkah-langkah pemasangan/format disk ke run )

+1 Ini akan sangat berguna untuk lingkungan "docker in docker"

Memberi +1 pada ini, iptables tidak berfungsi dalam mode tidak istimewa, yang menyebabkan apa pun yang mencoba mengatur aturan firewall gagal.

@PerilousApricot : perhatikan, bagaimanapun, bahwa bahkan jika Anda dapat menetapkan aturan iptables di RUN , itu akan segera hilang, karena gambar hanya menyimpan status sistem file. Itu tidak tahu tentang proses yang berjalan, rute jaringan, aturan iptables, dll.

Tidak masalah bagi saya, karena wadah hanya memiliki port tertentu
diteruskan, saya tidak peduli dengan firewall, saya kebanyakan hanya ingin
installer untuk dapat berhasil sama sekali

Andrew Melo

@PerilousApricot saya mengerti! Dalam hal ini, bagaimana dengan symlink iptables ke /bin/true ? Itu seharusnya membuat penginstal senang juga. (Atau trik serupa untuk mengelabui penginstal?)

Saya mencobanya, tetapi penginstal juga perlu mengurai output dari
iptables, jadi tidak semudah itu :)

Oke, saya tahu ini mulai diretas, tapi -- bagaimana kalau memasang iptables palsu? Mana yang akan menghasilkan beberapa keluaran dummy?

Saya benar-benar mengerti bahwa itu tidak bagus; tapi serius, penginstal semacam itu harus diperbaiki di tempat pertama :)

Docker dalam kasus penggunaan buruh pelabuhan adalah yang membawa saya ke sini. Nah, buruh pelabuhan di lxc, untuk lebih spesifik, karena lingkungan pengembangan kami menggunakan lxc, dan saya ingin pengembang dapat membuat gambar di lxc.

Saya ingin ini untuk buruh pelabuhan di buruh pelabuhan juga. Ada gambar yang perlu ditarik sebelum aplikasi dapat dijalankan, yang agak besar, dan saya lebih suka itu ditarik dan di-cache sebagai bagian dari docker build daripada perlu sering menarik dan/atau komit wadah yang telah ditarik.

Fitur ini adalah IMHO yang harus dimiliki, kombinasi RUNP bersama dengan build-privileged akan sangat bagus.

Skenario kehidupan nyata/produksi yang saya lawan adalah gambar Docker yang dibuat dengan penyediaan Wayang dalam wadah perantara. Pada layanan tertentu yang memerlukan peningkatan kemampuan, terdapat kegagalan pada build yang mengharuskan container dijalankan di bawah -privileged dengan ENTRYPOINT atau CMD yang menerapkan kembali skrip boneka.

Ini menunda waktu startup layanan nyata dalam wadah karena konfigurasi boneka perlu dibangun dan kemudian diterapkan untuk memastikan status yang tepat (dan ini memakan waktu), serta wadah yang sedang berjalan _might_ tidak perlu dijalankan dalam -privileged mode

Saya harap hal di atas masuk akal.

@jpetazzo Saya mencoba membangun server web di atas centos6. Saya terdampar dalam mengonfigurasi aturan iptable melalui file docker. Ini mirip dengan masalah @PerilousApricot .

btw: Saya BUKAN untuk menerapkan peretasan seperti iptables palsu.

@pmoust : apakah Anda memiliki detail tentang operasi build mana yang memerlukan hak istimewa yang lebih tinggi? Saya mungkin akan merekomendasikan untuk menghindari masalah, dan saya benar-benar menyadari bahwa ini mungkin tidak memuaskan bagi Anda; namun demikian, saya akan dengan senang hati memahami pemasang/pembuat seperti apa yang mungkin memerlukan hak istimewa tersebut...

@passion4aix : perhatikan bahwa jika Anda menetapkan aturan iptables di Dockerfile, mereka TIDAK akan disimpan. Docker hanya menyimpan status sistem file, bukan perutean/pemfilteran/proses yang berjalan... Ada cara untuk mengatur aturan iptables dengan wadah "sidekick". Apakah itu sesuatu yang bisa menarik bagi Anda?

@jpetazzo Penginstal Bitrock adalah salah satu contohnya. Ini membutuhkan /tmp untuk dipasang sebagai tmpfs. Anda mungkin ingin melihat http://answers.bitrock.com/questions/3092/running-installer-inside-docker

@jpetazzo atau pada dasarnya semua penginstal openstack

Saya juga baru saja mengalami masalah serupa ketika mencoba menjalankan TokuMX dalam wadah Docker karena TokuMX memerlukan opsi kernel 'transparent_hugepage' untuk dinonaktifkan.

Apakah ada kemajuan dalam masalah ini? Sudah lebih dari satu tahun dan melihat komentar, kebanyakan orang telah menggunakan untuk menjalankan tindakan istimewa dari Dockerfile.

Secara pribadi saya tidak akan memilih build dengan solusi '--privileged'. Solusi RUNP lebih baik karena Anda hanya dapat menjalankan beberapa tindakan sebagai pengguna dengan hak istimewa daripada menjalankan seluruh instalasi sebagai hak istimewa. Dengan cara ini setidaknya Anda harus memikirkan kapan harus menggunakan RUNP dan hanya menggunakannya saat dibutuhkan.

Menurut saya pertanyaannya bukan lagi JIKA opsi ini harus ditambahkan, tetapi hanya Ketika selesai. Jadi, kapan kita bisa mengharapkan fungsi ini?

@diversit Mereka harus digabungkan. Jadi --privileged pada baris perintah akan memungkinkan kemampuan untuk menggunakan RUNP , jika tidak, ini akan menjadi mimpi buruk keamanan bagi orang-orang yang melakukan pembuatan kode yang tidak tepercaya (termasuk DockerHub).

Tetapi juga perlu diingat, Anda dapat melakukan ini secara manual di luar sintaks Dockerfile. Proses build membaca Dockerfile, membuat container darinya, dan mengembalikannya ke image.

@deas : Saya pikir ini bisa diselesaikan dengan melakukan VOLUME /tmp .

@PerilousApricot : dapatkah Anda menjelaskan sedikit? Saya tidak mengerti mengapa segala jenis penginstal memerlukan hak istimewa. (Ya, saya adalah orang tua Unix yang keras kepala, itu salah satu kekurangan saya :D)

@diversit : untuk kasus khusus itu, saya pikir admin mesin harus menonaktifkan halaman besar transparan sebelum membangun. Karena jika pembuat diizinkan untuk melakukan itu, ia akan melakukannya secara global (kan?) dan mungkin merusak wadah lain yang mungkin memerlukan fitur tersebut. Apakah Anda melihat apa yang saya maksud? Akan menjadi buruk jika membangun container X merusak container Y yang sedang berjalan...

Semua orang: Saya benar-benar mengerti bahwa itu sangat membuat frustrasi ketika Dockerfile tidak berfungsi, dan yang Anda butuhkan hanyalah flag --privileged / RUNP . Tetapi jika kita mulai memiliki build yang diistimewakan, itu akan merusak banyak hal (misalnya build otomatis di Docker Hub!), jadi itu sebabnya kami merasa sangat tidak enak tentangnya. Dan untuk apa nilainya, saya bersedia menyelidiki semua skenario yang membutuhkan bangunan istimewa dan membantu memperbaikinya :-) (Karena keyakinan pribadi saya bahwa penginstal tersebut rusak!)

@jpetazzo Banyak/sebagian besar alat penerapan openstack (mis. https://openstack.redhat.com/Main_Page) menetapkan aturan iptables. Saya ingin dapat menggulung/menyebarkan versi aplikasi yang kemas, jadi dapat membangun dockerfile dan melakukannya dalam sekali jalan adalah penting bagi saya. Saya tahu bahwa aturan iptables tidak dipertahankan melalui proses containerization secara asli, tetapi mereka bertahan melalui iptables-save, jadi iptables-restore sederhana dalam proses CMD akan menyebabkan aturan dimuat ulang. Jauh lebih rumit untuk hanya "mematikan" iptables karena banyak alat penyebaran menggunakan alat CI seperti boneka atau koki untuk melakukan penyebaran yang sebenarnya, jadi Anda perlu entah bagaimana membuat rintisan yang kompatibel yang pada akhirnya akan meniru semua input/output ke perintah iptables "nyata".

Lebih lanjut, saya pikir ini adalah tradeoff yang adil untuk mengatakan, "Jika Anda memiliki Dockerfile yang memerlukan build istimewa, Anda kehilangan fitur X, Y, Z"

Oracle xe tidak akan berjalan tanpa ruang mem bersama yang cukup. Semua akun adalah remountimg tmpfs dengan ruang enuf membuat Oracle xe senang untuk memulai dan menyelesaikan konfigurasinya .. (bagi mereka yang memiliki wawasan, ini adalah langkah '/etc/init.d/Oracle-xe configure' yang mengeluhkan tentang batasan memori target dikabarkan akan diatasi dengan meningkatkan ukuran mount)

Selama membangun
JALANKAN unmount tmpfs
gagal dengan
umount: /proc/kcore: harus superuser untuk umount

beri saya RUNP atau beri saya kematian .... atau .... tunjukkan apa yang bisa saya lakukan secara berbeda :)

Contoh saya tidak valid; @jpefazzo masih berdiri :) Pengaturan Oracle saya menyebabkan masalah dan tampaknya tidak perlu menyesuaikan ukuran tmpfs ... setidaknya untuk instalasi awal.

Saya mengalami masalah iptables di CentOS 7.0 yang hanya diselesaikan ketika run ning dengan --privileged https://github.com/docker/docker/issues/3416

Tanpa dukungan untuk bangunan istimewa, saya tidak yakin bagaimana lagi untuk mengatasi masalah ini

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley Saya percaya dengan tambahan security-opts di #8299 akan mungkin untuk melakukan ini tanpa --privileged

@jpetazzo Saya tidak melihat bagaimana menggunakan VOLUME /tmp memecahkan masalah Pemasang Bitrock. Itu mungkin berhasil untuk build, tetapi itu juga akan membuat /tmp melewati layering AUFS untuk semua kontainer berdasarkan gambar itu, bukan? Pada akhirnya, tampaknya akar masalah harus diperbaiki di AUFS.

Inilah kasus penggunaan saya: Saya ingin membangun lingkungan chroot di dalam wadah buruh pelabuhan. Masalahnya adalah debootstrap tidak dapat dijalankan, karena tidak dapat me-mount proc di chroot:
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Jika saya run --privileged wadah, itu (tentu saja) berfungsi ...
Saya benar-benar ingin mendebootstrap chroot di Dockerfile (jauh lebih bersih). Apakah ada cara saya bisa membuatnya berfungsi, tanpa menunggu RUNP atau membangun --privileged?

Terima kasih banyak!

+1 untuk --privileged atau pemasangan. Kebutuhan untuk membangun glusterfs secara otomatis

Ini memengaruhi upaya saya untuk membuat gambar dari penginstal Bitnami Tomcat. 99% dari proses instalasi berjalan tanpa masalah tetapi, ketika mencoba memulai Tomcat untuk pertama kalinya, itu gagal dengan output berikut di catalina-daemon.out:

set_caps: gagal menyetel kemampuan
periksa apakah kernel Anda mendukung kapabilitas
set_caps(CAPS) gagal untuk pengguna 'Tomcat'
Layanan keluar dengan nilai pengembalian 4

Saya berhasil menjalankan penginstal Tomcat secara manual dalam wadah yang saya buat dengan "--cap-add ALL". Tampaknya aneh bahwa saya tidak dapat menggunakan 'docker build' untuk membuat gambar yang dapat saya buat secara manual menggunakan 'docker run' lalu 'docker commit'. Kontainer yang digunakan selama proses pembuatan harus memiliki semua fungsionalitas seperti kontainer yang dapat Anda buat menggunakan 'docker run'.

@gilbertpilz Mereka secara eksplisit tidak dapat melakukan itu untuk memastikan portabilitas dan keamanan build.

@ cpuguy83 - Itu tidak masuk akal. Saya dapat membuat gambar yang saya inginkan, dengan tangan, jika saya melakukannya:

docker run --cap-add ALL .... /bin/bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
keluar
buruh pelabuhan berkomitmen ....

Yang saya minta hanyalah kemampuan untuk menggunakan "docker build" untuk melakukan hal yang sama yang saya lakukan secara manual di sini. Saya gagal melihat bagaimana "portabilitas dan keamanan" sedang "dipastikan" jika saya dapat membuat gambar dengan satu cara tetapi tidak dengan cara yang lain.

Oke, izinkan saya memberi Anda Dockerfile yang memasang /etc/passwd Host ke dalam builder dan kebetulan mengirimkannya kepada saya.

Benda ini bisa berbahaya.
Perhatikan juga bahwa --privileged (dan --cap-add ALL) memberi pengguna dalam wadah kendali penuh atas host.

Membiarkan hal-hal ini akan membahayakan keseluruhan DockerHub

@ cpuguy83 - Anda tidak perlu meletakkan kontrol di Dockerfile. Anda dapat menambahkan opsi "--cap-add" (atau yang serupa) ke perintah "docker build". Jika kami mengikuti logika Anda, skrip shell seharusnya tidak mengizinkan penggunaan perintah "sudo" karena seseorang dapat menulis skrip yang melakukan hal-hal buruk.

Tetapi Anda tidak akan memberi seseorang sudo yang tidak terlalu Anda percayai dengan kunci kerajaan.
Build harus dapat, seaman mungkin, menjalankan kode yang tidak tepercaya.

Memperkenalkan flag CLI untuk mengaktifkan fitur tambahan pada build merusak portabilitas build, dan itulah sebabnya ia belum ditambahkan.

Yang mengatakan, penginstal hampir pasti salah di sini meminta hal-hal yang seharusnya tidak dapat diaksesnya sendiri.

Tepat. Anda tidak boleh memberi orang yang tidak Anda percayai kemampuan untuk menjalankan build buruh pelabuhan yang memerlukan hak istimewa, tetapi buruh pelabuhan tidak boleh mencegah orang yang Anda _do_ percayai untuk melakukannya. Ini adalah keputusan kebijakan dan saya sangat tidak suka ketika alat-alat dianggap membuat keputusan kebijakan untuk saya. Alat yang baik memungkinkan saya untuk menerapkan keputusan kebijakan yang telah saya buat dengan cara yang jelas dan tidak mengejutkan.

Anda tidak melihat gambaran yang lebih besar.

Ada lebih banyak ekosistem ini daripada server Anda dan server saya. DockerHub, misalnya, selalu membuat kode yang tidak tepercaya.

Maka DockerHub harus _not_ mengaktifkan penambahan kemampuan untuk build-nya. Jika ini berarti saya tidak dapat mendorong build buruh pelabuhan saya ke DockerHub, saya setuju dengan itu.

@cpuguy83 @tianon @jpetazzo -- Saat FUD dimulai, saya terpaksa angkat bicara:

Membiarkan hal-hal ini akan membahayakan keseluruhan DockerHub

srly?
Menerapkan fitur ini == TEOTWAWKI ?

Tentu saja DockerHub akan pernah menjalankan docker build dengan meminta --privileged bendera.
Tanpa terlalu banyak berpikir, setidaknya ada dua cara yang jelas untuk menerapkannya:

• flag hanya berfungsi jika Anda juga meluncurkan docker -d dengan beberapa flag baru seperti: --i-want-a-broken-security-model
• Buat flag waktu kompilasi yang mengaktifkan jalur kode.

Secara keseluruhan rasio kertakan gigi dengan alasan berbasis rekayasa terhadap implementasi tampaknya sangat tinggi di sini.

@tamsky Dan kemudian kami memiliki situasi di mana build berfungsi di satu tempat tetapi tidak di tempat lain.
Saya menjelaskan mengapa segala sesuatunya seperti itu, tidak memperdebatkan satu kasus atau lainnya.

Tetapi juga... kebanyakan hal tidak memerlukan akses istimewa apa pun, dan mereka yang membutuhkan akses istimewa umumnya tidak _sangat_ membutuhkannya agar instalasi berfungsi. Jika pemasangan sesuatu gagal karena ini, penginstal itu rusak, seperti halnya dengan masalah Tomcat yang dikutip.
Mengaktifkan fitur seperti itu akan mendorong orang untuk menjalankan dengan mode istimewa alih-alih benar-benar menyelesaikan masalah sebenarnya yang dihadapi.

@cpuguy83

Dan kemudian kami memiliki situasi di mana bangunan bekerja di satu tempat tetapi tidak di tempat lain.

Bayangkan sejenak kita telah dibawa secara ajaib ke dunia di mana _kebijakan_ berbeda, dan beberapa bangunan berfungsi di satu tempat tetapi tidak di tempat lain...

Mengapa ini masalah besar?
Siapa yang peduli?

Apakah Docker Inc menganggap bahwa mantra penyebut umum terendah/persyaratan "semua bangunan harus berfungsi di mana saja" mungkin sebenarnya mengabaikan kebutuhan pelanggan yang sebenarnya?

Kebijakan saat ini adalah mengeksternalisasi biaya rekayasa bagi pelanggan untuk "mendapatkan X untuk membangun buruh pelabuhan":

Alih-alih menyediakan fitur ini di buruh pelabuhan, Anda memaksa setiap proyek pihak ke-3 di dunia yang tidak "memerlukan akses istimewa apa pun" (tetapi sebenarnya membutuhkan), untuk terlebih dahulu diperbarui atau ditambal untuk menangani kasus pembangunan buruh pelabuhan.

Akhirnya, jika Docker akan berjalan di banyak platform, 'docker build' TIDAK akan bekerja sama di semua sistem. Artinya, build container Windows, container Solaris, atau bahkan container ARM Linux tidak akan sama dengan yang ada di x86-64 Linux. Konteks keamanan untuk ini juga akan berbeda, sesuai dengan platform mereka.

Artinya, @cpuguy83 , kami tidak selalu dapat menganggap bahwa Dockerfiles akan tetap universal. Namun, saya setuju bahwa kita perlu meminimalkan berapa banyak perbedaan yang ada di antara mereka. Mungkin layak untuk menyertakan pertimbangan bagi pengguna yang menginginkan fitur ini, meskipun berbahaya, dalam percakapan yang pada akhirnya perlu terjadi seputar dukungan multi-arch / multi-platform.

Build tidak berfungsi di semua tempat karena misalnya memuat profil pelindung aplikasi.
Juga bagaimana Anda melakukan kasus dengan wadah buruh pelabuhan pra-cache yang dipanggang menjadi gambar?

Pada 18. 11. 2014, pukul 2:53, tamsky [email protected] menulis:

@cpuguy83

Dan kemudian kami memiliki situasi di mana bangunan bekerja di satu tempat tetapi tidak di tempat lain.

Silakan bayangkan sejenak kita telah dibawa secara ajaib ke dunia di mana kebijakannya berbeda, dan beberapa bangunan berfungsi di satu tempat tetapi tidak di tempat lain...

Mengapa ini masalah besar?
Siapa yang peduli?

Apakah Docker Inc menganggap bahwa mantra penyebut umum terendah/persyaratan "semua bangunan harus berfungsi di mana saja" mungkin sebenarnya mengabaikan kebutuhan pelanggan yang sebenarnya?

Kebijakan saat ini adalah mengeksternalisasi biaya rekayasa bagi pelanggan untuk "mendapatkan X untuk membangun buruh pelabuhan":

Alih-alih menyediakan fitur ini di buruh pelabuhan, Anda memaksa setiap proyek pihak ke-3 di dunia yang tidak "memerlukan akses istimewa apa pun" (tetapi sebenarnya membutuhkan), untuk terlebih dahulu diperbarui atau ditambal untuk menangani kasus pembangunan buruh pelabuhan.

—
Balas email ini secara langsung atau lihat di GitHub.

Bukan "penginstal" yang "rusak" dalam situasi ini, melainkan Tomcat 7. Saya menggunakan tumpukan Tomcat Bitnami yang mengintegrasikan Tomcat dengan Apache dan MySQL. Docker duduk di ujung rantai pasokan layanan sumber, konfigurasi, integrasi, pengujian, dan pengemasan. Mengharuskan saya untuk "memperbaiki" Tomcat mencegah saya mengambil keuntungan dari rantai pasokan ini. Jauh lebih mudah untuk membuat gambar yang saya inginkan dengan tangan (mulai wadah dengan "--privileged", jalankan penginstal, potret wadah, dll.) daripada "memperbaiki" Tomcat.

+1
Saya tidak dapat mem-porting peran chef saya ke buruh pelabuhan karena semuanya melibatkan penggunaan ufw untuk membuka port.
menambahkan --privileged untuk membangun akan memperbaikinya.

+1. Tidak dapat memiliki debootstrap sebagai langkah di Dockerfiles saya.

+1. Tidak dapat memiliki debootstrap sebagai langkah di Dockerfiles saya.

Tampaknya wajar untuk membangun chroot saya melalui Dockerfile/build tetapi mengalami masalah yang sama seperti yang disebutkan @fbrusch .

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

gagal dengan:

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

Bagaimana dengan alih-alih RUNP , miliki flag build --insecure .
Untuk semua perintah RUN, container berikutnya akan dijalankan dengan --add-cap=all . Ini bukannya istimewa karena hak istimewa melakukan beberapa hal lain juga ...
Tapi sebenarnya ini bisa berubah untuk mengimplementasikan pengaturan privileged jika diperlukan di beberapa titik tanpa harus mengubah flag.

@cpuguy83
Saya tidak keberatan harus menggunakan flag yang diteruskan ke build buruh pelabuhan yang memungkinkan perintah RUN untuk diistimewakan atau mengaktifkan perintah RUNP. Ada nilai untuk dapat melihat Dockerfile dan mengetahui dengan perintah atau sesuatu di dalamnya, bahwa itu akan memerlukan akses istimewa, dan saat runtime alih-alih mencapai langkah 10 dan melakukan kesalahan, itu akan di-shortcut di awal bahwa Dockerfile berisi perintah yang membutuhkan hak istimewa.

Kasus penggunaan yang membawa saya ke utas ini adalah pengikatan mount, yang ingin saya lakukan intracontainer. Saat ini Anda hanya dapat melakukannya jika Anda menjalankan wadah dalam mode istimewa. Ini memaksa Anda untuk menyatukan perintah di awal, atau memiliki skrip init yang berjalan untuk menyelesaikan pengaturan sistem sebelum proses yang ingin Anda jalankan.

Akan menyenangkan jika hanya memiliki di Dockerfile:

RUN mount --bind /dir1 /dir2

Saya akan menjelaskan kasus penggunaan saya lebih banyak jadi ini bukan hanya permintaan perintah istimewa yang luas. Kasus khusus saya adalah saya ingin mengikat mount direktori di area aplikasi ke volume data yang dilampirkan.

misalnya

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

Ini dapat diselesaikan dengan juga melakukan pemasangan volume langsung ke area aplikasi, tetapi saya mencari cara untuk menyediakannya di lokasi yang sama dan membiarkan wadah aplikasi melakukan pemetaan spesifiknya. Ini juga dapat diselesaikan dengan symlink , tetapi beberapa aplikasi tidak berfungsi dengan baik dengan symlink sebagai folder target/datanya. Dan jika aplikasi mendukung konfigurasi lokasi direktori datanya, itu juga dapat dilakukan untuk menunjuk ke area pemasangan volume. Kasus penggunaan saya aplikasi tidak mendukung konfigurasi lokasi direktori data, dan kenyataannya akan selalu ada aplikasi yang harus Anda lakukan beberapa pengikatan atau symlinking untuk memisahkan data dan ruang aplikasi dengan benar.

Kemampuan untuk dapat melakukan ini A -> B -> C memungkinkan penyimpanan wadah data tetap generik dan memberikan fleksibilitas dalam berbagai kombinasi yang dapat Anda capai dengan --volumes-from dengan wadah aplikasi dan data.

Anda dapat mencapai ini juga dengan memiliki rantai wadah dengan --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

Yang mungkin merupakan jawaban yang tepat, tetapi Anda dapat menghilangkan keharusan membuat wadah lain untuk data aplikasi jika wadah aplikasi dapat menjalankan pengikatan mount.

Saya dapat mencapai ini hari ini dengan menjalankan wadah dalam mode istimewa dan kemudian menjalankan mount bind, tetapi seperti yang akan Anda lihat di bawah, tidak ada cara untuk membuat mount bind itu bertahan dan itu harus diatur ulang setiap kali Anda memulai wadah . Symlinks dipertahankan pada komit.

Jawaban untuk kasus penggunaan khusus saya mungkin menggunakan pendekatan wadah 3 rantai atau skrip init, tetapi memiliki kemampuan untuk melakukan pengikatan mount intracontainer (atau perintah istimewa lainnya) dari Dockerfile akan menyenangkan. Mungkin ada kasus penggunaan lain untuk pengikatan mount yang dapat dijelaskan yang tidak melibatkan host ke pemetaan kontainer yang tidak dapat diselesaikan dengan merantai kontainer data.

Tidak yakin apakah ini terkait atau lebih merupakan masalah khusus pengikatan, tetapi memiliki hasil dari perintah istimewa tetap ada ketika Anda melakukan komit buruh pelabuhan akan memungkinkan Anda untuk memisahkan pembuatan gambar buruh pelabuhan dan menjalankan gambar buruh pelabuhan. Anda dapat mengontrol area tempat Anda melakukan pembangunan buruh pelabuhan dan pengguna akhir hanya mendapatkan wadah berkomitmen yang dapat mereka jalankan dalam mode tidak memiliki hak istimewa. Ini saat ini bukan penyebab ketika Anda menjalankan bind mount dan komit. Ini mungkin lebih terkait dengan cara kerja /proc/mounts .

Berikut adalah contoh sederhana

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Buat contoh pengikatan mount, buat juga contoh symlink

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

Tampilkan file dilihat dari semua 3 direktori

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

Tampilkan /proc/mounts diperbarui

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

Keluar dari wadah yang menghentikannya, lalu mulai lagi

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts tidak memiliki pengikatan mount

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Symlink selamat, tetapi tidak mengikat mount

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

Setel ulang pengikatan mount

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

Alih-alih keluar dari wadah, lepaskan dengan ctrl+p ctrl+q dan kemudian komit wadah

Komit wadah sebagai gambar baru, mulai wadah baru dari gambar dalam mode nonpriv

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

Periksa /proc/mounts
bind mount tidak ada, tidak yakin apa yang memicu ekstra /proc/[sys,sysrq-trigger,irq,bus,kcore] mount

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

Symlink selamat

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

Saat ini saya mencoba menjalankan gambar buruh pelabuhan di langkah pembuatan saya, menggunakan dind . Jadi, saat ini, tidak ada cara untuk menggunakan gambar run docker di build Anda?

Semuanya, jika Anda menginginkan ini, coba '/usr/bin/unshare -f -m -u -i -n -p -U -r -- /path/to/binary'. Ini akan membuat wadah di dalam bangunan Anda dengan ruang nama pengguna. Anda dapat men-tweak opsi untuk berhenti berbagi seperlunya. Saya benar-benar menggunakan ini untuk menjalankan '/ sbin/capsh', untuk secara terperinci mengatur kemampuan untuk proses saya.

Saya tidak bisa mengatakan ini akan menyelesaikan semua kasus pengguna untuk bangunan yang diistimewakan, tetapi ini akan membantu sebagian dari Anda.

Saya setuju ini harus menjadi bagian dari Docker itu sendiri, dan integrasi ruang nama pengguna tampaknya sedang berlangsung.

@saulshanabrook Anda tidak dapat menjalankan gambar buruh pelabuhan dalam build, tidak persis. Saya berharap suatu hari nanti, ini akan menjadi mungkin. Saya telah melakukan beberapa penyelidikan tentang ini dan telah menemukan bahwa Anda dapat melakukan 'docker pull' dari dalam build, selama Anda menggunakan penyimpanan VFS. Mudahnya, 'docker save' juga berfungsi.

Ini bukan solusi nyata bagi seseorang yang ingin menjalankan gambar buruh pelabuhan, tetapi saya perhatikan bahwa 'unshare' dan 'capsh' berfungsi, jadi mungkin untuk melakukan runtime seperti container di container yang tidak memiliki hak istimewa (seperti selama build ). Diperdebatkan, dimungkinkan untuk melangkah ke samping 'docker run' dan melakukan langkah ini secara manual, dan mengkomit ulang gambar kembali ke buruh pelabuhan. Saya memiliki sebagian besar pekerjaan ini hari ini, bahkan jika saya tidak memiliki semuanya terbungkus dalam busur. Akhirnya, tentu saja, fungsionalitas seperti itu perlu masuk ke Docker itu sendiri.

+1 untuk tarikan buruh pelabuhan melalui RUNP

Ketidakmampuan untuk menjalankan hak istimewa membangun buruh pelabuhan mendorong pembangunan secara manual dengan shell dan komit buruh pelabuhan, yang menjadikan Dockerfiles tidak berguna. Saya tidak berpikir bahwa menambahkan flag istimewa ke build buruh pelabuhan akan menarik garis antara build dan build yang diistimewakan; garis itu sudah ditarik ketika bendera ditambahkan untuk dijalankan dan itu perlu didukung.

+1 Ini membuat wadah buruh pelabuhan yang dapat direproduksi pada titik waktu tertentu (hanya perlu membawa file docker saja)

+1 harus benar-benar merobek peran dasar saya yang mungkin hanya untuk mengatasi hal-hal seperti ini. Saya benar-benar berharap bahwa adopsi buruh pelabuhan akan memungkinkan saya menggunakan banyak kode yang ada, tetapi saya tidak hanya telah membuat peran khusus untuk ukuran, tetapi sekarang saya harus mengatasi masalah seperti ini.

@lsjommer hal-hal apa yang harus Anda

Saya tidak mengatakan mari kita tidak menerapkan ini, tetapi mari kita nyatakan apa yang sedang kita bicarakan.

Juga ini akan relatif mudah diterapkan jika seseorang ingin melakukannya ...

@ cpuguy83 Ini dari peran dasar "bare metal" standar kami yang saya coba adopsi ke dalam wadah buruh pelabuhan untuk menginstal semua lib, dan ini berhubungan dengan memori bersama tetapi mungkin saya bahkan tidak perlu repot dengan itu di wadah build dan hanya perlu menjalankannya di host container?
http://Pastebin.com/P3QQxjNQ

Saya akui bahwa saya tidak sepenuhnya mengerti bagaimana Docker menangani berbagi sumber daya.

@ljsommer Jadi pengaturan shm adalah binatang yang berbeda secara keseluruhan dan tidak akan bertahan di antara perintah RUN (atau ketika Anda sebenarnya docker run ).

@ cpuguy83 Ya, saya pikir ini sebagian besar adalah kesalahan saya dalam hal bahwa saya mencapai apa yang saya pikir sebagai masalah yang bisa saya alihkan ke baseline untuk Host kontainer itu sendiri.
Terima kasih telah meluangkan waktu untuk menanggapi dan meminta maaf karena tidak mendidik diri saya dengan benar sebelum mengeluh.
;)

Adakah ide tentang RUNP / -privileged selama proses pembuatan?
Akan sangat bagus untuk mengatur tabel ip untuk membatasi akses buruh pelabuhan ke alamat ip yang ditentukan

Saya juga ingin RUNP dan/atau "docker build --privileged".

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

Dockerfile ini tidak berfungsi karena kesalahan berikut tetapi berfungsi jika dilakukan dengan "docker run --privileged"...

getsockopt failed strangely: Operation not permitted

@malcm , @sakurai-youhei: bahkan jika Anda memiliki sesuatu seperti RUNP , itu tidak akan berfungsi dalam skenario ini, karena aturan iptables tidak dipertahankan di sistem file.

Mari saya jelaskan: ketika Anda melakukannya RUN x , Docker mengeksekusi x kemudian mengambil snapshot dari sistem file. Hal-hal di luar sistem file (proses yang berjalan, tabel perutean, aturan iptables, pengaturan sysctl ...) tidak disimpan dalam gambar Docker.

Jika Anda ingin aturan iptables khusus, salah satu metodenya adalah:

• mulai wadah Anda misalnya dengan --name myapp
• mulai wadah lain, istimewa, satu-shot, untuk mengatur aturan iptables, misalnya docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

Apakah itu masuk akal?

@jpetazzo : Terima kasih atas tanggapannya. Dalam kasus saya, saya meletakkan perintah kedua untuk membuat aturan iptables tetap ada sebagai data pada sistem file seperti di bawah ini. Ini akan memungkinkan saya untuk memuat aturan iptables setelah memulai wadah dengan opsi --privileged.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

Tanpa RUNP atau "build --privileged", saya dipaksa untuk menulis seperti:

ADD iptables.rules /etc/

Ya, ini mungkin cukup, namun, saya perlu menambahkan iptables.rules di samping Dockerfile di repo saya.

Itu sebabnya saya ingin (atau ingin dengan lembut) RUNP. :)

@jpetazzo @strib
Di luar masalah iptables, mount, dan operasi istimewa lainnya, saya pikir ada satu skenario build yang harus kita tangani.

Kami mengirimkan peralatan untuk ditempatkan di VM dan instalasi bare-metal. Namun, untuk pengujian kami menggunakan lingkungan container. Pada gilirannya, di dalam peralatan itu kami menjalankan wadah. Jadi wadah uji harus didasarkan pada docker-in-docker. Sekarang bayangkan bahwa kita memiliki citra layanan yang perlu dimuat sebelumnya dalam citra uji (sehingga citra layanan tidak diunduh dari registri pada waktu pengujian). Saat ini kami tidak dapat melakukannya karena kami tidak dapat menjalankan wadah d-in-d dalam mode istimewa selama pembuatan Dockerfile yang menggunakan d-in-d sebagai basis: daemon docker tidak akan mulai, "docker pull " atau "beban buruh pelabuhan" tidak akan berfungsi.

Saya memiliki masalah ketika menjalankan pada host RHEL7, su akan gagal jika pengguna saat ini adalah root. Anehnya, jika pengguna saat ini adalah sesuatu yang lain, su bekerja dengan baik. Terlepas dari itu, solusinya adalah meneruskan perintah run flag --add-cap=SYS_RESOURCE ; karena masalah ini, bagaimanapun, tidak mungkin melakukan ini selama langkah pembuatan.

+1 Skrip di sekitar Dockerfiles dengan docker run dan docker commit adalah konyol. Harap sertakan fungsi ini.

+1 pada perlunya fitur ini. Saya pikir "tingkat keamanan" global dapat dikonfigurasi dalam file konfigurasi yang membatasi kemampuan yang dapat diberikan ke sebuah wadah. Seharusnya ada default yang aman (seperti hari ini) dan sysadmin dapat mengubahnya untuk memungkinkan wadah berjalan dengan lebih banyak hak istimewa. dockerfiles dengan instruksi RUNP seperti itu dapat gagal dijalankan dengan pesan seperti "Dockerfile ini memerlukan kemampuan berikut .... untuk membangun" pada sistem yang memiliki batasan global tersebut.

Saya pikir ini memungkinkan keseimbangan antara keamanan dan kegunaan.

Kami juga mengalami masalah ini saat mencoba membuat gambar dengan db berpemilik evli, yang akan tetap tanpa nama, di dalamnya.
Db ingin mengalokasikan sejumlah besar memori, yang tidak diizinkan oleh buruh pelabuhan.

Solusi kami saat ini adalah pembangunan 2 fase dengan langkah run --privileged, dan langkah komit terpisah.

Mungkin kita bisa mengonfigurasi buruh pelabuhan untuk mengizinkan alokasi memori dengan cara lain. Agak sulit untuk mengetahui apa yang sebenarnya ingin dilakukan db karena miliknya.

+1
untuk fitur ini.
untuk contoh kasus sejarah dan penggunaan lihat penipuan ini
https://github.com/docker/docker/issues/12138#issuecomment -90536998
terima kasih @cpuguy83 untuk menunjukkan penipuan

saya juga memiliki masalah ini, mencoba menghubungkan ke cifs share selama pembangunan buruh pelabuhan tidak diizinkan kecuali jika bendera istimewa disediakan, adakah cara untuk mengatasi ini?

Sekarang ada permintaan tarik yang mengimplementasikan ini; Anda dapat memeriksa kemajuan di sana; https://github.com/docker/docker/issues/12261

Jika ada sesuatu yang memerlukan mode istimewa maka mungkin memodifikasi host dalam beberapa cara, yang berarti gambar mungkin tidak portabel karena modifikasi ini perlu dijalankan pada host lain yang mencoba menggunakan gambar.

Setelah #13171 digabungkan, saya pikir kita harus menutup ini karena akan membuat rolling pembangun Anda sendiri menjadi sepele, dan dengan demikian mengizinkan --privileged.
Saya tidak berpikir docker build bawaan seharusnya mengizinkan ini.

Jadi @cpuguy83 , jika saya mengerti benar, cara untuk mendukung masalah ini adalah dengan mengimplementasikan ulang docker build sepenuhnya tetapi dengan parameter tambahan?

Saya kira untuk mengatakan, setelah tambalan lain didorong, saya harus mengumpulkan versi saya sendiri dari docker build (mungkin docker pbuild ?) untuk mengisi fungsionalitas tambahan?

Apakah ada kemajuan dalam masalah ini? Saya memeriksa PR yang disebutkan di atas dan semuanya gagal.
Apakah mungkin untuk membuat opsi BUILD --privileged/--granted lebih terperinci dan memberikan akses yang diberikan ke grup sumber daya Host tertentu yang terbatas hanya untuk pembuat/pemilik gambar?

+1 untuk solusi apa pun yang memungkinkan saya melakukan RUN docker pull di Dockerfile.

Kasus penggunaan: Saya memerlukan banyak alat untuk konversi gambar dan pembuatan dokumentasi, namun, semua alat ini tidak dapat diinstal ke dalam satu gambar karena perpustakaan yang saling bertentangan. Itu sebabnya saya memisahkan beberapa alat ini menjadi gambar terpisah dan saya ingin mendistribusikan semua alat dalam satu gambar, yaitu gambar dalam gambar. Itu sebabnya saya ingin melakukan RUN docker pull di Dockerfile saya.

@ cpuguy83 sepertinya masalah ini tidak diselesaikan untuk kepuasan siapa pun. Saya benar-benar, 100%, harus dapat melakukan sesuatu yang membosankan seperti menulis ke /proc/sys/kernel/core_pattern selama pembuatan.

Di dunia saat ini, saya dapat melakukan operasi istimewa ini melalui solusi run dan tetap mendorong gambar itu ke hub. Selain itu, tidak ada Dockerfile saya _ever_ produksi benar-benar dapat direproduksi, karena mereka menarik dari repo publik yang terus berubah secara acak. Saya tidak tahu itu

1. Konsumsi publik atas gambar saya adalah prioritas.
2. Mereka selalu memiliki kebutuhan untuk dapat direproduksi.

Orang-orang _akan_ melakukan solusi buruk untuk mendapatkan privileged dalam build. Saya pikir Anda pasti harus pergi ke tempat pengguna Anda berada dan mengizinkan ini di alat pembuatan inti. Tambahkan pesan yang menakutkan jika perlu.

cc @thaJeztah , yang tampaknya bersimpati dengan posisi ini

Dengar, saya membuat PR untuk mengaktifkan ini dan ditolak.
Saya tidak melihat ini terjadi dengan pembangun dalam bentuk apa pun.

Sepertinya Anda membuat panggilan terakhir. Saya akan mengagitasi di utas PR itu sendiri, kalau begitu.

Ini diperlukan untuk menginstal paket JDK 1.6 yang lebih lama di bawah CentOS karena upaya RPM untuk mendaftar adalah binmft_misc yang gagal tanpa berjalan di bawah --privileged.

Dockerbuild adalah non-stater untuk membangun wadah dengannya.

Untuk meniru

DARI Centos5.11
JALANKAN yum intall -y jre-1.6.0_29-fcs

Kita perlu memiliki bagian perintah istimewa dari build sebagai flag opsional. Saya mencoba mem-port salah satu aplikasi kami ke buruh pelabuhan sebagai POC dan gagal untuk salah satu komponen kami karena memiliki pengaturan IPtables yang tidak diterapkan dan build gagal. Saya dapat melakukan perubahan yang diperlukan secara manual dan mengkomitnya, tetapi kemudian apa yang menyenangkan dari build docker. Itu hanya bagian dari build dan harus mudah di-porting karena sudah menjadi bagian dari rilis utama.

Docker harus dapat dengan mudah menjalankan container perantara dengan set opsi istimewa.

@shubhamrajvanshi kami sedang dalam proses memindahkan "pembangun" dari daemon (dan ke klien), ini akan membuka pintu untuk lebih banyak penyesuaian pada proses pembangunan (termasuk mampu mengimplementasikan pembuat kustom). Mungkin mengizinkan build "hak istimewa" dapat dipertimbangkan, tetapi itu adalah keputusan yang dapat dibuat setelah refactoring. (Lihat https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi Anda tidak dapat membuat perubahan pada iptables di build karena alasan yang bagus, pengaturannya tidak akan pernah bertahan.

Ada sangat sedikit hal yang dapat dilakukan dengan --privileged yang bahkan masuk akal dalam pembuatannya.

@thaJeztah Terima kasih itu akan sangat membantu.
@ cpuguy83 Apakah itu akan terjadi bahkan jika saya menggunakan paket iptables-persistent pada gambar.

Ini akan menyimpan aturan ke disk, kemudian aturan itu masih harus dimuat ulang, sayangnya.

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan notifikasi jika ada perubahan dalam diskusi ini adalah dengan mengklik tombol Subscribe di kanan atas._

Orang-orang yang tercantum di bawah ini menghargai diskusi bermakna Anda dengan +1 acak:

@karelstriegel

Saya juga sangat menyukai ini, untuk mengizinkan penggunaan driver CUDA nVidia dari dengan Docker di CoreOS. Pemasang yang mereka sediakan membangun modul kernel terhadap sumber kernel, dan kemudian menginstalnya menggunakan modprobe. Saya tidak dapat melihat bagaimana membuatnya bekerja tanpa semacam opsi --privileged untuk membangun.

Mengapa tidak secara default selalu mendukung mode istimewa saat dibangun?

+1
Saya ingin menggunakan perintah mysql di Dockerfile untuk centos7.
Tentu saja kita dapat menggunakan entrypoint.sh tetapi akan lebih berguna jika kita dapat menggunakan -privileged untuk build dan run.

Tidak perlu --privileged untuk menjalankan perintah MySQL.

Masalah ini harus ditutup karena sepertinya ini tidak akan terjadi (atau bahkan seharusnya terjadi).
Mengizinkan hak istimewa dalam pembuatan berarti mengizinkan pembuat untuk mengubah hal-hal pada host yang pada gilirannya membuatnya sehingga gambar hanya berfungsi pada host tersebut (atau host yang memiliki modifikasi serupa).

Mengizinkan hak istimewa dalam pembuatan berarti mengizinkan pembuat untuk mengubah hal-hal pada host yang pada gilirannya membuatnya sehingga gambar hanya berfungsi pada host tersebut (atau host yang memiliki modifikasi serupa).

Apakah ini berlaku untuk kasus pengguna chroot?

Saya mencoba mencari cara melakukan dpkg-depcheck -d ./configure tanpa sesuatu seperti ini.

Selama membangun (atau menjalankan tanpa --priviledged) saya mendapatkan kesalahan di bawah ini - saya tidak tahu bagaimana cara mengetahui izin apa yang diperlukan atau cara mengaktifkannya.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

Setelah sekitar 3 tahun dan 162 komentar, saya pikir itu menarik untuk dilakukan. Komentar tentang mode hak istimewa yang tidak diperlukan untuk sebagian besar kasus yang dikutip adalah benar, bahkan komentar saya sendiri; tetapi tidak boleh digunakan untuk melarang apa yang mungkin berguna untuk bangunan lokal, sementara, eksplorasi, dan/atau bijaksana. Menerbitkan peringatan sampai sapi kentut harmoni, mencetak peringatan baris perintah, mencaci maki dan mencela penggunaannya, tetapi memberikan orang fleksibilitas. Portabilitas tidak selalu menjadi minat utama semua orang.

_POLONGAN PENGGUNA_

_Cara terbaik untuk mendapatkan pemberitahuan tentang pembaruan adalah dengan menggunakan tombol _Berlangganan_ di halaman ini._

Tolong jangan gunakan komentar "+1" atau "Saya juga punya ini" pada masalah. Kami secara otomatis
kumpulkan komentar-komentar itu untuk membuat utas singkat.

Orang-orang yang tercantum di bawah telah mendukung masalah ini dengan meninggalkan komentar +1:

@robeferre

+1

Saya benar-benar perlu memasang volume NFS di dalam wadah buruh pelabuhan, sampai sekarang saya tidak dapat membuat bagian NFS tanpa tanda "--privileged=true". Kasus terbaik menurut saya adalah membangun gambar menggunakan perintah istimewa. Bagaimana ini mungkin?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

Saya mencoba menginstal gobject-introspection di sistem gentoo di docker selama build tetapi gagal dengan kesalahan ini:

• ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operasi tidak diizinkan

Hasil yang sama ketika saya mencoba menginstalnya secara manual dalam wadah tetapi ketika mencobanya dari wadah yang diluncurkan dalam mode istimewa (docker run --privileged) maka itu berfungsi dengan baik.

Masalah yang sama ketika saya mencoba menginstal glibc.

Jadi saya juga membutuhkan cara bagaimana menjalankan perintah yang diistimewakan saat membangun.

Saya menggunakan buruh pelabuhan versi 1.10.1 dan masalah dengan glibc tidak muncul di 1.9

Di versi 1.10 ada yang rusak dan kami tidak dapat membuat wadah 32bit, karena jaringan tidak tersedia
--privileged atau --security-opt seccomp:unconfined untuk BUILD - sangat diperlukan.
Atau arahan yang sesuai di Dockerfile

+1 besar dari saya

Ini masalah nyata bagi saya bahwa saya tidak dapat menggunakan perintah 'mount' selama build.
Saya mencoba untuk mengatasi batasan direktori Host yang tidak dapat dipasang ke dalam wadah selama pembuatan, jadi saya menyiapkan server NFS di Host dan mencoba memasang berbagi NFS, hanya untuk mengetahui bahwa itu tidak mungkin karena mode unprivileged.

Dalam kasus penggunaan saya, saya perlu menginstal beberapa hal dalam gambar tanpa menyalinnya ke konteks build, dan MENAMBAHnya sebelum menginstalnya.

Terasa seperti aku dibiarkan tanpa pilihan.

thaJeztah mereferensikan masalah ini pada 10 Maret
Regresi dalam perilaku LTTng setelah memutakhirkan ke 1.10.2 #20818 Ditutup

Tidak, ini tidak ditutup, kami menggunakan 1.11.0-0~wily dan dalam wadah 32bit, jaringan tidak berfungsi sejak 1.10.0, tetapi 1.9.x bekerja dengan baik.
Hanya -privileged yang dapat membantu kami memulai container. Tapi kita tidak bisa membangun baru

Saya kagum bahwa sesuatu yang begitu jelas dibutuhkan oleh begitu banyak orang belum diimplementasikan meskipun orang-orang telah memohonnya selama 2,5 tahun di utas ini saja dan mengingat bahwa orang-orang telah mengirimkan PR untuk mengimplementasikan fungsi ini.

Setuju @ctindel , masalah ini adalah salah satu alasan mengapa saya bermigrasi dari docker ke rkt .

@ctindel Itu adalah sesuatu yang belum siap kami implementasikan atau dukung. Implementasinya sendiri agak sederhana (saya bahkan menerapkannya sendiri sehingga kita bisa berdiskusi), bukan itu masalahnya.

--privileged adalah sebuah tank, dan membiarkannya di build berbahaya, dan sangat mempengaruhi portabilitas gambar.

Brian,

Jika Anda memiliki pekerjaan di sekitar, Anda dapat membagikannya kepada saya juga. saya akan
menghargai itu.

Terima kasih
Shubham Rajvanshi
669-300-8346

Pada Senin, 2 Mei 2016 pukul 14:30, Brian Goff [email protected] menulis:

@ctindel https://github.com/ctindel Ini adalah sesuatu yang kami belum siap
melaksanakan atau mendukung. Implementasinya sendiri agak sederhana (saya bahkan
menerapkannya sendiri sehingga kita bisa berdiskusi), bukan itu masalahnya.

--privileged adalah tank, dan membiarkannya membangun itu berbahaya, dan
sangat mempengaruhi portabilitas gambar.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

Saya tidak mengerti efeknya pada portabilitas. Bagaimana operasi istimewa pada waktu pembuatan memengaruhi portabilitas? Maksud saya, tidak sulit untuk membuat gambar non-portabel dengan berbagai cara dengan atau tanpa hak istimewa, tetapi apakah ada cara agar gambar yang dibuat dengan operasi istimewa tentu tidak portabel?

Saya tidak percaya setiap wadah harus portabel. Beberapa kontainer dibuat untuk dibagikan dengan komunitas dan beberapa mungkin dibuat untuk menyebarkan aplikasi internal.

Masalah portabilitas dengan aplikasi yang membutuhkan berjalan dalam mode istimewa terletak pada aplikasi itu sendiri.

Mode istimewa adalah cara terakhir untuk membuat aplikasi bekerja tanpa perubahan kode.

Saya percaya bahwa pembuat gambar yang membutuhkan pembuatan mode istimewa memahami bahwa wadah semacam itu mungkin juga perlu dijalankan dalam mode istimewa.

Harus didokumentasikan dengan jelas bahwa membangun dalam mode istimewa tidak disarankan karena dapat menimbulkan masalah portabilitas.

Dikirim dari Outlook Mo bilehttps://aka.ms/blhgte

Pada Senin, 2 Mei 2016 pukul 14.53 -0700, "Trevor Blackwell" < [email protected] [email protected] > menulis:

Saya tidak mengerti efeknya pada portabilitas. Bagaimana operasi istimewa pada waktu pembuatan memengaruhi portabilitas? Maksud saya, tidak sulit untuk membuat gambar non-portabel dengan berbagai cara dengan atau tanpa hak istimewa, tetapi apakah ada cara agar gambar yang dibuat dengan operasi istimewa tentu tidak portabel?

Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/docker/docker/issues/1916#issuecomment -216375159

@tlbtlbtlb Karena mode istimewa memberi Anda akses penuh ke Host. Mungkin saya mengatur sesuatu yang sederhana seperti shmmax atau sesuatu yang jauh lebih buruk.
Saya jamin hal-hal ini akan terjadi pada hari 1 bahwa ini tersedia.

@davidl-zend "portabel" tidak berarti berbagi dengan komunitas. Artinya berpindah dari satu mesin ke mesin lainnya.

@ cpuguy83 Seperti yang telah ditunjukkan orang lain, ada banyak cara lain untuk merusak portabilitas gambar juga. Semua yang Anda lakukan dengan tidak memiliki proses untuk membangun hak istimewa adalah memaksa orang untuk memiliki proses dua langkah, baik dengan membangun sebagian dari Dockerfile dan kemudian secara manual mengubah wadah dan melakukan komit, atau dengan membangun sebagian dari Dockerfile dan menyelesaikan instalasi istimewa pertama kali wadah diluncurkan yang menyebalkan karena itu berarti jika Anda melakukan sesuatu yang memakan waktu, mungkin perlu beberapa menit agar boot pertama berfungsi.

Mengingat komentar yang saya lihat di berbagai forum, saya berani bertaruh bahwa BANYAK orang sudah melakukan hal ini untuk mengatasi batasan buruh pelabuhan yang ada saat ini.

Setelah Anda memiliki arsitektur di mana portabilitas gambar rusak dalam lusinan cara lain, apa gunanya memiringkan kincir angin khusus ini?

Jelas Anda tidak akan lagi dapat memiliki hub buruh pelabuhan atau travis-ci membangun gambar Anda, tetapi orang-orang yang membutuhkannya dibangun dengan mode hak istimewa akan memahaminya.

@ctindel Saya ingin melihat beberapa contoh portabilitas gambar rusak

Melakukan hal-hal semacam ini pada awal penampung pertama adalah _tepat_ cara yang tepat untuk melakukannya.
Ini adalah konfigurasi runtime yang seharusnya tidak ada dalam gambar.

@ cpuguy83 Apakah Anda memperdebatkan fakta bahwa seseorang dapat melakukan sebagian build dari Dockerfile, memutar wadah dalam mode istimewa, membuat lebih banyak perubahan, lalu melakukan docker commit? Apa bedanya dengan melakukan build dalam mode istimewa? Karena itulah yang dilakukan orang lain hari ini.

Saya tidak mencoba untuk menjadi mudah tersinggung, saya hanya mengatakan ini adalah batasan parah pada platform yang orang-orang kerjakan dengan cara yang canggung.

Misalnya, ada paket debian pihak ke-3 (dan mungkin RPM) yang tidak dapat diinstal dengan benar kecuali Anda memiliki kemampuan tertentu dalam sistem. Menginstal paket debian bukanlah "konfigurasi runtime" itu adalah bagian yang menakutkan dari proses instalasi.

@ctindel Saya tidak memperdebatkan ini sama sekali. Perbedaannya adalah mendukung perilaku. Jika tidak ada perbedaan, kami tidak akan melakukan diskusi ini.

Bagi saya, saya adalah orang dewasa yang setuju dan ingin dapat menggulung gambar packstack di banyak node. Membangun dengan bom Dockerfile saat ini, jadi saya harus curang untuk mengatasi batasan buruh pelabuhan.

@ cpuguy83 Masih sangat tidak jelas bagi saya (dan saya pikir orang lain di utas ini) apa sebenarnya yang diperoleh dengan tidak memberikan opsi ini yang dikerjakan orang dengan cara lain. Jenis kemurnian arsitektur (saya tidak punya kata yang lebih baik untuk itu) yang tampaknya Anda perdebatkan telah hilang begitu opsi komit ditambahkan, jadi saya benar-benar tidak mengerti apa perbedaannya apakah itu dilakukan melalui a Dockerfile dengan build yang diistimewakan atau melalui komit docker dalam wadah yang diistimewakan.

Kecuali bahwa satu cara adalah PITA yang menakutkan bagi orang-orang dan slot satu arah ke dalam mekanisme pembangunan saat ini dengan Dockerfile dengan sangat baik.

Juga, Anda tidak menjawab pertanyaan saya. Mengapa Anda menganggap instalasi sederhana dari paket debian pihak ke-3 (atau packstack) sebagai "konfigurasi runtime"?

@ctindel Portabilitas. Hanya karena sesuatu dapat dilakukan tidak berarti itu didukung, dan memasukkannya ke dalam build , membuatnya nyaman untuk dilakukan semua orang, itu berarti didukung.
Kami _akan_ dibanjiri dengan masalah gambar yang tidak berfungsi di antara host... yang pada dasarnya mengalahkan seluruh alasan untuk Docker.

Jika sebuah paket memerlukan --privileged untuk diinstal, maka paket tersebut harus ditangani dengan paket tersebut. Instalasi seharusnya tidak memerlukan --privileged ... dan jika itu benar-benar membutuhkannya, maka ini adalah tanda bahwa instalasi itu sendiri tidak portabel (memerlukan perubahan pada host)... Saya bahkan ingin lihat buruh pelabuhan dapat dijalankan dalam wadah tanpa --privileged (perhatikan bahwa itu dapat dijalankan, Anda dapat menginstalnya semua yang Anda inginkan tanpa masalah tanpa --privileged).

Tetapi membiarkannya dilakukan melalui komit buruh pelabuhan berarti itu juga didukung!

Saya tidak mengerti, Anda membuat banyak orang mengatasi keterbatasan dalam produk ini karena Anda khawatir seseorang akan mengeluh kepada Anda secara pribadi tentang semacam gambar yang tidak didukung?

Anda masih belum menjawab pertanyaan saya tentang mengapa tindakan menginstal sebuah paket (saya bahkan tidak berbicara tentang mengonfigurasinya di sini) adalah tindakan "konfigurasi runtime". Hanya mengatakan "portabilitas" tidak berarti apa-apa.

Apakah ada sesuatu yang spesifik x86_64 tentang buruh pelabuhan? Tidakkah pada akhirnya akan ada gambar buruh pelabuhan yang dibuat untuk arsitektur CPU tertentu? Bukankah itu juga membuat mereka tidak portabel? Maksud saya seluruh gagasan ini bahwa entah bagaimana Anda akan selalu dapat mengambil gambar buruh pelabuhan dan menjalankannya di host buruh pelabuhan mana pun di dunia terlepas dari banyak variabel lain tampaknya tidak mungkin, jadi saya tidak mengerti kebutuhan super kuat untuk mendorong kembali pada fitur khusus ini yang diminta orang.

BTW, izinkan saya berterima kasih di sini atas balasan dan keterlibatan Anda yang berkelanjutan. Banyak proyek github lain di mana utas masalah diabaikan!

Saya setuju dengan poin tentang orang-orang yang mengatasi ini dengan menggunakan docker run --privileged dengan docker commit . Saya telah membuat solusi seperti itu untuk dua perusahaan sejauh ini. Orang AKAN membuat gambar seperti itu dan tidak ada gunanya bertindak seolah-olah melakukannya adalah sesuatu yang mengerikan, hal yang mengerikan.

Sial, jika Anda sangat takut mendukung wadah yang dibuat dengan --privileged maka sebutkan saja dengan jelas dalam dokumentasi sehingga orang-orang sangat sadar bahwa mereka melakukannya dengan risiko mereka sendiri. Meskipun saya belum melihat efek negatifnya sejauh ini. Tapi sekali lagi kami belum mencoba menjalankan container di distro yang berbeda.

@PerilousApricot apa yang sebenarnya menyebabkan masalah dengan packstack? Kami senang untuk memperbaiki masalah tertentu, atau membantu hulu memperbaikinya, tetapi jangan berpikir bahwa hanya dengan menambahkan --privileged yang memberikan akses root tanpa batas ke server host Anda adalah cara yang tepat untuk melakukan ini. Semua kasus yang saya ketahui di mana orang telah mengangkat masalah build tertentu umumnya dapat diperbaiki, karena kebanyakan hal sebenarnya tidak memerlukan akses root pada mesin Host sebenarnya untuk melakukan build.

@justincormack Apa solusi untuk paket pihak ke-3 (yaitu tidak dapat diubah) yang memulai layanannya sendiri di mana skrip init perlu memasang sistem file tmpfs? Maksud saya bahkan mengabaikan --privileged untuk saat ini juga tidak ada cara untuk melakukan --cap-add atau --security-opt apparmor:unconfined selama build (saya rasa tidak?)

@ctindel Seharusnya tidak mencoba memasang tmpfs saat instalasi. Jika perlu tmpfs saat runtime maka bagus, tetapi pada waktu instal itu pasti tidak benar.

@ cpuguy83 Anda memaksakan filosofi arsitektur dan implementasi pada sesuatu yang tidak dapat diubah karena berasal dari pihak ke-3 komersial. Tidak semuanya akan diperbaiki "upstream", bahkan jika mereka memperbaiki versi .deb atau .rpm yang lebih baru, itu tidak berarti mereka akan kembali dan memposting ulang versi yang lebih lama yang mungkin Anda perlukan di gambar buruh pelabuhan.

Itulah inti dari seluruh diskusi ini, Anda memberlakukan pembatasan sewenang-wenang yang membuatnya jauh lebih sulit untuk menggunakan buruh pelabuhan karena beberapa kekhawatiran filosofis tentang permintaan dukungan dari orang-orang yang "melakukannya salah".

Itu seperti mengatakan Sistem Operasi seharusnya tidak mengizinkan orang untuk mengubah kelas penjadwalan proses karena jika Anda salah melakukannya dapat menyebabkan inversi prioritas. Atau, tidak seorang pun boleh membuat palu karena ibu jari Anda mungkin terbentur jika Anda salah menggunakannya.

Seperti yang telah dikatakan berkali-kali, buruh pelabuhan SUDAH MENDUKUNG INI melalui perintah komit, itu hanya lebih menyakitkan bagi pengguna Anda. Orang yang tidak menginginkan fitur ini tidak akan menggunakannya, dan orang dewasa yang setuju yang ingin menggunakannya dengan memahami batasannya dapat melakukannya dengan mata terbuka lebar.

@ctindel Lebih seperti tidak, Anda tidak dapat menangani bom nuklir ini karena Anda dapat membunuh semua orang dalam radius 50 km.

Ada apa dengan paket ini yang perlu memuat tmpfs selama instalasi? Instalasi secara harfiah mengekstraksi file dari beberapa format arsip ke rootfs.

Apa pun bisa diubah.
Ini adalah perubahan yang jauh lebih sederhana dan lebih aman untuk dibuat di hulu untuk tidak memasang tmpfs saat instalasi daripada mengaktifkan hak istimewa saat membangun.

Docker adalah tentang portabilitas beban kerja. Mengaktifkan hak istimewa saat membangun (atau hak ekstra, atau mengubah profil keamanan, dll) pada dasarnya merusak ini dan bukan sesuatu yang dapat kami terima hari ini.

commit dan build adalah dua hal yang sangat berbeda, dan hanya karena mungkin untuk melakukan sesuatu dengan satu cara tidak berarti kita harus mengizinkan melakukannya dengan cara lain juga.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

Tidak ada hak istimewa yang diperlukan.

Gereja profitabilitas.
Suatu hari portabilitas "dipaksa" akan mematikan proyek ini - ia sudah melakukannya.
Begitu banyak fitur yang ditolak karena portabilitas yang sulit dipahami, begitu banyak kemajuan yang tidak dibuat karena itu .....
Suatu hari seseorang akan membayar proyek dan menjadikan portabilitas opsional. Mimpi... mimpi.... Amin.

Jika kita memecahnya menjadi dua kasus:

1. Pemasang yang menggunakan operasi istimewa secara sembrono, seperti memasang tmpfs untuk kinerja. Pemasang semacam itu dapat dengan mudah diperbaiki (tetapi mungkin tidak dalam waktu dekat).

Dalam hal ini, merupakan filosofi yang valid bagi Docker untuk mendorong kembali installer yang berperilaku buruk. Sebagian besar penginstal memiliki semacam solusi yang hanya membuat Dockerfile sedikit lebih lama.

1. Pemasang yang secara mendasar bergantung pada operasi istimewa, seperti memasang modul kernel untuk driver GPU. Ini juga pada dasarnya non-portabel. Mereka tidak akan bekerja pada mesin buruh pelabuhan untuk Mac, misalnya.

Dalam hal ini, pengalaman Docker tetap rusak. Saya tidak dapat menggunakan mesin buruh pelabuhan di Mac, misalnya, saya hanya dapat membuat gambar pada mesin host target yang kompatibel. Kasus penggunaan saya adalah menginstal driver GPU nVidia pada OS host (CoreOS) yang tidak disarankan untuk menginstal langsung di OS host.

Jadi, saya kira saya datang untuk melihat kebaikan dari tidak mendukung --privileged dalam kedua kasus tersebut. Saya pikir apa yang membuat saya berubah pikiran adalah kenyamanan membangun gambar di laptop saya menggunakan mesin buruh pelabuhan, daripada terlebih dahulu mendorong kode saya ke kotak Ubuntu dan membangun di sana.

@tlbtlbtlb Saya tidak mengerti "kebajikan" apa yang Anda maksud. Pertimbangkan sesuatu yang tidak sembrono, tetapi ada banyak gambar buruh pelabuhan yang akan berjalan di satu lingkungan tetapi tidak di lingkungan lain. Misalnya, Anda dapat memasang volume Host ke dalam wadah mongodb dari linux->linux karena dan driver penyimpanan mmapv1 akan berfungsi dengan baik, tetapi Anda tidak dapat meneruskan direktori mac osx melalui kotak virtual ke wadah mongodb di laptop Anda karena hal mmap tidak akan berfungsi dengan baik dalam kasus itu.

Saya menyadari ini bukan masalah sehubungan dengan bangunan, tetapi gagasan bahwa gambar buruh pelabuhan "portabel" dan dapat "berjalan di mana saja" adalah omong kosong pada saat ini. Jika mereka tidak bisa lari kemana-mana, apa gunanya mengatakan bahwa mereka harus bisa "membangun di mana saja"?

Intinya adalah bahwa gambar mongodb berfungsi di mana-mana. Menyediakan konfigurasi runtime yang tidak valid adalah hal yang berbeda.

Docker memiliki pemisahan konfigurasi portabel dan non-portabel yang sangat spesifik dan usus.

Bagaimana dengan ini ?
Saya perlu memiliki ip asli saya di dalam wadah ke pass pemeriksaan konfigurasi nginx saya.

ini Dockerfile saya:

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

Karena jika saya menjalankan wadah dengan opsi hak istimewa, saya dapat menyelesaikan antarmuka ip ke loopback. Tapi itu satu skrip lagi untuk ditambahkan.

@cpuguy83 Saya memiliki sekitar 20 baris entri iptable Saya ingin RUN di Dockderfile tetapi tidak bisa karena saya membutuhkan --cap-add=NET_ADMIN . Perintah-perintah ini harus terjadi terlepas dari siapa yang menjalankan container dan terlepas dari mesin apa mereka menjalankannya (container menjalankan aplikasi internal). Di mana / bagaimana Anda menyarankan saya melakukan itu berdasarkan apa yang Anda diskusikan di atas?

@MatthewHerbst Sayangnya aturan iptables tidak/tidak dapat bertahan dengan gambar.

@cpuguy83 Saya menggunakan gambar centos:6 dan dapat menjalankan run /sbin/service iptables save untuk mempertahankan aturan ke sistem file. Saya percaya mereka adalah kemampuan yang serupa di Ubuntu dan lainnya melalui paket iptables-persistent .

Anda bisa membuat aturan iptables untuk file itu, tidak perlu
benar-benar menerapkannya. Situasi jaringan tempat container dijalankan mungkin
sangat berbeda sehingga Anda hanya harus menerapkan aturan saat run time (jika itu, Anda
mungkin lebih baik dengan host yang membuatnya).

Pada 16 Mei 2016 16:03, "Matthew Herbst" [email protected] menulis:

@ cpuguy83 Saya menggunakan CentOS dan dapat menjalankan run /sbin/service iptables simpan ke
mempertahankan aturan ke sistem file. Saya percaya mereka mirip
kapabilitas di Ubuntu dan lainnya melalui paket iptables-persistent.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

@justincormack tidak tahu mengapa saya tidak memikirkan itu! Terima kasih!

Bagaimana Anda seharusnya menjalankan perintah yang memerlukan hak istimewa saat menggunakan docker service ? Saya perlu mengatur nama host di beberapa mesin saya, tetapi sayangnya ini membutuhkan hak istimewa.

@nostrebor yang sangat tidak terkait dengan masalah terbuka ini.
Kami mengevaluasi opsi apa yang perlu ada untuk layanan daripada menyalinnya 1-1. Mode hak istimewa mungkin tidak akan berada di 1,12 untuk layanan.

Saya mencoba membangun buruh pelabuhan yang mengkompilasi sesuatu untuk instalasi, tetapi harus dikompilasi terhadap perpustakaan yang ada pada sistem file jaringan CVMFS. Tentu saja, saya tidak dapat memasang CVMFS tanpa menjalankan --privileged, jadi saya tidak dapat melakukannya sama sekali menggunakan Dockerfile.

@ cpuguy83 @tlbtlbtlb Ini adalah kasus 'installer' tergantung fundamental pada tindakan istimewa. Tapi itu bukan apa yang saya sebut 'penggunaan sembrono', saya hanya perlu akses ke perpustakaan bersama pada sistem file jaringan. Namun, instalasi dalam hal ini BUKAN hanya mengekstrak file dari beberapa arsip.

Saya tidak mengerti bagaimana memasang sistem file jaringan adalah masalah portabilitas. (Semua lingkungan target kami akan memiliki akses ke sistem file ini. Mereka diharuskan karena mereka membangun kode lain yang JUGA harus ditautkan ke kode biner pada sistem file jaringan.)

Haruskah saya mencoba pendekatan yang berbeda? Haruskah saya memasang CVMFS di Host dan membagikan direktori itu dengan wadah atau sesuatu? Saya tidak ingin harus menyiapkan sistem pembangunan eksternal hanya untuk membuat gambar ini - gambar yang menjadi dasarnya sudah memiliki seluruh sistem pembangunan yang akan melakukan pekerjaan itu. Saya hanya perlu dapat memasang CVMFS.

Saya senang melakukan ini dengan Dockerfile, tetapi sepertinya saya harus melakukannya dengan cara yang sulit menggunakan beberapa skrip dengan docker run --privileged , atau menggunakan sesuatu yang lain alih-alih buruh pelabuhan. Apakah ada cara memasang sistem file dalam wadah _tanpa_ yang memiliki akses istimewa?

Saya melakukan solusi, dengan menempatkan / menggemakan perintah istimewa di dalam skrip dan menggunakan instruksi CMD untuk menjalankan skrip di titik masuk wadah, jadi setelah membuat gambar seperti itu, saya hanya dapat menjalankan wadah dalam mode istimewa dan semuanya berfungsi.

@drstapletron , menurut dokumentasi cvmfs CERN , Anda memiliki dua opsi untuk saat ini, baik memasang cvmfs dari Host ke wadah atau menginstal cvmfs di dalam wadah istimewa.

Untuk kasus detik, saya baru saja menulis file buruh pelabuhan untuk cmssw guys, di sini:
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

jadi menggunakan file ini, Anda bisa membuat gambar (atau mungkin Anda mengambilnya dari cmssw dockerhub), dan menjalankannya dalam mode P, dan semuanya sudah ada di dalam wadah ( ls /cvmfs/*)

Tidak yakin apakah ini tercakup di atas karena ini adalah daftar umpan balik yang agak panjang tentang masalah ini. Saya juga ingin memiliki --privileged build perintah. Kasus penggunaan saya saat ini adalah untuk mengatasi masalah yang saya hadapi dengan membangun go ebuild di gentoo stage3. Jika saya tidak menggunakan wadah, instruksi saat ini di buku pegangan gentoo menyebabkan systemd berperilaku tidak menentu setelah saya 'umount -l /mnt/gentoo/dev{/shm,pts,} && umount -l /mnt/gentoo/{ proc,sys}' dari sistem yang di-boot dengan systemd... Ketika saya memindahkan build stage3 saya ke dalam wadah buruh pelabuhan, semuanya berfungsi dengan baik hingga build memerlukan ptrace, atau beberapa fitur terbatas lainnya... yang mana go-1.7.1. ebuild tampaknya membutuhkan.

Untuk saat ini saya hanya menjalankan build dalam perintah docker run, melakukan dan kemudian melanjutkan dari sana, tetapi akan lebih baik untuk mengaktifkan ptrace dalam perintah docker build itu sendiri untuk menghindari langkah-langkah manual.

Saya juga ingin fitur ini. Saya ingin membuat lingkungan build, tetapi memerlukan modul kernel dan modprobe tidak akan bekerja sama dengan saya saat saya membangun. Apakah ada solusi untuk ini?

Secara khusus:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

Sepertinya kasus penggunaan yang benar-benar masuk akal.

@seltzy Saya sarankan untuk tidak menahan napas menunggu siapa pun dari docker untuk mengakui kewajaran kasus penggunaan Anda.

Ketika datang ke arsitektur dan fitur-inklusi, mereka sangat berat, pragmatis, menyendiri, dan cenderung mengabaikan setiap dan semua kasus penggunaan yang tidak sesuai dengan peta jalan _mereka_.

Kami orang biasa perlu memahami, tim docker membuat keputusan arsitektur yang memenuhi kebutuhan mereka sendiri (kemungkinan pelanggan bisnis dan swalayan), dan keputusan tersebut jarang tumpang tindih dengan (pengguna akhir publik) kami yang dibuat dengan sangat susah payah masalah yang kami ajukan di sini.

Mereka, tentu saja, bebas mengalokasikan sumber daya teknik mereka dengan cara ini.
Tapi itu memang memberikan rekam jejak yang akan menimbulkan imajinasi jika perusahaan itu pernah digambarkan sebagai "memperhatikan kebutuhan pengguna dengan serius."

@tamsky Anda berhasil!

@tamsky Saya dapat mengerti mengapa Anda berpikir demikian, karena proyek tersebut belum menerima fitur yang jelas-jelas Anda inginkan.

Saya dapat meyakinkan Anda bahwa ini tidak ada hubungannya dengan keputusan bisnis apa pun. Faktanya adalah, --privileged pada build akan menghasilkan gambar non-portabel.
Hal-hal seperti modprobe di lingkungan build tidak membantu dan bahkan dapat menyebabkan dua build menghasilkan hasil yang sama sekali berbeda.

Saya sendiri telah mengimplementasikan --privileged pada build. Ini bukan masalah rekayasa, dan sebenarnya cukup sepele untuk diterapkan. Itu mendukungnya itulah masalahnya.
Untuk pengguna tingkat lanjut, pembuat kustom dapat diimplementasikan, bahkan menggunakan kembali kode yang ada, menggunakan API yang ada yang dapat menyertakan dukungan istimewa.

Yang mengatakan, masalah ini masih terbuka karena suatu alasan. Itu karena orang-orang mendengarkan.

Terimakasih atas pertimbangan anda.

@cpuguy83 Terima kasih atas penjelasannya. Saya tidak menyadari itu adalah masalah portabilitas. Saya kira keinginan saya untuk ini didorong oleh kesalahpahaman.

Apa pendekatan filosofis umum yang harus diambil ketika menghadapi godaan untuk memiliki bangunan istimewa?

@seltzy jangan terlalu yakin bahwa kasus penggunaan Anda bukan contoh yang masuk akal tentang perlunya fitur ini

@ cpuguy83 Saya masih menunggu balasan tentang kasus penggunaan saya. Sistem pembangunan institusi kami didistribusikan melalui sistem file jaringan yang harus saya pasang di wadah saya. Ini membutuhkan wadah untuk berjalan dalam mode istimewa. Keputusan institusi saya untuk menggunakan sistem file jaringan untuk distribusi perangkat lunak bukanlah hal yang aneh untuk fisika partikel. Anda mengklaim bahwa --privileged pada build membuat gambar non-portabel, tetapi ini sama sekali tidak terkait dengan kasus penggunaan saya. Model pengembangan kami telah melepaskan semua portabilitas yang _mungkin_ hilang karena penggunaan sistem file jaringan (benarkah?). Kami hanya membutuhkan mesin pengembangan untuk memasangnya.

@ cpuguy83 PS Anda menyebutkan pembuat kustom. Di mana saya dapat menemukan informasi tentang ini? Terima kasih!

Seluruh diskusi tentang portabilitas kontainer ini adalah ikan haring merah raksasa. Anda sudah dapat mencapai hal yang sama dengan membuat gambar tahap 1, meluncurkan wadah dalam mode istimewa, melakukan apa pun yang harus Anda lakukan, lalu menggunakan komit buruh pelabuhan untuk membuat gambar akhir dari wadah itu.

Begitu mereka menambahkan opsi komit buruh pelabuhan, gagasan tentang portabilitas gambar tetap keluar, jadi memaksa orang untuk melakukan ini dalam 3 langkah alih-alih 1 tidak mendapatkan apa-apa dan hanya mengganggu orang yang benar-benar dapat menggunakan opsi pembuatan istimewa.

@drstapletron Memasang sistem file belum tentu sesuatu yang dapat merusak portabilitas (kecuali seseorang mengharapkan itu untuk dipasang pada gambar).
Masalahnya di sini adalah memiliki kemampuan untuk memasang sistem file juga berarti dapat melakukan banyak hal buruk lainnya.

@ctindel Ya, Anda dapat melakukan apa pun yang Anda inginkan dalam wadah yang Anda buat. Fakta bahwa docker build adalah "" metode yang didukung untuk membangun gambar, berarti kita perlu memastikan bahwa gambar yang dibuat dengannya _are_ portabel.

Gambar portabel bukanlah ikan haring merah. Portabilitas beban kerja adalah tujuan desain utama Docker. Arahan utama kami, seolah-olah.

@seltzy Sebagian besar hal yang memerlukan hak ekstra dimiliki saat runtime, karena sebagian besar waktu hak istimewa yang ditinggikan digunakan untuk memodifikasi Host dalam beberapa cara.
Yang mengatakan saya pasti dapat memahami bahwa beberapa hal diperlukan pada waktu pembuatan (seperti pemasangan nfs di atas).... tetapi bahkan dengan kasus NFS dan membangun gambar secara manual (bukan dengan docker build ), saya tidak akan memberikan wadah --privileged atau kemampuan tambahan apa pun, sebaliknya saya akan memasang ekspor nfs sebagai volume.

@drstapletron mount tidak memerlukan --privileged hanya kemampuan yang lebih terbatas dan lebih mungkin terjadi lebih cepat daripada mode hak istimewa penuh, karena itu memberikan akses root penuh ke Host yang dilakukan kebanyakan orang tidak ingin. (Masih memiliki masalah keamanan tetapi lebih mudah dikelola).

Jadi saya memiliki kasus penggunaan yang sepenuhnya portabel dan tidak mengubah host. Ini bahkan open source dan Anda dapat melihatnya di sini .

Pada dasarnya, saya ingin menjalankan Mock dalam wadah Docker portabel untuk membangun image ISO CentOS yang disesuaikan. Mock, bagi mereka yang tidak tahu, adalah pembangun RPM kemas. Masalahnya adalah, karena menggunakan wadah saya perlu --privileged atau --cap-add . Idealnya, saya pikir docker build akan bekerja seperti sebuah fungsi, mengambil beberapa argumen dan mengembalikan hasil akhirnya. Tanpa bendera ini, saya tidak bisa melakukan itu.

Sama disini ! Menggunakan tiruan di dalam buruh pelabuhan adalah mimpi buruk karena itu :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@cpuguy83 menulis:

Faktanya adalah, --privileged on build akan menghasilkan gambar non-portabel.

Mengapa tidak mengizinkan --privileged untuk mereka yang tidak membutuhkan portabilitas yang luas?
Catatan sederhana dalam dokumentasi resmi akan menjadi kompromi yang masuk akal (misalnya _Peringatan: meneruskan --privilege ke perintah build dapat menghasilkan gambar yang kurang portabel!_). Ini akan menyelesaikan kebutuhan hampir semua orang; beberapa pengguna tidak memerlukan portabilitas, beberapa lagi, peringatan akan cukup untuk memenuhi kebutuhan semua orang.

Saya yakin kurangnya build --privileged secara signifikan memperumit kasus penggunaan saya saat ini.

Itu bisa disebut --non-portable . Saya belum menggunakan bagian penyebaran buruh pelabuhan, tetapi hal-hal sistem file isolasi + overlay sangat berguna tanpa itu.

Saya perlu menggunakan beberapa perangkat lunak berpemilik yang memerlukan wadah khusus untuk dipasang. Tidak ada yang bisa saya lakukan tentang ini. Saya terjebak dengan kebutuhan untuk melakukan proses build, run, commit 3 tahap.

Portabilitas kontainer tidak berarti apa-apa bagi saya atau bisnis saya, bahkan saya berani bertaruh itu tidak berarti apa-apa bagi sebagian besar bisnis. Yang penting adalah saya ingin memelihara lebih sedikit perangkat lunak, jadi saya pikir memilih portabilitas daripada kegunaan dalam masalah ini merugikan Docker.

+1 untuk ini, dalam proses build kami menggunakan setfacl, ini gagal selama build dan layanan gagal dimulai di wadah. Saya pikir sebagai pengguna akhir kita tidak boleh dibatasi, gunakan opsi --priviledge hanya jika Anda perlu dan default dinonaktifkan.

+1 untuk ini. Dalam proses pembuatan kami, diperlukan untuk memasang /proc dan /dev. Idealnya kita harus dapat memiliki langkah mount sebagai bagian dari file docker.

@ samsun387 Mengapa proses pembuatan Anda memerlukan ini?

@skshandilya setfacl tidak portabel dan saya akan terkejut jika acl dapat dipertahankan pada gambar.

@robhaswell "membutuhkan wadah istimewa" tidak banyak membantu. Apa yang sebenarnya digunakan saat menginstal?

+1. mock init membutuhkan ini.
hampir membaca seluruh masalah. tidak mengerti mengapa orang terus bertanya "mengapa Anda membutuhkan ini" selama 3 tahun berturut-turut.

@Betriebsrat Karena "X membutuhkan ini" tidak terlalu membantu.
Apa yang "X" lakukan? Mengapa "X" membutuhkan ini selama fase pembuatan?

Misalnya, kasus di atas dengan kemampuan untuk memasang /proc dan /dev benar-benar tidak tampak seperti tempat yang tepat untuk fase pembuatan, dan bahkan tampak seperti gambar akan diikat ke Host sedemikian rupa sebuah kasus.

"hak istimewa" juga merupakan tangki. Ini benar-benar membuka segalanya, menonaktifkan semua fitur keamanan, memberikan akses tulis ke tempat yang biasanya hanya-baca... di mana seseorang mungkin hanya perlu dapat melakukan hal yang sangat spesifik.

Pertanyaan-pertanyaan ini diajukan agar kita bisa mendapatkan use case yang sebenarnya dan bagaimana kita bisa memenuhi case seperti itu.

Omong-omong, ketika saya mengatakan "fitur keamanan", maksud saya dua hal:

1. Hal-hal untuk mencegah peretasan
2. Isolasi masalah aplikasi dari masalah host (yaitu, pembuatan gambar tidak boleh mengikat gambar ke host tempat ia dibangun).

Sepertinya milik saya diselesaikan oleh 21051, saya keluar, untuk saat ini :)

@shykes berkata pada 28 November 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Maaf, desain saat ini adalah untuk menerapkan '1 source, 1 build' itulah sebabnya kami tidak mengizinkan argumen apa pun untuk membangun buruh pelabuhan selain direktori sumber.

Saya memahami fakta bahwa beberapa build saat ini tidak dapat dilakukan karena mereka memerlukan operasi istimewa. Untuk menanganinya dengan benar, kita mungkin perlu 1) mengizinkan Dockerfile untuk mengekspresikan kebutuhan untuk dibangun dengan cara yang diistimewakan, dan 2) menerapkan sistem otorisasi/trus yang memungkinkan buruh pelabuhan untuk menjeda pembangunan, memperingatkan pengguna dengan benar tentang risikonya, mengekspos informasi tentang asal dan kepercayaan Dockerfile, lalu mengumpulkan keputusan pengguna untuk mengizinkan atau menolak build.

@cpuguy83 , apakah desainnya berubah sama sekali dari menegakkan: "1 sumber, 1 build"?
Apakah Proyek Docker bersedia mengubah desain itu dan mengizinkan fitur yang diminta komunitas ini?

Komentar Shykes di atas tampaknya menjelaskan apa yang "kita mungkin perlu" lakukan untuk menangani ini. Pada saat yang sama, bahasa yang digunakan ("mungkin") tampaknya memberikan banyak ruang bagi proyek buruh pelabuhan untuk menemukan alasan tambahan untuk menolak perubahan desain ini.

Menambahkan deklarasi NEEDS_PRIVILEGED masuk akal, tetapi semua hal tentang menjeda build? Gagal saja dengan kesalahan dan biarkan operator melewati opsi --privileged jika mereka memang ingin mengizinkan build yang diistimewakan.

@cpuguy83 masalahnya adalah, orang yang membutuhkan mode istimewa dalam pembuatan biasanya adalah pengguna yang kuat yang tahu betul apa risiko menggunakannya. Dan sebagian besar dari mereka menerimanya dan mengatasinya hanya dengan menggunakan docker commit sebagai bagian dari build mereka untuk langkah yang membutuhkannya.

Anda sama sekali tidak mencegah orang menggunakan mode hak istimewa dalam pembuatan, Anda hanya membuatnya menjengkelkan untuk dilakukan.

Jika tujuan Anda membuatnya menjengkelkan untuk dilakukan, katakan saja secara langsung dan tutup masalah ini alih-alih membiarkannya berlangsung selama bertahun-tahun.

Katakan "kami tidak akan memperbaiki ini karena kami ingin itu mengganggu" dan tutup masalah ini.

/benang

@cpuguy83 , dari pemahaman saya, Mock menggunakan unshare(2) dengan CLONE_NEWNS flag-- dan mungkin yang lain-- ketika menciptakan lingkungan chroot/wadahnya. Ini membutuhkan setidaknya CAP_SYS_ADMIN .

Apa yang "X" lakukan? Mengapa "X" membutuhkan ini selama fase pembuatan?

Dalam kasus penggunaan kami, kami tidak tahu. Ini adalah omong kosong yang tidak bisa kita ubah. Masalahnya, bisnis kami tidak peduli tentang "keamanan" (dalam konteks ini) atau portabilitas, atau masalah apa pun yang telah terdaftar. Kami hanya ingin memasukkan sampah sialan ini ke dalam wadah dan melanjutkan untuk melakukan sesuatu yang berharga.

Seperti yang dikatakan @PonderingGrower , kita akan tetap melakukannya, hanya masalah berapa banyak waktu yang kita buang saat melakukannya.

orang yang membutuhkan mode istimewa dalam pembuatan biasanya adalah pengguna yang kuat yang tahu betul apa risiko menggunakannya

Saya sangat tidak setuju dengan anggapan itu. Secara keseluruhan, orang yang menggunakan --privileged adalah kategori pengguna yang sama yang menjalankan chmod -r 777 "karena seseorang menulis bahwa itu memperbaiki masalah"

Dalam kasus penggunaan kami, kami tidak tahu. Ini adalah omong kosong yang tidak bisa kita ubah. Masalahnya, bisnis kami tidak peduli tentang "keamanan" (dalam konteks ini) atau portabilitas, atau masalah apa pun yang telah terdaftar.

"dalam konteks ini" di sini, artinya: memberikan akses root "sebagian omong kosong" pada host Anda.

@thaJeztah Saya tidak punya masalah dengan itu. Ini adalah perangkat lunak yang telah kami beli dan bayar dukungannya. Jika kami tidak menggunakan wadah, itu masih membutuhkan root untuk menginstal.

Kami membutuhkan fitur ini untuk menggunakan dind saat membangun untuk mengonfigurasi beberapa wadah di dalam wadah yang sedang kami bangun.

Apa yang Anda diskusikan di sini selama 3 tahun?

docker run memiliki opsi --cap-add , --cap-drop dan lainnya. Jadi perintah RUN di Dockerfile ingin memiliki opsi yang sama. Jadi Dockerfile ingin mengirim permintaan ke mesin induk dan memintanya untuk menambah/menghapus beberapa hak istimewa.

Mesin induk dapat melakukan apa yang diinginkannya dengan permintaan ini. Anda dapat membuat shell interaktif, Anda dapat membuat dialog konfirmasi gui, dll. Mengapa Anda membahas resolusi permintaan ini dalam masalah ini?

Sejumlah besar pengguna buruh pelabuhan menginginkan kemampuan --cap-add atau --privileged dalam perintah build, untuk meniru apa yang ada di perintah run.

Itu sebabnya tiket ini telah dibuka selama 3 tahun dengan orang-orang terus-menerus menimpali meskipun pengelola tidak tertarik untuk memberikan apa yang diinginkan pengguna dalam contoh khusus ini.

@ctindel Ini jelas merupakan masalah dari masalah ini. Ada kesenjangan antara docker build --cap-add dan RUN --cap-add .

Beberapa orang ingin menyelesaikan permintaan hak istimewa dari mesin anak hanya dengan docker build --cap-add=caps_array . Apa itu? Ini hanya: caps_array.include? requested_cap .

Beberapa orang ingin pre_requested_caps.include? requested_cap . Beberapa orang menginginkan stdout << requested_cap, stdin.gets == 'y' .Beberapa orang menginginkan gui_confirm requested_cap . Beberapa orang pasti menginginkan UAC_fullscreen_dialog requested_cap .

Metode resolusi requested_cap tergantung pada selera pengguna dan saya pikir pertanyaan ini tidak akan pernah selesai.

Tapi RUN --cap-add tidak ada hubungannya dengan selera orang. Apa yang kita tunggu?

@andrew-aladev Saya tidak begitu mengerti apa yang dikatakan posting Anda. Intinya adalah bahwa orang memiliki perangkat lunak pihak ke-3 (RPM, DEB, apa pun) yang tidak berada di bawah kendali mereka, yang ingin mereka instal ke dalam gambar pada waktu "pembuatan buruh pelabuhan", dan yang memerlukan kemampuan ekstra untuk menginstal dengan benar. Karena mereka adalah RPM pihak ketiga, tidak ada cara untuk menyelesaikan persyaratan untuk peningkatan hak istimewa selama fase penginstalan.

Mereka mengatasi masalah dengan menjalankan wadah dengan kemampuan yang ditingkatkan, menginstal perangkat lunak mereka, dan kemudian membuat gambar dari wadah itu. Ini menyakitkan dan dengan jelas menunjukkan bahwa tidak ada alasan fungsional untuk melarang cap-add pada waktu pembuatan karena tujuan yang sama dapat dicapai secara sirkular.

@ctindel Bahasa Inggris saya tidak terlalu bagus, maaf.

Aku tahu. Saya telah mencoba emerge glibc dan saya menerima ptrace not permitted .

docker dapat menjalankan container dengan peningkatan/penurunan kemampuan dengan sendirinya. RUN perintah di Dockerfile harus mendukung --cap-add , --cap-drop , dll.

Mari kita bayangkan Dockerfile akan memiliki RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . Bagaimana cara kerjanya?

1. Mesin anak mengirimkan permintaan ke induk dan meminta SYS_PTRACE .
2. Induk memungkinkan kemampuan yang diperluas.
3. Induk membuat wadah baru dengan SYS_PTRACE diizinkan.

Saya melihat bahwa tidak ada seorang pun dalam masalah ini yang benar-benar berdebat tentang itu. Orang-orang hanya berdebat tentang metode yang memungkinkan kemampuan ini.

@thaJeztah berkata

Secara keseluruhan, orang yang menggunakan --privileged adalah kategori pengguna yang sama yang menjalankan chmod -r 777

Pria ini menginginkan metode validasi yang lebih fleksibel log :info, requested_cap; return privileged? .

@ctindel katamu

Menambahkan deklarasi NEEDS_PRIVILEGED masuk akal, tetapi semua hal tentang menjeda build? Gagal saja dengan kesalahan dan biarkan operator melewati opsi --privileged jika mereka memang ingin mengizinkan build yang diistimewakan.

Anda ingin membuat shell interaktif. Anda ingin stdout << requested_cap, stdin.gets == 'y' . Ini adalah metode lain dari validasi kemampuan yang diperlukan.

@cpuguy83 berkata

seseorang mungkin hanya perlu dapat melakukan hal yang sangat spesifik... hal-hal untuk mencegah peretasan.

Pria ini menginginkan docker build --cap-add=caps_array caps_array.include? requested_cap . Ini adalah metode lain dari validasi kemampuan yang diperlukan.

Jadi saya bertanya: Mengapa RUN di Dockerfile masih tidak memiliki dukungan --cap-add , --cap-drop , dll? Tidak ada yang berdebat tentang itu. 3 tahun berlalu!

@andrew-aladev Saya berasumsi tidak ada yang memperdebatkan sintaks itu karena telah dijelaskan bahwa sintaks dockerfile dibekukan sampai pembuatnya ditulis ulang/direfaktor/dipisahkan dari mesin utama. https://github.com/docker/docker/issues/29719#issuecomment -269342554

Lebih khusus lagi, judul masalah dan OP meminta --privileged build

ini membuat Fonzie tepuk tangan: .

dapat menjalankan strace pada langkah build membantu.
saat ini, saya mengatasi ini dengan memindahkan semua hal yang saya perlukan untuk debug ke langkah run - tidak ideal.

adakah yang tahu mengapa itu akan berhasil di langkah run dan bukan build ? yaitu, alasan historis.
apakah ada alternatif untuk strace yang berfungsi tanpa banyak izin atau konfigurasi?

Ada solusi/solusi yang diusulkan untuk ini di
https://github.com/docker/docker/issues/6800#issuecomment -50494871 :

jika Anda memiliki masalah dalam membangun buruh pelabuhan, Anda dapat menggunakan "wadah pembangun":
docker run --cap-add [...] mybuilder | docker build -t myimage -

Bisakah seseorang (mungkin @tiborvass) menguraikan ini? Apa jenis mybuilder sini ?
Nama gambar dengan beberapa ENTRYPOINT ? Atau apakah gambar bagian dari [...] dan mybuilder merujuk
ke skrip shell? Dan bagaimana cara meyakinkan docker run untuk meneruskan context.tar.gz ke docker build -
jika itu benar-benar terjadi di sini. Terima kasih sebelumnya, Steffen

@sneumann mybuilder akan menjadi nama gambar dan memiliki beberapa CMD atau ENTRYPOINT memang. Kontrak agar solusi itu berfungsi adalah bahwa mybuilder harus tar konteks dari dalam wadah dan melepaskannya ke stdout. Itu diteruskan ke stdin docker build , berkat pipa shell | dan dianggap sebagai konteks karena jalur konteks untuk docker build -t myimage - adalah - .

agak aneh saat melihat kodenya sepertinya opsi ini tersedia di perintah build :

• run : saya berasumsi bahwa container sini berarti run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go #L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

ada yang lebih paham punya ide mengapa itu tidak diterapkan?

@mbana --security-opt adalah untuk wadah Windows asli, yang mendukung "credentialspec" https://github.com/docker/docker/pull/23389

apakah mungkin untuk memodifikasi ini dan membuatnya bertahan sehingga build masa mendatang akan mengaktifkan ptrace ?

bagi siapa pun yang tertarik di sini adalah beberapa tautan bagus:

• http://www.projectatomic.io/docs/docker-building-images/ - cara membuat gambar menggunakan teknik yang dijelaskan di atas. yaitu, gunakan run untuk build gambar.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - misc

Saya telah melihat banyak klaim dari berbagai orang bahwa fitur ini tidak diperlukan karena build dapat diubah agar tidak memerlukan operasi istimewa tertentu, tetapi tidak ada saran tentang apa yang harus dilakukan tentang kasus "docker in docker". Jika sebuah build perlu menjalankan perintah docker , misalnya untuk menarik beberapa gambar yang ingin kita kirimkan di dalam yang ini, atau untuk membangun sub-gambar, bagaimana kita bisa melakukan ini tanpa semacam hak istimewa membangun opsi?

Untuk saat ini saya akan mengatasi ini menggunakan docker run dan docker commit tetapi akan lebih bagus jika docker build dapat mendukung kasus penggunaan ini.

@scjody Kedengarannya seperti yang Anda inginkan #31257

@ cpuguy83 Saya tidak yakin itu mencakup apa yang terjadi dalam kasus ini, tetapi saya akan mencobanya setelah digabungkan. Terima kasih!

Hai, saya ingin memasukkan nama saya ke dalam topi tolong-terapkan-ini. Atau mungkin ada solusi berbeda untuk masalah saya (docker noob di sini) yang dapat diarahkan oleh seseorang kepada saya?

Saya mencoba membuat gambar berdasarkan gambar centos/systemd resmi dan menyediakannya dengan Saltstack. Ini membutuhkan memulai (dan mungkin memulai ulang) daemon salt-minion dengan systemd yang tidak dapat dilakukan (AFAIK) tanpa mode istimewa.

@onlyanegg Saya pikir dalam situasi itu, Saltstack sebagian besar menggantikan fungsionalitas pembangun; perlu diingat bahwa setiap pernyataan RUN dieksekusi dalam wadah baru, di mana wadah pembangunan sebelumnya dihentikan, dan dikomit ke gambar/lapisan.

Sudahkah Anda mempertimbangkan untuk melakukan pembangunan dengan menjalankan wadah, dan melakukan hasilnya ( docker commit )?

Terima kasih atas tanggapannya, @thaJeztah. Saya tidak menyadari itulah yang dilakukan direktif RUN . Saya memang membaca sebagian besar masalah ini, jadi saya mengetahui solusi docker build -> docker run -> docker commit , yang kemungkinan besar akan saya lakukan pada akhirnya. Saya hanya lebih menyukai memiliki satu file yang menggambarkan gambar saya - tampaknya lebih rapi. Mungkin saya bisa memasukkan semua langkah itu ke dalam prosesor pasca pengepakan dan kemudian saya akan melakukannya.

Mengapa yang satu ini begitu diabaikan? Pada saat kontainer, kubernetes dan minikube, dan penggunaan buruh pelabuhan di CI dan penyatuan lingkungan pengembangan, fungsi ini sangat penting.

@onlyanegg Anda harus dapat me-restart layanan _tanpa_ mode istimewa. Jika Anda memiliki Dockerfile yang menggambarkan hal itu (yaitu, "perintah RUN pada baris 8 dari Dockerfile ini tidak berfungsi karena memerlukan mode istimewa"), saya akan dengan senang hati memeriksanya!

@derberg tepatnya! Pada saat container, CI, CD, penting agar alat build dapat ditampung (dalam arti keamanan). Jika Anda mengizinkan mode istimewa, Anda harus mengubah secara dramatis cara Anda menggunakan alat CI seperti Jenkins, Travis, Codeship, dll. Pertanyaan yang sama: jika Anda memiliki Dockerfile yang memerlukan mode istimewa, saya akan dengan senang hati menyarankan alternatif.

Terima kasih!

@jpetazzo coba dapatkan gambar buruh pelabuhan dengan buruh pelabuhan di dalamnya:

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

Sekarang bangun dan mulai. Setelah mulai jalankan service docker start untuk memulai deamon buruh pelabuhan. Kemudian periksa status layanan service docker status :

• dengan status bendera istimewa tidak apa-apa dan Anda dapat memulai wadah tanpa masalah
• tanpa bendera, itu tidak pernah dimulai

@jpetazzo ech, baru perhatikan bahwa Anda adalah pencipta https://github.com/jpetazzo/dind :) jadi Anda mengetahui konsep buruh pelabuhan di buruh pelabuhan :)

Bagaimanapun, jadi Anda sadar bahwa flag istimewa diperlukan untuk dijalankan. Jadi sekarang Anda dapat membayangkan sekelompok orang yang bekerja di beberapa lingkungan dan ingin memiliki lingkungan terpadu untuk pengembangan dengan beberapa hal yang telah dikonfigurasi sebelumnya di dalamnya, misalnya minikube dengan komponen yang sudah diinstal sebelumnya atau apa pun

Jadi, apakah ada cara untuk memasang share NFS atau SMB di docker build ?

@derberg langkah-langkah itu tidak akan berfungsi, bahkan jika wadah build berjalan --privileged ; paket buruh pelabuhan (dan skrip instal) adalah (misalnya) menginstal paket kernel di Ubuntu 16.04.
Itulah alasan --privileged adalah ide yang buruk untuk docker build , karena dapat membuat perubahan pada _host_.

Meskipun buruh pelabuhan akan membutuhkan hak istimewa saat _running_, instalasi itu sendiri tidak membutuhkan ini; misalnya, inilah langkah-langkah yang Anda jalankan untuk menginstal buruh pelabuhan di gambar Anda;

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

Dan Anda dapat menjalankannya dengan baik (saya menggunakan --privileged sini, tetapi mungkin izin yang lebih halus dimungkinkan):

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

Inilah cara saya menghindari masalah ini, untuk orang-orang yang benar-benar perlu membuat gambar buruh pelabuhan dalam mode istimewa. Ini mungkin tidak menyelesaikan semua kasus tetapi dapat membantu dalam beberapa kasus.

Metode ini membutuhkan Dockerfile, file docker-compse, dan skrip shell.

File Docker

Ini sama seperti yang Anda perlukan untuk membangun gambar. Satu-satunya perbedaan, berhenti di tempat Anda perlu melakukan operasi istimewa, jangan sertakan. Mereka harus dijalankan oleh docker-compose, sebagai skrip. Sebagai contoh:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

Lebih banyak perintah yang perlu dijalankan dalam mode istimewa sekarang ada di further-commands-to-run-in-privileged-mode.sh . Itu disertakan dalam gambar dan nantinya akan dijalankan oleh komposer buruh pelabuhan untuk menyelesaikan proses pembangunan.

File penulisan buruh pelabuhan

File penulisan adalah kuncinya. Ini akan membangun gambar terlebih dahulu dari atas Dockerfile, dan memulai wadah dari gambar itu dalam mode istimewa , kemudian Anda dapat melakukan operasi istimewa Anda di sana. Sebagai contoh:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

Membangun gambar

Langkah-langkah di bawah ini juga dapat disimpan dalam skrip shell.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah Saya tidak punya masalah dengan instalasi, saya punya masalah dengan memulai layanan buruh pelabuhan selama membangun dan menarik beberapa gambar agar mereka tersedia dalam gambar di luar kotak.

Tambahkan skrip berikut ke Dockerfile Anda dan Anda akan melihat bahwa layanan buruh pelabuhan tidak pernah bangun

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg Oke, saya mengerti! _Secara pribadi_, jika saya ingin memasukkan gambar dalam wadah dind , saya akan mengunduhnya (misalnya dengan reg ) dan saya akan memuatnya pertama kali wadah dimulai. Mengapa? Karena jika Anda menarik gambar selama pembuatan, gambar akan bekerja _hanya jika dind dimulai dengan driver penyimpanan yang sama_. Dengan kata lain, gambar Anda mungkin atau mungkin tidak berfungsi di mesin lain.

Juga–jika gambar Anda besar (yaitu apa pun selain, katakanlah, busybox atau alpine ), Anda akan mendapatkan gambar DinD yang sangat besar...

Saya ingin tahu lebih banyak tentang kasus penggunaan akhir Anda – karena saya yakin kami dapat membantu Anda menemukan cara yang lebih efisien daripada membuat gambar DinD yang besar :-)

(Jika tidak, solusi yang diusulkan oleh @kraml agak elegan!)

Lihat juga https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Mengunduh gambar hanya menggunakan bash+curl+tar.
Kami menggunakannya di sini: https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo kami sudah menjalankan dengan solusi build-run-commit seperti itu, tapi ya, itu masih solusi dari sudut pandang saya. Use case cukup spesifik terkait dengan lingkungan kubernetes dan minikube dan tidak ada yang bisa kita lakukan untuk saat ini. Untuk saat ini kami dapat memulai minikube di docker hanya dengan docker sebagai daemon, menggunakan virtualbox atau driver vm lainnya tidak berfungsi, jadi kami bergantung pada pendekatan dind

Mengalami masalah ini saat mencoba membangun gambar yang berisi aplikasi lawas (kasus penggunaan yang cukup normal), di mana penginstal mencoba menjalankan perintah sysctl dan gagal.

Kembali ke utas ini dan meninjau seluruh 4 tahun (!!!) bolak-balik tentang masalah cara menambahkan semacam kemampuan istimewa ke perintah build docker, tampaknya opsi yang tersedia dalam situasi ini adalah a sekumpulan perintah sed yang jahat untuk memodifikasi penginstal untuk menghapus panggilan sysctl, atau build multi-tahap -> jalankan -> komit pipa. Saya setuju dengan @derberg bahwa 'build -> run -> commit' terasa sebagai solusi (imo solusi kotor/retas) dan saya tidak berpikir bahwa kasus penggunaan saya seunik itu. Memeriksa utas lain Saya telah melihat banyak orang melaporkan masalah dengan berbagai aplikasi dan instalasi basis data dengan perintah docker build gagal karena kurangnya hak istimewa.

Pada titik ini, perintah docker run mendukung opsi 'hak istimewa' yang luas, bersama dengan "kontrol butir halus atas kemampuan menggunakan --cap-add dan --cap-drop". Jadi, saya pikir keberatan atas dasar keamanan atau teknis bisa diperdebatkan. Jika opsi menjalankan hak istimewa ditambahkan bersama dengan '--cap-add' dan '--cap-drop', seorang insinyur yang sadar akan keamanan dapat memilih untuk membatasi build yang diistimewakan agar hanya menyertakan kemampuan khusus yang diperlukan untuk build mereka.

Hai ,

Saya sudah melaporkan ini sebelumnya, masalah yang sama.

Bagaimana dengan mereka yang hanya ingin menjalankan satu container per VM dengan user id yang sama pada VM dan container , menggunakan buruh pelabuhan hanya sebagai alat pengemasan?

Apakah masih ada masalah keamanan terkait hal ini?

Berlari ke masalah ini. Benar-benar bisa menggunakan kemampuan untuk membangun.

Berlari ke masalah ini juga.
Ini sangat berguna saat menggunakan buruh pelabuhan sebagai budak CI/CD yang mungkin memerlukan izin istimewa pada docker build untuk menginstal rantai alat pembuatan/pengujian CI/CD saat membangun citra buruh pelabuhan.
Saya menunggu fitur ini selama bertahun-tahun dan sangat berharap fitur ini dapat didukung di masa mendatang.

Saya benar-benar tidak mengerti mengapa ada begitu banyak penolakan dari para pengembang tentang --privileged untuk gambar buruh pelabuhan.
Jika pengguna ingin menembak dirinya sendiri di kaki, mengapa tidak membiarkannya? Hanya menempatkan pesan peringatan dan hanya itu. Sudah ada solusi untuk mencapai hal yang sama, mengapa tidak memudahkan pengguna yang benar-benar membutuhkannya??
Sudah 4-5 tahun dan belum ada kemajuan dalam hal ini.
Luar biasa...

Sampai hari ini, bahkan fitur ini belum diimplementasikan:
JALANKAN --cap-add=SYS_PTRACE
yang akan sesuai dengan kebutuhan banyak pengguna..

Bisakah Anda menyarankan bagaimana saya dapat membangun Dockerfile ini di host Gentoo Linux:

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

karena saya mendapatkan kesalahan ini saat emerge-ing dev-lang/go:

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

Bagaimana saya bisa menjalankannya tanpa --cap-add=SYS_ADMIN --device /dev/fuse atau --privileged ?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

Saya dapat melakukannya dengan file bash terpisah di titik masuk, tetapi saya membutuhkan satu file Docker

@amd-nick apa harapan Anda dari baris RUN unionfs-fuse ... selama pembuatan? Bahkan jika itu berhasil, itu hanya akan memiliki sistem file yang dipasang selama RUN tunggal itu, dan hilang di langkah berikutnya.

@thaJeztah sulit untuk menjelaskan untuk saya. Saya mencoba untuk mengubah repo ini . Bisakah saya melewati garis ini di gedung?

Hai

Secara acak build docker memilih nama host mulai nol '0' yang merusak aplikasi kami, saya mencoba menjalankan "nama host" dalam kasus seperti itu di dalam DockerFile saya tetapi menghadapi masalah yang sama.

Saya juga ingin memiliki opsi untuk menjalankan docker build dengan RUNP atau mendapatkan opsi untuk memilih nama host selama build.

Adakah yang mencoba membuat gambar seperti ini dengan Kaniko ? Saya baru saja melakukannya dengan @maneamarius 's Dockerfile di Docker untuk Mac dan tampaknya berhasil dibangun setelah Anda memanggil perintah Kaniko docker run "build" dengan --cap-add=SYS_PTRACE . Meskipun, saya mengalami sedikit masalah saat memuat tarball yang dihasilkan secara lokal, penggunaan RAM agak tinggi karena tidak dapat menggunakan overlayf, dan cache lapisan masih WIP. Hal-hal mungkin Hanya Bekerja jika saya mendorong ke registri tetapi saya belum mencobanya.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

Memiliki fitur ini akan sangat membantu upaya membangun image Docker melalui Puppet pada image dasar Redhat/CentOS.

Sejak saya terakhir memposting, saya telah menindaklanjuti kembali dengan perubahan di Kaniko . Mereka tidak lagi tarballing di memori dan tarballing ke disk yang berarti dukungan untuk Dockerfiles yang menjelaskan gambar besar. Caching lapisan masih merupakan WIP tetapi mereka memiliki opsi untuk menyimpan gambar dasar untuk saat ini (Itu berarti saat ini tidak ada iterasi RUN menyimpan dan menjalankan jenis pekerjaan tetapi kami dapat men-cache alpine , ubuntu , dan basis populer apa pun yang ada di luar sana).

Itu pada keadaan di mana saya telah berhasil membangun Dockerfile @maneamarius yang memunculkan Golang dalam gambar Gentoo dalam proyek/demo ini tanpa memodifikasi Dockerfile @maneamarius atau memotongnya dengan cara apa pun ( EDIT: Sejak itu harus memodifikasi Dockerfile untuk menyematkan gambar dasar gentoo ke versi latest pada saat posting ini. Jika tidak, itu masih belum dimodifikasi. ):

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

Saya juga telah mengonfigurasi Azure Pipelines untuk membuat Dockerfile menjadi gambar dengan Kaniko dengan --cap-add=SYS_PTRACE , memuat tarball keluaran Kaniko, dan menjalankan go version pada gambar yang dihasilkan. Saya pikir beberapa "bukti kehidupan" interaktif akan menarik. Beberapa komentar sebelumnya di sini juga prihatin tentang sistem CI jadi saya pikir saya akan mengonfigurasi sistem CI publik agar berfungsi juga. BTW, Travis CI dipertimbangkan tetapi output build terlalu panjang dan dihentikan dan Azure sangat senang dengan 166k baris output. Jika Dockerfile dibuat dengan output sekitar 70rb lebih sedikit, mungkin akan berhasil di Travis CI. Tautan ke output build Azure Pipeline ada di bagian atas README.

Gunakan buildah Luke

Saya menutup masalah ini, karena fitur ini sekarang tersedia sebagai docker buildx build --allow security.insecure

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run ---securityinsecuresandbox

@AkihiroSuda Saya telah memperbarui buruh pelabuhan saya ke versi 19.03 untuk mencoba buildx . Ketika saya mencoba perintah yang Anda sebutkan, itu memberi saya kesalahan

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

dokumen buildx: For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Terima kasih @AkihiroSuda . Ini berhasil sekarang.

hanya untuk menambahkan kasus penggunaan lain.
Saya mencoba memperbaiki build dockerfile dari wadah ibmdb2 dengan database pengujian
IBM menghapus gambar v10 dari hub. Tetapi gambar DB v11 hanya dimulai dengan --privileged.
Jadi semua kode yang mengatur database di Dockerfile tidak berfungsi sekarang karena db2 tidak dimulai tanpa hak istimewa. :(
Tampaknya ada solusi yang rumit dengan menggunakan docker run dan docker commit.
Dalam pipa pembangunan yang produktif, ini menciptakan banyak kerumitan ekstra.

Saya harus bertanya seperti https://github.com/maneamarius di https://github.com/moby/moby/issues/1916#issuecomment -361173550

Mengapa begitu besar untuk mendukung ini? Build memang menjalankan run di bawah tenda.

Dalam kasus penggunaan khusus ini, opsi pembuatan yang diistimewakan akan mendukung semacam "kompatibilitas mundur" dan saya tahu saya bukan satu-satunya yang memiliki masalah ini setelah penelitian web saya.

@uvwild Saya tidak yakin apakah ini membantu kasus penggunaan Anda tetapi Anda dapat mencoba membangun dengan kaniko Gambar Anda akan dibuat tanpa deamon buruh pelabuhan dan Anda dapat mengekstrak gambar setelah selesai dan menggunakan kaniko sama seperti menjalankan wadah anda dapat menggunakan --privileged atau --cap-add <capability which is needed> yang mungkin dapat menyelesaikan masalah anda.

Saya menerima ini bukan solusi lengkap yang Anda harapkan tetapi solusi yang lebih mudah yang mungkin sesuai dengan pipa build Anda.

EDIT: Seperti yang dikatakan @alexey-vostrikov buildah bisa menjadi solusi yang lebih layak untuk kasus penggunaan yang membutuhkan --privileged untuk membangun gambar