Apakah alat manajemen konfigurasi sesuai untuk digunakan sebagai alat penyebaran?

10

Di belakang jawaban saya untuk pertanyaan: Bagaimana DevOps dapat membantu meningkatkan prosedur Escrow Perangkat Lunak? Tensibai memiliki pertanyaan:

Apa yang mengharuskan Capistrano di atas boneka atau koki?

Tanggapan saya adalah memasang tautan ke artikel Noah Gibbs, "Apakah Kita Membutuhkan Capistrano dan Koki?" . Secara pribadi, saya masih menganut pandangan Nuh bahwa paling tepat untuk:

menggunakan alat penyebaran spesialis seperti Capistrano untuk penyebaran.
menggunakan alat manajemen konfigurasi khusus seperti Chef untuk manajemen konfigurasi.

Pendekatan mendasar yang digunakan setiap jenis alat untuk menyelesaikan tugasnya sangat berbeda:

Alat Manajemen Konfigurasi - adalah tentang membuat dan memelihara keadaan sistem yang diinginkan, mereka pada dasarnya bersifat idempoten. Contoh alat manajemen konfigurasi adalah Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .
Alat Penempatan - adalah tentang memberikan versi perangkat lunak ke dalam lingkungan hosting, mereka menyediakan fungsionalitas untuk mempertahankan beberapa versi perangkat lunak pada beberapa mesin dan mengelola versi mana yang "saat ini", mereka pada dasarnya bersifat imperatif. Contoh alat penyebaran adalah Capistrano , Octopus Deploy , Deployer dan Command.io .

Saya percaya bahwa Alat Manajemen Konfigurasi dapat melakukan pekerjaan alat penyebaran dan dalam kasus Infrastruktur yang Tidak Berubah mereka adalah alat yang paling tepat untuk pekerjaan itu karena versi perangkat lunak pada target tidak perlu dipertahankan.

Pertanyaan: Apakah alat manajemen konfigurasi seperti Chef, Ansible, dan Wayang telah matang hingga mereka mampu memenuhi model idempoten dan imperatif?

— Richard Slater
sumber

Mungkin selalu bisa, Wayang sejak 4.0

— Jiri Klouda

1

Richard, terima kasih atas semua pertanyaan berkualitas tinggi yang Anda kirimkan akhir-akhir ini. Saya sangat menghargai kerja keras yang Anda lakukan sebelum mempopulasikan situs ini selama versi beta. Mengajukan pertanyaan memimpin yang baik itu sulit dan Anda benar-benar bagus dalam apa yang Anda lakukan.

— Jiri Klouda

@JiriKlouda Anda sangat disambut, secara harfiah memiliki "DevOps SE" post-it ™ di komputer saya untuk mengingatkan saya untuk mengirim pertanyaan ketika muncul di pikiran.

— Richard Slater

10

Dalam konteks seperti itu saran tipikal harus segera diterapkan: gunakan alat yang tepat untuk pekerjaan itu.

Tetapi kemudian Anda juga tidak dapat mengabaikan kecenderungan alat perangkat lunak yang hampir mematikan untuk memperluas fungsionalitas ke bidang yang kurang lebih terkait dan benar-benar menjadi toolset karena berbagai alasan: fitur keren untuk dimiliki, memperluas basis pelanggan, mengumpulkan lebih banyak pendapatan, dll.

Misalnya banyak alat manajemen file menyertakan fitur tampilan gambar dan banyak alat pemrosesan gambar menyertakan fitur manajemen file. Anda dapat memindahkan file dan Anda dapat melihat gambar dengan salah satu alat, seringkali sama baiknya.

Karena ini sangat mungkin untuk memiliki seluruh bagian dari proses pengembangan perangkat lunak tertutup / tumpang tindih oleh beberapa alat (set) bahkan jika fitur / kemampuan utama mereka berbeda.

Jadi itu benar-benar bermuara pada fungsionalitas tepat yang ingin Anda capai dalam proses khusus Anda dan seberapa baik satu alat atau yang lain melakukan pekerjaan dalam konteks Anda . Subjektivitas / preferensi / kenyamanan disertakan.

