Get best of the week

Perbaiki masalah di bawah Docker. Tampaknya, apa hubungannya GIT dengan itu?



Docker di bawah Windows adalah petualangan yang berkelanjutan. Kemudian dia perlu memperbarui OS, jika versi terbaru tidak diinstal, maka dia lupa bagaimana menghubungkan ke jaringan. Secara umum, setiap hari darinya berita. "Setel dan lupakan" bukan tentang Docker Desktop untuk Windows. Terutama ketika itu tidak digunakan persis seperti yang direkomendasikan pengembangnya. Dan untuk beberapa alasan mereka tidak menyetujui menghubungkan windows eksternal ke drive jaringan sebagai lokal. Dan mereka tidak menyetujui akses ke folder jaringan yang juga terletak di mesin host. Mereka menulis bahwa ini adalah horor-horor dari sudut pandang keamanan, mereka memerlukan semua jenis kunci seperti: agar perintah mount berfungsi dalam wadah, dan seterusnya dan seterusnya.

cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH



Secara umum, ketika sekali lagi setelah kontainer diunggah ke server pelanggan, layanan berhenti melihat drive jaringan, saya tidak terlalu terkejut. Ini sudah terjadi, dan bahkan instruksi selangkah demi selangkah ditulis untuk kelompok pendukung, bagaimana dan apa yang harus di-boot ulang ketika pengaturan jaringan buruh pelabuhan rusak.

Jadi saya membuka instruksi dan mengambil tindakan. Memulai ulang wadah tidak membantu. Saya memulai kembali melalui buruh pelabuhan-menulis dengan rekreasi infrastruktur - tidak membantu. Saya mereset pengaturan Docker ke pengaturan pabrik, mengembalikan pengaturan untuk mesin virtual, memuat ulang gambar, menjalankan melalui pembuatan docker - sekali lagi, semuanya seperti sebelumnya - tidak melihat jaringan. Lebih tepatnya, itu tidak terhubung ke bola jaringan, meskipun ping dari wadah ke server SMB adalah normal. Poin terakhir adalah me-reboot server dan menginstal ulang Docker, sementara saya melewatkan, karena saya benar-benar tidak ingin me-restart server. Pada instruksi ini berakhir.

Oke, saya pindah ke mesin rumah saya, di sini saya juga memiliki Docker untuk Windows, tetapi versi yang sedikit lebih baru. Saya memeriksanya. Telur yang sama:

Tidak ada koneksi, tetapi Anda tunggu!

Ya. Yah, sungguh, saya pikir Docker menggulung pembaruan dengan semacam keamanan dan sekarang skrip saya tidak memulai karena ini? Pemeriksaan terakhir adalah untuk sepenuhnya menghapus Docker dari mesin, dan pasang kembali. Ini harus lebih dingin daripada mengatur ulang ke pengaturan pabrik. Saya melakukan seluruh daftar dari langkah sebelumnya, hanya selain ini saya juga me-restart mobil saya sehingga benar-benar ironis. Saya meletakkan Docker dari awal, mengunggah gambar, meluncurkan docker-compose - eprst! Semua layanan sama-sama tidak melihat bola jaringan dan terus menulis "kesalahan pemasangan (22): Argumen tidak valid" saat memuat.

Saya mencoba menjalankan skrip baris demi baris dari baris perintah: sambungkan ke wadah, jalankan perintah pada gilirannya dan lihat bahwa semuanya terhubung dan berfungsi seperti perlu:

mkdir -p $SMB_MOUNT_POINT
mount -t cifs $SMB_SHARE $SMB_MOUNT_POINT -o user=$SMB_USER,password=$SMB_PASSWORD,vers=2.0
ls $SMB_MOUNT_POINT

Artinya, apa ini, semacam omong kosong dengan melewati parameter ke skrip ketika wadah dimulai?

Kami mencari lebih banyak ide. Semua opsi dengan reboot buruh pelabuhan adalah dangkal, ada opsi dengan kemungkinan perubahan pada gambar induk. Gambar saya dibuat berdasarkan openjdk: 8-jdk-alpine , tidak ada versi spesifik yang ditentukan, sehingga peningkatan keamanan apa pun dapat merusak skrip saya. Mungkin mereka mengubah sesuatu di OpenJDK atau anak perusahaan dari Alpine?

Saya memeriksa log proyek, mencoba memilih openjdk yang lebih lama: 8-jdk-alpine-3.8, openjdk: 8-jdk-alpine-3.7, dll. - setiap kali saya membangun kembali wadah, periksa - semuanya seperti sebelumnya.

Sial! Mungkin saya masih mengubah sesuatu di majelis saya? Membongkar dari versi GIT'a proyek sebulan yang lalu, mengumpulkan - gangguan yang sama. Tiga bulan lalu - masalahnya masih ada. Bagaimana? Apa yang berubah? Konfigurasi buruh pelabuhan saat ini dijamin berfungsi, konfigurasi gambar juga tidak berubah, sumber proyeknya sama (GIT menyimpan semuanya). Tidak ada keajaiban - Anda perlu memahami di mana perubahan itu muncul. Dalam prod, saya secara manual meluncurkan perintah koneksi ke bola - jadi sampai restart layanan akan berfungsi dengan baik dan pergi tidur. Pagi lebih bijaksana dari pada malam hari.

Tidak ada koneksi, tetapi Anda tunggu!

