cara yang elegan untuk membetulkan ID pengguna dalam bekas docker menggunakan docker_userid_fixer

tentang apa?

Ini mengenai isu yang agak teknikal dalam menggunakan bekas docker yang berinteraksi dengan komputer hos docker, secara amnya berkaitan dengan menggunakan sistem fail hos di dalam bekas.
Itu berlaku khususnya dalam konteks penyelidikan yang boleh diterbitkan semula.
Saya membangunkan utiliti sumber terbuka yang membantu menangani isu itu.

bekas docker sebagai persekitaran pelaksanaan

Kes penggunaan awal dan utama bekas docker: aplikasi diri sendiri yang hanya berinteraksi dengan sistem hos dengan beberapa port rangkaian.
Fikirkan aplikasi web: bekas docker biasanya mengandungi pelayan web dan aplikasi web, berjalan sebagai contoh pada port 80 (di dalam bekas). Bekas itu kemudiannya dijalankan pada hos, dengan mengikat port dalaman kontena 80 ke port hos (mis. 8000).
Kemudian satu-satunya interaksi antara aplikasi kontena dan sistem hos adalah melalui port rangkaian terikat ini.

Bekas sebagai persekitaran pelaksanaan adalah berbeza sama sekali:

• daripada menyimpan aplikasi, ia adalah sistem binaan aplikasi yang disimpan dalam kontena.
  • ia boleh menjadi pengkompil, IDE, enjin buku nota, sistem penerbitan Quarto...
• matlamatnya ialah:
  • untuk mempunyai standard, mudah dipasang dan berkongsi persekitaran
    • bayangkan persekitaran binaan yang kompleks, dengan versi tetap R, python dan berjuta-juta pakej luaran. Memasang segala-galanya dengan versi yang betul boleh menjadi tugas yang sangat sukar dan memakan masa. Dengan berkongsi imej docker yang mengandungi semua yang telah dipasang dan diprakonfigurasikan adalah penjimat masa sebenar.
  • untuk mempunyai persekitaran boleh dihasilkan semula
    • dengan menggunakannya, anda boleh menghasilkan semula beberapa keputusan analisis, kerana anda menggunakan persekitaran terkawal yang sama
    • anda juga boleh menghasilkan semula pepijat dengan mudah, yang merupakan langkah pertama untuk membetulkannya

Tetapi, untuk menggunakan persekitaran pelaksanaan tersebut, bekas tersebut mesti mempunyai akses kepada sistem hos, khususnya kepada sistem fail pengguna hos.

bekas docker dan sistem fail hos

Andaikan anda telah menyimpan IDE, mis. Rstudio.
Rstudio anda dipasang dan berjalan di dalam bekas docker, tetapi ia perlu membaca dan mengedit fail dalam folder projek anda.

Untuk itu anda bind mount folder projek anda (dalam sistem fail hos anda) menggunakan pilihan docker run --volume.
Kemudian fail anda boleh diakses daripada bekas docker.

Cabarannya sekarang ialah kebenaran fail. Katakan pengguna hos anda mempunyai id pengguna 1001 dan katakan bahawa pengguna yang memiliki proses Rsudio dalam bekas itu sama ada 0 (root), atau 1002.

Jika pengguna kontena adalah root, maka ia tidak akan menghadapi masalah dalam membaca fail anda.
Tetapi sebaik sahaja anda mengedit beberapa fail sedia ada, menghasilkan yang baharu (cth. pdf, html), fail ini akan menjadi milik root juga pada sistem fail hos!.
Bermaksud bahawa pengguna hos tempatan anda tidak akan dapat menggunakannya atau memadamkannya, kerana mereka tergolong dalam akar.

Kini jika id pengguna kontena ialah 1002, Rstudio mungkin tidak dapat membaca fail anda, mengeditnya atau menghasilkan fail baharu.
Walaupun boleh, dengan menetapkan beberapa kebenaran yang sangat permisif, pengguna hos tempatan anda mungkin tidak dapat menggunakannya.

Sudah tentu satu cara bruteforce untuk menyelesaikan isu itu ialah menjalankan dengan root pada komputer hos dan dengan bekas docker. Ini tidak selalu mungkin dan menimbulkan beberapa kebimbangan keselamatan kritikal yang jelas.

menyelesaikan isu pemilik fail bahagian 1: docker run --user option

