👩‍⚕️ 😸 👇 "Docker sudah mati" atau apa pun yang ingin Anda ketahui tentang Devops tetapi takut untuk bertanya 👩‍🚀 🙅🏾 🙂

Baru-baru ini, Alexander Chistyakov, DevOps dengan 7 tahun pengalaman dan salah satu pendiri Komunitas Insinyur DevOps St. Petersburg, berbicara di jejaring sosial kami.

Sasha adalah salah satu pembicara terbaik di bidang ini, dia tampil di panggung utama di Highload ++, RIT ++, PiterPy, Strike, membuat total setidaknya 100 laporan. Senin lalu dia menjawab pertanyaan dari pemirsa dan berbicara tentang pengalamannya.

Kami membagikan rekaman dan transkrip siaran.

Nama saya Alexander Chistyakov, saya telah bekerja sebagai insinyur DevOps selama bertahun-tahun. Saya telah lama menasihati berbagai perusahaan tentang penerapan praktik DevOps, menggunakan alat DevOps modern dan mengatur infrastruktur sehingga kita semua dapat tidur nyenyak di malam hari, dan orang-orang terus menerima uang untuk barang dan layanan mereka.

Pada dasarnya saya berkonsultasi dengan perusahaan asing.

Kami akan berbicara tentang bagaimana orang-orang menggunakan Kubernetes dalam praktik sehari-hari, mengapa itu diperlukan, mengapa Anda tidak perlu takut, apa yang harus Anda perhatikan dan apa yang akan terjadi selanjutnya.

Saya pikir para sysadmin, insinyur DevOps, CIO, dan spesialis lain yang terlibat dalam manajemen infrastruktur (dan simpatisan) akan merasakan manfaatnya.

Bagaimana lanskap ini berkembang? Saya ingat komputer dengan ROM Basic diinstal dan dimungkinkan untuk menulis program tanpa OS diinstal. Banyak air mengalir di bawah jembatan sejak itu. Pada awalnya, tidak ada OS seperti itu (lebih tepatnya, ditulis dalam assembler). Kemudian bahasa C muncul dan situasinya meningkat secara dramatis. Tentu saja, sekarang kita semua sudah familiar dengan konsep OS: ini adalah platform yang memungkinkan kita menjalankan aplikasi kustom dan mengelola sumber daya yang kita miliki di komputer ini. Atau yang lainnya, jika didistribusikan. Meskipun demikian, kluster komputasi berperforma tinggi masih dapat dirakit dari laptop dan desktop Anda - inilah yang dilakukan para siswa di asrama Universitas Politeknik St. Petersburg pada tahun 1997.

Kemudian ternyata - saya mungkin membaca artikel ini 10 tahun yang lalu - bahwa Google, yang menemukan email web, sedang membangun sistem operasi di sekitar email web ini sehingga pengguna dapat menggunakannya dari tablet dan ponsel. Ini tidak terduga, biasanya sistem operasi adalah sesuatu yang menjalankan binari, dan ketika Anda melihat aplikasi melalui browser, Anda bahkan tidak tahu apakah biner itu ada. Anda dapat membaca email, mengobrol di messenger online, menggambar slide, dan mengedit dokumen bersama-sama. Ternyata ini cocok untuk banyak orang.

Benar, Google tidak terlalu konsisten dan membuat banyak produk yang tidak diperlukan dan tidak melampaui prototipe - misalnya, Google Wave. Nah, ini adalah kebijakan perusahaan besar mana pun - bergerak cepat, sering mogok, hingga perusahaan itu tidak ada lagi.

Namun demikian, dalam kesadaran massa telah terjadi pergeseran ke arah gagasan OS sebagai platform yang tidak menyediakan layanan yang pernah disetujui oleh beberapa komite pengaturan standar dan ditugaskan untuk itu, tetapi hanya memenuhi kebutuhan pengguna. Apa kebutuhan ini?

Dulu sudah menjadi kebiasaan untuk bertanya kepada pengembang tentang apa yang dia tulis. Ada spesialis C ++ (mungkin, dan sekarang ada di suatu tempat), sekarang ada banyak spesialis PHP (terkadang mereka menertawakan diri mereka sendiri) dan banyak pengembang JavaScript. Ketikan, bahasa GoLang yang orang-orang dengan pengetahuan PHP telah beralih ke, sekarang mendapatkan popularitas. Ada bahasa Perl (mungkin masih tersisa, tetapi telah kehilangan banyak popularitas), bahasa Ruby. Secara umum, aplikasi bisa ditulis dalam bentuk apapun. Jika Anda tinggal di dunia nyata, Anda mungkin pernah menemukan fakta bahwa mereka ditulis dalam segala hal: Javascript, Rust, C; munculkan nama - ada sesuatu yang tertulis di atasnya.

Dan semua ini harus dieksploitasi. Ternyata dalam sistem yang heterogen ini, pertama-tama, diperlukan spesialis untuk mengembangkan dalam berbagai bahasa, dan, kedua, diperlukan platform yang memungkinkan Anda meluncurkan layanan di lingkungan yang menyenangkan dan memantau siklus hidupnya. Ada kontrak tertentu dengan platform ini, yang di dunia modern terlihat seperti ini: Anda memiliki gambar kontainer (sistem manajemen kontainer sekarang ada di mana-mana - Docker, meskipun saya tidak bisa mengatakan hal yang baik tentang itu; kita akan membicarakan masalah nanti).

Terlepas dari kenyataan bahwa umat manusia sedang bergerak dalam proses evolusi tertentu, proses ini memiliki konvergensi. Dalam industri kami, ternyata seseorang masih menulis kode di Perl (di bawah mod_perl Apache), dan seseorang sudah menulis arsitektur layanan mikro di GoLang. Ternyata kontrak dengan platform sangat penting, konten platform sangat penting, dan sangat penting bahwa platform membantu seseorang. Menjadi sangat mahal untuk melakukan operasi manual untuk menyelesaikan dan memulai layanan. Saya telah menemukan proyek di mana terdapat 20 layanan - dan itu bukanlah proyek yang sangat besar; Saya pernah mendengar tentang orang-orang yang memiliki seribu layanan berbeda. 20 adalah jumlah normal; dan setiap rangkaian layanan dikembangkan oleh timnya sendiri dalam bahasanya sendiri, mereka hanya terhubung oleh protokol pertukaran.

