Get best of the week

Kubernetes, Microservices, CI / CD dan Dockers untuk Retrogrades: Tips Belajar

Tampaknya topik "mengapa kita membutuhkan Kubernetes" sudah menjengkelkan. Saya ingin mengatakan: "semua orang yang membutuhkannya telah lama memahami", tetapi saya akan membagi pekerja teknis (dan hampir teknis) menjadi mereka yang "mengerti dan tahu cara menggunakan", dan mereka yang "mengerti, tetapi ingin tahu bagaimana membuat pengetahuan yang relevan ".

Mungkin Anda adalah seorang manajer yang telah mengerjakan tumpukan yang sama selama 10 tahun terakhir; Anda mungkin seorang pengembang yang mendukung solusi lama atau menulis dalam bahasa yang akrab di lingkungan yang akrab. Mungkin Anda baru saja beralih dari manajemen teknis ke manajemen organisasi dan tiba-tiba menemukan bahwa semua yang Anda tahu sudah tidak relevan lagi, dan saya ingin memahami apakah ada skenario yang relatif sederhana tentang bagaimana hal ini dapat dilakukan. Saya akan mencoba memberikan saran berdasarkan pengalaman saya sendiri - dari seseorang yang menyadari bahwa berada dalam manajemen organisasi akan segera diungkapkan oleh kata-kata "Kubernetes adalah teknologi yang efektif, kita harus berusaha untuk penerapannya", tidak sepenuhnya memahami apa yang ada di balik dengan kata-kata ini dan di balik semua budaya teknis yang telah berkembang baru-baru ini.

Mengapa saya merasa penting untuk dapat mengubah paradigma pemikiran teknologi?

Hal yang paling sulit bagi mereka yang telah bekerja dalam teknologi untuk waktu yang lama adalah menerima bahwa tren baru telah menjadi permanen. Lebih dari 20 tahun bekerja, saya melihat bagaimana berbagai teknologi datang dan pergi, dan beberapa di antaranya "sangat relevan" selama beberapa bulan.

Saya membaca Joel Spolsky tentang bagaimana Microsoft secara sistematis menciptakan tumpukan baru untuk pengembang untuk mencegah mereka melihat sesuatu yang lain. Seperti SRE, saya takut dua kali lipat terhadap setiap teknologi baru: semua yang baru adalah mentah, semuanya mentah tidak stabil. Semua yang tidak stabil akan menyebabkan masalah dalam produksi, dan stabilitas produksi adalah hal utama.

Sebagai seorang programmer dan pengusaha, saya ingin membuat produk lebih cepat - saya perlu mempelajari segala sesuatu yang baru, mengubah pendekatan yang biasa, yang berarti - meluncurkan fitur lebih lambat. Jika beberapa teknologi baru diadopsi dengan cepat, maka segala sesuatu yang berkaitan dengan pengembangan berorientasi layanan-mikro (sebut saja seluruh tumpukan modern) perlu diajarkan. Dan setiap tahun untuk belajar lebih lama; jauh lebih mudah untuk menulis dengan cara yang sudah dikenal lama dan mengirimkan produk lebih cepat.

Namun faktanya tetap ada: terkadang teknologi baru tetap ada dan mengubah keseluruhan paradigma. Dan di sini muncul pilihan: untuk tetap dalam paradigma lama atau pindah ke paradigma baru. Cobol-programmer masih bisa mendapatkan pekerjaan, perl-pengembang ingat tentang pemesanan, tetapi cara-cara alternatif untuk orang-orang ini menjadi semakin berkurang. Dan kemudian "kemunduran" atas nama stabilitas menjadi batasan. Dengan seluruh tumpukan modern, jika Anda tidak ingin membatasi diri, waktunya bukan apa yang telah terjadi, tetapi kita sudah ketinggalan. Dan, jika kita tidak ingin terjebak dalam perl, kita perlu belajar. Butuh waktu lama. Saya akan mencoba menceritakan pengalaman saya selangkah demi selangkah dalam belajar.

Petunjuk selam


Memahami cara menjalankan aplikasi di buruh pelabuhan. Pertama-tama, veteran harus memahami bahwa cara untuk "menyimpan" dan "meluncurkan" aplikasi telah berubah selamanya. Kemungkinan besar, seorang pengembang yang telah belajar untuk mengembangkan dalam beberapa tahun terakhir tidak tahu cara menjalankan aplikasi dalam produksi tanpa buruh pelabuhan. Kepala pengembang semacam itu mungkin tidak memiliki konsep "menyimpan file secara lokal", kecuali untuk kasus penyimpanan bersama yang jarang, tetapi hal utama yang perlu dipahami oleh "veteran" adalah: buruh pelabuhan adalah alat baru. Format exe mungkin memiliki kekurangannya, tetapi tidak ada yang benar-benar memikirkannya.