Menjadikan pertanyaan ini terutama berdasarkan opini;)

— Dan Cornilescu
sumber

Saya sangat setuju! Semakin banyak organisasi yang mengembangkan "DevOps toolchain" secara khusus dengan alat yang tepat ini untuk ide pekerjaan. Untuk info lebih lanjut, halaman wiki ini melakukan pekerjaan yang layak dengan membicarakan berbagai alat / pekerjaan yang berbeda: en.wikipedia.org/wiki/DevOps_toolchain

— Karl Harnagy

Saya hanya menambahkan bahwa semakin Anda memperluas penggunaan alat di luar tujuan utamanya, semakin banyak upaya yang diperlukan untuk melakukannya. Anda mungkin dapat menggunakan alat tertentu untuk penyebaran dan konfigurasi, tetapi ada kemungkinan alat itu akan lebih berfungsi (atau membutuhkan praktik terbaik yang berjalan di samping) daripada hanya menggunakan dua alat.

— jschmitter

6

Alat manajemen konfigurasi digunakan untuk membuat sistem menjadi kondisi yang dikenal. Alat penyebaran menyebarkan file program dan data program baru ke suatu sistem. Pada akhirnya, kedua jenis alat melakukan kombinasi antara:

Tentukan kondisi sistem saat ini.
Transfer file ke sistem.
Tambah atau ubah data persisten (mis. File konfigurasi, data database, pengaturan registri)
Mulai atau mulai ulang program.

Alat manajemen konfigurasi memiliki bahasa deklaratif yang menentukan kondisi sistem. Alat penyebaran memiliki bahasa yang sangat penting yang memberi tahu sistem untuk melakukan sesuatu. Seseorang DevOps perlu melakukan keduanya.

Menggunakan alat penyebaran Capistrano, sangat canggung untuk menggunakan bahasanya untuk memberi tahu sistem untuk memastikan bahwa server web aktif. Anda harus mengeluarkan perintah untuk me-restart server web, dan yang lain untuk memeriksa untuk melihat apakah server web sudah habis. Ini adalah kludge untuk menjadikan server web ke status yang dikenal.

Menggunakan alat manajemen konfigurasi Ansible, canggung untuk memulai kembali server web. Bahasa ini memungkinkan Anda memberi tahu server web untuk "naik", tetapi jika Anda secara khusus ingin memulai kembali, Anda harus mengatur statusnya menjadi "dimulai kembali". Tetapi tidak ada cara mudah untuk memeriksa apakah server web telah dimulai ulang. Ini adalah kludge di Ansible untuk mengaktifkan operasi sekali saja.

Beberapa orang lebih suka melakukan kedua jenis pekerjaan dengan satu alat, dan bekerja dengan kasar. Orang lain lebih suka memiliki dua alat untuk melakukan hal yang hampir sama, tetapi tanpa tepi kasar. Untuk menjawab pertanyaan, "kesesuaian" adalah masalah selera. Jawaban ini menjelaskan alasannya.

— Jay Godse
sumber

Saya setuju Capistrano sedikit canggung untuk kasus ini. Biasanya digunakan sebagai namespace untuk skrip / snippet / lambda yang dijalankan dari jarak jauh melalui ssh. Bagian Anda pada Ansible tidak benar. Anda mungkin ingin sedikit meneliti dan memperbaikinya. Pos pertama yang bagus, tapi tolong kerjakan sedikit lagi.

— Jiri Klouda

@JiriKlouda ada apa dengan bagian Ansible? Apakah maksud Anda bagian no easy way to check if the web server has been restartedyang dapat diperiksa dengan mendaftarkan variabel?

— David Vasandani

Ada beberapa cara untuk melakukannya, penulis jawabannya tidak tahu mereka. Jangan ragu untuk mengubahnya menjadi pertanyaan terpisah karena komentar bukanlah tempat yang baik untuk jawaban teknis.

— Jiri Klouda

4

TL; DR : Hanya digunakan Ansbile, itu adalah baik konfigurasi dan alat penyebaran :)