Oleh kerana kami tidak dapat mengetahui terlebih dahulu apakah yang akan menjadi id pengguna hos (di sini 1001), kami tidak boleh pra-konfigurasi
id pengguna pengguna kontena docker.

docker run kini menyediakan pilihan --user yang membolehkan untuk mencipta pseudo pengguna dengan beberapa userid yang dibekalkan
pada masa larian. Contohnya, docker run --user 1001 ... akan mencipta bekas docker yang berjalan dengan proses
kepunyaan pengguna dengan id pengguna 1001.

Jadi apa yang kita masih bincangkan isu ini? Tidakkah ia diselesaikan?

Berikut beberapa keanehan tentang pengguna yang dibuat secara dinamik itu:

• ia adalah pengguna pseudo
• ia tidak mempunyai direktori rumah (/home/xxx)
• ia tidak muncul dalam /etc/passwd
• ia tidak boleh diprakonfigurasikan, mis. dengan profil bash, beberapa env vars, lalai aplikasi dll...

Kita boleh menyelesaikan masalah ini, tetapi ia boleh membosankan dan mengecewakan.
Apa yang kami benar-benar mahukan, adalah untuk pra-konfigurasi pengguna kontena docker, dan dapat menukar secara dinamik userid beliau pada runtime...

menyelesaikan isu pemilik fail bahagian 2: masukkan docker_userid_fixer

docker_userid_fixer ialah utiliti sumber terbuka yang bertujuan untuk digunakan sebagai docker entrypoint untuk membetulkan isu userid yang baru saya bangkitkan.

Mari lihat cara menggunakannya: anda menetapkannya sebagai ENTRYPOINT docker anda, dengan menyatakan pengguna mana yang patut digunakan dan userid beliau diubah suai secara dinamik:

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

Mari tepat dalam istilah kami:

• pengguna sasaran, ialah pengguna yang diminta untuk docker_userid_fixer, di sini user1
• pengguna diminta, ialah pengguna yang diperuntukkan oleh docker run, iaitu pengguna yang (pada mulanya) memiliki proses pertama (PID 1)

Kemudian, pada penciptaan masa jalan kontena, terdapat dua pilihan:

• sama ada diminta id pengguna (sudah) sepadan dengan sasaran id pengguna, maka tiada apa yang perlu diubah
• atau tidak. Contohnya diminta userid ialah 1001 dan sasaran userid ialah 100. Kemudian, docker_userid_fixer akan membetulkan id pengguna sasaran pengguna pengguna1 daripada 1000 hingga 1001, terus dalam proses utama kontena.

Jadi dalam amalan ini menyelesaikan masalah kami:

• jika anda tidak perlu membetulkan id pengguna kontena anda, hanya gunakan docker run seperti biasa (tanpa pilihan --user)
• atau anda menggunakan --user option, kemudian sebagai tambahan menjalankan proses utama anda dengan userid yang anda minta, ia akan mengubah suai pengguna prakonfigurasi anda kepada userid yang anda minta, supaya bekas anda berjalan dengan pengguna yang anda maksudkan dan dimaksudkan id pengguna.

persediaan docker_userid_fixer

Anda boleh mendapatkan arahan tentang persediaan di sini.

Tetapi ia bermuara kepada:

• bina atau muat turun boleh laku kecil (17k)

• salin ke dalam imej docker anda

• jadikan ia boleh laku sebagai akar setuid

• konfigurasikan ia sebagai titik masuk anda

butiran berdarah

Saya telah meletakkan beberapa nota ringkas https://github.com/kforner/docker_userid_fixer#how-it-works
tetapi saya akan cuba menguraikan semula.

Inti pelaksanaan ialah setuid root docker_userid_fixer boleh laku dalam bekas.
Kami memerlukan kebenaran root untuk menukar id pengguna, dan setuid ini membolehkan pelaksanaan istimewa itu hanya untuk
program docker_userid_fixer, dan itu untuk masa yang sangat singkat.

Sebaik sahaja userid telah diubah suai jika perlu, docker_userid_fixer akan menukar proses utama
kepada pengguna yang diminta (dan id pengguna!).

Jika anda berminat dengan topik ini (docker, penyelidikan boleh ulang, pembangunan pakej R, algoritma, pengoptimuman prestasi, paralelisme...) jangan teragak-agak untuk menghubungi saya untuk membincangkan peluang pekerjaan dan perniagaan.

Atas ialah kandungan terperinci cara yang elegan untuk membetulkan ID pengguna dalam bekas docker menggunakan docker_userid_fixer. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!