Pagi berikutnya idenya datang - bahwa mungkin sudah saatnya untuk mencari tahu, dan apa tepatnya skrip tidak suka saat dieksekusi.

Pesan "mount error (22): Argumen tidak valid" tidak terlalu informatif. Saya menemukan bahwa ada kunci ajaib untuk bash yang dengannya menampilkan informasi debug ketika menjalankan skrip.

Mulai debugging di dalam sh:

/ # sh -x /entry-point.sh
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
' mkdir -p '/pipeline
' mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o 'user=<private_user>,password=<private_password>,vers=2.0
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
' ls '/pipeline
+ exec

Dan di sini beberapa momen aneh muncul - garis dimulai dengan tanda kutip, lalu tanda kutip di bagian akhir ... Dari mana tanda kutip?

Ide - dapat meluncurkan menggunakan bash nyata lebih informatif?

Pasang di wadah BASH:

apk add bash

Saya mulai debugging:

/ # bash -x /entry-point.sh
' echo 'Mount //<private_ip>/Exchange/Pipeline to /pipeline
Mount //<private_ip>/Exchange/Pipeline to /pipeline
+ mkdir -p $'/pipeline\r'
+ mount -t cifs //<private_ip>/Exchange/Pipeline /pipeline -o $'user=<private_user>,password=<private_password>,vers=2.0\r'
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //<private_ip>/Exchange/Pipeline on /pipeline failed: Invalid argument
+ ls $'/pipeline\r'
+ exec

Sial, tampaknya seperti ketika garis dimulai dengan ditambah - baik itu, tetapi beberapa jenis \ r dan $ '...' parameter muncul .

Kami menetapkan Midnight Commander untuk bereksperimen dengan fasilitas apk add mcdan membuka naskah untuk mengedit, dan ada:



Oppa! ^ M di akhir setiap baris. Baiklah, lihat proyek lokal - bagaimana dengan akhiran garis ???? CRLF. Kami bekerja di bawah Windows.

Ubah file CRLF spesifik ini menjadi LF (long Notepad ++!), Kumpulkan proyek - bingo! Ini berfungsi sebagaimana mestinya.

Mengapa dulu tidak apa-apa, tetapi sekarang semuanya telah terbang? Saya melihat komitmen - tidak ada perubahan. Dan kemudian saya ingat bahwa GIT dapat mengedit umpan baris dengan cepatfile teks. Dan suatu hari saya menghubungkan repositori baru, dan mungkin mengunggah semua file dari sana dengan konversi ke CRLF.

Sebagai hasilnya, kami menambahkan file .gitattributes ke proyek , menunjukkan bahwa dalam file terpisah perlu untuk menyimpan karakter baris akhir seperti dalam UNIX:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Declare files that will always have LF line endings on checkout.
*.sh text eol=lf

Moralitas - terkadang pelakunya bahkan tidak jatuh ke dalam lingkaran tersangka awal.

P.S


Setelah memperbarui ke versi terbaru Docker Desktop untuk Windows 2.2.0.3, semuanya berhenti bekerja kembali. Kali ini, saya langsung masuk ke dalam wadah, dan mulai men-debug. Ternyata alamat IP 10.0.75.1 untuk mengakses mesin host berhenti berfungsi, DockerNat sekarang dihapus dari sistem, dan mesin virtual DockerDesktopVM bahkan tidak memiliki adaptor jaringan eksternal, mis. komunikasi dengannya tidak melalui jaringan standar, tetapi entah bagaimana berbeda. Dan untuk mengakses host, Anda harus menggunakan host.docker.internal . Rekan pengembang dan menulis itu
DockerNAT telah dihapus dari Docker Desktop 2.2.0.0 karena menggunakan alamat IP untuk berkomunikasi dari host ke wadah bukan fitur yang didukung. Untuk berkomunikasi dari sebuah wadah ke host, Anda harus menggunakan nama DNS khusus host.docker.internal.

Ok, saya memperbaiki konfigurasi untuk lingkungan pengujian, mengambil database, ping dari wadah ke host.docker.internal melewati, tetapi drive jaringan tidak terhubung. Saya mencoba menjalankan mount secara manual dari shell, dan saya mendapatkan error "mount error (22): Argumen tidak valid".

Saya menghapus argumen pada gilirannya - saya hanya menjalankan "mount -t cifs //host.docker.internal/playground / pipeline" - sepertinya berhasil, tetapi mengetuk dari pengguna root.

Tambahkan pengguna: mount -t cifs //host.docker.internal/playground / pipeline -o pengguna = smbuser - meminta kata sandi dan menghubungkan!

Versi lengkap juga berfungsi:

mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword

tetapi " mount -t cifs //host.docker.internal/playground / pipeline -o pengguna = smbuser, kata sandi = smbpassword, vers = 2.0 " tidak membajak.

Saya mengubah parameter terakhir ke vers = 2.1 - cheers, berfungsi!

Tampaknya Docker dalam versi terbarunya membuat implementasi sendiri dari server SMB dengan blackjack, tetapi tanpa dukungan 2.0. Omong kosong, tentu saja, dibandingkan dengan berita lain.

Semua kebaikan, kekuatan dan ketekunan!

Ilustrasi untuk artikel ini diambil dari blog.eduonix.com/software-development/learn-debug-docker-containers

More articles:


All Articles