Manajemen konfigurasi untuk 'satu server multi admin'

Kami telah menyiapkan server yang menjalankan infrastruktur untuk asosiasi kecil. Sejauh ini, kami sudah mencoba mengelola konfigurasi dengan Ansible, tetapi itu belum berhasil. Mungkin kita salah melakukannya.

Pada prinsipnya, idenya adalah bahwa server ini akan dibiarkan sendirian sebagian besar waktu, dengan orang-orang menambahkan atau mengubah sesuatu sekali dalam bulan biru. Ini membuatnya penting bahwa apa pun yang dikonfigurasikan dan berjalan di server didokumentasikan dengan baik dan jelas, karena orang yang tidak mengadministrasi sistem sering kali akan kehilangan gambaran umum (apalagi mengingat detailnya). Selain itu, seiring berjalannya waktu, komposisi grup orang yang akan mengelola server ini akan berubah (ketika orang pergi dan bergabung dengan 'komite').

Kami mulai dengan instalasi yang bersih, menambahkan peran yang memungkinkan setiap kali kami ingin mengatur sesuatu (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Mungkin karena kurangnya pengalaman kami, kami tentu saja tidak pernah dapat mengetik satu set tugas yang mungkin dilakukan persis seperti yang kami butuhkan dalam sekali jalan, juga karena konfigurasi adalah sedikit proses coba-coba. Itu berarti bahwa dalam praktiknya, kami biasanya akan mengkonfigurasi layanan apa pun yang ingin kami jalankan di server , dan kemudian menerjemahkannya ke tugas yang mungkin. Anda bisa melihat ke mana arah ini. Orang-orang lupa untuk menguji tugas itu, atau takut melakukannya dengan risiko melanggar sesuatu, atau lebih buruk lagi: kita lupa atau lalai menambahkan hal-hal yang mungkin.

Hari ini, kami memiliki keyakinan yang sangat kecil bahwa konfigurasi yang ada benar-benar mencerminkan apa yang dikonfigurasikan di server.

Saat ini saya melihat tiga masalah utama:

Sulit untuk (baca: kami tidak memiliki cara yang baik untuk) menguji tugas-tugas yang mungkin dilakukan tanpa mempertaruhkan banyak hal.
Ini menambah pekerjaan tambahan untuk mencari tahu konfigurasi yang diinginkan, dan kemudian mencari cara menerjemahkan ini ke tugas yang mungkin.
(Idealnya,) kita tidak cukup sering menggunakannya untuk membangun keakraban dan rutinitas.

Pertimbangan penting di sini adalah bahwa untuk apa pun yang akhirnya kita lakukan, seharusnya mudah bagi pendatang baru untuk mempelajari tali tanpa satu ton latihan.

Apakah ada alternatif lain yang masih memberikan beberapa jaminan dan pemeriksaan (sebanding dengan menggabungkan file yang mungkin dengan beberapa master) yang "mengkonfigurasi hal-hal dan menuliskan apa yang Anda lakukan" gagal memberikan?

EDIT: Kami telah mempertimbangkan /etcuntuk berkomitmen pada git. Apakah ada cara yang masuk akal untuk melindungi rahasia (kunci privat, dll) seperti itu, tetapi entah bagaimana masih ada repositori konfigurasi yang tersedia di luar server?

ansible configuration-management

— Joost
sumber

Jawaban:

Cukup jalankan tes / pementasan VM yang dapat Anda gunakan untuk memvalidasi perubahan Anda. Metode Anda saat ini melakukan perubahan secara manual terlebih dahulu rusak tanpa harapan dan ditakdirkan untuk gagal. Anda dan tim Anda harus berkomitmen untuk menggunakan CM dengan benar dan sebagian dari itu memiliki sistem pengujian yang tersedia. Bahkan hanya VM gelandangan lokal saja sudah cukup.

Ini tidak hanya akan membantu menguji perubahan baru, tetapi juga akan berfungsi sebagai test bed untuk karyawan baru (atau karyawan yang lebih tua yang tidak menggunakan sistem untuk sementara waktu) untuk membiasakan diri dengan pengaturan yang dimungkinkan.

Mengenai menjaga / etc / in git: tidak, jangan lakukan ini. Direktori itu hanya sebagian kecil dari apa yang mungkin diubah, dan memiliki git di sana hanya akan mendorong orang untuk melakukan perubahan lokal.

Simpan playbook Anda yang ada di git. Pertimbangkan untuk membatasi izin sehingga hanya Anda yang bisa menerapkan perubahan yang dimungkinkan untuk server langsung. Orang lain dapat mengirimkan permintaan tarik dengan perubahannya, yang dapat Anda tinjau dan gabungkan menjadi master jika perlu.

— EEAA
sumber

Benar, itu skenario ideal. Saya mengerti. Masalahnya, kami bukan perusahaan, dan kami tidak memiliki orang yang bekerja penuh waktu ini. Mungkin saya membuat skala ini tidak cukup jelas .. Setiap bagian tambahan (seperti vagrantfile) menambah kompleksitas yang perlu diteruskan, dan menjalankan dua konfigurasi (yaitu satu sistem pengujian di mana hal-hal seperti otomatisasi mari kita enkripsi perlu diejek) tidak tidak membantu kesederhanaan.

— Joost

Nah, Anda bertanya bagaimana cara menyelesaikan masalah Anda dan saya memberikan jawaban saya. Di atas persis bagaimana kita melakukan sesuatu di perusahaan saya, dan itu bekerja dengan sangat baik. Ya, ada biaya tambahan dalam hal ruang server dan waktu yang diperlukan untuk menguji, tetapi itu sangat berharga karena kami memiliki tingkat jaminan yang sangat tinggi bahwa dalam beberapa menit, kami dapat membangun kembali server kami jika diperlukan.

— EEAA

Pada intinya, ini benar-benar masalah budaya dan sumber daya, bukan masalah teknis. Anda belum berkomitmen untuk menggunakan manajemen konfigurasi. Apakah Anda perusahaan atau tidak tidak relevan. Anda meminta bantuan tentang cara melakukan sesuatu dengan benar, dan memiliki lingkungan panggung adalah bagian dari itu.

— EEAA

IMHO, ya, Anda harus berkomitmen untuk itu. Namun, apakah Anda bisa meyakinkan kolega Anda adalah pertanyaan lain. Tidak ada cara ringan untuk melakukan ini yang tidak memerlukan tingkat intensionalitas dari mereka yang mengelola server. Dari sistem CM modern, sejauh ini yang termudah adalah yang paling cepat. Anda tidak ingin melacak perubahan server dari waktu ke waktu. Satu-satunya cara untuk melakukan ini dengan andal adalah menggunakan CM.

— EEAA

@ThomWiggers Saya akan menganggap kalian berdua berada di tim yang sama karena Anda menggunakan "kami". Oke, Anda bertanya bagaimana cara melakukannya dengan benar. Saya memberi jawaban. Entah Anda ingin melakukannya dengan benar atau tidak. Melakukan CM dengan benar membutuhkan waktu, uang, dan intensionalitas. Jika Anda memiliki persyaratan seperti pengadaan dan penerapan sertifikat melalui LE, maka siapkan mesin virtual $ 5US / bulan dengan Digital Ocean dan gunakan itu untuk pengujian. Heck, Anda bahkan bisa menggunakannya saat diminta ketika Anda ingin menguji perubahan dan kemudian membunuhnya.

— EEAA

Mungkin karena kurangnya pengalaman kami, kami tentu saja tidak pernah dapat mengetik satu set tugas yang mungkin dilakukan persis seperti yang kami butuhkan dalam sekali jalan, juga karena konfigurasi adalah sedikit proses coba-coba. Itu berarti bahwa dalam praktiknya, kami biasanya akan mengkonfigurasi layanan apa pun yang ingin kami jalankan di server, dan kemudian menerjemahkannya ke tugas yang mungkin.

Meskipun ada masalah lain (seperti tidak memiliki lingkungan pengujian), Anda dapat mengalami peningkatan besar dengan tidak melakukan ini .

Salah satu tujuan desain inti Ansible adalah menjadi idempoten , yang berarti bahwa menjalankan playbook Anda beberapa kali tidak akan mengubah apa pun (kecuali Anda telah mengubah permainannya). Jadi, ketika saya mengkonfigurasi perangkat lunak baru, langkah saya adalah:

Buat perubahan pada tugas Ansible.
Jalankan playbook.
Periksa sistem, dan jika itu tidak benar, kembali ke langkah 1.
Komit perubahan saya.

Jika Anda tidak berpikir Anda akan menulis hal yang benar pertama kali di Ansible, tulis saja dan ulangi sampai benar, sama seperti kode lainnya. Ini sangat mengurangi kemungkinan lupa untuk Ansiblize beberapa perubahan yang Anda buat, karena setiap perubahan yang Anda buat sudah dalam Ansible di beberapa titik selama proses pengembangan Anda.

— Boikot SE untuk Monica Cellio
sumber

Yap, ini saran yang bagus. Melakukan hal ini, dan memastikan bahwa Anda selalu bisa mendapatkan server Anda kembali ke keadaan baik-dikenal sangat membebaskan - jika hal-hal pergi ke selatan, hanya nuklir server dan gunakan kembali.

— EEAA

Benar, saya setuju bahwa ini adalah jalan tengah yang sangat solid antara tempat kita sekarang dan di mana kita seharusnya berada. Tentu saja, beginilah cara kami memulai. Saya mengira bahwa alasan utama kita melayang ke tempat kita sekarang adalah bahwa langkah 2 membuat seluruh siklus terlalu lama. Bisa jadi kami salah melakukan playbook. Sekarang kita sudah sedikit lebih berpengalaman dalam menulis tugas yang mungkin mungkin perlu untuk dicoba lagi. Dalam pengalaman Anda, berapa lama siklus penuh dan seberapa sering satu iterate? Saya menyadari angka apa pun akan didasarkan pada segala macam asumsi ..

— Joost

Masalah lain yang saya alami dengan proses berulang ini terjadi ketika Anda menulis tugas yang membuat perubahan, membuat perubahan ke server, menemukan bahwa perubahan itu salah, memperbarui tugas Anda dan menerapkan kembali playbook. Sekarang server berisi campuran dari dua set perubahan: yang dari iterasi pertama dari tugas, dan yang dari yang kedua. Biasanya iterasi kedua akan menimpa yang pertama, tetapi tidak selalu selalu. Apakah ada cara yang masuk akal untuk 'membersihkan' daripada 1) secara manual SSH'ing untuk membatalkan, atau 2) mulai dari instalasi bersih setiap waktu?

