lxc exec: Terokai daya tarikannya yang unik

Pengenalan

Baru-baru ini, saya telah membuat beberapa penambahbaikan pada lxc exec. Jika anda tidak mengetahuinya, izinkan saya memperkenalkannya lxc exec ialah alat klien LXD Ia menggunakan api klien LXD untuk berkomunikasi dengan daemon LXD dan melaksanakan pelbagai program yang ingin dilaksanakan oleh pengguna daripada perkara yang boleh anda gunakan:

Salah satu matlamat utama kami adalah untuk menjadikan lxc exec serupa dengan ssh, kerana ia adalah standard untuk menjalankan arahan dari jauh, secara interaktif atau tidak interaktif. Ini menjadikan melakukan lxc exec dengan baik agak sukar.

1. Memproses tugas latar belakang

Masalah yang berlarutan sudah tentu ialah cara mengendalikan tugas latar belakang dengan betul. Berikut ialah contoh masalah dengan contoh LXD 2.7:

Anda dapat melihat bahawa melaksanakan tugas di latar belakang akan menyebabkan lxc exec gagal untuk keluar. Banyak arahan boleh mencetuskan isu ini:

chb@conventiont|~ 
> lxc exec zest1 bash 
root@zest1:~# yes &
 y
 y 
 y 
 . 
 . 
 .

Tiada apa yang boleh menyelamatkan anda sekarang. ya akan sentiasa menulis terus ke stdout.

Punca masalah ialah stdout sentiasa terbuka, tetapi ini perlu kerana ia digunakan untuk memastikan bahawa sebarang data yang ditulis oleh proses yang dimulakan oleh pengguna sebenarnya dibaca dan dihantar semula melalui sambungan websocket yang kami sediakan.

Jika anda mahu melakukan ini, jalankan sesi shell, kemudian jalankan proses di latar belakang dan keluar dari shell dengan segera. Maaf, ia tidak berfungsi seperti yang diharapkan.

Pendekatan pertama dan primitif ialah dengan hanya menutup stdout sebaik sahaja anda mengesan program latar depan (cth. shell) telah keluar. Tetapi ini tidak sebaik yang kelihatan Masalah ini menjadi jelas apabila anda menjalankan program pelaksanaan pantas, seperti:

lxc exec -- ls -al /usr/lib

Di sini proses lxc exec (dan proses forkexec yang berkaitan. Tetapi jangan fikir tentangnya sekarang, cuma ingat bahawa Go + setns() don't interact...) akan keluar sebelum semua data buffer dalam stdout telah dibaca . Keadaan ini akan mengakibatkan keluaran terpotong, yang tiada siapa yang mahu. Selepas mencuba beberapa kaedah untuk menyelesaikan masalah, termasuk melumpuhkan penimbalan pty (biar saya beritahu anda, ia tidak cantik dan tidak berfungsi seperti yang diharapkan.) dan idea pelik lain, saya berjaya melalui beberapa poll() "helah" ( Dalam erti kata "helah") menyelesaikan masalah ini. Kini anda akhirnya boleh menjalankan tugas latar belakang dan keluar sepenuhnya. Seperti yang ditunjukkan dalam gambar:

2. Laporkan kod keluar yang disebabkan oleh isyarat

ssh ialah alat yang hebat. Tetapi satu perkara yang saya selalu tidak suka ialah ssh sentiasa melaporkan -1, iaitu kod keluar 255, apabila arahan yang dijalankan oleh ssh menerima isyarat. Ini menjengkelkan apabila anda ingin memahami isyarat yang menyebabkan program ditamatkan. Itulah sebabnya saya baru-baru ini melaksanakan konvensyen yang digunakan oleh cengkerang standard untuk melaporkan sebarang keluar yang disebabkan oleh isyarat, 128 + n, di mana n ditakrifkan sebagai semafor yang menyebabkan pelaksana keluar. Sebagai contoh, pada isyarat SIGKILL, anda akan melihat 128 + SIGKILL = 137 (kira kod keluar untuk isyarat maut lain sebagai latihan untuk pembaca). Jadi anda boleh melakukan ini:

chb@conventiont|~ 
> lxc exec zest1 sleep 100

Sekarang, hantar SIGKILL kepada pelaksana (bukan lxc exec itu sendiri, kerana SIGKILL tidak boleh dimajukan).

kill -KILL $(pidof sleep 100)

Akhirnya semak kod keluar program anda:

chb@conventiont|~
> echo $?
137

Tengok. Ini nampaknya hanya berfungsi jika a) kod keluar tidak melebihi halangan pengiraan 8-bit, dan b) apabila pelaksana tidak menggunakan 137 untuk menunjukkan kejayaan (bagaimana...menarik?!). Tiada hujah yang kelihatan sangat meyakinkan saya. Yang pertama adalah kerana semafor maut tidak boleh melebihi julat ini. Yang terakhir kerana (i) ia adalah isu pengguna, (ii) kod keluar ini sebenarnya dikekalkan (saya fikir begitu.), dan (iii) anda akan menghadapi masalah yang sama menjalankan program secara tempatan atau di tempat lain.

Kelebihan utama yang saya lihat ialah keupayaan untuk melaporkan status keluar secara terperinci kepada pelaksana. Ambil perhatian bahawa kami tidak melaporkan semua kejadian program yang dibunuh oleh isyarat. Sebagai contoh, apabila program anda dapat mengendalikan SIGTERM dan keluar dengan bersih, LXD tidak mempunyai cara mudah untuk mengesan ini dan melaporkan bahawa program itu telah dibunuh oleh isyarat. Anda hanya akan menerima kod keluar 0.

3. Isyarat hadapan

Ini mungkin tidak terlalu menyeronokkan (atau mungkin tidak, siapa tahu), tetapi saya rasa ia sangat berguna. Seperti yang anda lihat dalam kes SIGKILL, saya secara jelas menyatakan bahawa SIGKILL mesti dihantar kepada pelaksana, bukan perintah lxc exec itu sendiri. Ini kerana SIGKILL tidak boleh dikendalikan dalam program tersebut. Satu-satunya perkara yang boleh dilakukan oleh program ialah mati, seperti sekarang...seperti dalam contoh ini...segera (anda mendapat idea...). Tetapi program ini boleh mengendalikan banyak isyarat lain, SIGTERM, SIGHUP', dan sudah tentu SIGUSR1 dan SIGUSR2. Jadi apabila anda menghantar isyarat yang boleh dikendalikan oleh lxc exec` tetapi bukan oleh pelaksana, versi LXD yang lebih baharu akan memajukan isyarat kepada pelaksana. Ini sangat mudah dalam skrip.

Apa pun, saya harap anda dapati artikel kecil lxc exec ini berguna. Nikmati LXD, ia bermain dengan binatang yang cantik gila. Sila cuba percubaan dalam talian: https://linuxcontainers.org/lxd/try-it/, dan untuk pembangun lihat di sini: https://github.com/lxc/lxd dan hantarkan patch kepada kami.

Kami tidak memerlukan sebarang CLA untuk ditandatangani, kami mengikut gaya kernel selagi terdapat baris "Ditandatangani oleh" di dalamnya.

---

Atas ialah kandungan terperinci lxc exec: Terokai daya tarikannya yang unik. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!