Ini adalah terjemahan dari artikel Patrick Lee Scott yang diposting di hackernoon.com. Penulis menawarkan untuk berkenalan dengan beberapa prinsip penting yang akan membantu Anda memompa di DevOps.
Beberapa hari yang lalu saya mencoba mengupas telur dengan cara yang bodoh, dan pacar saya Angeli bertanya kepada saya mengapa saya melakukan ini.
Dia mengambil telur rebus dan menabraknya di atas talenan, lalu menekannya dan menggulungnya di atas meja. Hanya perlu 3 detik untuk membersihkan. Dan saya berdiri dan melepaskan cangkang itu sepotong demi sepotong.
Apa yang ingin saya katakan dengan ini:
kami melebih-lebihkan pentingnya upaya.Solusi terbaik sederhana dan efektif. Apakah sulit untuk membersihkan baut berkarat? Mungkin ya. Tetapi hanya jika Anda tidak tahu bahwa ini dapat dilakukan dengan Coca-Cola. Masih rumit? Tidak. Anda hanya perlu meletakkan baut di gelas dan tunggu.
Tanpa mengetahui teknik sederhana, Anda tidak bisa menerapkannya. Alih-alih menerapkan, Anda melakukan eksperimen, alih-alih replikasi, Anda melakukan penelitian.
Jika dalam pemrograman Anda menggunakan beberapa jenis pendekatan lagi dan lagi, karena memungkinkan Anda untuk menyederhanakan masalah yang diselesaikan, pendekatan ini menjadi templat atau apa yang disebut praktik terbaik.
Terlepas dari nama-nama yang kompleks dan menakutkan seperti Segregation Command Query Responsibility (CQRS) atau Event Sourcing (ES), praktik ini membantu memecahkan masalah. Terutama yang muncul ketika membangun sistem terdistribusi.
Jika Anda melihat perkembangan secara keseluruhan, kita akan melihat bahwa ada prinsip yang lebih universal, misalnya, "Tetap Sederhana, Bodoh" (KISS) dan "Jangan Ulangi Diri Sendiri" (KERING). Saya ingin berbicara tentang pola dan prinsip yang sama terkait dengan DevOps.
DevOps sering disajikan sebagai tanah yang dijanjikan, tempat burung bernyanyi dan matahari bersinar. Tetapi tanpa menggunakan metode yang tepat, DevOps akan berubah menjadi neraka, dan Anda akan menusuk semua jari Anda dengan cangkang (seperti saya).
Menciptakan sistem DevOps, saya menemukan beberapa solusi untuk diri saya di samping prinsip-prinsip universal seperti KISS dan DRY. Meskipun mereka tidak dapat disebut template, tetapi mereka akan membantu Anda dengan cepat membersihkan telur. Solusi ini (dalam urutan acak):
- Jangan lakukan apa yang orang lain lakukan sebelum Anda.
- Biarkan pengembang menjadi seproduktif mungkin.
- Produksi adalah mitos.
- Transfer semuanya ke cluster dan buat cadangan keseluruhan.
- VPN terlalu rumit, solusinya lebih mudah.
- Atur, otomatisasi, dan taklukkan!
Pelajaran 1. Jangan lakukan apa yang dilakukan orang lain sebelum Anda
Jika Anda memiliki kesempatan untuk membeli produk jadi atau jika Anda memiliki alat yang diperlukan dan nyaman di domain publik, gunakan ini.
Jangan menemukan kembali roda - beli itu.
Tahukah Anda bahwa Anda dapat menggunakan server email yang sama dengan yang digunakan Craigslist? Dan apa itu gratis? Perlu server surat - jangan membuat yang baru, bekerja dengan yang sudah ada.
Saya suka mencari alat dalam daftar yang di-host-sendiri atau menggunakan Hub Hub untuk ini.
Terlepas dari kenyataan bahwa Helm adalah alat yang cukup baru untuk menemukan perangkat lunak, situs ini telah dibuat: https://v3.helm.sh/Dengan Helm, Anda dapat dengan mudah mencari sepeda yang sudah jadi.
Mari kita kembali ke masa ketika saya baru memulai program. Di kelas 9, saya belajar bahasa "nyata" pertama saya - QBasic. Sebelum itu, saya telah membuat situs HTML dan CSS selama beberapa tahun. Kemudian Internet adalah baru, dan meskipun orang tahu cara membuat paket, mereka tidak membagikannya, seperti kita sekarang. Saya biasanya menggunakan floppy disk untuk penyimpanan - alangkah baiknya menemukannya bersama-sama dengan gim seperti arkanoid, yang saya tulis di Java Swing di kelas 11 ...
Yang saya gunakan adalah perpustakaan standar, sayang! Setidaknya pada usia 13 saya hanya tahu tentang mereka. Meskipun saya yakin bahwa beberapa pro java (halo, Vlad dan Nick!) Sudah keren saat itu. ;)
Sekarang semuanya salah. Hari ini Anda dapat menemukan seluruh perpustakaan UI. Anda dapat menemukan perpustakaan untuk menangani tanggal secara elegan dan mudah dengan satu perintah.
Akan lebih bagus jika ada alat untuk menggunakan dan menginstal subsistem yang berfungsi penuh, kan? Butuh database?
instal basis dataBerita bagus: alat seperti itu ada! Dengan Helm, Anda juga dapat menginstal subsistem yang berfungsi penuh yang dikemas dan siap digunakan.
Prinsipnya sama dengan untuk NPM dan Gradle, tetapi paket yang kami kelola di Helm disebut grafik. Bagan menandai wadah sehingga mereka berjalan di Kubernet dengan berbagai cara.
Ternyata solusi turnkey, membeli sepeda. Grafik adalah roda, dan wadah dengan deskripsi yang mengalir di dalam Kubernetes adalah roda.
Apa yang keren tentang grafik adalah kemampuan untuk mengemas layanan dan menjalankannya di setiap cluster Kubernetes dan bahkan membaginya dengan orang lain jika Anda mau.
Ini berarti Anda dapat menggambarkan seluruh lingkungan menggunakan kode:
- name: backup repository: http:
Perlu meningkatkan situs pemasaran Anda ke 1.2.0? Buat saja perubahan dan komit.
Pelajaran 2. Biarkan pengembang menjadi seproduktif mungkin.
Saya pernah duduk di meja, melihat kode saya dan mencoba melacak bug. Pengguna telah mengeluh tentang dia selama beberapa minggu sekarang, dan akhirnya saya punya sedikit waktu luang untuk nongkrong.
Tada-a-am! Menemukannya! Diperbaiki!
Saya duduk di belakang sebuah partisi di tempat kerja saya di sebuah ruangan yang diterangi matahari dan berteriak kepada yang lain: "Saya memperbaiki bug!"
Selasa depan, ketika pengguna melihat rilis, mereka pasti akan menghargai upaya saya! Tetapi untuk ini kita harus berkemas dan mencoba untuk melepaskan rilis dari tempat ... Mungkin kita akan berhasil jika tidak ada yang terjadi ...
Baiklah, oke,
jika rilisnya masih akan datang Selasa depan, pengguna pasti akan menghargainya!
Begitulah cara saya melakukan penempatan di pekerjaan kampus pertama saya, sebagai programmer junior.
Sejak itu, banyak yang berubah.
Sekarang saya menggunakan pengembangan berbasis trunk dan menggunakan modul berkali-kali sehari. Ketika saya mengirim Permintaan Tarik, bot akan memposting komentar yang sesuai dengan kode ulasan dengan lingkungan yang dikumpulkan setelah tes telah lulus dan build telah dikumpulkan.
Hari ini Anda tidak perlu berteriak melalui partisi di kantor.
Semakin banyak kebebasan yang Anda berikan kepada programmer - kebebasan untuk mengontrol bagian-bagian infrastruktur yang mereka butuhkan - semakin mudah bagi Anda untuk bekerja sebagai insinyur DevOps.
Dalam pelajaran pertama, kami melihat bahwa untuk memperbarui dalam produksi cukup untuk mengubah satu digit dan melakukan. Dalam dunia yang ideal di mana kita memasukkan aplikasi ke dalam bagan, setiap programmer dalam tim memiliki kesempatan untuk mempengaruhi cara alat bekerja pada tahap produksi. Kubernet memahami grafik sebagai deskripsi kontainer, itulah sebabnya mereka menggambarkan persyaratan sumber daya.
Logikanya kira-kira seperti ini: Saya tidak bisa menebak berapa banyak memori atau pengaturan CPU apa yang diperlukan untuk layanan baru (dan saya pikir saya bukan satu-satunya). Oleh karena itu, saya juga menggunakan pemantauan dan peringatan dengan aturan yang menurutnya tim saya dan saya akan diberitahu di Slack bahwa pengaturan ini perlu diubah. Artinya, sistem akan memberi tahu Anda tentang pengaturan yang diperlukan saat kami menerapkannya. Saya biasa duduk berjam-jam, mengirim permintaan melalui Prometheus dan menyesuaikan pengaturan, sama seperti saya dulu memilih shell. Dan sekarang saya telah belajar untuk melakukan segalanya dengan bijak.
Saya sudah dapat mendengar Anda berkata: "Kedengarannya terlalu rumit!" Tidak. Cukup atur grafik.
Jika Anda dapat mengotomatiskan atau menyederhanakan sesuatu - silakan. Misalnya, bagaimana jika Anda dapat menetapkan jalur DNS dengan hanya menggunakan layanan dengan label "expose: true"? Di sinilah operator muncul. Ini adalah alat Kubernet yang lebih canggih, dan Anda harus mengetahuinya. Tapi jangan terlalu detail.
Pelajaran 3. Produksi adalah mitos
Ini adalah wahyu yang nyata bagi saya. Saya harus melihat sesuatu dari sudut yang berbeda, jadi dengarkan baik-baik.
Selama lebih dari sepuluh tahun, saya berpikir bahwa di dunia hanya ada beberapa jenis lingkungan. Dalam skenario paling sederhana, ada pementasan dan produksi lingkungan. Pertama dikerahkan ke pementasan, kemudian diuji, pindah ke tahap berikutnya, dikerahkan, diuji dan sebagainya. Segera setelah semuanya macet - putranya terintegrasi - Anda dapat mulai berproduksi.
Saya mengikuti pola ini tahun demi tahun dan tidak pernah sekalipun meragukannya. Selalu begitu.
Dan skema ini adalah cara lain yang tidak produktif untuk menyingkirkan cangkang.
Intinya, bagan adalah bagan ketergantungan. Ini dapat digunakan untuk mewakili lingkungan, dan kemudian proses penyebaran dalam produksi turun ke penggelaran satu bagan tunggal.
Jika setiap tim, proyek, atau grup yang terhubung dengan konteks umum memiliki bagan sendiri, beberapa lingkungan muncul yang memungkinkan Anda untuk mengelompokkan dan memperbarui semua layanan dalam satu transaksi.
Jangan menganggap produksi sebagai lingkungan besar yang mencakup semuanya, padahal itu adalah produksi kecil.
Perubahan besar menakutkan dalam skalanya. Dan jika Anda memiliki beberapa lingkungan pengembangan kecil, Anda dapat mengisolasi perubahan dan membuat sistem lebih fleksibel.
Selain itu, jika semuanya diatur dalam bentuk bagan, variabel akan ditetapkan dan dapat diubah dari luar, dengan cara yang sama. Misalnya, untuk menghubungkan cluster kafka yang kurang kuat ke praproduksi, di mana tidak diperlukan, Anda hanya perlu mengubah konfigurasi.
Pelajaran 4. Transfer semuanya ke cluster dan buat cadangan keseluruhan
Jadi, kami memilah-milah produksi. Apa yang harus dilakukan dengan basis data? Dengan Kafka? Dengan masalah keamanan?
Jika Anda membaca dengan seksama, maka ingat: Saya menulis bahwa database dapat dimasukkan dalam paket grafik.
Kubernetes memiliki API terpisah untuk menjalankan basis data dan aplikasi stateful lainnya dalam bentuk yang nyaman -
StatefulSets.Inti dari Kubernetes adalah meningkatkan keandalan peluncuran kontainer. Dengan itu dan menggunakan alat Velero (diinstal melalui Helm Chart), Anda dapat membuat cadangan dari seluruh cluster Kubernetes, bersama dengan disk yang melekat padanya, misalnya, yang dibuat oleh StatefulSet, dan mengembalikan semuanya dengan satu perintah. Selain itu, mudah untuk mengkonfigurasi pencadangan otomatis sesuai jadwal.
Cadangan, pemulihan dalam satu tim, dan manajer Kubernetes akan membantu Anda menggunakan kluster yang sama sekali baru dan memulihkan cadangannya hanya dengan dua tim. Maksimal tiga, jika Anda pertama kali ingin membuat cadangan baru.
Alih-alih berpikir di server, Anda dapat beroperasi di seluruh cluster.
Apakah pra-produksi mengganggu? Keluarkan dari pandangan - ke jarak pencadangan, pemulihan, dan perubahan DNS.
Pelajaran 5. VPN terlalu rumit, ada solusi yang lebih mudah
Apakah Anda pernah menggunakan VPN dengan senang hati?Tidak, sungguh
Apakah itu mungkin?Google telah melakukan upaya seperti itu. Tetapi beberapa tahun yang lalu, perusahaan mengumumkan bahwa mereka tidak akan menggunakan VPN. Saya pikir mereka juga tidak menikmatinya.
Google beralih ke jaringan tanpa kepercayaan. Mereka tidak memiliki kunci master yang cocok untuk jaringan apa pun, tetapi di pintu masuk ke setiap layanan ada kunci dalam bentuk layar masuk SSO. Ingin masuk ke layanan pemantauan? Masuk menggunakan nama pengguna dan kata sandi perusahaan Anda.
Hanya diperlukan sedikit perubahan: alih-alih menggunakan VPN untuk otorisasi, gunakan proxy.
VPN juga menghosting tautan manajemen Kubernetes di jaringan pribadi, sedangkan SSO tidak. Tetapi mereka memiliki mekanisme otorisasi mereka sendiri. Dalam kasus Google Cloud dan AWS, ini adalah Identity and Access Management (IAM) dan kemampuan untuk memasukkan daftar putih alamat IP.
Jika mungkin untuk bekerja dengan arsitektur yang kurang besar tanpa banyak kerugian, mengapa tidak? Jadilah seperti Google: Pindah dari VPN ke sistem “tidak percaya”.
Pelajaran 6. Mengatur, Mengotomatisasi, dan Menaklukkan
Ah, sepertinya bagi Anda bahwa sistematisasi itu lama? Omong kosong! Di masa depan, ini akan menghemat berjam-jam, berhari-hari, dan bahkan berminggu-minggu. Untuk bekerja!
Sistematisasi adalah satu-satunya cara realistis untuk menciptakan kembali infrastruktur lebih dari sekali.
Jika setiap item pengaturan dapat ditingkatkan dengan mengubah dan melakukan sesuatu di git, pada dasarnya seluruh organisasi teknologi Anda bersifat deklaratif. Setiap pengembang dengan akses ke git dapat dengan mudah memelihara sistem apa pun dalam kondisi kerja.
Untuk melakukan ini, gunakan beberapa repositori kecil. Monorepos membuat orang memotong sudut dan bergantung pada struktur dengan kepentingan artifisial. Alih-alih, lebih baik menggunakan banyak repositori kecil yang bisa Anda tautkan nanti.
Teman saya Matt dan saya sedang membuat alat yang disebut
meta untuk membantu melakukan ini pada tahap pengembangan. Helm melakukan ini pada tahap produksi: baginya semuanya adalah bagan ketergantungan!
Kesimpulan
Jangan mengambil cangkang dari sepotong telur demi sepotong. Kocok dan putar.