Berkenaan dengan cara kerja kontrak untuk aplikasi tersebut. Ada "manifesto aplikasi 12 faktor" - 12 aturan tentang bagaimana aplikasi harus diatur agar nyaman digunakan. Aku tidak menyukainya. Secara khusus, dikatakan bahwa Anda perlu mengirimkan konfigurasi melalui variabel lingkungan; dan saya telah berulang kali menemukan fakta bahwa di Amazon, misalnya, jumlah variabel lingkungan yang dapat diteruskan ke Elastic Beanstalk adalah satu halaman dari kernel Linux - 4 kilobyte. Dan mereka meluap dengan sangat cepat; ketika Anda memiliki 80 variabel yang berbeda, 81 sulit untuk diterapkan. Selain itu, ini adalah ruang konfigurasi datar - jika ada variabel, variabel harus diberi nama dengan huruf kapital dengan garis bawah, dan tidak ada hierarki di antara variabel tersebut; sulit untuk memahami apa yang sedang terjadi. Saya belum menemukan cara untuk mengatasinya, dan saya tidak punya siapa-siapa untuk membahasnya - tidak ada kelompok penggemar,siapa yang akan menentang pendekatan seperti itu. Jika ini tiba-tiba juga tidak cocok untuk seseorang - tulis kepada saya (demeliorator di Telegram), saya akan tahu bahwa saya tidak sendiri. Saya sama sekali tidak menyukainya. Sulit untuk mengelola, sulit untuk mentransfer data hierarkis; ternyata tugas seorang insinyur modern adalah untuk mengetahui di mana variabel-variabel itu, apa artinya, apakah mereka telah diatur dengan benar, betapa mudahnya untuk mengubahnya. Menurut saya, aturan konfigurasi lama yang baik lebih baik.apakah mereka telah diatur dengan benar, betapa mudahnya untuk mengubahnya. Saya pikir aturan konfigurasi lama yang baik lebih baik.apakah mereka telah diatur dengan benar, betapa mudahnya untuk mengubahnya. Menurut saya, aturan konfigurasi lama yang baik lebih baik.

Kembali ke kontrak. Ternyata Anda membutuhkan Gambar Docker: Anda akan membutuhkan Docker itu sendiri (meskipun faktanya itu sendiri buruk - saya harap beberapa Microsoft akan membelinya dan mengubur atau mengembangkannya secara normal). Jika Anda tidak senang dengan Docker, Anda dapat mencoba Stack Red Hat; Saya tidak bisa mengatakan apa-apa tentang itu, meskipun menurut saya itu lebih baik dari sekedar vanilla Kubernetes. Orang-orang dari Red Hat lebih memperhatikan masalah keamanan, mereka bahkan tahu bagaimana melakukan instalasi multi-turn, multi-pengguna, multi-klien, dengan pemisahan hak yang normal - secara umum, mereka memastikan bahwa manajemen hak sudah ada.

Mari kita bahas masalah keamanan. Itu buruk dengannya di mana-mana, tidak hanya di Kubernetes. Jika kita berbicara tentang masalah keamanan dan orkestrasi kontainer, saya memiliki harapan besar untuk perakitan web, yang dilakukan oleh sisi server, dan untuk aplikasi perakitan web dimungkinkan untuk membatasi konsumsi sumber daya, panggilan sistem dapat diikat dalam wadah khusus, di Rust. Ini akan menjadi jawaban yang bagus untuk pertanyaan keamanan. Dan Kubernetes tidak memiliki keamanan.

Katakanlah kita memiliki aplikasi. Ini adalah image Docker, dengan 12 faktor - yaitu, konfigurasi Anda dapat diambil dari variabel lingkungan, dari file yang Anda pasang di dalam container. Ini dapat diluncurkan - di dalamnya mandiri, Anda dapat mencoba menautkannya dengan aplikasi lain melalui konfigurasi, secara otomatis. Dan itu harus menulis log ke keluaran standar - yang mungkin paling jahat; ketika penampung menulis log ke file, tidak mudah untuk mengumpulkannya dari sana. Bahkan Nginx telah ditambal sehingga dimungkinkan untuk mengumpulkan log dari output standar kontainer, ini dapat diterima (sebagai lawan meneruskan konfigurasi melalui parameter). Sebenarnya, kami dulu memiliki beberapa orkestra: Peternak, Marathon Mesos, Nomad; tetapi, seperti yang dikatakan prinsip Anna Karenina terkait dengan sistem teknis,sistem teknis yang kompleks diatur dengan cara yang sama.

Dengan Kubernetes, kami memiliki situasi yang sama dengan maskapai penerbangan dengan Boeing 737 MAX - tidak terbang, karena ada kesalahan di dalamnya, tetapi tidak ada yang lain, karena desainnya sangat kompleks. Saya tidak bisa mengatakan bahwa saya menyukainya - seperti bahasa GoLang, dan mengontrol melalui format YAML, ketika Anda memiliki beberapa sintaks, dan tidak ada apa-apa di atasnya - tidak ada pemeriksaan pada apa yang Anda tulis, tidak ada tipe data. Semua pemeriksaan yang Anda lakukan sebelum menerapkan konfigurasi di Kubernetes adalah dasar. Anda dapat mencoba menerapkan konfigurasi yang salah dan itu akan berlaku tanpa pertanyaan dan Anda tidak tahu apa. Sangat mudah untuk menulis file konfigurasi yang salah. Ini adalah masalah besar, dan orang-orang sudah mulai menyelesaikannya secara perlahan menggunakan DSL dan Kubernetes dalam bahasa Kotlin, bahkan Typecript. Ada proyek Pulumi seperti itu,ada proyek Amazon EKS - meskipun lebih terfokus pada Amazon; Pulumi adalah Terraform, hanya di Typecript. Saya berharap saya sudah mencoba Pulumi karena saya percaya ini adalah masa depan. Konfigurasi tersebut harus dijelaskan dalam bahasa pemrograman dengan pengetikan statis yang kuat, sehingga sebelum diterapkan, yang berpotensi dapat merusak kluster, Anda setidaknya akan diberi tahu pada saat kompilasi bahwa hal ini tidak mungkin dilakukan.