Ya, pendekatan layanan mikro telah menjadi standar. Begitu OOP muncul untuk memudahkan tim besar untuk menulis perangkat lunak besar; sekarang layanan microser telah menjadi standar yang sama. Mereka bahkan dibudidayakan oleh orang yang sama (lihat Fowler) Ini masuk akal: jika API aplikasi versi, lebih mudah bagi masing-masing tim untuk menulis aplikasi yang berdiri sendiri daripada yang besar. Mengapa menulis aplikasi microservice kecil, Anda dapat berdebat, tetapi pada titik tertentu mereka semua mulai menulisnya dalam gaya OOP - begitu akrab (lihat di atas tentang exe). Ada banyak yang berpendapat bahwa komunikasi antarproses (terutama yang dibangun di atas tumpukan TCP) memiliki sejuta kekurangan kinerja (satu layanan akan pergi ke yang lain melalui TCP alih-alih hanya membuat panggilan assembler - Anda dapat membayangkan apa perbedaannya dalam produktivitas?), tetapi faktanya tetap bahwa layanan microser memiliki kelebihan dalam mengembangkan proyek menengah dan besar, dan mereka juga telah menjadi standar. Memahami bagaimana microservices berinteraksi satu sama lain (HTTP API, grpc,interaksi asinkron melalui antrian - sejuta cara), sebagai bonus - pahami apa itu mesh layanan. (Sesaat humor yang marah: Ya ampun, teman-teman, mereka datang dengan ide berbagi aplikasi, dan ternyata komunikasi antara aplikasi yang terbagi adalah lelucon yang sulit, jadi mereka menambahkan lapisan lain untuk memudahkan kengerian interproses, untuk apa ini bagi kita?)

, .Jadi, kami berdamai bahwa kami sekarang meluncurkan aplikasi di buruh pelabuhan dan bahwa kami membagikan aplikasi ke layanan microser. Sekarang kita perlu entah bagaimana mengelola buruh pelabuhan yang sedang beroperasi. Anda dapat melakukannya sendiri di server khusus (dan mengarahkan, misalnya, Docker Swarm, atau membangun Kubernetes), atau Anda dapat menggunakan layanan yang cloud berikan - layanan kontainer dari AWS atau Kubernetes. Ada satu keuntungan yang sangat besar untuk menggunakan cloud. Anda, pada kenyataannya, berhenti berpikir tentang lapisan yang berjalan di bawah pengelola wadah (SRE akan tertawa sekarang, tapi mari kita akui - ketika semuanya stabil, kami tidak memanjat node GKE dalam banyak kasus). Jadi, pada kenyataannya, manajer kontainer, yang menjadi standar Kubernetes, berubah menjadi sistem operasi. Ini memiliki manajer paket, Anda dapat "menginstal perangkat lunak" ke dalamnya, Anda dapat menjalankan "exe-shniki" di dalamnya - buruh pelabuhan,memiliki kronjoby. Kubernetes adalah OS baru.

Memahami bagaimana kontainer buruh pelabuhan akan dikirim. Tata letak situs sederhana sekarang membutuhkan waktu 5 menit, dan orang menganggap ini sebagai norma. Kita perlu mengumpulkan buruh pelabuhan, mengujinya, memasukkannya ke dalam registri dan meletakkannya di pengelola buruh pelabuhan (mari kita bicara lebih banyak tentang Kubernetes). Ini adalah kebiadaban (?) Bahwa semua orang terbiasa, itu dioptimalkan dan ini adalah standar. Sistem CI / CD telah menjadi tata letak standar, dan mereka perlu ditangani. Sama seperti dengan GitOps.

Memahami bahwa hosting on-premise untuk sebagian besar aplikasi akan menjadi sesuatu dari masa lalu (di Barat - sudah hilang).Sekali waktu, itu adalah norma untuk membeli server, merakit mereka, membawanya ke DC, memasukkan colocation dan beralih. Bahkan untuk proyek kecil. Kemudian datang server khusus. Berapa banyak orang sekarang berpikir untuk menyiksa, membeli dan mengumpulkan besi pada proyek-proyek kecil dan menengah? Didedikasikan - di Barat sekarang, dan di Federasi Rusia segera - akan digantikan oleh awan. Ini telah dibicarakan selama seratus tahun, saya telah menggunakan AWS sejak 2008, dan memiliki masalah, tetapi ketika kita berbicara tentang layanan yang mengambil alih pengelolaan Kubernet (EKS, GKE, Kubernet dari Yandex atau Selectel), saya tidak mengerti mengapa harus mengelola Kubernetes dan Dediks sendiri, jika orang lain melakukannya? Saya tidak lagi mengganti pendingin di Dediks ... Pertanyaan tentang prevalensi distribusi Kubernet di Federasi Rusia adalah masalah nilai tukar dolar,UU Persdans dan "Pemuda" hosting cloud Rusia. Cepat atau lambat, ini akan diputuskan dan di tempat akan menjadi keliaran yang diinginkan perusahaan dan proyek-proyek besar yang dimuat. Dengan basis yang sama. Jika kita berbicara tentang sebagian besar aplikasi yang tidak memerlukan beban super tinggi atau penyetelan yang sangat kuat, maka PostreSQL / MongoDB / MySQL berbasis cloud memberikan sejumlah besar keuntungan. Tidak perlu memikirkan penyetelan, tidak perlu memikirkan pencadangan. Buat server dev dari server produksi - beberapa perintah di konsol cloud. Saya mengerti bahwa seluruh gagasan ini dapat menyebabkan kemarahan pada admin: kawan, saya sendiri admin, tetapi untuk sebagian besar tugas yang tidak buruk, manajemen basis data, bagaimanapun, tidak diperlukan. AWS dan GKE mungkin mahal dan tidak dapat diakses oleh kami karena hukum Persia, tetapi ini hanya waktu tambahan untuk tertinggal: cepat atau lambat, Yandex atau Selectel akan memiliki fitur yang sama,dan paradigma akan berubah.

