Apakah alat manajemen konfigurasi (Wayang, Koki) mampu menjaga agar paket yang diinstal tetap mutakhir?

Ini mungkin pertanyaan sederhana bagi Anda yang sudah menjalankan alat manajemen konfigurasi. Apakah alat manajemen konfigurasi seperti Wayang atau Chef adalah pendekatan yang tepat untuk menjaga agar paket yang diinstal tetap terbaru?

Misalkan saya menjalankan sejumlah server, sebagian besar didasarkan pada Debian dan Ubuntu. Apakah alat manajemen konfigurasi memudahkan untuk memperbarui paket yang diinstal dari repositori ketika pembaruan keamanan atau perbaikan bug terjadi?

Saat ini saya menjalankan "upgrade tanpa pengawasan" untuk membiarkan sistem secara otomatis menginstal pembaruan keamanan, tetapi saya masih harus terhubung ke server dan aptitude update && aptitude safe-upgradesering menjalankannya . Tentu ini menjadi membosankan, membosankan dan rawan kesalahan semakin banyak server yang ada.

Apakah alat-alat seperti Wayang atau Koki merupakan pendekatan yang tepat untuk menjaga agar paket yang terinstal tetap terbarui? Apakah ada di antara Anda menggunakan alat ini untuk menghindari berjalan secara manual aptitudeatau setara pada 15 server? Saya cukup yakin jawaban untuk pertanyaan-pertanyaan ini adalah "Ya, tentu saja!"

Tetapi di mana saya dapat menemukan informasi lebih lanjut tentang kasus penggunaan khusus ini? Saya belum punya waktu untuk mempelajari Wayang atau Koki secara mendalam, dan contoh buku masak atau kelas hanya menunjukkan contoh-contoh sepele menginstal satu paket tertentu, seperti ssh. Apakah Anda memiliki sumber daya untuk direkomendasikan, selain dari dokumentasi resmi (saya, tentu saja, akan mempelajari dokumen setelah saya tahu mana, jika ada, alat yang tepat untuk saya).

Wayang (saya cukup yakin koki juga) berhubungan dengan repositori perangkat lunak apt-get / yum Anda . Karena mereka melakukan pekerjaan berat mencari tahu paket mana yang tersedia, itu berarti ensure => latesthanya berfungsi untuk Ubuntu / CentOS / Debian sejenisnya. Selama Anda mengatur file yang sesuai dengan benar ( /etc/apt/sources.list, dll).

Anda dapat melakukannya dengan boneka, Anda juga dapat:

ensure => latest,

atau

ensure=> "1.0.2",

untuk menentukan versi terbaru / wajib. yaitu

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

Setidaknya ini berarti Anda dapat menentukan versi yang sama di semua sistem, serta mencegah server dari (berpotensi berbahaya) memutakhirkan diri secara otomatis. Saya telah menggunakan metode ini dalam produksi di sejumlah situs, dan ini bekerja dengan sangat baik.

Menjalankan peningkatan yang tidak dijaga membuat saya sedikit takut, terutama jika mereka meningkatkan paket-paket penting, kernel, pustaka mysql, apache, dll. Terutama jika skrip instalasi mungkin ingin memulai kembali layanan!

Saya pikir ini mungkin pertanyaan yang salah. Tentu saja menggunakan alat manajemen konfigurasi seperti Puppet dan Chef untuk memelihara infrastruktur Anda adalah langkah besar untuk mencoba melakukan semuanya secara manual. Masalah menjaga versi paket Anda tetap mutakhir dan sinkron bukanlah salah satu dari alat ini yang dipecahkan secara langsung. Untuk mengotomatiskan ini dengan benar, Anda perlu membawa sendiri repositori paket di bawah kendali Anda.

Cara saya melakukan ini adalah memelihara repo Yum khusus (untuk Redhat / Fedora / CentOS; repositori APT untuk Debian / Ubuntu) yang berisi paket-paket yang saya pedulikan untuk situs tertentu. Biasanya ini adalah dependensi dari aplikasi itu sendiri (Ruby, PHP, Apache, Nginx, libraries dan sebagainya) dan paket-paket yang sangat penting untuk keamanan.

Setelah Anda mengatur ini (biasanya Anda hanya dapat mencerminkan paket-paket yang diperlukan dari repo hulu untuk memulai), Anda dapat menggunakan sintaks Puppet's "Pastikan => terbaru" untuk memastikan bahwa semua mesin Anda akan mengikuti perkembangan repo.

Adalah bijaksana untuk menggunakan repo 'pementasan' untuk memungkinkan Anda menguji versi paket yang diperbarui sebelum meluncurkannya dengan gembira ke produksi. Ini mudah dilakukan dengan Wayang tanpa duplikasi kode dengan menggunakan templat repositori.

Mengotomatiskan versi paket Anda sangat mendorong Anda untuk menyinkronkan semua sistem produksi Anda, karena mempertahankan beberapa repo dan paket untuk berbagai distro OS, versi dan arsitektur mesin sangat memakan waktu dan cenderung menyebabkan segala macam masalah yang tidak jelas dan tidak kompatibel.