Ada beberapa jenis penempatan:

Berbasis aplikasi (file, paket arsip)
Berbasis kontainer (termasuk VM, Habitat, LXC, Docker)
Berbasis fungsi (layanan Mikro / Lambdas / Fungsi)

Saya berasumsi dalam hal ini kita hanya berbicara tentang pembaruan aplikasi di server.

Untuk penyebaran Anda harus memiliki dua hal terjadi:

File atau paket yang benar harus dipindahkan ke server.
Konfigurasi dan status layanan perlu diubah.

Sekarang untuk (1) Anda dapat menggunakan beberapa strategi:

Repositori / Sinkronisasi Artefak
Paket Repositori / Manajer Paket
Sistem Kontrol Versi / Pembaruan + Kompilasi (opsional)
Protokol transfer file (scp, rsync, ftp)
Alat Penempatan

Untuk (2) Anda dapat menggunakan:

Alat manajemen konfigurasi
Alat Penempatan

Jadi, meskipun Alat Penempatan adalah cara untuk melakukan penempatan sekaligus, mereka tidak selalu merupakan strategi terbaik. Terkadang Anda ingin menggunakan kombinasi cara ini untuk penerapan. Kemungkinan besar Anda sudah menggunakan manajer paket setidaknya di server Anda. Anda kemungkinan besar menjalankan alat konfigurasi. Masalah dengan beberapa alat konfigurasi adalah orkestrasi yang tepat di antara beberapa server, tetapi sekarang bahkan Chef dan Wayang dapat melakukannya dengan cukup baik. Kemungkinan selalu bagus dalam hal ini.

Dari pengalaman pribadi , saya telah menggunakan semua kombinasi, tetapi saat ini kami menggunakan Capistrano untuk penerapan dan sinkronisasi yang mungkin untuk manajemen konfigurasi, dan VCS dan paket repositori untuk transfer file, tetapi ada masalah dengan Capistrano dan kami berencana untuk pindah dari itu ke unify on Ansible untuk penerapan, pemeliharaan, dan manajemen konfigurasi.

— Jiri Klouda
sumber

2

Pengalaman saya dengan Ansible dan Capistrano akan menuntun saya ke kesimpulan yang sama. Saya hanya akan pergi dengan Ansible. Dan hal yang menyenangkan tentang Ansible adalah deklarasi "state yang diinginkan" memetakan dengan sangat baik perintah-perintah penting yang mendasarinya.

— Jay Godse

1

Orang terkadang mengabaikan kontribusi komunitas di sekitar alat Manajemen Konfigurasi. Komponen komunitas Ansible adalah, dengan beberapa pengecualian yang mencolok (seperti DebOps), belum dipoles dan fitur-lengkap seperti Chef's dan Puppet's. Sebagai pengukuran ini, sementara aku menemukan Wayang dan Chef mampu baik "berlaku" dan unapply perintah konfigurasi (melakukan atau membatalkan set perubahan), Ansible besar di "menerapkan" bagian, tapi tidak begitu besar di " bagian "tidak disetujui.

— Jesse Adelman

3

Penerapan aplikasi adalah hal yang sulit untuk dijabarkan karena memiliki banyak sub-masalah. Sistem manajemen konfigurasi sangat baik dalam tugas pemodelan yang konvergen dan bekerja dengan "apa yang diinginkan dari sistem". Dalam konteks penyebaran aplikasi, ini bagus untuk hal-hal seperti mengerahkan bit ke mesin, mengelola file konfigurasi, dan mengatur layanan sistem. Yang sangat buruk adalah hal-hal yang secara inheren prosedural, terutama migrasi basis data dan layanan restart. Saya biasanya mencoba untuk menempatkan logika konvergen di Chef dan membiarkan alat prosedural eksternal (biasanya Fabric dalam kasus saya) menangani beberapa bit yang tersisa serta mengurutkan konvergensi yang sebenarnya.

Jadi, pada dasarnya, Anda harus menggunakan keduanya untuk potongan-potongan terbaik mereka.

— pembuat kode
sumber

3