Jadi, saat ini hanya ada satu orkestra. Saya tahu masih ada beberapa pengguna MATA, saya menjabat tangan mereka; Saya harap tidak ada orang lain yang menggunakan Docker Swarm - pengalaman saya dengannya cukup negatif. Saya yakin bisa jadi sebaliknya, tetapi saya tidak tahu mengapa; Saya tidak melihat perkembangan lebih lanjut dari Docker Swarm, dan saya tidak berpikir bahwa orang yang merilisnya akan melakukan apa pun dengannya sekarang. Kapitalisme; jika Anda tidak menghasilkan uang, maka tidak ada yang bisa dibelanjakan untuk pengembangan - dan perusahaan mereka telah berada di "lembah kematian" untuk para pemula selama dua tahun terakhir: tidak ada yang mau memberi mereka uang. Anda dapat mengajukan penawaran tentang siapa yang akan membelinya. Microsoft tidak tertarik. Mungkin beberapa Microfocus akan melakukannya jika Docker bertahan.

Karena hanya ada satu Kubernetes yang tersisa, mari kita bahas. Ada gambar yang indah dengan pentagram dari lima binernya; tertulis bahwa Kubernetes sangat sederhana, hanya lima binari. Tetapi saya jauh dari mengukur kompleksitas sistem dalam jumlah binari yang dikompilasi dan dalam jumlah layanan yang membentuk inti sistem. Tidak masalah berapa banyak binari yang ada - yang penting adalah apa yang dapat dilakukan Kubernetes dan bagaimana cara kerjanya secara internal.

Apa yang dapat dia lakukan? Bayangkan saja Anda perlu menjelaskan kepada seorang anak berusia lima tahun apa yang Anda lakukan di tempat kerja. Maka ayah, yang mencoba menulis buku pedoman dan peran di Ansible yang akan memungkinkannya melakukan penerapan biru-hijau berdasarkan Nginx pada host dan satu set wadah yang tidak terdaftar dengan apa pun selain TV-ansible, berkata: “Anda tahu, Nak, saya mencoba segalanya saatnya membuat Kubernetes Anda sendiri. Tidak berfungsi dengan baik, tidak teruji dengan baik, saya tidak memahaminya dengan baik, saya tidak tahu semua kondisi batas, bekerja dalam mesin yang sama, tetapi ini milik saya! " Saya telah melihat ini berkali-kali tanpa alasan - saya hanya menontonnya 2 atau 3 kali, dan 2 kali saya berpartisipasi dalam menulis sesuatu seperti ini. Cepat atau lambat, seseorang yang berpartisipasi dalam hal ini, menyadari bahwa seharusnya tidak ada yang keempat kalinya. Ini seperti teman mobil sayayang pernah memulihkan VAZ-2101 - jendela listrik terpasang, memperbaiki interior dengan kawanan, mengecatnya dengan logam. Membuat orkestrator Anda sendiri adalah seperti ini. Anda dapat mencobanya sekali untuk memastikan Anda bisa, tetapi saya belum siap merekomendasikannya kepada semua orang - tidak hanya penggemar. Oleh karena itu, manajemen siklus hidup, manajemen keadaan kontainer adalah tugas Kubernetes.

Dia dapat memastikan bahwa penampung berjalan di node di mana terdapat sumber daya, ia dapat memulai kembali penampung yang mati, ia dapat memastikan bahwa jika penampung tidak dimulai, lalu lintas tidak akan pergi ke sana jika ada penerapan baru. Kami juga memulai dengan mengatakan bahwa Kubernetes adalah OSnya; di mana OSnya, harus ada manajer paket. Ketika Kubernetes dimulai, deskripsi objek sangatlah penting; himpunan stateful dan deskripsi kode adalah deskripsi yang bekerja secara langsung, dan Anda perlu menambahkan sesuatu di atasnya untuk membuat status [??? 18:52 - kesalahan perekaman]. Sebenarnya, perbedaan radikal dari Ansible dan sistem manajemen konfigurasi serupa lainnya adalah bahwa di Kubernetes Anda menjelaskan apa yang seharusnya dihasilkan, bukan bagaimana hasilnya. Anda menggambarkan secara alamiobjek apa yang Anda miliki dan properti apa yang dimilikinya. Objeknya adalah layanan, penerapan, daemonset, statefulset. Menariknya, selain objek yang bisa dibuat secara standar, ada juga objek kustom yang bisa dideskripsikan dan dibuat di Kubernetes. Itu sangat berguna; itu juga akan sangat menipiskan jajaran sysadmin dan insinyur pengembang.

Kapan Kubernetes akan mati?

Pertanyaan bagus. Tergantung apa yang dimaksud dengan kata "mati". Inilah Docker - setahun yang lalu kami berkumpul di sebuah konferensi di St. Petersburg, ada meja bundar, dan kami memutuskan bersama (yah, karena kami adalah industri, saya pikir ada mayoritas yang memenuhi syarat di sana, dan kami mampu untuk berbicara untuk semua orang) bahwa Docker telah mati. Mengapa? Karena di konferensi tersebut tidak ada pembicaraan tentang Docker, meski usianya belum terlalu lama. Tidak ada yang memberitahu apapun tentang dia. Kita berbicara tentang Kubernetes, tentang langkah selanjutnya - Kube Flow, misalnya, tentang penggunaan operator, tentang cara menempatkan basis Kubernetes. Apa pun kecuali Docker. Ini adalah kematian - ketika Anda begitu buruk sehingga Anda tampak hidup, tetapi tidak ada yang datang kepada Anda.

Docker sudah mati. Ketika Kubernetes meninggal - mari kita tunggu 5 tahun. Dia tidak akan mati, semua orang akan memilikinya - dia akan berada di dalam Tesla, di dalam ponsel Anda, di mana saja, dan tidak ada yang akan tertarik untuk membicarakannya. Saya pikir ini adalah kematian. Mungkin bahkan tidak dalam 5 tahun, tapi dalam 3. Pertanyaan lain adalah apa yang akan menggantikannya: beberapa teknologi baru yang keras yang akan dibicarakan semua orang, mungkin sama sekali bukan dari dunia DevOps. Sekarang mereka berbicara tentang Kubernetes bahkan hanya untuk menjaga percakapan tetap berjalan, dan tidak apa-apa - ini modis.

Ada apa dengan Docker?