Memahami infrastruktur apa yang sekarang ditulis. Saya tidak suka IaaC ketika dia adalah Chef dan Wayang, tetapi, alhamdulillah, mereka digantikan oleh Terraform dan Pulumi yang lebih memadai untuk menggambarkan apa yang ingin Anda tingkatkan di kluster, dan Dimungkinkan untuk bekerja di dalam. Masuk dan letakkan sesuatu di shell - sekarang kebiadaban mutlak. Ya, ini lebih cepat dan lebih nyaman, tetapi dalam paradigma baru itu keliaran: ingat tentang exe.

Kursus menyelam dalam


Bagaimana cara melihat cara teknis tertentu untuk memahami cara bekerja dengan tumpukan modern?

1) Buat akun percobaan di cloud hosting. Semua penyedia hosting menyediakannya. Saya mulai dengan GKE, tetapi Anda dapat, misalnya, mengambil akun di layanan hosting Rusia, jika Anda berharap bahwa Anda akan bekerja, kemungkinan besar, di wilayah ini.
Jika Terraform / Pulumi mendukung cloud Anda, jelaskan infrastruktur yang ingin Anda buat di dalamnya. Jika Anda memiliki keterampilan pemrograman, saya sarankan Pulumi: alih-alih Terraform SDL Anda sendiri, Anda dapat menulis dalam bahasa dan konstruksi yang sudah dikenal.

2) Temukan aplikasi dan kemas dalam docker. Apa yang ada untuk berkemas - pilihan ada di tangan Anda. Saya tiba-tiba menemukan sendiri bagaimana NodeJS menjadi tersebar luas, dan memutuskan untuk mengambil studi mendalam tentang operasinya, jadi saya terus bekerja dengan node tersebut. Di sini, misalnya, adalah sebuah blog di NodeJS , yang dapat dimunculkan, tetapi secara umum semuanya tergantung pada kebijaksanaan Anda.

3) Berurusan dengan konstruksi dasar (untuk, penyebaran, layanan) K8S dan gunakan aplikasi dengan tangan Anda di kluster K8S.

4) Berurusan dengan Helm, tulis grafik Helm, gunakan aplikasi Helm.
Ambil paket gratis di CircleCI sebagai CI-ke, yang tidak perlu diatur, dan konfigurasikan: konfigurasi akan mirip dengan sistem lain.

5) Perbaiki aplikasi melalui CI-ku.
Pisahkan CI (apa yang dibangun aplikasi) dan CD. Buat CD dengan GitOps (lihat, misalnya, ArgoCD).

Apa berikutnya


Di suatu tempat mulai sekarang, Anda, pada prinsipnya, akan menyadari basis utama dari tumpukan modern.
Di mana saya bisa menggali lebih jauh?

  • Jika Anda mencari pekerjaan / ingin bekerja di Barat, Anda dapat pergi ke pengetahuan yang lebih dalam tentang komputasi awan: kirimkan sertifikat Google atau setara dari AWS ke Cloud Architect (kami baru-baru ini menerima 3 sertifikat semacam itu di ITSumma ). Ini akan memberikan gambaran tentang fitur yang memberi Cloud, dan membantu mereka menavigasi. Kursus yang bagus di linuxacademy .
  • Serahkan ke CKA: ini adalah topik yang sulit, tetapi tidak sia-sia. Persiapan ujian akan memberikan paket besar pengetahuan.
  • Belajar memprogram jika Anda tidak tahu caranya. Sekarang saya pergi untuk mempelajari bagian depan dan kagum pada bagaimana semuanya telah berubah. Pengetahuan saya berakhir di suatu tempat di 2012 atau bahkan lebih awal, kembali di jQuery, orang-orang tertawa. Bagian depan sekarang menjadi lebih rumit daripada bagian belakang, ada sejumlah besar logika aplikasi dan pada saat yang sama paradigma yang sama sekali tidak biasa bagi saya. Sangat menarik!

Dan saya sedikit lebih biasa daripada blog di sini, saya menyimpan saluran telegram saya , berlangganan :-)

More articles:


All Articles