Praktik yang baik untuk mengelola pembaruan paket untuk banyak server CentOS

Sebagai bagian dari pekerjaan saya, saya mengelola beberapa server CentOS 5, menggunakan boneka untuk pengaturan utama. Sekitar setengah dari server kami memiliki pengaturan standar untuk hosting berbagai situs Django, sementara sisanya adalah campuran mash aplikasi.

Saya secara bertahap memilah praktik hosting kami, dan sekarang saya sampai pada titik bagaimana mengelola pembaruan keamanan di tingkat OS. Saya khawatir hanya memiliki pekerjaan cron melakukan yum -y updatetetapi juga tidak ingin harus berkeliling setiap server dalam waktu dan meninjau setiap paket dengan pembaruan yang tersedia, karena itu akan memakan waktu.

Jadi saya bertanya-tanya apakah ada jalan pintas atau praktik kerja yang baik yang akan meminimalkan risiko yang terlibat dan meminimalkan jumlah waktu yang harus saya habiskan. Atau dengan kata lain apakah ada alat atau praktik yang dapat mengotomatisasi banyak pekerjaan sambil tetap memberikan kontrol.

Langkah-langkah yang saya putuskan sejauh ini:

• nonaktifkan semua repositori pihak ketiga dan atur repositori kita sendiri sehingga saya dapat mengontrol pembaruan apa yang terjadi di sana.
• kami memiliki server pentas untuk (sebagian besar) server produksi kami di mana saya dapat melakukan pengujian (tetapi berapa banyak pengujian yang cukup untuk pengujian?)

Juga perhatikan bahwa saya telah melihat plugin keamanan yum tetapi tidak bekerja pada CentOS .

Jadi, bagaimana Anda mengelola pembaruan untuk sejumlah besar server CentOS yang menjalankan beragam aplikasi yang heterogen?

Di sebagian besar lingkungan saya, biasanya skrip kickstart dan post-install untuk mendapatkan sistem utama dan terkini dengan pembaruan pada saat itu. Saya biasanya akan memiliki repo lokal yang disinkronkan dengan cermin CentOS setiap hari atau setiap minggu. Saya cenderung untuk membekukan paket kernel kapan saja saat waktu instalasi dan memperbarui paket secara individual atau sesuai kebutuhan. Seringkali, server saya memiliki periferal yang memiliki driver yang terkait erat dengan versi kernel, jadi itu pertimbangan.

CentOS 5 telah jatuh tempo ke titik di mana pembaruan konstan tidak diperlukan. Tetapi juga perlu diingat bahwa CentOS 5 sedang mereda. Tingkat pembaruan agak melambat, dan sifat pembaruan lebih sejalan dengan perbaikan bug dan lebih sedikit tentang perubahan fungsi utama.

Jadi dalam kasus khusus ini, hal pertama yang dapat Anda lakukan adalah membangun mirror / repo lokal. Gunakan manajemen konfigurasi yang ada untuk mengontrol akses ke repo pihak ketiga. Mungkin menjadwalkan kebijakan untuk memperbarui layanan kritis atau layanan yang dihadapi publik (ssh, http, ftp, dovecot, dll.) Segala sesuatu yang lain akan memerlukan pengujian, tetapi saya merasa bahwa sebagian besar lingkungan tidak berjalan dengan sistem yang sepenuhnya diperbarui / ditambal.

Ada banyak alat yang dapat membantu dengan ini! Secara umum sistem paket dan paket mana yang digunakan ditangani oleh manajemen konfigurasi. Alat-alat ini biasanya mencakup lebih dari sekadar yum dan rpms, dan akan menghemat waktu Anda dan mencegah banyak sakit kepala!

Alat yang paling saya kenal adalah boneka yang saya gunakan untuk mengelola hampir setiap konfigurasi di lingkungan saya. Berikut adalah beberapa contoh boneka untuk mengelola yum secara khusus:

http://people.redhat.com/dlutter/puppet-app.html

Ada sejumlah alat manajemen konfigurasi yang tersedia saat ini, ini memiliki grup pengguna yang cukup besar:

• Cfengine http://cfengine.com/cfengine3
• Puppet http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (Beberapa orang yang saya kenal baru-baru ini menerapkan ini dan menyukainya)

Menerapkan ini dalam lingkungan akan menambah tahun hidup Anda. Ini mengurangi jumlah sakit kepala dari sistem yang tidak terkonfigurasi dan memungkinkan peningkatan / pembaruan yang mudah. Sebagian besar alat ini juga dapat memberikan fungsionalitas tingkat audit juga yang dapat sangat mengurangi waktu perbaikan untuk kesalahan konfigurasi.

Sehubungan dengan pertanyaan Anda tentang pengujian, saya telah menggunakan lingkungan pementasan yang kami arahkan ke beberapa pelanggan (biasanya pelanggan beta atau sebagian kecil dari lalu lintas produksi). Kami biasanya membiarkan cluster ini menjalankan kode baru setidaknya selama beberapa hari, hingga satu minggu (tergantung pada gravitasi perubahan) sebelum kami menyebarkannya ke produksi. Biasanya saya menemukan pengaturan ini bekerja paling baik jika Anda mencoba dan mencari tahu berapa lama sebagian besar kesalahan ditemukan. Dalam sistem yang banyak digunakan ini bisa menjadi masalah jam, di sebagian besar lingkungan yang saya lihat seminggu cukup lama untuk menemukan bahkan bug yang tidak biasa dalam staging / QA.

Satu bagian yang sangat penting tentang pengujian adalah replikasi data / penggunaan. Anda menyebutkan bahwa Anda memiliki versi pementasan sebagian besar perangkat keras produksi Anda. Apakah mereka juga memiliki salinan data produksi yang identik? Bisakah Anda memutar ulang beban produksi yang menentangnya? Bisakah Anda menjadikannya bagian dari kluster produksi menggunakan traffic mirroring? Ini biasanya menjadi trade-off langsung antara jumlah sumber daya yang bersedia dikeluarkan oleh bisnis untuk pengujian / QA. Semakin banyak pengujian yang lebih baik, cobalah untuk tidak membatasi diri (dengan alasan) dan melihat apa yang akan didukung bisnis (kemudian menemukan cara untuk melakukan 10% lebih banyak).