Semua. Ini adalah binar tunggal untuk mengelola segalanya, ini adalah layanan yang harus diluncurkan di sistem, ini adalah bagian yang dikontrol melalui soket juga. Ini adalah produk yang memiliki banyak kode yang belum pernah ditinjau oleh siapa pun, seperti yang saya kira. Ini adalah produk yang, pada umumnya, tidak ada uang perusahaan. Red Hat memiliki orang-orang yang sangat pintar, saya sangat menghormati mereka, dan jika Anda adalah insinyur rata-rata, Anda harus melihat apa yang mereka lakukan karena hal itu dapat menentukan lanskap untuk 5 tahun ke depan. Nah, Red Hat membuang Docker sama sekali. Mereka bergerak menuju tidak memilikinya. Sejauh ini, mereka tidak dapat melakukan ini sampai akhir, tetapi mereka sudah dekat, dan cepat atau lambat mereka akan menyelesaikan Docker. Dia, selain semua yang telah saya daftarkan, memiliki area serangan yang sangat besar. Tidak ada keamanan di sana. Tidak banyak CVE yang diangkat di dalamnya, tetapi jika Anda melihatnya, jelas bahwa,seperti dalam proyek lain mana pun di mana keselamatan tidak berada di garis depan, hal itu ditangani dengan basis sisa. Ini hukumnya. Keamanan adalah proses yang panjang, mahal, dan suram, membatasi pengembang, membuat hidup menjadi sangat sulit. Menyelesaikan keselamatan dengan benar adalah kerja keras dan Anda harus membayarnya. Jika Anda berbicara dengan profesional keamanan mana pun, apa pun kualifikasinya, Anda akan mendengar banyak cerita horor tentang Docker dan cerita tentang betapa buruknya hal itu. Mereka sebagian terkait dengan Docker itu sendiri, sebagian dengan orang yang mengoperasikannya, tetapi Docker sendiri dapat membantu orang dan melakukan beberapa pemeriksaan keamanan di dalamnya; misalnya, jangan memulai proses dalam wadah dari root, kecuali secara eksplisit diminta untuk melakukannya.membatasi pengembang, membuat hidup sangat sulit. Menyelesaikan keselamatan dengan benar adalah kerja keras dan Anda harus membayarnya. Jika Anda berbicara dengan profesional keamanan mana pun, apa pun kualifikasinya, Anda akan mendengar banyak cerita horor tentang Docker dan cerita tentang betapa buruknya hal itu. Mereka sebagian terhubung dengan Docker sendiri, sebagian dengan orang yang mengoperasikannya, tetapi Docker sendiri dapat membantu orang dan melakukan beberapa pemeriksaan keamanan di dalamnya; misalnya, jangan memulai proses dalam wadah dari root, kecuali secara eksplisit diminta untuk melakukannya.membatasi pengembang, membuat hidup sangat sulit. Menyelesaikan keselamatan dengan benar adalah kerja keras dan Anda harus membayarnya. Jika Anda berbicara dengan profesional keamanan mana pun, apa pun kualifikasinya, Anda akan mendengar banyak cerita horor tentang Docker dan cerita tentang betapa buruknya hal itu. Mereka sebagian terkait dengan Docker itu sendiri, sebagian dengan orang yang mengoperasikannya, tetapi Docker sendiri dapat membantu orang dan melakukan beberapa pemeriksaan keamanan di dalamnya; misalnya, jangan memulai proses dalam wadah dari root, kecuali secara eksplisit diminta untuk melakukannya.sebagian - dengan orang-orang yang mengeksploitasinya, tetapi Docker sendiri dapat membantu orang dan melakukan beberapa pemeriksaan keamanan di dalamnya; misalnya, jangan memulai proses dalam wadah dari root, kecuali secara eksplisit diminta untuk melakukannya.sebagian - dengan orang-orang yang mengeksploitasinya, tetapi Docker sendiri dapat membantu orang dan melakukan beberapa pemeriksaan keamanan di dalamnya; misalnya, jangan memulai proses dalam wadah dari root, kecuali secara eksplisit diminta untuk melakukannya.

Bagaimana cara menyimpan negara bagian? Bisakah saya menghosting database di Kubernetes?

Jika Anda bertanya kepada DBA, atau orang yang bertanggung jawab atas infrastruktur database ini sebelum Anda memutuskan untuk meletakkannya di Kubernetes, orang tersebut akan menjawab tidak. Saya pikir di banyak meja bundar orang akan mengatakan bahwa seharusnya tidak ada database di Kubernetes: sulit, tidak dapat diandalkan, tidak jelas bagaimana mengelolanya.

Saya percaya bahwa DB di Kubernetes dapat direpresentasikan. Seberapa andal itu? Nah, lihat: kita berurusan dengan sistem terdistribusi. Saat Anda meletakkan database di cluster, Anda harus memahami bahwa Anda memiliki persyaratan untuk toleransi kesalahan. Jika Anda memiliki persyaratan seperti itu, kemungkinan besar yang Anda masukkan ke dalam Kubernetes adalah cluster database. Berapa banyak orang di dunia modern yang tahu cara melakukan cluster database normal? Apakah banyak database menyediakan kemampuan pengelompokan? Di sini dimulai pembagian database menjadi tradisional - relasional, dan non-relasional. Perbedaan mereka bukanlah bahwa yang terakhir tidak mendukung SQL dalam satu atau lain bentuk. Perbedaannya adalah bahwa database non-relasional jauh lebih cocok untuk bekerja dalam cluster, karena mereka pada awalnya ditulis sehingga database itu terdistribusi. Karena itu,jika untuk beberapa MongoDB atau Cassandra Anda ingin melakukan hosting di Kubernetes, saya tidak dapat menghalangi Anda, tetapi Anda harus memiliki gagasan yang sangat baik tentang apa yang akan terjadi selanjutnya. Anda harus memahami dengan baik di mana data Anda, apa yang akan terjadi jika terjadi kegagalan dan pemulihan, bagaimana proses pencadangan, di mana titik pemulihan berada, dan berapa lama waktu yang dibutuhkan untuk memulihkan. Pertanyaan-pertanyaan ini tidak relevan dengan Kubernetes; mereka berhubungan dengan bagaimana Anda pada dasarnya mengoperasikan solusi cluster berdasarkan database konvensional. Lebih mudah dengan solusi NoSQL, mereka segera cloud-ready.di mana titik pemulihan dan berapa lama waktu yang dibutuhkan untuk pulih. Pertanyaan-pertanyaan ini tidak relevan dengan Kubernetes; mereka berhubungan dengan bagaimana Anda pada dasarnya mengoperasikan solusi cluster berdasarkan database konvensional. Lebih mudah dengan solusi NoSQL, mereka segera cloud-ready.di mana titik pemulihan dan berapa lama waktu yang dibutuhkan untuk pulih. Pertanyaan-pertanyaan ini tidak relevan dengan Kubernetes; mereka berhubungan dengan bagaimana Anda pada dasarnya mengoperasikan solusi cluster berdasarkan database konvensional. Lebih mudah dengan solusi NoSQL, mereka segera cloud-ready.

