Apa itu server yang tidak bisa diubah?

Ada beberapa pertanyaan tentang server yang tidak dapat diubah , seperti:

• Bagaimana menerapkan pola server tidak berubah tanpa kehilangan kemampuan untuk melakukan post-mortem?
• Apa peran yang dimainkan oleh alat Manajemen Konfigurasi dalam infrastruktur yang tidak dapat diubah?

Tampak jelas bahwa itu ada hubungannya dengan server (bagian yang saya dapatkan). Dan hanya mencerna tata bahasa abadi , saya akan berpikir itu ada hubungannya dengan "tidak mungkin untuk bisu ". Jika tebakan itu dekat, saya tidak tahu apa yang sebenarnya tidak bisa diredam (dan saya ragu itu ada hubungannya dengan kartu suara atau sesuatu ...).

Pertanyaan saya :

• Apa yang sebenarnya merupakan "server yang tidak dapat diubah" (dalam konteks DevOps)?
• Mengapa mereka digunakan?

Immutability adalah istilah yang sering digunakan dalam lingkaran ilmu komputer, yang umumnya bermuara pada "tidak mungkin berubah setelah penciptaan". Biasanya digunakan dalam referensi paralelisme, konkurensi, dan keamanan utas.

Diskusi tentang topik itu menarik, tetapi umumnya dapat ditemukan di tempat lain di Stack Overflow . Saya menahan keinginan untuk terjun ke sini. Konsep kuncinya adalah 'tidak mungkin diubah setelah penciptaan'.

Bayangkan jika, di Amazon, Anda menggunakan layanan web dengan memanggangnya ke dalam Gambar Mesin (AMI - contoh yang sudah dibuat sebelumnya, Anda dapat berulang kali melakukan penyediaan ulang). Ini terhubung ke database backend melalui kredensial yang dikeluarkan dari registri saat startup. Ini membuang log ke alat logging seperti Splunk. Untuk operasi sehari-hari yang normal, Anda tidak punya alasan untuk ssh ke dalam kotak ini. Jika Anda perlu meningkatkan layanan itu, Anda cukup membuat lebih banyak instance AMI itu dan menyesuaikan penyeimbang beban. Menurunkannya hanyalah penghancuran instance dan load balancers.

Untuk operasi sehari-hari, kotak ini tidak memiliki alasan untuk berubah . Kami hanya bisa menjalankan lebih dari AMI.

Apa yang terjadi ketika Anda perlu menyediakan patch keamanan tingkat OS? Ini adalah ketika Anda memiliki keputusan untuk membuat ... apakah Anda membuat AMI baru dengan tambalan diinstal dan memindahkan semua instans yang berjalan, atau apakah Anda ssh ke gambar yang ada dan memperbarui tambalan? Ada banyak orang yang hanya akan masuk. Para penganut 'arsitektur abadi' hanya meneriaki saya karena bahkan menyarankan hal seperti itu adalah mungkin.

Immutabilis (jika ada kata seperti itu) menganjurkan memanggang ami baru. Mereka menganjurkan menghapus semua alasan untuk ssh ke dalam mesin. Mereka menganjurkan bahwa konfigurasi mesin spesifik apa pun harus terjadi pada startup mesin itu dengan menarik detail konfigurasi dari repositori. Ini adalah ungkapan pamungkas 'ternak, bukan hewan peliharaan'.

Arsitektur yang tidak dapat diubah secara khusus tentang konfigurasi mesin yang tidak memiliki alasan untuk berubah setelah pembuatan gambar mesin . Jika sesuatu perlu diubah, buat gambar contoh baru, matikan yang lama, buka yang baru.

Teknologi cloud menggeser batas antara perangkat keras dan perangkat lunak sehingga banyak operasi teknis yang sebelumnya merupakan warga negara eksklusif perangkat keras juga merupakan subjek dari bidang perangkat lunak. Lingkungan komputasi bersama mungkin setua komputer itu sendiri ¹ tetapi teknologi cloud dapat mempopulerkannya dengan menawarkan metafora yang nyaman dan akrab untuk berinteraksi dengan mereka: pengguna cloud memesan sebuah contoh, komputer lengkap atau meniru, sedangkan lingkungan komputasi berbagi yang lebih lama memiliki semua kemungkinan yang ditetapkan dengan batasan yang sangat berat dan "program Anda harus diunggah di server FTP itu, akan berjalan di lingkungan X (biasanya dengan versi lama dari perangkat lunak apa pun yang ingin Anda gunakan), selama paling lama 60 menit" mungkin terdengar asing bagi pengguna lama atau pengguna sebenarnya. pusat komputasi.

