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?

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.

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:

1. Buat perubahan pada tugas Ansible.
2. Jalankan playbook.
3. Periksa sistem, dan jika itu tidak benar, kembali ke langkah 1.
4. 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.

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.

1. Memindahkan semua pekerjaan yang terkait dengan alur kerja yang terkait dengan bisnis ke rundeck khusus.

2. Membagi tugas pada kotak, Anda mungkin memiliki dua kotak atau lebih dalam satu sekarang.

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