Tapi tetap, muncul pertanyaan - mengapa meletakkan database di Kubernetes? Anda dapat menggunakan layanan yang disediakan oleh penyedia Anda, solusi terkelola; Anda dapat mengambil RDS dari Amazon, dan juga mengelola database dari Google. Dan bahkan klaster database yang terdistribusi secara geografis, dalam kasus Amazon, ini adalah Aurora, Anda dapat menginstal dan menggunakan. Namun, jika Anda akan menginstal cluster basis yang terdistribusi secara geografis, baca dokumentasinya dengan cermat; Saya telah melihat cluster Aurora dengan satu node - mereka bahkan tidak terpecah menjadi dua wilayah. Apalagi daerah kedua tidak dibutuhkan sama sekali. Secara umum, orang memiliki hal-hal yang sangat aneh di kepala mereka: mereka percaya bahwa yang utama adalah memilih produk, dan kemudian akan menyediakan dirinya sendiri dan berfungsi sebagaimana mestinya. Tidak. Database relasional sama sekali tidak siap untuk bekerja bahkan di cluster biasa,belum lagi terdistribusi secara geografis. Oleh karena itu, jika Anda melakukan sesuatu yang rumit berdasarkan mereka, lihat dokumentasinya.

Pada dasarnya, saya memiliki pengalaman mengoperasikan database di dalam Kubernetes. Tidak ada yang buruk. Ada beberapa crash terkait dengan node yang jatuh; perpindahan tersebut bekerja secara normal ke node lain. Semuanya terkendali. Satu-satunya hal yang saya tidak bisa menyenangkan Anda dan mengatakan bahwa ada ribuan permintaan per detik.

Jika Anda memiliki solusi menengah atau kecil - solusi rata-rata untuk Rusia kira-kira sesuai dengan kantor berita besar seperti Lenta - maka seharusnya tidak ada sejumlah besar kueri kompleks ke database. Jika pangkalan tidak mengatasi, maka, mungkin, Anda melakukan sesuatu yang salah, dan Anda perlu memikirkannya. Jangan meningkatkan skala tanpa berpikir panjang. Memindahkan solusi non-cluster ke cluster memiliki kelebihan, tetapi juga sejumlah besar kerugian - terutama jika Anda mengambil cluster postgres berdasarkan Patroni atau Stallone. Ada banyak syarat batas; Saya belum menemukannya, tetapi kolega dari Data Egret akan dengan senang hati memberi tahu Anda bagaimana hal itu terjadi. Ada laporan bagus dari Alexei Lesovsky tentang apa yang akan terjadi jika Anda mencoba mentransfer basis Anda ke cluster tanpa berpikir.

Sekitar ribuan permintaan per detik. Jika Anda memiliki satu Instans DB, menyesuaikannya dengan ribuan permintaan per detik masih ditingkatkan. Cepat atau lambat Anda akan mendapat masalah. Menurut saya, lebih baik, jika direncanakan beban berat, untuk mempertimbangkan opsi penskalaan horizontal. Temukan tabel terbesar di database Anda, lihat apa yang ada di sana, dan pikirkan apakah tabel tersebut dapat dipindahkan ke penyimpanan non-relasional. Pikirkan bagaimana tidak menyimpan dalam database relasional apa yang biasanya Anda simpan di dalamnya - misalnya, log akses sistem, yang banyak jatuh, dan Anda biasanya mengaksesnya sesuai dengan pola yang sama seperti yang Anda gunakan untuk mengakses penyimpanan nilai kunci ... Jadi mengapa tidak menulis log di Cassandra? Ini pertanyaan untuk seorang arsitek. Mempertahankan instance dasar yang kecil dan tidak terlalu sibuk di Kubernetes adalah hal yang paling pentingkarena keajaiban operator mulai bertanggung jawab untuk itu.

Pada dasarnya, jika Anda melihat apa itu Kubernetes sebagai OS dan platform, maka ini adalah konstruktor do-it-yourself. Ada segalanya bagi Anda untuk membangun arsitektur layanan mikro, termasuk kemampuan untuk menyimpan status pada disk, mengatur telemetri, pemantauan, dan peringatan. Ini dilakukan oleh Helm, manajer paket Kubernetes. Ada banyak Helm Charts open source yang tersedia untuk umum di Internet. Cara termudah untuk meningkatkan infrastruktur proyek adalah dengan menggunakan Helm Chart yang menempatkan aplikasi Anda, layanan Anda, jika layanan ini adalah database Redis, PostgreSQL, Patroni - apapun; mulai konfigurasikan, dan terapkan konfigurasi ini. Ini sepenuhnya deklaratif; apa pun yang bisa diramalkan, biasanya penulis Helm Charts menyediakan. Aplikasi Anda paling baik dirilis dengan Helm juga.Helm ketiga tidak berisi layanan sisi kluster; yang kedua berisi, ia memiliki layanan yang terus bekerja dari administrator klaster, yang diperlukan untuk mendistribusikan rilis berdasarkan namespace, tetapi Helm ketiga menutup celah keamanan ini.

Helm adalah mesin templat yang didasarkan pada sintaks templat GoLang. Dibutuhkan daftar variabel, yang merupakan struktur non-planar (alhamdulillah, ini hierarkis - ditulis dalam YAML); Menggunakan Helm, variabel-variabel ini ditempatkan di tempat yang tepat di Template Helm, lalu Anda menerapkan semuanya di beberapa namespace, kode Anda, layanan diluncurkan di sana, peran Anda dibuat. Ada generator perancah yang memungkinkan Helm Chart untuk menulis tanpa sadar kembali. Satu-satunya hal yang saya tidak suka adalah kebutuhan untuk mengetahui sintaks dari template GoLang dan cabang bersyarat di Helm itu sendiri; mereka dibuat menurut prinsip cadel, dengan notasi awalan. Ada baiknya seseorang masih menyukainya, tetapi itu membuat kepala beralih setiap saat. Nah, kita akan mengatasinya.

