Kami mengembangkan DevOps sebaik mungkin. Ada 8 orang di tim kami, dan Vasya adalah yang paling keren. WindowsTiba-tiba Vasya pergi, dan saya mendapat tugas untuk meluncurkan proyek baru yang memasok Windows-pengembangan. Saat saya menumpahkan seluruh tumpukan ke atas meja. Windows-perkembangan-perkembangan itu, lalu saya menyadari bahwa situasinya menyakitkan...
Beginilah ceritanya dimulai Alexandra Sinchinova pada Ketika spesialis terkemuka itu meninggalkan perusahaan. WindowsAlexander bertanya-tanya apa yang harus dilakukannya sekarang. Pergi ke LinuxTentu saja! Alexander akan memberi tahu Anda bagaimana dia berhasil menciptakan preseden dan menerjemahkan sebagiannya. Windows perkembangan pada Linux Dengan menggunakan contoh proyek yang telah selesai untuk 100.000 pengguna akhir.
Cara mudah dan tanpa hambatan mengirimkan proyek ke RPM menggunakan TFS, Puppet, Linux .NET Core? Bagaimana Anda mempertahankan versi basis data proyek jika pengembang baru pertama kali mendengar kata-kata Postgres dan Flyway, dan tenggat waktunya lusa? Bagaimana Anda mengintegrasikannya dengan Docker? Bagaimana Anda memotivasi pengembang .NET untuk meninggalkan Windows dan smoothie untuk Puppet dan LinuxBagaimana cara menyelesaikan konflik ideologis jika Anda sedang bertugas? Windows Tidak punya energi, keinginan, atau sumber daya untuk memulai produksi? Presentasi Alexander membahas hal ini, serta penerapan web, pengujian, CI, praktik TFS dalam proyek yang sudah ada, dan, tentu saja, solusi sementara yang gagal dan solusi yang berhasil.
Jadi, Vasya pergi, tugas itu menjadi milikku, dan para pengembang menunggu dengan tidak sabar sambil memegang garpu rumput. Ketika akhirnya aku menyadari bahwa Vasya tidak akan kembali, aku langsung приступи ke pekerjaan. Pertama, aku menilai persentase Win VM di armada kami. Peluangnya tidak menguntungkannya. Windows.
Karena kami aktif mengembangkan DevOps, saya menyadari bahwa kami perlu mengubah sesuatu dalam pendekatan untuk menyebarkan aplikasi baru. Hanya ada satu solusi: pindahkan semuanya ke native, jika memungkinkan. LinuxGoogle membantu saya - pada saat itu .Net sudah diporting ke Linux, dan saya menyadari bahwa inilah solusinya!
Mengapa .NET Core digunakan bersamaan dengan... Linux?
Ada beberapa alasan untuk ini. Jika diberi pilihan antara membayar dan tidak membayar, kebanyakan orang akan memilih yang terakhir—begitu pula saya. Lisensi untuk MSDB harganya sekitar $1.000, dan memelihara sejumlah mesin virtual Windows Jumlahnya mencapai ratusan dolar. Bagi perusahaan besar, ini merupakan pengeluaran yang signifikan. Oleh karena itu, tabungan - alasan pertama. Bukan yang paling penting, tapi salah satu yang signifikan.
Mesin virtual Windows menggunakan lebih banyak sumber daya daripada saudara-saudara mereka dari Linux - mereka beratMengingat skala perusahaan yang besar ini, kami memilih Linux.
Sistem ini hanya diintegrasikan ke dalam CI yang sudah adaKami menganggap diri kami sebagai perusahaan DevOps progresif, kami menggunakan Bamboo, Jenkins, dan GitLab CI, sehingga sebagian besar pekerjaan kami dilakukan di platform tersebut. Linux.
Alasan terakhir adalah iringan yang nyaman. Kami perlu menurunkan hambatan masuk bagi "pemelihara"—mereka yang memahami sisi teknis, memastikan waktu aktif, dan memelihara layanan dari lini kedua. Mereka sudah familiar dengan tumpukan teknologi yang kami gunakan. LinuxOleh karena itu, jauh lebih mudah bagi mereka untuk memahami, mendukung, dan memelihara produk baru daripada menghabiskan sumber daya tambahan untuk memahami fungsionalitas serupa dari perangkat lunak yang sudah ada. Windows platform.
Persyaratan
Pertama dan terutama - kenyamanan solusi baru bagi pengembangTidak semua dari mereka siap untuk perubahan, terutama setelah kata itu diucapkan. LinuxPara pengembang menginginkan Visual Studio favorit mereka, TFS dengan pengujian build otomatis, dan Smoothie. Bagaimana mereka mengirimkan ke produksi bukanlah hal yang penting bagi mereka. Itulah mengapa kami memutuskan untuk tidak mengubah proses yang sudah familiar dan membiarkannya seperti itu. Windows- perkembangan tetap tidak berubah.
Dibutuhkan proyek baru diintegrasikan ke dalam CI yang ada. Relnya sudah ada dan semua pekerjaan harus dilakukan dengan mempertimbangkan parameter sistem manajemen konfigurasi, standar pengiriman yang diterima, dan sistem pemantauan.
Kemudahan dukungan dan pengoperasian, sebagai syarat batas minimum masuk bagi seluruh peserta baru dari berbagai divisi dan departemen pendukung.
Batas waktu - kemarin.
Menangkan Grup Pengembangan
Saat itu, tim tersebut menggunakan apa? Windows?
Sekarang saya dapat dengan yakin mengatakan itu Server Identitas4 adalah alternatif gratis yang keren untuk ADFS dengan kemampuan serupa, atau apa Inti Kerangka Entitas - surga bagi seorang pengembang, di mana Anda tidak perlu repot menulis skrip SQL, tetapi mendeskripsikan kueri dalam database dalam istilah OOP. Namun kemudian, saat mendiskusikan rencana tindakan, saya melihat tumpukan ini seolah-olah itu adalah tulisan paku Sumeria, hanya mengenali PostgreSQL dan Git.
Saat itu kami aktif menggunakan Wayang sebagai sistem manajemen konfigurasi. Di sebagian besar proyek kami, kami menggunakan GitLab CI, Elastis, menggunakan layanan beban tinggi yang seimbang HAProksi memantau semuanya dengan Zabbix, ligamen grafana и Prometheus, Kain triko vol, dan semua ini berputar pada potongan-potongan besi HP c ESXi pada VMware. Semua orang tahu itu - genre klasik.
Mari kita lihat dan coba pahami apa yang terjadi sebelum kita memulai semua intervensi ini.
Apa yang terjadi
TFS adalah sistem yang cukup kuat yang tidak hanya mengirimkan kode dari pengembang ke mesin produksi akhir, tetapi juga memiliki serangkaian integrasi yang sangat fleksibel dengan berbagai layanan - untuk menyediakan CI di tingkat lintas platform.
Sebelumnya, semuanya berupa jendela. TFS menggunakan beberapa agen Build, yang membangun banyak proyek. Setiap agen memiliki 3-4 pekerja untuk memparalelkan tugas dan mengoptimalkan proses. Kemudian, sesuai dengan rencana rilis, TFS mengirimkan Build yang baru saja selesai ke Windows-server aplikasi.
Apa yang ingin kami capai?
Kami menggunakan TFS untuk pengiriman dan pengembangan, dan meluncurkan aplikasi pada Linux Server aplikasi, dan ada semacam keajaiban di antara keduanya. Ini kotak ajaib dan inilah tantangan pekerjaan yang akan datang. Sebelum saya membongkarnya, saya akan minggir dan menyampaikan beberapa patah kata tentang aplikasi tersebut.
Proyek
Aplikasi ini menyediakan fungsionalitas untuk menangani kartu prabayar.
Konfirmasi
Ada dua jenis pengguna. Pertama memperoleh akses dengan masuk menggunakan sertifikat SSL SHA-2. kamu kedua ada akses menggunakan login dan kata sandi.
HAProxy
Kemudian permintaan klien masuk ke HAProxy, yang memecahkan masalah berikut:
- otorisasi utama;
- penghentian SSL;
- menyetel permintaan HTTP;
- permintaan siaran.
Sertifikat klien diverifikasi di sepanjang rantai. Kami - kewenangan dan kami mampu membelinya, karena kami sendiri yang menerbitkan sertifikat untuk melayani klien.
Perhatikan poin ketiga, kita akan kembali lagi nanti.
Backend
Bagian backend direncanakan akan dikerjakan pada LinuxSistem backend berinteraksi dengan basis data, memuat daftar hak akses yang diperlukan, dan kemudian, tergantung pada hak akses pengguna yang berwenang, memberikan akses untuk menandatangani dokumen keuangan dan mengirimkannya untuk dieksekusi, atau menghasilkan laporan.
Menghemat dengan HAProxy
Selain dua konteks yang dinavigasi setiap klien, ada juga konteks identitas. Server Identitas4 hanya memungkinkan Anda untuk masuk, ini adalah analog gratis dan kuat untuk ADFS - Layanan Federasi Direktori Aktif.
Permintaan identitas diproses dalam beberapa langkah. Langkah pertama - pelanggan masuk ke bagian belakang, yang berkomunikasi dengan server ini dan memeriksa keberadaan token untuk klien. Jika tidak ditemukan, permintaan dikembalikan ke konteks asalnya, tetapi dengan pengalihan, dan dengan pengalihan tersebut menuju ke identitas.
Langkah kedua - permintaan telah diterima ke halaman otorisasi di IdentityServer, tempat klien mendaftar, dan token yang telah lama ditunggu-tunggu itu muncul di database IdentityServer.
Langkah ketiga - klien dialihkan kembali dengan konteks dari mana hal itu berasal.
IdentityServer4 memiliki fitur: itu mengembalikan respons terhadap permintaan pengembalian melalui HTTP. Tidak peduli seberapa keras kami berjuang dalam menyiapkan server, tidak peduli seberapa banyak kami mencerahkan diri dengan dokumentasi, setiap kali kami menerima permintaan klien awal dengan URL yang datang melalui HTTPS, dan IdentityServer mengembalikan konteks yang sama, tetapi dengan HTTP. Kami terkejut! Dan kami mentransfer semua ini melalui konteks identitas ke HAProxy, dan di header kami harus mengubah protokol HTTP ke HTTPS.
Apa peningkatannya dan di mana Anda menabung?
Kami menghemat uang dengan menggunakan solusi gratis untuk mengotorisasi sekelompok pengguna, sumber daya, karena kami tidak menempatkan IdentityServer4 sebagai node terpisah di segmen terpisah, tetapi menggunakannya bersama dengan backend di server yang sama tempat backend aplikasi berjalan .
Bagaimana cara kerjanya
Jadi, seperti yang saya janjikan – Kotak Ajaib. Kita sudah memahami bahwa kita pasti bergerak ke arah itu. LinuxMari kita rumuskan tugas-tugas spesifik yang perlu diselesaikan.
Pertunjukan boneka. Untuk menyampaikan dan mengelola layanan dan konfigurasi aplikasi, resep keren harus ditulis. Gulungan pensil dengan fasih menunjukkan betapa cepat dan efisiennya hal itu dilakukan.
Metode Pengiriman. Standarnya adalah RPM. Semua orang mengerti itu. Linux Tidak ada cara lain, tetapi proyek itu sendiri, setelah dibangun, merupakan kumpulan file DLL yang dapat dieksekusi. Ada sekitar 150 file, sehingga proyek tersebut menjadi cukup berat. Satu-satunya solusi yang berkelanjutan adalah mengemas biner-biner ini ke dalam RPM dan menyebarkan aplikasi dari sana.
Pembuatan versi. Kami berencana merilis versi secara sangat sering, dan kami harus memutuskan bagaimana membentuk nama paketnya. Ini adalah pertanyaan tentang tingkat integrasi dengan TFS. Kami memiliki agen build di LinuxKetika TFS mengirimkan tugas ke worker pada agen Build, TFS juga meneruskan sejumlah variabel yang tersimpan di lingkungan worker tersebut. Variabel lingkungan ini berisi nama Build, nama versi, dan variabel lainnya. Detail selengkapnya tersedia di bagian "Membangun Paket RPM".
Menyiapkan TFS Semuanya bermuara pada pengaturan Pipeline. Sebelumnya, kami biasa membangun berdasarkan... Windows-semua agen Windows-proyek, dan sekarang tampaknya Linux-agent — sebuah agen Build yang perlu disertakan dalam grup build, diperkaya dengan beberapa artefak, menentukan jenis proyek apa yang akan dibangun pada agen Build ini, dan Pipeline dimodifikasi dengan cara tertentu.
Server Identitas. ADFS bukan pilihan kami, kami memilih Open Source.
Mari kita lihat komponennya.
kotak ajaib
Terdiri dari empat bagian.
Linux Agen pembangun. LinuxKarena kita sedang mengkompilasinya—itu masuk akal. Bagian ini diselesaikan dalam tiga langkah.
- Konfigurasikan pekerja dan tidak sendirian, karena pekerjaan yang terdistribusi pada proyek tersebut diharapkan terjadi.
- Instal .NET Core 1.x. Mengapa 1.x padahal 2.0 sudah tersedia di repositori standar? Karena ketika kami memulai pengembangan, versi stabilnya adalah 1.09, dan diputuskan untuk membuat proyek berdasarkan versi tersebut.
- Git 2.x.
Repositori RPM. Paket RPM perlu disimpan di suatu tempat. Kami seharusnya menggunakan repositori RPM perusahaan yang sama yang dapat diakses oleh semua orang. Linux Host. Itulah yang kami lakukan. Server repositori telah dikonfigurasi. kait web yang mengunduh paket RPM yang diperlukan dari lokasi yang ditentukan. Versi paket dilaporkan ke webhook oleh agen Build.
GitLab. Harap dicatat: GitLab tidak digunakan oleh pengembang di sini, tetapi oleh departemen operasional untuk mengontrol versi aplikasi, versi paket, dan status semuanya. Linux-mesin dan menyimpan resepnya - semua manifestasi Puppet.
Wayang — menyelesaikan semua masalah kontroversial dan memberikan konfigurasi yang kami inginkan dari Gitlab.
Kami mulai menyelam. Bagaimana cara kerja pengiriman DLL ke RPM?
Pengiriman DDL ke RPM
Katakanlah kita memiliki bintang rock pengembangan .NET. Ia menggunakan Visual Studio dan membuat cabang rilis. Setelah itu, ia mengunggahnya ke Git, dan Git di sini adalah entitas TFS, yaitu repositori aplikasi tempat pengembang bekerja.
Setelah itu, TFS melihat bahwa commit baru telah tiba. Aplikasi yang mana? Pengaturan TFS menunjukkan sumber daya apa yang dimiliki setiap Build Agent. Dalam hal ini, ia melihat bahwa kita sedang membangun proyek .NET Core dan memilih Linux Buat agen dari kumpulan tersebut.
Agen Build menerima sumber dan mengunduh yang diperlukan ketergantungan dari repositori .NET, npm, dll. dan setelah membangun aplikasi itu sendiri dan pengemasan selanjutnya, mengirimkan paket RPM ke repositori RPM.
Di sisi lain, hal berikut terjadi. Insinyur departemen operasi terlibat langsung dalam peluncuran proyek: dia mengubah versi paket Hiera di repositori tempat resep aplikasi disimpan, setelah itu Wayang terpicu Yum, mengambil paket baru dari repositori, dan versi baru aplikasi siap digunakan.
Semuanya sederhana dalam kata-kata, tetapi apa yang terjadi di dalam agen Build itu sendiri?
Kemasan DLL RPM
Menerima sumber proyek dan tugas pembangunan dari TFS. Agen pembangun mulai membangun proyek itu sendiri dari sumber. Proyek rakitan tersedia sebagai satu set file DLL, yang dikemas dalam arsip zip untuk mengurangi beban pada sistem file.
Arsip ZIP dibuang ke direktori pembuatan paket RPM. Selanjutnya, skrip Bash menginisialisasi variabel lingkungan, menemukan versi Build, versi proyek, jalur ke direktori build, dan menjalankan RPM-build. Setelah build selesai, paket dipublikasikan ke repositori lokal, yang terletak di agen Build.
Selanjutnya dari Build agent ke server di repositori RPM Permintaan JSON dikirim menunjukkan nama versi dan build. Webhook, yang saya bicarakan sebelumnya, mengunduh paket ini dari repositori lokal di agen Build dan membuat rakitan baru tersedia untuk instalasi.
Mengapa skema pengiriman khusus ini untuk repositori RPM? Mengapa paket yang sudah dibuat tidak dapat langsung diunggah ke repositori? Ini adalah persyaratan keamanan. Skenario ini membatasi kemungkinan orang yang tidak berwenang mengunggah paket RPM ke server yang dapat diakses publik. Linux-mobil.
Pembuatan versi basis data
Pada konsultasi pengembangan, ternyata para pengembang lebih dekat dengan MS SQL, tetapi dalam kebanyakan kasus bukan...Windows Kami sudah menggunakan PostgreSQL secara ekstensif untuk beberapa proyek. Karena kami sudah memutuskan untuk beralih dari perangkat lunak berbayar, kami mulai menggunakan PostgreSQL di sini juga.
Pada bagian ini saya ingin memberi tahu Anda bagaimana kami membuat versi database dan bagaimana kami memilih antara Flyway dan Entity Framework Core. Mari kita lihat pro dan kontra mereka.
Kontra
Jalur Terbang hanya berjalan satu arah, kita kita tidak bisa memutar kembali — ini adalah kekurangan yang signifikan. Ini dapat dibandingkan dengan Entity Framework Core dalam hal lain—dari perspektif kemudahan pengembang. Anda ingat bahwa kami menjadikan ini prioritas utama, dan kriteria utamanya adalah tidak mengubah apa pun untuk Windows-perkembangan.
Untuk Jalur Terbang kami diperlukan semacam pembungkusagar orang-orang tidak menulis Kueri SQL. Mereka lebih dekat untuk beroperasi dalam istilah OOP. Kami menulis instruksi untuk bekerja dengan objek database, membuat kueri SQL dan menjalankannya. Versi baru database sudah siap, diuji - semuanya baik-baik saja, semuanya berfungsi.
Entity Framework Core memiliki kekurangan - di bawah beban berat membangun kueri SQL suboptimal, dan penurunan database bisa sangat signifikan. Namun karena kami tidak memiliki layanan dengan beban tinggi, kami tidak menghitung beban dalam ratusan RPS, kami menerima risiko ini dan melimpahkan masalahnya ke masa depan kami.
Kelebihan:
Inti Kerangka Entitas bekerja di luar kotak dan mudah dikembangkan, dan Jalur Terbang Mudah diintegrasikan ke dalam CI yang ada. Tapi kami membuatnya nyaman bagi pengembang :)
Prosedur penggulungan
Wayang melihat bahwa ada perubahan dalam versi paket, termasuk versi yang bertanggung jawab untuk migrasi. Pertama, ia menginstal paket yang berisi skrip migrasi dan fungsionalitas terkait database. Setelah ini, aplikasi yang bekerja dengan database di-restart. Berikutnya adalah instalasi komponen lainnya. Urutan instalasi paket dan peluncuran aplikasi dijelaskan dalam manifes boneka.
Aplikasi menggunakan data sensitif, seperti token, kata sandi basis data, semua ini ditarik ke dalam konfigurasi dari master Wayang, di mana data tersebut disimpan dalam bentuk terenkripsi.
Masalah TFS
Setelah kami memutuskan dan menyadari bahwa semuanya benar-benar berfungsi untuk kami, saya memutuskan untuk melihat apa yang terjadi dengan rakitan di TFS secara keseluruhan untuk departemen pengembangan Win pada proyek lain - apakah kami sedang membangun/meluncurkan dengan cepat atau tidak, dan menemukan masalah signifikan dengan kecepatan.
Salah satu proyek utama membutuhkan waktu 12-15 menit untuk dirakit - itu waktu yang lama, Anda tidak bisa hidup seperti itu. Analisis cepat menunjukkan penurunan yang parah pada I/O, dan ini terjadi pada array.
Setelah menganalisanya komponen demi komponen, saya mengidentifikasi tiga fokus. Pertama - "Antivirus Kaspersky", yang menjadi tanggung jawab semua orang Windows Agen pembangun memindai kode sumber. Yang kedua adalah Windows Pengindeks. Itu tidak dinonaktifkan, dan semuanya diindeks secara real time di agen Build selama proses penerapan.
Ketiga - Instal Npm. Ternyata di sebagian besar Pipeline kami menggunakan skenario persis seperti ini. Kenapa dia jahat? Prosedur instalasi Npm dijalankan ketika pohon ketergantungan terbentuk package-lock.json, tempat versi paket yang akan digunakan untuk membangun proyek dicatat. Kelemahannya adalah Npm install menarik paket versi terbaru dari Internet setiap saat, dan ini memakan banyak waktu untuk proyek besar.
Pengembang terkadang bereksperimen pada mesin lokal untuk menguji cara kerja sebagian atau keseluruhan proyek. Kadang-kadang ternyata semuanya keren secara lokal, tetapi mereka merakitnya, meluncurkannya, dan tidak ada yang berhasil. Kami mulai mencari tahu apa masalahnya - ya, versi paket yang berbeda dengan dependensi.
keputusan
- Sumber dalam pengecualian AV.
- Nonaktifkan pengindeksan.
- Pergi ke npm ci.
Kelebihan npm ci adalah kita Kami mengumpulkan pohon ketergantungan satu kali, dan kami mendapat kesempatan untuk menyediakannya kepada pengembang daftar paket saat ini, yang dengannya dia dapat bereksperimen secara lokal sebanyak yang dia suka. Ini menghemat waktu pengembang yang menulis kode.
Konfigurasi
Sekarang sedikit tentang konfigurasi repositori. Secara historis kami menggunakan Nexus untuk mengelola repositori, termasuk REPO internal. Repositori internal ini berisi semua komponen yang kami gunakan untuk keperluan internal, misalnya pemantauan yang ditulis sendiri.
Kami juga menggunakan NuGet, karena memiliki caching yang lebih baik dibandingkan dengan pengelola paket lainnya.
Hasil
Setelah kami mengoptimalkan Agen Pembuat, waktu pembuatan rata-rata berkurang dari 12 menit menjadi 7 menit.
Jika kita menghitung semua mesin yang bisa kita gunakan untuk Windows, tetapi diterjemahkan menjadi Linux Dalam proyek ini, kami menghemat sekitar $10.000. Dan itu hanya untuk lisensi; jika Anda memperhitungkan kontennya, penghematannya akan lebih besar lagi.
Rencana
Untuk kuartal berikutnya, kami berencana berupaya mengoptimalkan pengiriman kode.
Beralih ke image Docker prebuild. TFS adalah hal yang keren dengan banyak plugin yang memungkinkan Anda berintegrasi ke dalam Pipeline, termasuk perakitan berbasis pemicu, misalnya, image Docker. Kami ingin menjadikan pemicu ini untuk pemicu yang sama package-lock.json. Jika komposisi komponen yang digunakan untuk membangun proyek berubah, kami membuat image Docker baru. Ini kemudian digunakan untuk menyebarkan wadah dengan aplikasi yang telah dirakit. Hal ini tidak terjadi saat ini, namun kami berencana untuk beralih ke arsitektur layanan mikro di Kubernetes, yang secara aktif berkembang di perusahaan kami dan telah melayani solusi produksi sejak lama.
Ringkasan
Saya mendesak semua orang untuk membuangnya. WindowsNamun, bukan karena saya tidak tahu cara memasaknya. Alasannya adalah sebagian besar solusi sumber terbuka Linux-tumpukan. Apakah kamu baik-baik saja menghemat sumber dayaMenurut saya, masa depan terletak pada solusi Open Source. Linux dengan komunitas yang kuat.
Profil pembicara Alexander Sinchinov .
adalah konferensi tentang integrasi proses pengembangan, pengujian dan operasi untuk para profesional oleh para profesional. Itu sebabnya proyek yang dibicarakan Alexander? diimplementasikan dan dikerjakan, dan pada hari pertunjukan ada dua rilis yang berhasil. Pada Pada tanggal 27 dan 28 Mei akan ada lebih banyak lagi kasus serupa dari praktisi. Anda masih bisa melompat ke gerbong terakhir dan atau luangkan waktumu tiket. Temui kami di Skolkovo!
Sumber: www.habr.com