Untuk perangkat lunak dan menyebarkan kode ke server yang ada atau di dalam wadah Docker, jawabannya relatif sederhana - Tidak, Anda tidak perlu keduanya, tetapi Anda mungkin menginginkan keduanya jika alat atau utilitas lain menambah nilai dan merupakan alat yang tepat untuk pekerjaan itu Namun, segala sesuatunya menjadi lebih rumit ketika Anda menggunakan server dan sistem operasi.

Salah satu nilai tambah dari mentalitas DevOps adalah memperlakukan infrastruktur sebagai kode dan sering mengerahkan atau menghancurkan mesin virtual atau bahkan logam telanjang di lingkungan yang sangat elastis. Sistem manajemen konfigurasi Anda tidak dapat dengan mudah melakukan netboot dan memulai server Anda untuk Anda dan tidak dapat mengelola repositori, paket, dan pembaruan / perbaikan untuk Anda selama dan setelah penyebaran atau dalam beberapa kasus, lisensi dan hak.

Untuk Amazon Web Services, ini agaknya mudah dikelola oleh API untuk sebagian besar, tetapi bagi kita yang harus mengelola pusat data kita sendiri, ini bukan pilihan. Untuk alasan ini, proyek Foreman (dan Red Hat yang merek-ulang ini ) merasa perlu untuk menggabungkan Katello , Candlepin dan manajer konfigurasi seperti Ansible, Foreman atau Wayang bersama ketika menggunakan Skenario Katello .

Jadi sementara Anda mungkin bisa lolos dengan menggunakan alat manajemen konfigurasi untuk penyebaran kode perangkat lunak di sisi Dev rumah, di sisi Ops, ada beberapa kasus di mana jawabannya adalah "tidak, alat manajemen konfigurasi tidak layak untuk digunakan sebagai alat penyebaran "Melakukan hal itu akan membutuhkan penemuan kembali roda yang serius dan tidak praktis. Sebagai gantinya, Anda harus menggunakan alat manajemen konfigurasi untuk memulai penyebaran di alat lain.

— James Shewey
sumber

Atau tidak, koki menangani Capistrano dengan anggun seperti penyebaran, paket cokelat yang disebarkan di bawah jendela dan semua paket yang diketahui baik (deb, rpm, msi, nullsoft, dll.). Itu memang membawa beban pada sisi pengemasan, yang habitatnya ingin selesaikan, tapi itu adalah sistem manajemen konfigurasi yang cukup mampu menangani penyebaran, saya bisa mengatakannya dengan melihatnya melakukan sekitar 40 penyebaran per minggu di berbagai lingkungan termasuk produksi, itu bukan tanpa beban tinggi sebelumnya untuk kode itu, tapi itu tidak jauh di atas hal yang sama dengan alat lain yang dimakan.

— Tensibai

1

Sebenarnya The Foreman bukanlah sistem manajemen penyediaan, penyebaran atau konfigurasi. Ini hanya kulit yang menyediakan UI dan kerangka kerja berbasis web yang menempelkan sistem manajemen konfigurasi (boneka), sistem manajemen lisensi (candlepin), sistem manajemen repositori dan tambalan (Katello), dan sistem penyediaan / penyebaran (kickstart). Ini menjadi ujung tombak semua proyek yang berbeda ini dan merekatkannya bersama. Sementara hampir semua sistem manajemen konfigurasi dapat menginstal paket, apa yang tidak dapat mereka lakukan adalah memberikan manajemen patch dengan cara yang mirip dengan server WSUS

— James Shewey

atau menyematkan atau menyebarkan versi paket tertentu, termasuk paket yang tidak ada di repo hulu atau repo mashup. Maksud saya adalah bahwa jika Red Hat / The Foreman / Katello merasa itu tidak dapat dilakukan hanya dengan sistem manajemen konfigurasi - terutama karena tidak memiliki bagian penyediaan / penyebaran yang patut dicatat.

— James Shewey

Saya salah membaca kalimat tentang katello, salah saya. Komentar pertama adalah demi kelengkapan :)

— Tensibai