Sekarang sedikit tentang apa yang akan terjadi selanjutnya. Saya sudah menyerupai operator; ini adalah layanan yang hidup di dalam cluster Kubernetes dan mengelola siklus hidup aplikasi lain yang lebih besar. Cukup sulit. Anda dapat menganggap operator sebagai insinyur keandalan situs rumah silikon Anda; pasti di masa depan orang akan menulis lebih banyak operator, karena tidak ada yang mau menjaga perubahan dari orang tingkat dukungan 1 yang akan mengikuti jadwal Nagios, melihat pemadaman dan mengambil tindakan manual. Operator memahami status sistem yang mungkin; itu adalah mesin negara. Sekarang konsentrasi pengetahuan manusia, yang ditulis dalam bahasa GoLang atau sejenisnya, dikompilasi, dimasukkan ke dalam cluster dan melakukan banyak pekerjaan untuk Anda: menambah atau menghapus node, mengkonfigurasi ulang, memastikan bahwa node yang jatuh naik,sehingga data berlabuh ke kode yang diinginkan dari tempatnya. Secara umum, ia mengatur siklus hidup dari apa yang dipasang di bawahnya. Operator sekarang benar-benar untuk segalanya. Saya telah bersenang-senang dengan menggunakan operator Rook untuk menempatkan sev langsung ke cluster Kubernetes. Saya melihat bagaimana ini terjadi, dan saya sangat senang, dan saya pikir lebih banyak operator yang dibutuhkan, dan kita semua harus berpartisipasi dalam mengujinya. Waktu yang Anda habiskan untuk mengoreksi operator orang lain adalah hadiah bagi kemanusiaan. Anda tidak perlu lagi melakukan pekerjaan yang sama berulang kali. Anda dapat meletakkan pekerjaan ini dalam bentuk terasing di repositori, dan kemudian program cerdas akan melakukannya untuk Anda - bukankah ini kebahagiaan?Operator sekarang benar-benar untuk segalanya. Saya telah bersenang-senang dengan fakta bahwa menggunakan operator Rook, saya meletakkan sev langsung ke dalam cluster Kubernetes. Saya melihat bagaimana ini terjadi, dan saya sangat senang, dan saya pikir lebih banyak operator yang dibutuhkan, dan kita semua harus berpartisipasi dalam mengujinya. Waktu yang Anda habiskan untuk mengoreksi operator orang lain adalah hadiah bagi kemanusiaan. Anda tidak perlu lagi melakukan pekerjaan yang sama berulang kali. Anda dapat meletakkan pekerjaan ini dalam bentuk terasing di repositori, dan kemudian program cerdas akan melakukannya untuk Anda - bukankah ini kebahagiaan?Operator sekarang benar-benar untuk segalanya. Saya telah bersenang-senang dengan fakta bahwa menggunakan operator Rook, saya meletakkan sev langsung ke dalam cluster Kubernetes. Saya melihat bagaimana ini terjadi, dan saya sangat senang, dan saya pikir lebih banyak operator yang dibutuhkan, dan kita semua harus berpartisipasi dalam mengujinya. Waktu yang Anda habiskan untuk mengoreksi operator orang lain adalah hadiah bagi kemanusiaan. Anda tidak perlu lagi melakukan pekerjaan yang sama berulang kali. Anda dapat meletakkan pekerjaan ini dalam bentuk terasing di repositori, dan kemudian program cerdas akan melakukannya untuk Anda - bukankah ini kebahagiaan?yang Anda keluarkan untuk mengoreksi operator orang lain adalah hadiah bagi kemanusiaan. Anda tidak perlu lagi melakukan pekerjaan yang sama berulang kali. Anda dapat meletakkan pekerjaan ini dalam bentuk terasing di repositori, dan kemudian program cerdas akan melakukannya untuk Anda - bukankah ini kebahagiaan?yang Anda habiskan untuk mengoreksi operator orang lain adalah hadiah bagi kemanusiaan. Anda tidak perlu lagi melakukan pekerjaan yang sama berulang kali. Anda dapat meletakkan pekerjaan ini dalam bentuk terasing di repositori, dan kemudian program cerdas akan melakukannya untuk Anda - bukankah ini kebahagiaan?

Saya mengunduh buku Red Hat - mereka memberikannya secara gratis - tentang cara kerja operator Kubernetes dan cara menulisnya sendiri, saya sarankan Anda mengunjungi situs web mereka dan mengunduhnya juga, bukunya sangat menarik. Jika saya membacanya secara lengkap, mungkin kita bisa menganalisis beberapa operator bersama-sama.

Siapa yang Mendukung Swarm? Selain Docker Inc?

Tak seorangpun. Dan Docker Inc. sudah terbelah menjadi dua bagian, dan satu setengah dijual di suatu tempat. Saya tidak mengikuti apa yang terjadi dengan mereka; pada suatu waktu mereka menyebut produk Mobi, tetapi itu adalah versi open source, artinya, itu bukan versi terbuka. Dan ada sesuatu yang dijual dengan hak, tapi ada yang tidak dijual. Bagi saya ini terlihat seperti "seorang pasien berkeringat sebelum kematiannya" - orang-orang entah bagaimana berusaha untuk mendapatkan uang yang diinvestasikan. Secara umum, tidak ada yang mendukungnya.

Tuan / Budak

Berhasil. Jika master / slave berhenti bekerja dalam database relasional, dunia akan berakhir di sana. Kubernetes tidak mengganggu pengoperasian database dengan cara apapun; satu-satunya hal yang dibawa adalah pemeriksaan kesehatan yang berbeda, yang dapat dinonaktifkan jika diinginkan, dan, pada prinsipnya, pengelolaan negara. Dianjurkan untuk tidak menonaktifkannya - operator Anda yang mengelola database harus melihat statusnya.

Apa nama buku Red Hat?

Operator Kubernetes disebut demikian. Bebek itu ditarik ke sana. Buku O'Reilly, sekarang mendesain ulang sampulnya; cukup banyak buku telah diterbitkan bekerja sama dengan Red Hat. Red Hat memiliki 3 atau 4 lebih buku Kubernetes yang dapat Anda unduh secara gratis: misalnya, Kubernetes Patterns, gRPC. Protokol gRPC, meskipun tidak terkait langsung dengan Kubernetes, digunakan oleh banyak orang untuk bertukar data antar layanan mikro. Selain itu, digunakan di penyeimbang beban generasi berikutnya, misalnya, di Envoy.

Apa itu SRA?