Konsekuensi praktis dari pergeseran ini adalah bahwa prosedur penyebaran sekarang dapat diwakili oleh artefak perangkat lunak. (Prosedur penyebaran adalah petunjuk yang memberi tahu cara mengatur infrastruktur, dengan basis data, server web atau apa pun yang termasuk infrastruktur ini, bersama dengan jaringan tempat mereka beroperasi.) Ditujukan dengan lensa baru ini, pemeliharaan manual server cukup mirip tambalan manual kode produksi - yang hanya dalam hal yang sangat jarang hal yang diinginkan. Pemeliharaan manual rentan untuk memperkenalkan perbedaan antara sistem yang benar-benar berjalan dalam produksi dan kode yang menggambarkan sistem ini, yang pada gilirannya berarti perilaku yang tidak dapat direproduksi dan analisis bug yang tidak mungkin, perbaikan dua bug, dan bencana lainnya.

The Pola Server abadi hanyalah transposisi untuk operasi awan mantra di atas, sesuai dengan yang kita harus menghindari perawatan manual dari program yang berjalan. Alih-alih mengonfigurasikan severs secara manual, pola server yang tidak berubah merekomendasikan untuk melakukan konfigurasi otomatis ini.

Rasa implementasi

Sementara gambaran umum dari pola server yang tidak dapat diubah cukup jelas, ada banyak nuansa implementasi. Sebagai contoh, beberapa pendekatan menyarankan untuk tidak memperbarui server sama sekali tetapi untuk mengganti server secara sistematis . Ini karena memperbarui situasi hasil di mana penyebaran terdiri dari server telah dimulai pada beberapa waktu yang berbeda dan telah melalui beberapa, proses pembaruan yang berbeda yang menyiratkan serangkaian server tidak homogen dan dapat menyebabkan perbedaan halus dalam bagaimana server menangani pekerjaan mereka. Poin variasi populer kedua adalah disiplin mengenai akses jarak jauh ke server. Beberapa suka menonaktifkan akses administratif sepenuhnya jauh ke server, untuk menjamin bahwa pemeliharaan manual tidak pernah terjadi.

Catatan sejarah

Sepengetahuan saya, istilah "server tidak berubah" telah dipopulerkan oleh Kief Morris tetapi idenya sendiri jauh lebih tua. Pada tahun 1999 penjara FreeBSD telah mempopulerkan gagasan untuk mengotomatiskan sepenuhnya konfigurasi lingkungan komputasi sekali pakai, ini adalah bagaimana saya mulai menerapkan pola "server tidak berubah" bertahun-tahun sebelum saya mendengar nama ini untuk menggambarkan teknik ini.

Ketidakmampuan, dengan kedok ketidakmampuan fisik berdasarkan CD-ROM, juga telah menjadi langkah populer untuk memproduksi sistem komputasi tepercaya. Ini tidak salah dengan pola server yang tidak dapat diubah.

Server yang tidak dapat diubah adalah server yang tidak dapat membuat perubahan (selain pembaruan dan patch keamanan idealnya). Alih-alih mengubah perangkat lunak di server, Anda menambah server baru dengan perangkat lunak yang diinginkan dan kemudian mengakhiri yang lebih lama.

Konsep ini membantu memastikan bahwa pengujian, pengembangan, dan server QA Anda semuanya identik, yang penting karena berbagai alasan di luar cakupan pertanyaan ini. Manfaat lain dari server yang tidak dapat diubah adalah kemampuan untuk mengembalikan aplikasi ke server yang lebih lama. Sebagai contoh, saya perlu mengganti K pada server produksi 1, jadi saya spool server 2 dan ganti K. Sekarang setelah 10 menit, saya perhatikan bahwa K memecahkan sesuatu dengan aplikasi saya, daripada harus memperbaikinya segera yang bisa memakan waktu berjam-jam dan berpotensi menyebabkan downtime untuk pelanggan saya, saya mengarahkan lalu lintas kembali ke server 1, sementara saya mencari tahu apa yang salah dengan 2.

Penjelasan terbaik dapat ditemukan (seperti biasa) pada artikel bliki Martin Fowler tentang Server Tidak Berubah .

