Halo semuanya!
NetCracker telah mengembangkan dan memasok aplikasi perusahaan untuk pasar global operator telekomunikasi selama bertahun-tahun. Pengembangan solusi semacam itu cukup rumit: ratusan orang berpartisipasi dalam proyek, dan jumlah proyek aktif dalam puluhan.
Sebelumnya, produknya monolitik, tetapi sekarang kami dengan percaya diri bergerak menuju aplikasi layanan mikro. DevOps menghadapi tugas yang agak ambisius - untuk menyediakan lompatan teknologi ini.
Hasilnya, kami mendapat konsep perakitan yang sukses, yang ingin kami bagikan sebagai praktik terbaik. Deskripsi implementasi dengan detail teknis akan sangat banyak, kami tidak akan melakukan ini dalam kerangka artikel ini.
Dalam kasus umum, perakitan adalah transformasi beberapa artefak menjadi artefak lainnya.
Siapa yang akan tertarik
Perusahaan-perusahaan yang menyediakan perangkat lunak siap pakai untuk organisasi pihak ketiga yang sepenuhnya dan dibayar untuk itu.
Inilah yang mungkin terlihat seperti pengembangan tanpa pengiriman eksternal:
- Departemen TI di pabrik mengembangkan perangkat lunak untuk perusahaannya.
- Perusahaan ini bergerak dalam bidang outsourcing untuk pelanggan asing. Pelanggan secara independen mengkompilasi dan mengoperasikan kode ini di server webnya sendiri.
- Perusahaan memasok perangkat lunak ke pelanggan eksternal, tetapi di bawah lisensi sumber terbuka. Dengan demikian, sebagian besar tanggung jawab dibebaskan.
Jika Anda tidak dihadapkan dengan pasokan eksternal, maka banyak dari apa yang tertulis di bawah ini akan tampak berlebihan atau bahkan paranoid.
Dalam praktiknya, semuanya harus dilakukan sesuai dengan persyaratan internasional untuk lisensi dan enkripsi yang digunakan, jika tidak setidaknya konsekuensi hukum akan muncul.
Contoh pelanggaran adalah mengambil kode dari perpustakaan dengan lisensi GPL3 dan menanamkannya dalam aplikasi komersial.
Munculnya layanan mikro membutuhkan perubahan
Kami telah memperoleh pengalaman luas dalam perakitan dan pengiriman aplikasi monolitik.
Beberapa server Jenkins, ribuan pekerjaan CI, beberapa jalur perakitan sepenuhnya otomatis berdasarkan Jenkins, puluhan insinyur rilis khusus, kelompok ahli sendiri tentang manajemen konfigurasi.
Secara historis, pendekatan di perusahaan adalah ini: pengembang menulis kode sumber, dan DevOps menemukan dan menulis konfigurasi sistem perakitan.
Sebagai hasilnya, kami memiliki dua atau tiga konfigurasi perakitan khas yang dirancang untuk operasi di ekosistem perusahaan. Secara skematis, tampilannya seperti ini:
Alat bangun biasanya semut atau pakar, dan sesuatu diterapkan oleh plug-in yang tersedia untuk umum, ada sesuatu yang ditulis sendiri. Ini bekerja dengan baik ketika perusahaan menggunakan serangkaian teknologi yang sempit.
Layanan microser berbeda dari aplikasi monolitik terutama dalam beragam teknologi.
Ternyata banyak konfigurasi perakitan untuk setidaknya setiap bahasa pemrograman. Kontrol terpusat menjadi tidak mungkin.
Diperlukan untuk menyederhanakan skrip perakitan sebanyak mungkin dan memungkinkan pengembang untuk mengeditnya secara mandiri.
Selain kompilasi dan pengemasan sederhana (dalam diagram berwarna hijau ), skrip ini berisi banyak kode untuk integrasi dengan ekosistem perusahaan (dalam diagram berwarna merah ).
Oleh karena itu, diputuskan untuk menganggap perakitan sebagai "kotak hitam", di mana lingkungan perakitan "cerdas" dapat menyelesaikan semua masalah, kecuali untuk kompilasi dan pengemasan sendiri.
Pada awal pekerjaan tidak jelas bagaimana cara mendapatkan sistem seperti itu. Membuat keputusan arsitektur untuk tugas-tugas DevOps membutuhkan pengalaman dan pengetahuan. Bagaimana cara mendapatkannya? Opsi yang memungkinkan di bawah ini:
- Cari informasi di Internet.
- Pengalaman dan pengetahuan sendiri dari tim DevOps. Untuk melakukan ini, ada baiknya membuat tim programmer ini dengan pengalaman serbaguna.
- Pengalaman dan pengetahuan yang diperoleh di luar tim DevOps. Banyak pengembang di perusahaan memiliki ide bagus - Anda perlu mendengarnya. Komunikasi sangat membantu.
- Kami menciptakan dan bereksperimen!
Apakah saya memerlukan otomatisasi?
Untuk menjawab pertanyaan ini, Anda perlu memahami pada tahap evolusi apa pendekatan perakitan kami. Secara umum, tugas melewati level berikut.
- Tingkat Bawah Sadar
Kita perlu merilis satu perakitan per minggu, orang-orang kita baik-baik saja. Ini wajar, mengapa membicarakannya?
- Level "artisan", akhirnya berubah menjadi level "dodger"
Perlu untuk menghasilkan dua majelis per hari secara stabil dan tanpa kesalahan. Kami memiliki Vasya, ia melakukannya dengan tenang, dan tidak ada seorang pun selain dia yang menghabiskan waktu ini.
- Tingkat pabrik
Banyak hal sudah berjalan jauh. Anda membutuhkan 20 kebaktian per hari, Vasya tidak bisa mengatasinya, dan sekarang tim yang terdiri dari sepuluh orang sudah duduk. Mereka memiliki bos, rencana, liburan, cuti sakit, motivasi, pembangunan tim, pelatihan, tradisi, dan aturan. Ini adalah spesialisasi, pekerjaan mereka harus dipelajari.
Pada tingkat ini, tugas dipisahkan dari pelaksana konkret dan dengan demikian berubah menjadi sebuah proses.
Hasilnya akan menjadi deskripsi yang jelas, dikerjakan, dijalankan dan dikoreksi ratusan kali dari proses dengan teks.
- Tingkat "produksi otomatis"
Persyaratan modern untuk majelis tumbuh: semuanya harus cepat, dapat diandalkan, 800 majelis harus disediakan per hari. Ini penting, karena tanpa volume seperti itu perusahaan akan kehilangan keunggulan kompetitif.
Otomasi yang mahal sedang berlangsung, dan beberapa DevOps yang memenuhi syarat dapat menjaga proses tetap berjalan. Penskalaan lebih lanjut tidak lagi menjadi masalah.
Tidak setiap tugas harus mencapai tahap terakhir otomatisasi.
Seringkali satu pengrajin dengan garis perintah akan menyelesaikan masalah dengan mudah dan efektif.
Otomasi “membekukan” proses, mengurangi biaya operasi dan meningkatkan biaya perubahan.
Anda dapat langsung pergi ke perakitan mobil, tetapi sistemnya akan tidak nyaman, tidak akan mengimbangi persyaratan bisnis dan, sebagai hasilnya, akan menjadi usang.
Apa majelis dan mengapa masalahnya tidak diselesaikan oleh sistem perakitan siap pakai
Kami menggunakan klasifikasi berikut untuk menentukan tingkat agregasi perakitan.
L1. Bagian independen kecil dari aplikasi besar. Itu bisa satu komponen, microservice atau satu perpustakaan tambahan. Perakitan L1 adalah solusi untuk masalah teknis linier: kompilasi, pengemasan, bekerja dengan dependensi. Maven, gradle, npm, grunt, dan sistem build lainnya melakukan tugasnya dengan baik. Ada ratusan dari mereka.
Perakitan L1 harus dilakukan menggunakan alat pihak ketiga yang sudah jadi.
L2 +. Entitas Integrasi. Entitas L1 digabungkan ke dalam formasi yang lebih besar, misalnya, ke dalam aplikasi layanan-mikro sepenuhnya. Beberapa aplikasi ini dapat dibundel sebagai solusi tunggal. Kami menggunakan tanda "+", karena tergantung pada tingkat agregasi perakitan, tingkat L3 atau bahkan L4 dapat ditetapkan.
Contoh majelis seperti itu di dunia pihak ketiga adalah persiapan distribusi Linux. Paket meta di sana.
Selain tugas teknis yang cukup rumit (seperti ini: ru.wikipedia.org/wiki/Dependency_hell ). Majelis L2 + sering merupakan produk akhir dan oleh karena itu memiliki banyak persyaratan proses: sistem hak, perbaikan orang yang bertanggung jawab, tidak adanya kesalahan hukum, pasokan berbagai dokumentasi.
Pada L2 +, persyaratan proses diprioritaskan dengan otomatisasi.
Jika solusi otomatis tidak berfungsi karena nyaman bagi orang yang tertarik, itu tidak akan diterapkan.
Majelis L2 + kemungkinan besar akan dilakukan oleh alat berpemilik yang dirancang khusus untuk proses perusahaan. Apakah Anda pikir manajer paket Linux baru saja melakukannya?
Praktik terbaik kami
Infrastruktur
Ketersediaan zat besi secara permanen
Seluruh infrastruktur perakitan terletak di server tertutup di dalam jaringan perusahaan. Dalam beberapa kasus, layanan cloud komersial dimungkinkan.
Otonomi
Di semua proses CI, Internet tidak tersedia. Semua sumber daya yang diperlukan dicerminkan dan di-cache secara internal. Sebagian bahkan github.com (terima kasih, npm!) Sebagian besar masalah ini diselesaikan oleh Artifactory.
Karena itu, kita tenang ketika menghapus artefak dari pakar pusat atau menutup repositori populer. Ada sebuah contoh: community.oracle.com/community/java/javanet-forge-sunset .
Mencerminkan secara signifikan mengurangi waktu perakitan, membebaskan saluran Internet perusahaan. Lebih sedikit sumber daya jaringan yang kritis meningkatkan stabilitas pembangunan.
Tiga repositori untuk setiap jenis artefak
- Dev adalah repositori tempat siapa pun dapat mempublikasikan artefak asal apa pun. Di sini Anda dapat bereksperimen dengan pendekatan baru yang fundamental tanpa mengadaptasinya dengan standar perusahaan sejak hari pertama.
- Staging adalah repositori yang hanya diisi dengan pipa rakitan.
- Rilis - rakitan tunggal, siap untuk pengiriman eksternal. Itu diisi dengan operasi transfer khusus dengan konfirmasi manual.
Aturan 30 hari
Dari repositori Dev dan Staging- kami menghapus semua yang lebih lama dari 30 hari. Ini membantu memastikan setiap orang memiliki peluang penerbitan yang sama dengan menghabiskan ruang disk server yang terbatas.
Rilis disimpan selamanya, pengarsipan dilakukan jika perlu.
Bersihkan lingkungan perakitan
Seringkali setelah rakitan, file tambahan tetap berada dalam sistem, yang dapat memengaruhi proses perakitan lainnya. Contoh umum:
- masalah yang paling umum adalah cache yang rusak oleh satu perakitan yang salah (cara menangani cache, dijelaskan di bawah);
- beberapa utilitas, seperti npm, meninggalkan file layanan di direktori $ HOME yang memengaruhi semua peluncuran selanjutnya dari utilitas ini;
- rakitan tertentu dapat menghabiskan semua ruang disk di beberapa partisi / tmp, yang akan menyebabkan tidak tersedianya lingkungan secara umum.
Oleh karena itu, lebih baik untuk meninggalkan lingkungan terpadu demi wadah buruh pelabuhan. Wadah harus hanya berisi perangkat lunak yang diperlukan untuk perakitan khusus dengan versi tetap.
DevOps menyimpan koleksi gambar buruh pelabuhan perakitan, yang terus diperbarui. Awalnya ada sekitar enam, lalu di bawah 30, lalu kami menyiapkan pembuatan gambar otomatis dari daftar perangkat lunak. Sekarang cukup tentukan persyaratan seperti membutuhkan ('maven 3.3.9', 'python') - dan lingkungan sudah siap.
Diagnosis diri
Tidak hanya perlu mengatur dukungan pengguna untuk permintaan, kita juga harus menganalisis perilaku sistem kita sendiri. Kami terus mengumpulkan log, mencari kata kunci yang menunjukkan masalah.
Pada sistem "langsung", cukup menulis 20-30 ekspresi reguler sehingga untuk setiap majelis Anda dapat memberi tahu alasan penurunannya di level:
- Git server crash
- ruang disk telah habis di sana;
- membangun kesalahan karena kesalahan pengembang;
- Bug yang dikenal di Docker.
Jika ada sesuatu yang jatuh, tetapi tidak ada satu pun masalah yang diketahui telah terdeteksi, ini adalah kesempatan untuk mengisi kembali koleksi topeng.
Lalu kami pergi ke pengguna dan mengatakan bahwa ia memiliki build dan ini dapat diperbaiki dengan cara ini.
Anda akan terkejut betapa banyak masalah yang tidak dilaporkan pengguna dalam mendukung. Lebih baik memperbaikinya terlebih dahulu dan pada waktu yang tepat. Seringkali, kesalahan publikasi kecil diabaikan selama dua minggu, dan pada Jumat malam ternyata ini memblokir output eksternal.
Kami dengan hati-hati memilih sistem yang tergantung pada perakitan
Idealnya, secara umum, memastikan otonomi penuh majelis, tetapi paling sering ini tidak mungkin. Untuk majelis berbasis java, Anda memerlukan setidaknya Artifactory untuk mirroring - lihat di atas untuk otonomi. Setiap sistem terintegrasi meningkatkan risiko kegagalan. Sangat diharapkan bahwa semua sistem bekerja dalam mode HA yang layak.
Antarmuka jalur perakitan
Antarmuka tunggal untuk memanggil rakitan
Kami membuat segala jenis perakitan dengan satu sistem. Sidang dari semua tingkatan (L1, L2 +) dijelaskan oleh kode program dan dipanggil melalui satu pekerjaan Jenkins.
Namun, pendekatan ini tidak ideal. Lebih baik menggunakan mekanisme pembangkitan otomatis pekerjaan Jenkins: misalnya, 1 pekerjaan = 1 repositori git atau 1 pekerjaan = 1 cabang git. Ini akan mencapai yang berikut:
- log dari majelis heterogen tidak bingung dalam satu cerita di halaman kerja Jenkins;
- pada kenyataannya, Anda mendapatkan pekerjaan yang dialokasikan dengan nyaman untuk tim atau untuk pengembang; perasaan nyaman dapat ditingkatkan dengan menyesuaikan grafik dari hasil junit, cobertura, sonar.
Kebebasan memilih teknologi
Memulai build adalah panggilan ke skrip bash “./build.sh”. Dan kemudian - sistem rakitan, bahasa pemrograman, dan semua hal lain yang diperlukan untuk menyelesaikan tugas bisnis. Ini memberikan pendekatan untuk perakitan sebagai kotak hitam.
Pos cerdas
Jalur perakitan memotong publikasi dari kotak hitam dan menempatkannya di penyimpanan perusahaan. Untuk ini, masalah yang membosankan seperti menghasilkan nama gambar buruh pelabuhan dan memilih repositori yang tepat untuk publikasi secara otomatis diselesaikan.
Pementasan dan rilis repositori selalu ada pesanan. Diperlukan untuk mendukung publikasi spesifik dari berbagai jenis: pakar, npm, file, buruh pelabuhan.
Deskriptor majelis
Build.sh menjelaskan cara mengkompilasi kode, tetapi ini tidak cukup untuk wadah perakitan.
Anda juga harus tahu:
- lingkungan perakitan apa yang digunakan;
- variabel lingkungan tersedia di build.sh;
- publikasi apa yang akan dilakukan;
- opsi spesifik lainnya.
Kami telah memilih cara yang mudah untuk menggambarkan informasi ini dalam bentuk file yaml yang menyerupai .gitlab-ci.yaml.
Parameterisasi perakitan
Pengguna dapat menentukan parameter arbitrer tanpa menjalankan perintah git commit tepat di awal perakitan.
Kami telah menerapkan ini dengan mendefinisikan variabel lingkungan langsung dari antarmuka kerja Jenkins.
Misalnya, kami mentransfer versi pustaka dependen ke parameter perakitan seperti itu dan, dalam beberapa kasus, mendefinisikan kembali versi ini ke versi eksperimental. Tanpa mekanisme seperti itu, pengguna harus menjalankan perintah "git commit" setiap kali.
Portabilitas sistem
Anda harus dapat mereproduksi proses perakitan tidak hanya di server CI utama, tetapi juga di komputer pengembang. Ini membantu dalam men-debug skrip pembuatan yang rumit. Selain itu, daripada Jenkins, terkadang akan lebih mudah menggunakan Gitlab CI. Oleh karena itu, sistem build haruslah aplikasi java yang independen. Kami menerapkannya sebagai plugin gradle.
Satu artefak dapat diterbitkan dengan nama yang berbeda.
Ada dua persyaratan yang berlawanan untuk publikasi yang dapat muncul secara bersamaan.
Di satu sisi, untuk penyimpanan jangka panjang dan manajemen pelepasan, perlu untuk memastikan keunikan nama-nama artefak yang diterbitkan. Setidaknya ini akan melindungi artefak agar tidak ditimpa.
Di sisi lain, kadang-kadang nyaman untuk memiliki satu artefak yang sebenarnya dengan nama tetap seperti terbaru. Misalnya, pengembang tidak perlu mengetahui versi pasti dari ketergantungan setiap kali, Anda hanya bisa bekerja dengan yang terbaru.
Artefak dalam kasus ini diterbitkan dengan dua atau lebih nama, karena cocok untuk semua orang.
Sebagai contoh:
- nama unik dengan cap waktu atau UUID - untuk mereka yang membutuhkan akurasi;
- nama "terbaru" - untuk pengembang mereka, yang selalu mengambil kode terbaru;
- nama "<versi utama> .x-latest" adalah untuk tim tetangga yang siap untuk mengambil versi terbaru, tetapi hanya dalam kerangka utama tertentu.
Maven melakukan sesuatu yang serupa dalam pendekatannya ke SNAPSHOT.
Kurang pembatasan keamanan
Semua orang dapat memulai perakitan. Ini tidak akan membahayakan siapa pun, karena majelis hanya menciptakan artefak.
Kepatuhan Hukum
Kontrol interaksi eksternal dari proses perakitan
Majelis tidak dapat menggunakan apa pun yang dilarang dalam proses kerjanya.
Untuk ini, perekaman lalu lintas jaringan dan akses ke cache file diimplementasikan. Kami mendapatkan log aktivitas jaringan perakitan dalam bentuk daftar url dengan hash256 hash data yang diterima. Selanjutnya, setiap url divalidasi:
- daftar putih statis;
- database dinamis artefak yang diizinkan (misalnya, untuk dependensi maven-, rpm-, npm-). Setiap kecanduan dipertimbangkan secara individual. Izin otomatis atau larangan penggunaan mungkin berhasil, dan diskusi panjang dengan pengacara juga dapat dimulai.
Konten transparan artefak yang diterbitkan
Kadang-kadang tugasnya adalah menyediakan daftar perangkat lunak pihak ketiga di dalam perakitan apa pun. Untuk melakukan ini, mereka membuat penganalisa komposisi sederhana yang menganalisis semua file dan arsip dalam majelis, mengenali pihak ketiga dengan hash dan membuat laporan.
Kode sumber yang dikeluarkan tidak dapat dihapus dari GIT
Terkadang Anda mungkin perlu menemukan kode sumber dengan melihat artefak biner yang dikompilasi dua tahun lalu. Untuk melakukan ini, perlu untuk mengalokasikan tag di Git secara otomatis dengan output eksternal, serta melarang penghapusannya.
Logistik dan Akuntansi
Semua majelis disimpan dalam database.
Kami menggunakan repositori file di Artifactory untuk tujuan ini. Ini berisi semua informasi pendukung: siapa yang meluncurkannya, apa hasil pemeriksaannya, artefak apa yang diterbitkan, hash git mana yang digunakan, dll.
Kami tahu cara mereproduksi perakitan seakurat mungkin
Menurut hasil majelis, kami menyimpan informasi berikut:
- keadaan pasti kode yang dikumpulkan;
- dengan parameter apa peluncuran dilakukan;
- perintah apa yang disebut;
- apa akses ke sumber daya eksternal terjadi;
- lingkungan perakitan bekas.
Jika perlu, kita dapat secara akurat menjawab pertanyaan tentang bagaimana itu dikumpulkan.
Komunikasi dua arah perakitan dengan tiket JIRA
Pastikan Anda dapat memecahkan masalah berikut:
- untuk perakitan, buat daftar tiket JIRA yang termasuk di dalamnya;
- tuliskan di tiket JIRA majelis mana yang termasuk di dalamnya.
Komunikasi dua arah yang ketat antara majelis dan komit git disediakan. Dan kemudian dari teks komentar Anda sudah bisa mengetahui tentang semua tautan ke JIRA.
Kecepatan
Tembolok sistem perakitan
Tidak adanya cache maven dapat meningkatkan waktu pembuatan satu jam.
Cache melanggar isolasi lingkungan rakitan dan kebersihan rakitan. Masalah ini dapat diselesaikan dengan menentukan asalnya untuk setiap artefak yang di-cache. Kami memiliki masing-masing file cache yang dikaitkan dengan tautan https dari mana file itu pernah diunduh. Selanjutnya kami memproses pembacaan cache sebagai alamat jaringan.
Tembolok Sumber Daya Jaringan
Pertumbuhan geografis perusahaan mengarah pada kebutuhan untuk mentransfer file 300 MB antar benua. Banyak waktu dihabiskan, terutama jika Anda harus sering melakukan ini.
Git repositori, gambar buruh pelabuhan dari lingkungan perakitan, penyimpanan file - semuanya harus di-cache dengan hati-hati. Yah, tentu saja, bersih secara berkala.
Perakitan - secepat mungkin, yang lainnya - lalu
Tahap pertama: kami melakukan perakitan dan segera, tanpa gerakan yang tidak perlu, kami memberikan hasilnya.
Tahap kedua: validasi, analisis, akuntansi dan birokrasi lainnya. Ini dapat dilakukan sudah dalam pekerjaan Jenkins yang terpisah dan tanpa batas waktu yang ketat.
Apa hasilnya
- Hal utama adalah bahwa perakitan menjadi jelas bagi pengembang , mereka sendiri dapat mengembangkan dan mengoptimalkannya.
- Yayasan ini telah dibuat untuk membangun proses bisnis yang bergantung pada perakitan: instalasi, manajemen masalah, pengujian, manajemen rilis, dll.
- Tim DevOps tidak lagi menulis skrip perakitan: pengembang melakukannya.
- Persyaratan perusahaan yang kompleks berubah menjadi laporan transparan dengan daftar cek terakhir.
- Siapa pun dapat membangun repositori apa pun hanya dengan memanggil build.sh melalui satu antarmuka. Cukup baginya untuk menentukan koordinat git dari kode sumber. Orang ini bisa menjadi manajer tim, insinyur QA / IT, dll.
Dan beberapa angka
- . 15 Jenkins job build.sh. 15 docker-, , . . .
- . . 2200 . — on-commit-.
- 300 git-, .
- 30 , (25 ) — docker.
- , :
- glide, golang, promu;
- maven, gradle;
- python & pip;
- ruby;
- nodejs & npm;
- docker;
- rpm build tools & gcc;
- Android ADT;
- ;
- legacy-;
- .