Ini adalah tipe orang yang memahami kerangka waktu perubahan yang terjadi dalam sistem terdistribusi. Secara kasar, dia mengerti sudah berapa lama Anda berbaring bulan ini, berapa banyak lagi yang Anda bisa, apakah Anda bisa memberikan izin untuk pembebasan. Mengelola kunci dari cadangan, rencana pemulihan, masalah pemulihan bencana, masalah pemeliharaan infrastruktur untuk aplikasi industri yang seharusnya berfungsi 24/7. Ini memiliki metrik untuk status dan bisnis aplikasi dalam metrik aplikasi - berapa banyak latensi, di mana dan berapa banyak permintaan; 4 sinyal emas yang sama. Selanjutnya, SRA, berdasarkan metrik ini, dapat mengambil langkah untuk mengembalikan sistem ke kesiapan tempur, dia memiliki rencana bagaimana melakukan ini. Untuk beberapa alasan, ini tidak diperlukan dari DevOps klasik, ini hanya membantu pengembang membawa aplikasi untuk dirilis, umumnya meluncurkannya di suatu tempat.Dan SRA juga menolak aliran permintaan dari berbagai sisi.

Saya berjanji untuk berbicara tentang keamanan. Anda tahu, ini adalah topik yang cukup muda di Kubernetes. Saya hanya tahu dasar-dasarnya: misalnya, Anda tidak boleh menjalankan aplikasi dalam layanan dari root, karena segera setelah ini terjadi, aplikasi tersebut memiliki akses ke semua yang ada di namespace, hak pengguna super, dan Anda dapat mencoba memecahkan kernel sistem host, yang, mungkin itu akan berhasil (dan melakukan operasi lain dari root). Jangan beri petunjuk seperti itu kepada peretas; jika memungkinkan, berikan hak sesedikit mungkin kepada pengguna dan tangani masukan pengguna dengan baik. Menurut saya, jika kita berbicara tentang keamanan Kubernetes, itu perlu dibawa keluar di suatu tempat di sirkuit tertutup yang kita miliki saat ini. Atau, jika Anda benar-benar ingin masuk ke masalah keamanan, Anda harus melihat proyek Cilium. Dia tahu cara menggunakan pelindung lonjakan arus,Diferensiasi lalu lintas jaringan berbasis BPF - ini bekerja lebih baik daripada iptables. Ini masa depan. Menurut saya, di luar California tidak ada yang benar-benar menggunakannya, tetapi Anda sudah bisa mulai. Mungkin akan ada proyek lain, tapi saya ragu. Secara umum, manusia hanya memiliki sedikit tangan yang bekerja.

Oleh karena itu, tidak ada yang khusus untuk saya katakan tentang keamanan. Ada berbagai opsi untuk memasang tenancy di Kubernetes, tetapi di sana Anda harus duduk dengan pensil dan mencari tahu apa yang orang lakukan, kerentanan apa yang mereka tutup, apakah masuk akal, apakah itu berlaku untuk model ancaman Anda. Ngomong-ngomong, saya sarankan untuk memulai dengan mencari deskripsi tentang bagaimana model ancaman dibangun dan membangunnya sendiri. Ada metode yang kurang lebih formal. Gambarlah, lihat itu, dan mungkin wawasan akan muncul, dan Anda akan memahami apa yang Anda butuhkan dan apa yang tidak dibutuhkan dalam situasi saat ini. Mungkin itu akan cukup untuk mendorong semua Kubernetes ke loop tertutup. Ngomong-ngomong, ini adalah keputusan yang tepat; Saya telah menemukan ini, dan itu tidak bisa ditembus. Jika Anda bisa mendapatkan akses ke sistem hanya dengan memberikan izin masuk ke jam tangan, dan tidak ada Internet di dalamnya, dan pertukaran melewati beberapa gateway khusus,terletak di DMZ dan sulit untuk dipecahkan karena ditulis secara tidak biasa - maka ini adalah sistem yang terlindungi dengan baik. Bagaimana melakukan ini dengan cara teknis - baik, Anda perlu memantau pasar solusi saat ini. Ini banyak berubah, keamanan adalah topik hangat. Ada banyak pemain yang mencoba menjadi, tetapi mana di antara mereka yang berbohong dan mana yang tidak - saya tidak berani mengatakannya. Meskipun Red Hat mungkin tidak berbohong, hal itu tidak mendahului semua orang. Kamu hanya perlu melakukan penelitian (dan aku juga), karena itu belum jelas.Kamu hanya perlu melakukan penelitian (dan aku juga), karena itu belum jelas.Kamu hanya perlu melakukan penelitian (dan aku juga), karena itu belum jelas.

Mari kita bahas tentang apa lagi yang harus dimiliki cluster Kubernetes. Karena kami memiliki kesempatan untuk menginstal aplikasi di sana secara gratis, dan kami tidak takut untuk menyimpan database di sana. Ngomong-ngomong, jika Anda memiliki Managed Kubernetes, maka tidak ada pertanyaan tentang di mana harus menyimpan database: Anda memiliki penyimpanan yang toleran terhadap kesalahan, dalam satu bentuk atau lainnya (seringkali dalam bentuk perangkat blok) yang dibawa dari cloud, yang menghosting Managed Kubernetes. Anda dapat dengan aman menempatkan disk dari penyimpanan ini di cluster Anda dan menggunakan snapshot untuk membuat backup yang konsisten. Hanya saja, jangan lupa bahwa snapshot bukanlah cadangan, Anda juga perlu menyalin snapshot di suatu tempat. Hal ini sudah jelas, tetapi hal yang sudah jelas baik untuk diulangi agar tidak dilupakan.