Server, baik itu perangkat keras atau server virtual di cloud, biasanya memiliki sistem operasi dan aplikasi yang berjalan di atasnya.

Seringkali aplikasi, dan komponen dari sistem operasi, memerlukan konfigurasi dan memerlukan perubahan untuk diterapkan. Misalnya tambalan keamanan, penyebaran versi baru aplikasi dan perubahan konfigurasi.

Ketika Anda menganggap bahwa setiap perubahan adalah mutasi pada keadaan server, istilah itu immutablemulai lebih masuk akal. Ini berarti bahwa tidak ada mutasi yang diizinkan pada server seperti itu.

Ini sering terjadi, ketika orang terlibat dalam mengubah keadaan server - baik itu penyebaran versi, atau perubahan konfigurasi, atau jalur keamanan. Hasilnya adalah server yang tidak lagi berfungsi seperti yang diharapkan. Misalnya, aplikasi mungkin tidak berjalan sekarang karena kesalahan konfigurasi, dll.

Inilah sebabnya mengapa praktik untuk membuat server yang tidak dapat diubah didirikan. Dengan server yang tidak dapat diubah , gambar server dibuat dengan semua konfigurasi, tambalan, versi aplikasi yang dibundel. Kemudian gambar server itu dapat digunakan untuk membuat server di berbagai lingkungan.

Lingkungan pertama di mana gambar tersebut digunakan, akan menjadi lingkungan di mana gambar dapat diuji untuk bekerja. Setiap kelainan terdeteksi, dan hanya dengan demikian gambar tersebut dapat dipromosikan ke lingkungan produksi untuk menggantikan server di sana dengan versi baru (yang diketahui bekerja dengan baik).

Setelah proses membuat gambar dan mempromosikan gambar diotomatiskan, Anda mendapatkan proses yang sangat tahan terhadap kegagalan yang melibatkan sedikit usaha manusia dan peluang yang sangat rendah untuk memperkenalkan kegagalan ke dalam layanan Anda.

Seringkali server yang tidak dapat diubah bahkan tidak menyertakan cara untuk "memasukkan" mereka, seperti misalnya server ssh tidak ada. Dalam hal ini juga sering terjadi bahwa semua metrologi server (metrik, log) dikirimkan ke sistem di luar seperti database metrik atau layanan agregasi log.

Dengan kontainer (lihat: Docker ) ada juga proses untuk membuat gambar, dan kemudian memunculkannya ke dalam wadah yang sedang berjalan. Ini cukup sering digantikan oleh wadah baru berdasarkan gambar yang diperbarui, dan tidak pernah bermutasi. Artinya tidak ada manusia yang masuk ke dalam wadah untuk "memperbaiki sesuatu" dengan memperkenalkan perubahan.

Mari kita mulai dengan invers, apa itu server yang bisa berubah?

Secara tradisional, infrastruktur server yang dapat berubah adalah infrastruktur yang terus dimodifikasi dan diperbarui di tempat. Anda dapat mengamankan shell ke dalamnya, memutakhirkan paket, mengonfigurasinya, menginstal layanan, dan menggunakan kode baru untuk itu. Inilah yang membuatnya bisa berubah, Anda dapat bermutasi atau memodifikasinya.

Infrastruktur yang tidak dapat diubah adalah paradigma infrastruktur lain di mana server tidak pernah dimodifikasi setelah dikerahkan. Jika sesuatu perlu diperbarui, diperbaiki, atau dimodifikasi dengan cara apa pun, server baru yang dibangun dari gambar umum dengan perubahan yang sesuai disediakan untuk menggantikan yang lama. Setelah divalidasi, mereka mulai digunakan dan yang lama dinonaktifkan.

Mengapa mereka digunakan? Manfaat dari infrastruktur yang tidak dapat diubah adalah konsistensi dan keandalan infrastruktur Anda yang lebih baik dan proses penyebaran yang lebih sederhana dan lebih dapat diprediksi serta mengurangi masalah server umum dalam infrastruktur yang dapat berubah, seperti downtime dari server yang crash atau apa pun.

Tetapi Anda harus tahu bagaimana cara menyediakannya secara efisien melalui otomatisasi penyebaran yang komprehensif dan penyediaan server yang cepat.

Bayangkan Anda menambang bitcoin, Anda tidak ingin downtime jika server Anda mogok, Anda akan membutuhkannya kembali secepat mungkin, sehingga infrastruktur yang tidak dapat diubah seharusnya menjadi solusinya.