Apa itu server yang tidak bisa diubah?


23

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

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?

4
tidak mungkin untuk bermutasi
Evgeny

3
@ Evgeny: ggggggggggrrrrrrrrrrrrrrrrr, saya sudah dekat, tapi benar-benar salah dengan tebakan bisu saya (tolong jangan menertawakan saya ...).
Pierre.Vriens


Saya minta maaf untuk menjadi sangat tumpul, tetapi apakah pencarian internet sederhana untuk mendefinisikan "abadi" yang memberatkan? Saya mendapatkan pertanyaan yang lebih besar dari itu, tetapi mencari arti kata daripada menebak mungkin memberi Anda awal yang baik.
Adrian

@Adrian tidak masalah dengan jumlah yang tumpul (karena saya menderita ESL, saya harus google itu untuk benar-benar mendapatkan persis tumpul dari tumpul). Namun saya ingin tahu apakah Anda mengetahui pertanyaan meta.SA ini ? Selain itu, saya lebih suka belajar dari para ahli DevOps, daripada alternatif seperti Wikipedia.
Pierre.Vriens

Jawaban:


19

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.


"Tutup yang lama, buka yang baru". Atau jika arsitektur Anda memungkinkan, buka yang baru, sesuaikan penyeimbang beban, matikan yang lama. Dengan begitu Anda dapat melakukannya kapan pun Anda suka, bahkan di tengah waktu puncak. :)
Tim Malone

Kekekalan jika dari pemrograman fungsional (1960-an), sekarang disadari bahwa itu tidak hanya mengurangi bug (sesuatu yang sering tidak dipedulikan), tetapi juga membantu dengan konkurensi.
ctrl-alt-delor

Saya benar-benar tertarik pada jawaban tambahan yang fantastis ini tentang bagaimana agen pemantau atau perangkat lunak tambahan yang mungkin sulit untuk dipasangkan ke aslinya mungkin ikut bermain di sini. Sebagai contoh, perangkat lunak pemantauan APM yang harus mendeteksi lingkungan mesin baru setelah pembuatan dan mengubah parameter. Saya menjelajahi SSM dan otomatisasi untuk menggunakan ini di AWS, tetapi telah menemukan sangat sedikit untuk membahas hal yang tidak dapat diubah dengan AMI / gambar ketika berhadapan dengan agen tambahan yang mungkin dipasang di lain waktu.
SheldonH

10

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 1 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.


1 Jika kita tidak menghitung tabel alat tenun otomatis atau organ rol sebagai komputer.


1
Wow, penjelasan menarik lainnya, merci! Sekarang saya benar-benar mendapat kesulitan untuk memutuskan jawaban mana yang harus diterima (sabar, tolong, dan ketahuilah bahwa saya hanya dapat menandai 1 pada maks, meskipun saat ini saya sama sekali tidak memutuskan yang mana .. .).
Pierre.Vriens

1
Avec plaisir! - Saya pikir itu ide yang baik untuk menunggu beberapa hari untuk menerima jawaban, ini meningkatkan kemungkinan pengguna menulis lebih banyak jawaban.
Michael Le Barbier Grünewald

9

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.


Hm, menarik ... Saya perlu waktu untuk mencerna ini lebih lanjut ... Tahu ungkapan seperti "1 jawaban untuk pertanyaan memicu 10 pertanyaan baru?" ...
Pierre.Vriens

1
Praktek untuk "rollback" yang cepat sering disebut "Deployment Biru / Hijau" (juga merah / hitam, tergantung siapa yang melakukan panggilan).
Evgeny

@ Evgeny dan yang lebih buruk dari semuanya, bisa disebut penyebaran A / B juga, garis blur dengan eksperimen A / B. (dan bahkan lebih buruk lagi, ketika jenis penyebaran ini, melipatgandakan versi dari aplikasi yang sama, dapat langsung melakukan percobaan A / B alih-alih bendera fitur)
Tensibai

Saya selalu diberitahu bahwa Penyebaran Biru / Hijau adalah untuk penyebaran pembaruan ke aplikasi yang ada, BUKAN server itu sendiri. @ Evgeny
Turtle

Iya nih. Anda dapat bertukar server, wadah, aplikasi dan yang lainnya dan masih menyebutnya Biru / Hijau . Saya pikir pantas mendapatkan Q&A sendiri di sini. Hanya ingin menunjukkan bahwa cara Anda menjelaskan kemunduran dalam jawaban Anda cukup sering disebut B / G.
Evgeny

6

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.


Penjelasan yang menarik, mungkin Anda ingin sedikit bermutasi , jika Anda bisa, dan jika masuk akal, untuk menguraikan sesuatu yang saya yakini terkait, misalnya, "menyiram" suatu sistem. Yang saya pikir adalah bahwa Anda membiarkan (kurang lebih) siapa pun "bermain" dengan sesuatu, dan memperingatkan mereka di muka bahwa (misalnya) setiap malam ada semacam reset ke beberapa keadaan awal. Kedengarannya input untuk reset seperti itu adalah ... euh ... apa yang akan saya katakan ... benar: thingie abadi yang dapat digunakan untuk itu.
Pierre.Vriens

2
Menjalankan layanan yang mengembalikan server ke kondisi yang diketahui (seperti Chef / Puppet / Ansible / etc ...), hanya berarti Anda tidak menggunakan server yang tidak dapat diubah. en.wikipedia.org/wiki/Promise_theory bagus, tetapi martinfowler.com/bliki/ImmutableServer.html bahkan lebih baik.
Evgeny

Anda menggodaku, saya percaya, atau lebih tepatnya "menantang saya" (untuk mencoba menemukan batas pertanyaan harian). Tidakkah ada juga aturan SE yang mengatakan "Anda hanya bisa mengajukan 50 pertanyaan dalam 30 hari"?
Pierre.Vriens

0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.