— Joost

Selain itu, nuking server seringkali tidak sepele jika Anda hanya punya satu

— Thom Wiggers

"Menurut pengalamanmu, berapa lama siklus penuh dan seberapa sering satu iterate?" - Saya mulai menggunakan Ansible pada bulan Januari; sekitar bulan Juni, saya sampai pada titik di mana saya lebih cepat melakukan seluruh proses dalam Ansible daripada dengan tangan, untuk sebagian besar tugas. Waktu spesifik tentu saja tergantung pada proyek, dari beberapa menit hingga beberapa minggu (untuk beberapa perangkat lunak yang sangat tidak ramah). Jika Anda menemukan bahwa menjalankan playbook itu sendiri memperlambat Anda, Anda mungkin ingin melihat menggunakan tag untuk hanya menjalankan subset selama loop iterasi Anda.

— Boikot SE untuk Monica Cellio

Ansible memiliki waktu peningkatan sebelum Anda melampaui tingkat produktivitas sebelumnya, tetapi begitu Anda melakukannya, status sistem Anda mudah dipastikan. Praktik Anda tampaknya tidak selaras dengan tujuan akhir Anda. Anda dapat menjadi produktif dengan perangkat CM, sambil mempertahankan praktik rekayasa yang solid, tetapi butuh waktu untuk menyusunnya dengan benar. Anda pada dasarnya perdagangan efisiensi dan implementasi yang mudah, untuk stabilitas dan skalabilitas perusahaan. Dengan cara yang sama persis seperti programmer profesional yang berpengalaman tidak menulis hacks jelek, konsekuensinya selalu lebih besar daripada manfaatnya.

