Masalah dan Penyelesaian CI/CD untuk Perisian Sumber Terbuka dalam Senibina ARM64

Menggunakan perisian sumber terbuka pada seni bina ARM64 memerlukan persekitaran CI/CD yang kuat. Walau bagaimanapun, terdapat perbezaan antara tahap sokongan ARM64 dan seni bina pemproses tradisional x86, yang sering merugikan. Pemaju komponen infrastruktur untuk pelbagai seni bina mempunyai jangkaan tertentu untuk persekitaran kerja mereka:

• Konsistensi: Alat dan kaedah yang digunakan di seluruh platform adalah konsisten, mengelakkan keperluan untuk mengubah proses pembangunan disebabkan penggunaan platform yang kurang popular.
• Prestasi: Platform dan mekanisme sokongan mempunyai prestasi yang baik untuk memastikan senario penempatan tidak terjejas oleh kelajuan yang tidak mencukupi apabila menyokong pelbagai platform.
• Liputan Ujian: Semua platform diuji serentak dengan kecekapan, pematuhan dan keselamatan tanpa perbezaan yang ketara.
• Pengekalkan: Membolehkan pemaju untuk mengautomasikan proses integrasi dan pembangunan semula untuk menjadikannya sesuai untuk semua platform tanpa pengubahsuaian.

Pengurus produk komponen ini juga perlu memenuhi keperluan ini, dan terdapat sekurang -kurangnya dua mata:

• Liputan Platform: Pengurus Akaun Teknikal (TAM) mempunyai kemahiran dan penyediaan yang diperlukan untuk bertindak balas terhadap keperluan pelanggan.
• Sokongan keupayaan hierarki: Membolehkan TAMS dan kakitangan IT lain untuk mengklasifikasikan tahap sokongan perisian berdasarkan keupayaan mereka untuk bertindak balas terhadap kecemasan atau kecemasan.

Bantuan platform yang digerakkan

Pemaju sumber terbuka Alex Ellis, yang bekerjasama dengan Ampere dan penyedia infrastruktur Equinix, menyediakan platform CI/CD yang digerakkan untuk beberapa projek sumber terbuka yang paling kritikal dalam ekosistem perisian awan asli.

Proses automasi yang dihoskan oleh GitHub (yang jurutera keselamatan membuktikan terdedah kepada serangan berniat jahat) dalam mesin maya mikro yang diasingkan dari Internet awam.

Pelaksanaan dan hasil

Beberapa projek sumber terbuka CNCF kritikal menggunakan persekitaran yang digerakkan untuk menjalankan semua tindakan GitHub ARM64 mereka. Persekitaran ini didasarkan pada pemproses AMPERE? Altra? dan disediakan dengan bantuan penyedia infrastruktur Equinix.

Kejayaan inisiatif ini telah membawa GitHub untuk menyediakan sokongan seni bina ARM64 penuh untuk tindakan GitHub. Pemaju yang pernah menjalankan proses membina ARM64 dalam persekitaran simulasi QEMU dengan seni bina x86 kini boleh memindahkannya ke ARM64 pada logam kosong.

ARM64 Pelari Host sendiri untuk Tindakan GitHub

Github menguasai hosting projek perisian. Cara yang paling popular untuk menjana integrasi berterusan membina dan melepaskan projek GitHub yang dihoskan adalah menggunakan tindakan GitHub, set alat CI yang dibina, platform. Peranan yang paling penting dalam tindakan GitHub CI/CD adalah untuk mengautomasikan proses pembangunan perisian.

Pelari bertanggungjawab untuk mencetuskan sebarang tindakan GitHub. Ia adalah proksi yang berjalan di pelayan, menunggu tugas dan bersedia untuk dilaksanakan sebaik sahaja tugas diterima. Ia mengambil tugas dari alur kerja dan bertanggungjawab untuk menyelesaikannya.

GitHub adalah platform penempatan perisian lengkap. Oleh itu, ia menjadi tuan rumah pelari sendiri, masing -masing menyesuaikan diri dengan persekitaran sasaran dan seni bina yang ditentukan. Sehingga baru -baru ini, GitHub belum menyediakan persekitaran pelari yang diuruskan untuk ARM64. Sesungguhnya ada pilihan untuk projek -projek yang ingin menjana binaan asli ARM64 - pelari yang dihoskan sendiri.

Pengguna GitHub boleh memasang ejen pada mesin fizikal atau maya yang dihoskan di tempat lain dan mempunyai tindakan GitHub yang menghantar pekerjaan kepada tuan rumah, yang dikendalikan oleh pengguna projek. Ini memerlukan Pentadbir Projek bukan sahaja untuk menguruskan projek itu sendiri, tetapi juga untuk mengekalkan dan memastikan keselamatan persekitaran membina projek yang akan digunakan.

Dalam kes CNCF, pemaju memanfaatkan titik logam Equinix, yang membolehkan mereka mengkonfigurasi contoh logam kosong dan menggunakannya sebagai pelari sendiri yang dihoskan untuk projek. Tetapi untuk projek makmal kod yang mesti melayani pemaju lain di seluruh dunia 24/7, keselamatan pelari yang dihoskan sendiri menimbulkan cabaran: menurut dokumentasi GitHub, sesiapa sahaja boleh mengklonkan repositori projek, mengubah suai pekerjaan tindakan, dan mengakses nod pelari untuk menjalankan apa-apa pekerjaan.