Semua saran ini berlaku sama untuk permata Ruby, telur Python dan sistem paket lainnya yang dapat Anda gunakan.

Saya telah menulis sedikit tutorial Wayang yang akan membantu Anda bangun dan berjalan dengan Wayang dengan cepat. Anda dapat menggunakan definisi repo khusus untuk mesin Anda menggunakan Wayang sebagai langkah pertama dalam mengendalikan versi paket.

Sementara Wayang / Chef yang mungkin pesaing untuk fungsi ini, untuk membuat mereka tetap segalanya pada sistem up-to-date membutuhkan baik jenis kustom atau daftar setiap paket (termasuk yang mendasari sistem perpustakaan seperti libc6) sebagai sumber daya dengan ensure => latest. Untuk kasus khusus pembaruan paket otomatis, Anda mungkin ingin melihat ke dalam cron-aptpaket, yang melakukan apa yang Anda inginkan juga.

Pertanyaan ini sudah lama, tetapi saya pikir saya akan menjawab dengan cara yang terbaru karena jawaban yang ada saat ini tidak tersedia saat itu.

Jika Anda menggunakan boneka atau koki, lihatlah di mcollective. Ini adalah alat yang sangat bagus oleh orang-orang puppetlab yang memungkinkan Anda untuk mengirim perintah ke grup server. http://docs.puppetlabs.com/mcollective/

Ini juga memiliki plugin apt, yang dapat digunakan untuk melakukan pembaruan apt pada sejumlah server: http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

Saya menyadari ini agak terlambat untuk pertanyaan awal Anda, tetapi ini adalah semangat "lebih baik terlambat daripada tidak pernah".

Saya menggunakan Cfengine 3 untuk melakukan ini di beberapa server. Saya menentukan daftar paket yang eksplisit untuk pembaruan otomatis, sehingga menghindari memperbarui semua paket tanpa sedikit pun berhati-hati. Ini bekerja dengan baik, dan cfengine 3 sangat ringan.

Berikut cuplikan janji dari konfigurasi cfengine saya:

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

Semoga ini membantu.

Saya setuju dengan Jonathan. Pendekatan Cfengine 3 bagus karena Anda dapat mengontrol semua aspek manajemen paket tanpa harus mengode ulang pada tingkat rendah.

Kami menggunakan boneka + apt-dater.

Anda juga dapat menggunakan alat manajemen paket seperti Canonicals Landscape yang dirancang untuk mengelola dan memantau sistem Ubuntu / Debian. Ini mengelola beberapa sistem, memungkinkan Anda untuk memperbaruinya secara bersamaan dan memberikan beberapa kemampuan pemantauan dasar.

Pembaruan keamanan

Secara umum saya pikir ini paling sederhana untuk menggunakan Ansible atau serupa untuk mengatur paket upgrade tanpa pengawasan yang kuat untuk Ubuntu / Debian (atau yum-cronuntuk RHEL / CentOS). Anda dapat menggunakan Wayang, Koki atau alat-alat lainnya, tetapi saya akan membahas Ansible di sini.

• unattended-upgrades dapat digunakan untuk membuat pembaruan non-keamanan pada saat yang sama jika Anda mau, yang jauh lebih mudah daripada menjalankan perintah via Ansible setiap hari.

• unattended-upgradesmenangani pembaruan otomatis setiap hari, dan biasanya dibatasi hanya untuk pembaruan keamanan (untuk meningkatkan stabilitas). Jika server memerlukan reboot setelah pembaruan, alat ini dapat melakukan reboot otomatis pada waktu tertentu.

Jika reboot Anda lebih kompleks, unattended upgradesdapat mengirim email kepada Anda, dan itu juga menciptakan /var/run/reboot-required, sehingga Ansible (atau serupa) dapat mengelola reboot pada waktu yang tepat (mis. Rolling reboot dari sekelompok web atau server DB untuk menghindari downtime, menunggu masing-masing server menjadi tersedia pada port TCP tertentu sebelum melanjutkan).

Anda dapat menggunakan peran yang dimungkinkan seperti jnv.unattended-upgrade untuk sistem Ubuntu / Debian, atau keamanan geerlingguy.security yang sederhana namun efektif , yang juga mencakup RHEL / CentOS (dan mengeraskan konfigurasi SSH).

Jika pembaruan keamanan yang cepat kurang penting, Anda dapat menempatkan mereka melalui proses pengujian pada server yang kurang penting terlebih dahulu, dan jalankan unattended-upgradeperintah setelah tes menunjukkan tidak ada masalah - namun sangat jarang perbaikan keamanan yang berorientasi server menyebabkan masalah, pada saya pengalaman.

Pembaruan umum

Pembaruan selain keamanan harus melalui integrasi dan proses pengujian normal terus menerus, untuk memastikan hal-hal tidak rusak.

Saya telah melihat aptitude safe-upgrademenyebabkan masalah serius pada server di masa lalu, jadi sebaiknya tidak menjalankan ini secara otomatis, sedangkan pembaruan keamanan umumnya cukup aman.