Sebagai permulaan, Anda mungkin memiliki terlalu banyak koki, tanpa kepemilikan yang jelas, jika demikian mengharapkan tragedi milik bersama. Setiap prioritas bisnis akan mengalahkan masalah rekayasa sistem setiap saat, kecuali jika hal itu dijinakkan secara luas dan yang tersisa mencerminkan langsung pada insinyur yang bertanggung jawab.

Toolset CM tidak mampu direkayasa oleh admin, ini yang baru saya sadari. Mereka dapat menggunakan kembali pekerjaan yang sudah ada, atau MUNGKIN memperluas basis suara, tetapi bahkan kemudian akan membutuhkan jumlah penegakan praktik yang memberatkan. Apa yang bisa dilakukan seorang Insinyur, BUKAN apa yang bisa dilakukan oleh seorang administrator. Banyak konsep dalam Ansible hampir sama seperti dalam basis kode, dapatkah Anda mengajarkan python Admin dan mengharapkan hasil yang kompeten? Tidak, tentu saja tidak, saya mengharapkan pekerjaan hack, jadi Anda perlu membuat tugas cukup terstruktur sehingga hack-job tertahankan.

Jadi, Anda perlu mengatur segalanya untuk sukses, merekayasa solusi untuk poin-poin administrasi yang tidak perlu. Perdagangkan kompleksitas sistem tingkat rendah untuk hal-hal yang bisa dilakukan oleh admin dengan sukses. Toolset CM TIDAK akan menyelamatkan Anda dari ketidakcocokan arsitektur atau desain.

Jadi pesanan dapat diubah, jelas karena implementasi tergantung pada jalur apa yang paling tidak mengganggu kondisi Anda saat ini.

Memindahkan semua pekerjaan yang terkait dengan alur kerja yang terkait dengan bisnis ke rundeck khusus.
Membagi tugas pada kotak, Anda mungkin memiliki dua kotak atau lebih dalam satu sekarang.
Terapkan kembali CM Anda dengan cara yang lebih terstruktur, dan ikuti praktik yang lebih baik, buku pedoman yang mewakili objek BUKAN fungsi atau peran. Setiap sistem harus dijelaskan dalam satu permainan.

— JM Becker
sumber