Memperbarui produksi Ubuntu mengemas dos dan tidak boleh dilakukan

Sering kali saya masuk ke kotak web / db / tools produksi dan melihat pesan khas:

30 paket dapat diperbarui. 16 pembaruan adalah pembaruan keamanan.

Pertanyaan saya adalah, bagaimana Anda semua menangani pembaruan pada kotak Ubuntu produksi Anda? Apakah Anda mengotomatiskan pembaruan ini? Apakah Anda mengatur waktu henti untuk mereka? Masalahnya adalah, Anda tidak pernah tahu kapan pembaruan akan merusak sesuatu, seperti mungkin file konfigurasi yang ada, dll.

Bagian lain dari masalah ini adalah, mengikuti patch adalah 'hal yang baik', tetapi patch dirilis hampir setiap hari. Berapa banyak pemadaman terjadwal yang harus dilakukan jika ada patch keamanan baru yang tersedia setiap hari?

Saya pikir utas jawaban tentang bagaimana Anda mengelola pembaruan Anda akan sangat berguna.

Tidak ada yang istimewa tentang menambal Ubuntu vs Windows, RHEL, CentOS, SuSE, debian, dll.

Keadaan dasar pikiran yang Anda butuhkan saat merancang prosedur tambalan Anda adalah mengasumsikan bahwa sesuatu akan rusak.

Beberapa pedoman dasar yang cenderung saya gunakan saat mendesain pengaturan tambalan adalah:

• Selalu gunakan sistem lokal untuk memusatkan secara internal ke jaringan Anda tempat tambalan diinstal

Ini mungkin termasuk menggunakan WSUS, atau mirror dari <your_os_here>ke mesin manajemen patch internal. Lebih disukai yang dapat secara terpusat menanyakan dan memberi tahu Anda status tambalan yang diinstal pada mesin Anda.

• Pra-tahap instalasi - bila memungkinkan - pada mesin.

Jika memungkinkan, ketika tambalan keluar, minta server pusat menyalinnya ke masing-masing mesin. Ini benar-benar hanya penghemat waktu sehingga Anda tidak perlu menunggu mereka mengunduh DAN menginstal, Anda hanya perlu memulai instalasi selama jendela patch Anda.

• Dapatkan jendela pemadaman untuk menginstal patch, Anda mungkin harus reboot, dan sesuatu mungkin akan rusak. Pastikan pemegang pasak untuk sistem tersebut mengetahui ada tambalan yang dikerahkan. Bersiaplah untuk "ini" tidak berhasil.

Sesuai dengan teori dasar saya bahwa tambalan memecahkan hal-hal, pastikan Anda memiliki jendela pemadaman untuk menerapkan tambalan cukup lama untuk memecahkan masalah kritis, dan mungkin memutar kembali tambalan. Anda tidak perlu harus memiliki orang yang duduk di sana menguji setelah patch. Secara pribadi saya sangat bergantung pada sistem pemantauan saya untuk memberi tahu saya semuanya berfungsi pada tingkat yang sangat minimum yang bisa kita hindari. Tetapi juga bersiaplah untuk masalah kecil yang mengganggu untuk dipanggil ketika orang mulai bekerja. Anda harus selalu memiliki seseorang yang dijadwalkan siap di sana untuk menjawab telepon - lebih disukai bukan orang yang bangun sampai 3 pagi menambal kotak.

• mengotomatiskan sebanyak mungkin

Seperti semua yang lain di IT, skrip, skrip lalu skrip lagi. Script unduhan paket, awal instalasi, mirror. Pada dasarnya Anda ingin mengubah tambalan jendela menjadi tugas bayi duduk yang hanya membutuhkan manusia di sana jika hal-hal rusak.

• Memiliki beberapa jendela setiap bulan

Ini memberi Anda kemampuan untuk tidak menambal beberapa server jika karena alasan apa pun mereka tidak dapat ditambal pada "malam yang ditunjuk". Jika Anda tidak dapat melakukannya pada malam 1, mengharuskan mereka gratis di malam hari 2. Juga memungkinkan Anda menjaga jumlah server yang ditambal pada saat yang sama waras.

Yang terpenting, ikuti terus tambalan! Jika tidak, Anda harus melakukan sendiri patch windows 10+ jam yang sangat besar hanya untuk kembali ke titik di mana Anda terjebak. Memperkenalkan lebih banyak poin di mana segala sesuatunya bisa salah, dan membuat penemuan patch mana yang menyebabkan dan mengeluarkan hal itu jauh lebih sulit.

Bagian lain dari masalah ini adalah, mengikuti patch adalah 'hal yang baik', tetapi patch dirilis hampir setiap hari. Berapa banyak pemadaman terjadwal yang harus dilakukan jika ada patch keamanan baru yang tersedia setiap hari?

Menambal server sebulan sekali atau sebulan sekali adalah - IMHO - tujuan yang sangat dapat dicapai, dan dapat diterima. Lebih dari itu, dan Anda akan terus-menerus menambal server, apalagi dan Anda mulai masuk ke situasi di mana Anda memiliki ratusan tambalan yang perlu diterapkan per server.