Sangat penting, ketika Anda memiliki platform arsitektur layanan mikro, untuk membuatnya dapat dilacak, diamati, sehingga Anda dapat memahami di mana permintaan berada dan di mana mereka membuang-buang waktu, dan seterusnya. Membangun platform seperti itu membutuhkan banyak pekerjaan. Anda membutuhkan Prometheus. Ini akan dibutuhkan karena ini adalah proyek Cloud Native Computing Foundation; itu dirancang khusus untuk memantau Kubernetes. Berisi sejumlah besar eksportir, pengumpul metrik; beberapa aplikasi secara bawaan berisi semua dasbornya. Jika aplikasi Anda tidak berisi mereka, maka perlu 20 menit untuk melampirkan ke aplikasi dasbor Prometheus yang berumur panjang. Meski untuk beberapa alasan tidak ada yang menempelkannya. Dalam pengalaman saya, ini karena orang-orang menyimpan produk mereka di awan. Ada Amazon CloudWatch, Google StackDriver,dan Anda dapat mengirim metrik ke sana dengan cara yang sama - meskipun itu memerlukan biaya. Artinya, jika masyarakat masih membayar infrastruktur, maka mereka membayar alat pemantauan yang menyertainya. Namun demikian, Prometheus bisa sangat nyaman jika Anda memiliki beberapa tempat berbeda di mana Anda mengambil metrik, jika cloud tidak ada di satu tempat, jika hybrid, jika Anda memiliki mesin di lokasi dan membutuhkan infrastruktur terpusat. Maka Prometheus adalah pilihan Anda.jika Anda memiliki mesin milik sendiri dan membutuhkan infrastruktur terpusat. Maka Prometheus adalah pilihan Anda.jika Anda memiliki mesin milik sendiri dan membutuhkan infrastruktur terpusat. Maka Prometheus adalah pilihan Anda.

Apa lagi yang kamu butuhkan? Jelas bahwa di mana Prometheus berada, ada juga kebutuhan akan Alert Manager. Dan Anda juga membutuhkan semacam pelacakan terdistribusi atas permintaan Anda. Bagaimana melakukan ini di Kubernetes - baik, ambil beberapa produk seperti jaeger, atau zipkin, atau apapun yang ada di atas sekarang; juga Cassandra untuk menyimpan jejak Anda, juga Grafana untuk membuatnya. Sejauh yang saya pahami, fitur ini muncul di Grafana baru-baru ini, tetapi ini bukan alasan untuk tidak menerapkannya. Artinya, Anda dapat secara manual merakit lingkungan di mana aplikasi akan [glitches 49:14] (miliki?) Dengan runtime ini penghitung dan metrik lain yang cocok untuk membangun, visualisasi jejak terdistribusi Anda: di mana aplikasi menghabiskan berapa lama?

Memang kurang nyaman untuk membicarakannya daripada menunjukkannya, tetapi tidak ada yang bisa ditunjukkan kepada saya sekarang; Saya tidak memiliki semua ini di laboratorium saya sekarang. Suatu hari saya mungkin akan bersiap-siap.

Saya pikir saya telah menceritakan semua yang ingin saya ceritakan. Saya akan mengulangi ketentuan utama sekali lagi.

Pertama: Kubernetes membebaskan Anda dari kebutuhan untuk menulis mekanisme penggantian satu container dengan lainnya di Ansible Engine X.

Kedua: Kubernetes tidak akan menghilang di mana pun. Itu bisa "mati", tetapi tidak mungkin lagi untuk berhenti menggunakannya, itu telah merebut sebagian besar pasar. Untuk pertanyaan "kapan Kubernetes akan mati:" Saya ingin bertanya "kapan WordPress akan mati?" Dan dia masih harus hidup dan hidup. Mari kita atur urutannya: WP dulu, lalu Kubernetes.

Jadi Kubernetes bersama kami. Bukan dia sendiri yang menarik, tetapi layanan yang disebutkan di atas menarik - ini adalah operator dan Definisi Sumber Daya Kustom. Kemampuan untuk mengambil dan menulis resource Anda sendiri, yang akan disebut "cluster PostgreSQL", mendeskripsikannya dengan satu footcloth YAML dan membuangnya ke cluster.

Apa lagi yang akan terjadi? Juga akan ada kemampuan untuk mengelola semua ini, bahasa pemrograman yang diketik secara statis seperti GoLang dan TypeScript. Dan saya sangat percaya pada Kotlin - banyak DSL keren yang sudah ditulis di atasnya. Dan lebih banyak lagi yang akan ditulis.

Juga akan ada Helm Chart berbayar, aplikasi berbayar yang dapat diluncurkan secara lokal, beberapa yang berlisensi, dengan berlangganan. Akan ada integrasi berbagai layanan - sebenarnya sudah ada, misalnya DataDog sudah terintegrasi dengan Kubernetes. Dan orang-orang baru yang akan muncul di pasar peringatan-pemantauan juga akan berintegrasi dengan Kubernetes, karena alasan yang jelas. Produk cloud apa pun tidak akan melewati Kubernetes, dengan satu atau lain cara. Ini adalah platform yang akan dituju semua orang.

Tetapi semua ini tidak berarti bahwa Kubernetes itu bagus, dan tidak ada yang lebih baik. Saya membandingkannya dengan sebelumnya - dengan solusi Amazon: ECS, Elastic Beanstalk. Mereka yang telah menemukan mereka tahu bahwa dalam analogi lama saya bahwa satu hal, yang lain tidak hanya 737 MAX, tetapi 737 MAX, terbuat dari pita listrik dan plastisin. Oleh karena itu, pemain utama - Amazon, Microsoft Azure, Google - semuanya sudah ada di Kubernetes. Mungkin, Yandex dan Mail.ru juga, tetapi saya tidak mengikuti mereka. Ini adalah masa depan yang umum. Masa depan bersama yang begitu buruk, tapi "cukup baik" yang sejauh ini disetujui semua orang. Apa semua ini bermutasi lebih lanjut, Anda harus bertanya pada Red Hat - mereka lebih pintar dari saya.

Bagaimana perasaan Java tentang Kubernetes?

Baik.

OS apa yang Anda gunakan di PC Anda?

Keduanya ada di macOS.

Apakah spesialis DevOps secara aktif direkrut sekarang?

Ya, mereka selalu aktif dibawa ke lokasi terpencil, dan sekarang secara aktif diambil dengan cara yang sama. Situasinya tidak akan berubah secara fundamental, saya pikir. Secara umum, saya tidak menganggap pekerjaan yang tidak dihapuskan: tidak setiap perusahaan yang baik memiliki kantor di St. Petersburg. Tentu saja, akan ada jarak, dan peristiwa terkini telah menunjukkan kepada orang-orang bahwa itu mungkin. Jumlah orang yang lebih nyaman dengannya hanya akan bertambah. Kami diberi tahu bahwa “banyak orang mencobanya dan kembali ke kantor” - nah, kembali ke kantor membutuhkan uang. Tidak ada uang - tidak ada pilihan, dan banyak perusahaan yang menabung sekarang.

"Docker sudah mati" atau apa pun yang ingin Anda ketahui tentang Devops tetapi takut untuk bertanya