Satu lagi masalah ialah memastikan konsistensi antara operasi CI. Bagi pelari yang dihoskan sendiri, jika terdapat kesan sampingan pada pekerjaan CI, seperti perubahan konfigurasi atau fail yang ditinggalkan selepas itu, mereka masih akan wujud dalam pekerjaan berikutnya.

Ini membawa masalah - apabila menjalankan pekerjaan CI yang membina atau menguji perisian, anda harus mempunyai persekitaran terkawal supaya satu -satunya perubahan antara setiap larian adalah perisian. Bagi pelari yang dihoskan sendiri, alam sekitar melayang dari masa ke masa. Tanpa proses pembersihan, menjalankan kerja membina yang sama pada tuan rumah yang sama boleh menghasilkan hasil yang berbeza dari masa ke masa.

Salah satu cara pemaju memintas keperluan pelari asli ARM64 adalah untuk menjalankan persekitaran ARM64 maya pada pelayan x86, menggunakan simulasi sumber terbuka QEMU. Persekitaran simulasi menambah overhead prestasi yang besar kepada kompilasi perisian, dan kelajuannya hanya sebahagian kecil daripada kelajuan kompilasi pada perkakasan asli, bukan analog.

Simulasi mudah digunakan untuk projek kecil dan sederhana. Walau bagaimanapun, jika pemaju perlu membina projek yang besar dan penting untuk ARM64, tekanan terhadap persekitaran maya menjadi begitu besar sehingga binaan akan gagal sepenuhnya.

Fenomena Gap

Tidak seperti perusahaan biasa, CNCF diwajibkan untuk membina komponen awan asli untuk semua seni bina pemproses utama di dunia.

Projek-projek seperti ContainerD Portable Container Runtime, ETCD Store Data Value Kunci, Fluentd Log Data Collector, Falco Alat Pengesanan Ancaman Masa Nyata, dan Opentelemetry Observability and Detection Toolkit adalah kebergantungan utama dalam ekosistem asli awan dan oleh itu mesti dibina untuk x86 dan ARM64.

Untuk membina komponen infrastruktur peringkat rendah yang menyokong ARM64, pemaju CNCF memerlukan akses kepada infrastruktur ARM64 asli. Ironinya, ini bermakna mereka memerlukan kategori alat yang mereka cuba buat.

Pada mulanya, Ampere dan Equinix bekerja dengan CNCF untuk mengatasi jurang ini dengan mendermakan pelayan berasaskan AMPERE ALTRA atau menubuhkan nod logam terdedah berasaskan altra di kemudahan Equinix. Granularity sumber pelayan berasaskan ARM64 yang Equinix boleh berkongsi adalah sistem logam node-160-slot Ampere Altra yang terdedah.

Sebaik -baiknya, pelayan sedemikian akan dikongsi di antara pelbagai projek, tetapi ini adalah di luar keupayaan CNCF pada masa itu. Ini adalah masalah ampere dan digerakkan ditangani untuk CNCF dengan membenarkan beberapa projek berjalan pada bilangan tuan rumah yang lebih kecil, menyediakan lebih banyak projek dengan akses mudah untuk membina perkhidmatan sambil memakan perkakasan yang kurang.

Terobosan: Pengubahsuaian kod yang digerakkan dan satu baris

Untuk bergerak ke arah langkah pertama ke arah konsistensi platform antara x86 dan ARM64, Ampere meminta bantuan daripada Alex Ellis, pencipta perkhidmatan yang dipanggil. Ini adalah produk yang menjalankan pekerjaan Github Actions dalam mesin maya mikro yang selamat dan terpencil yang dikesan untuk menerima pekerjaan membina dari tindakan GitHub dan menyediakan pemaju dengan penglihatan ke dalam prestasi kerja mereka dan beban sistem binaan bersama.

Selepas menukar garis kod untuk fail konfigurasinya, digerakkan boleh menjalankan semua pelari tindakan GitHub yang sedia ada CNCF, dan dalam beberapa kes ia juga memerlukan menampal beberapa coretan kod -perubahan telah dilaksanakan dalam masa kurang dari lima minit. Perubahan ini membolehkan projek-projek GitHub yang dihoskan untuk menunjuk kepada persekitaran yang didorong oleh mikro-VM yang digerakkan pada pemproses AMPERE ALTRA untuk pekerjaan membina mereka.

Padang permainan tahap

Menjelang awal 2023, terdapat beberapa pilihan untuk projek hosting GitHub yang ingin mengintegrasikan ARM64 sepenuhnya ke dalam proses integrasi yang berterusan. Melalui inisiatif ini, memanfaatkan penyelesaian perisian inovatif yang digerakkan dan CPU AMPERE yang diuruskan oleh Equinix, menurunkan halangan untuk projek CNCF untuk mula mencapai konsistensi dalam sokongan ARM64 dan x86.

Projek-projek awan utama termasuk ETCD, Containerd, Telemetri Terbuka, Falco, dan lain-lain boleh mempromosikan sokongan mereka untuk ARM64, mempercepat operasi CI pada infrastruktur ARM64 asli, dan menyokong lebih banyak pengguna untuk memanfaatkan pengkomputeran ARM64 di awan.

Pada akhir projek perintis ini, bilangan pilihan pemaju meningkat dengan ketara. CNCF kini menyediakan projek-projeknya dengan keupayaan untuk menjalankan pekerjaan tindakan GitHub pada kluster Kubernet yang diuruskan pada OCI, menggunakan contoh-contoh yang didorong oleh amperse dan projek GitHub yang sedang berkembang pesat.

Atas ialah kandungan terperinci CNCF mencetuskan penemuan pariti platform untuk ARM64 dan x86. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!