Sejauh berapa jendela yang Anda butuhkan sebulan? Itu tergantung pada lingkungan Anda. Berapa banyak server yang Anda miliki? Berapa waktu yang dibutuhkan untuk pengungkit Anda?

Lingkungan yang lebih kecil yaitu 9x5 mungkin bisa lolos dengan satu jendela tambalan sebulan. Toko 24x7 besar mungkin perlu dua. 24x7x365 sangat besar mungkin memerlukan jendela bergulir setiap minggu untuk memiliki satu set server yang berbeda ditambal setiap minggu.

Temukan frekuensi yang cocok untuk Anda dan lingkungan Anda.

Satu hal yang perlu diingat adalah bahwa 100% terkini adalah tujuan yang mustahil dicapai - jangan biarkan departemen keamanan Anda mengatakan sebaliknya. Lakukan yang terbaik, jangan ketinggalan terlalu jauh.

Hal yang harus dilakukan:

1. Ambil Cadangan
2. Pastikan itu cadangan yang dapat dipulihkan (meskipun, keduanya adalah poin umum)
3. Cobalah untuk mengarahkan lalu lintas dari kotak produksi saat Anda meningkatkan.
4. Cobalah untuk memiliki metode akses out-of-band jika semuanya berjalan salah, KVM, konsol serial, akses lokal, atau remote-hand.
5. Uji pada satu server, lalu pastikan semuanya berfungsi, sebelum menyebarkan pembaruan ke lebih banyak server
6. Gunakan boneka jika Anda bisa memastikan nomor versi sama di beberapa server. (Anda juga dapat menggunakannya untuk memaksa peningkatan)
7. Pada server pengujian, perbaiki versi file konfigurasi dengan yang baru (pembaruan diinstal), dan pastikan tidak ada yang akan merusak hal-hal serius. Sepertinya saya ingat bertanya dpkg sebelum menginstal versi baru yang berbeda dari yang diinstal saat ini.

Hal-hal yang harus dihindari:

1. Melakukan pembaruan di tengah hari, atau pukul 09:00 pada hari Senin pagi, atau jam 5 sore pada hari Jumat sore! (terima kasih @ 3 pengaruh!)
2. Memutakhirkan MySQL di server basis data yang sangat besar (memulai ulang bisa memakan waktu lama)
3. Melakukan semua server Anda sekaligus (terutama kernel)
4. Melakukan apa pun yang dapat mengubah / etc / networks (karena Anda dapat kehilangan konektivitas)
5. Pembaruan otomatis yang dapat melakukan hal di atas tanpa Anda berada di sana untuk memeriksa semuanya OK.

Poin lain yang patut dicatat: Jika Anda terbiasa dengan Windows, Anda akan terkejut bahwa sebagian besar pembaruan Linux tidak memerlukan downtime atau reboot. Beberapa melakukannya, seperti pembaruan kernel. Tetapi pembaruan yang membutuhkan boot ulang atau downtime biasanya ditandai seperti itu, dan dapat ditangani pada jadwal yang terpisah.

Mesin Ubuntu kami semuanya menjalankan rilis LTS.

Kami baru saja menginstal semua pembaruan secara otomatis - tentu saja itu bukan "praktik terbaik", tetapi kami adalah toko yang relatif kecil dan tidak memiliki lingkungan pengujian / pengembangan / produksi untuk setiap layanan tunggal. Pembaruan LTS umumnya cukup baik diuji dan invasif minimal.

Upgrade ke rilis baru jelas sedikit lebih terlibat.

Kami menangani pembaruan dengan cara berikut untuk sistem LTS ubuntu:

1. Dapatkan serangkaian tes penerimaan yang memeriksa semua jalur penting dalam perangkat lunak kami
2. Instal peningkatan keamanan tanpa pengawasan pada jam 4 pagi setiap pagi dan segera jalankan tes penerimaan. Jika ada yang gagal, seorang insinyur paged dan memiliki banyak waktu untuk memperbaiki barang-barang atau mundur sebelum jam 9 pagi. Sejauh ini hanya terjadi dua kali dalam lima tahun - LTS sudah teruji dan stabil.
3. Kami secara otomatis menggunakan kembali seluruh infrastruktur kami setiap minggu (di digitalocean) dengan penyebaran biru / hijau, yang menjaga semua paket pada versi terbaru mereka. Jika penyebaran baru gagal dalam tes penerimaan, penyebaran ditahan sampai seorang insinyur dapat men-debug masalah tersebut.

Langkah logis berikutnya bagi kami adalah menghilangkan informasi sesi dalam-memori sehingga kami dapat dengan mudah menggunakan kembali infrastruktur setiap hari atau bahkan beberapa kali per hari tanpa memengaruhi pelanggan dan menghilangkan langkah (2).

Pendekatan ini rendah pemeliharaan dan menghindari pemeliharaan windows sepenuhnya.

Satu hal yang saya sarankan adalah menangani rollback paket. Lihat Transaksi dan Kembalikan dengan Debian untuk saran tentang bagaimana melakukannya, karena kadang-kadang Anda memerlukan perbaikan cepat untuk peningkatan yang merusak sesuatu.