Apakah masuk akal untuk menjalankan proses dengan alat CI?

29

Di perusahaan saya, kami memiliki rawa pekerjaan cron yang berbeda (pada beberapa sistem) dan secara manual memulai proses yang menjaga fungsi bisnis kami yang merupakan hasil dari pengembangan yang cepat dan pengabaian selanjutnya.

Suatu hari, kita perlu menemukan solusi yang lebih terpusat untuk alasan yang jelas.

Satu pemikiran yang telah kami lakukan adalah menggunakan perangkat lunak Continuous Integration (Jenkins) kami untuk menjalankan proses ini, yang tampaknya logis.

Pertanyaan saya adalah: Apakah perusahaan lain melakukan ini? Apakah ini praktik yang diterima secara umum? Tidakkah ini bertentangan dengan definisi alat CI yang tersirat dalam namanya? Apakah ada opsi lain?

Catatan: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins mengklaim bahwa ia berfokus pada "Memantau eksekusi pekerjaan yang dijalankan secara eksternal, seperti pekerjaan cron dan pekerjaan procmail". Saya tidak yakin apakah ini yang saya bicarakan.

continuous-integration cron

— smp7d
sumber

2

Bisakah Anda mengklarifikasi sifat dari berbagai tugas & proses yang ada dalam pikiran Anda?

— Stephen Gross

campuran skrip dalam berbagai bahasa, proses java, dan perintah linux

— smp7d

Kami membutuhkan lebih banyak detail. Apa sifat dari tugas itu? Apa yang mereka lakukan? Bagaimana mereka dikelola?

— Stephen Gross

@StephenGross Kumpulkan data dari sistem eksternal untuk penyimpanan lokal, kirim pemberitahuan kepada pengguna berdasarkan aturan bisnis, periksa penggunaan disk, hapus anak yatim, dan sekitar seribu hal lainnya. Mereka semua dikelola oleh cron jika mereka dikelola sama sekali pada saat ini. Mengapa Anda membutuhkan detail ini? Anda dapat mengasumsikan bahwa mereka menjalankan fungsi-fungsi penting bisnis sesuai jadwal.

— smp7d

2

Alasan saya memerlukan detail ini adalah karena untuk membantu Anda dengan masalah Anda, saya perlu memahami masalahnya. Meskipun Anda sudah tahu banyak tentang tugas / proses ini, saya tidak; sangat membantu untuk memahami sifat tugas yang harus dijalankan ketika mengevaluasi solusi teknis seperti apa yang paling baik.

— Stephen Gross

17

Kami telah menggunakan Jenkins sebagai cron drop in selama beberapa tahun sekarang, dan berikut adalah beberapa pro dan kontra:

Pro

Jika Anda mengelola sejumlah besar proses di berbagai server dan beberapa lingkungan, itu membuat banyak hal lebih mudah. Anda mendapatkan peringatan email di luar kotak, dasbor umum untuk semuanya, antarmuka web untuk log, dan cara mudah untuk menyiapkan node tambahan untuk menjalankan pekerjaan. Tim pendukung terutama menghargai memiliki lokasi pusat ini untuk memeriksa masalah dan menjalankan kembali pekerjaan.
Ekosistem plug-in Jenkins sangat aktif dan menyediakan sejumlah fungsi tambahan ... Saya pikir ini benar-benar fitur 'pembunuh' Jenkins, karena jika Jenkins sendiri tidak menyediakan apa yang Anda cari (sering kali), lebih lanjut sering kali tidak ada plugin yang melakukannya. Beberapa favorit saya: Kolom Cron, Rebuild, Parameter NodeLabel, Log Parser, dan Email-ext.
Dukungan penjadwalan / pemicu lanjutan: Sintaks jadwal pada dasarnya adalah cron, jadi Anda memiliki fleksibilitas yang sama di sana, tetapi ini dilengkapi oleh Pemicu, API REST, dan API Groovy / Java

Cons

Titik pusat kegagalan: Karena semua pekerjaan Anda dimulai oleh satu server, jika kotak itu turun dan tidak ada yang memperhatikan, Masalah Besar. Jadi Anda sebaiknya memiliki pemantauan yang baik untuk menangkap pemadaman segera, serta semua konfigurasi Anda disimpan dalam kontrol sumber. Bahkan jika Anda tidak dapat membuat cadangan server asli, selama Anda memiliki pekerjaan Anda mengkonfigurasi itu sepele untuk membuatnya di tempat lain. Jika waktu untuk resolusi adalah masalah, memiliki siaga yang sudah dikonfigurasi sebelumnya di suatu tempat mungkin juga merupakan ide yang baik.
Jika Anda memiliki beberapa lingkungan (Dev, UAT, Prod), biasanya Anda memiliki versi pekerjaan yang sedikit berbeda di setiap lingkungan. Memiliki semua pekerjaan ini pada satu Jenkins bisa menjadi berat, dan secara manual mengonfigurasi mereka menjadi sangat menyebalkan. Dalam kasus kami, kami menjalankan instance Jenkins 'Cron' yang terpisah untuk setiap lingkungan. Mesin virtual diinstal dan dikonfigurasikan secara otomatis menggunakan alat penyebaran in-house. Anda mungkin tidak memiliki sesuatu seperti itu, tetapi ada alat open source yang melakukan hal serupa (menghasilkan konfigurasi menggunakan templat). Jika Anda dapat memecahkan masalah pembuatan konfigurasi, ini membuat pengaturan dan penggunaan Jenkins jauh lebih mudah, dan juga membuatnya lebih mudah untuk menjaga semua barang Anda di kontrol sumber.
Memutakhirkan Jenkins terkadang merusak fungsionalitas, terutama dengan plugin. Jangan meng-upgrade instance Jenkins Anda yang penting misi sebelum Anda mencoba versi baru di tempat lain terlebih dahulu. Di sinilah memiliki lingkungan Dev cermin dengan contoh Jenkins sendiri sangat berguna.

Satu hal yang mungkin ditekankan: Kami memang juga menggunakan Jenkins untuk CI, tapi ini adalah contoh terpisah ... contoh 'cron' didedikasikan untuk manajemen pekerjaan, dan contoh 'CI' didedikasikan untuk CI. Memisahkan kekhawatiran tampaknya membuat segalanya lebih bersih.

Sebagai catatan, saya menggunakan Jenkins daripada cron di kotak Linux saya di rumah :)

Omong-omong, ini sebenarnya kasus penggunaan Jenkins yang sangat umum. Misalnya, Lab Nasional Sandia menggunakan Jenkins dengan cara ini: https://software.sandia.gov/trac/fast/wiki/Hudson

Dan ada banyak posting blog dan tutorial yang menjelaskan hal ini. Berikut adalah beberapa contoh: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/12/1108

Saya juga harus menambahkan bahwa ini benar-benar hanya berkaitan dengan Jenkins, dan tidak semua alat CI secara umum. Hanya karena Jenkins sangat cocok untuk melakukan ini tidak berarti orang lain (TeamCity, buildbot, dll) ...

— Dylan Cali
sumber

8

Saya akan mengatakan bahwa Anda tidak menggunakan alat yang tepat untuk pekerjaan di sini karena titik utama alat CI adalah bahwa mereka memantau sesuatu - kode sumber Anda biasanya - dan ketika ada perubahan mereka memulai build / deploy / apa pun .

Namun, alat-alat ini dapat menjalankan pekerjaan yang dijadwalkan (misalnya TeamCity), jadi Anda dapat menggunakan situs web (misalnya) ketika tidak ada orang di sekitarnya. Jadi memiliki satu daftar pusat dari semua tugas yang Anda jalankan sebenarnya adalah ide yang bagus. Alat tersebut juga harus memungkinkan Anda untuk memutuskan kapan dan seberapa sering pekerjaan ini dijalankan.

Manfaat lain adalah Anda bahkan dapat memonitor sistem dari jarak jauh (jika Anda mau).

Jadi, secara seimbang, saya katakan itu hal yang masuk akal untuk dilakukan.

— ChrisF
sumber

Perasaan Anda pada subjek mencerminkan perasaan saya. Karena CI umumnya dikenal untuk membangun dan menguji, saya melihatnya sebagai solusi yang tidak lazim. Jawaban lain untuk pertanyaan ini jelas telah menunjukkan bahwa untuk menjadi kasus, karena banyak yang melihatnya jelas alat yang salah untuk pekerjaan itu. Karena TeamCity dapat melakukan tugas-tugas tambahan ini, alat CI apa pun yang menggunakan proyek Maven dapat melakukan sejumlah hal. Saya masih tidak nyaman bahwa itu adalah ide yang bagus.

— smp7d

1

@ smp7d - setuju. Ini solusi yang mungkin , tetapi bukan solusi yang ideal .

— ChrisF

6

Sepertinya cron sudah menjadi alat yang tepat untuk kebutuhan Anda. Saya sarankan Anda mulai dengan mendokumentasikan sistem Anda lebih baik. Audit berbagai sistem dan kumpulkan daftar lengkap proses mana yang berjalan pada mesin mana.

Kemudian pertimbangkan untuk menunjuk mesin khusus untuk menjalankan semua proses cron ini. Pastikan Anda mendokumentasikan mesin ini, dan berikan hak admin yang sesuai untuk mengendalikannya. Letakkan semua cronjobs pada mesin itu, dan kemudian Anda memiliki titik pusat kendali untuk berbagai proses otomatis Anda.

— Stephen Gross
sumber

2

Reaksi usus saya adalah sama, bahwa Anda menggunakan alat yang memiliki konsep jadwal di dalamnya, untuk melakukan pekerjaan penjadwal pekerjaan.

Anda belum menyebutkan apa pekerjaan Anda, tetapi penyebutan CRON membuat saya menebak itu adalah skrip shell, dll. Ada paket sumber terbuka dan penjadwal pekerjaan komersial di luar sana. Terkadang mereka disebut sebagai penjadwal batch. Beberapa hanya akan membungkus CRON dan membuatnya lebih ramah. Beberapa, seperti Quartz scheduler, melakukan manajemen pekerjaan yang kuat, tetapi mengharuskan mereka untuk diimplementasikan sebagai kelas Java. Anda berpotensi menggunakannya, dan membungkus panggilan runtime ke berbagai skrip Anda menggunakan pembungkus java. Saya percaya Anda akan menemukan banyak opsi jika Anda melihat lebih jauh.

— Guerry
sumber

Pekerjaan adalah campuran dari skrip dalam berbagai bahasa, proses java, dan perintah linux. Quartz sendiri tidak akan memberi saya ujung depan / manajemen gedung yang akan disediakan Jenkins dan saya tidak ingin membangun semua itu. Saya tidak akan terkejut jika Jenkins menggunakan Quartz di belakang layar. Saya akan memeriksa Manajer Kuarsa ini ( terracotta.org/products/quartz-scheduler ).

— smp7d

2

Jangan gunakan CI untuk menjalankan tugas berkala yang tidak terkait dengan membangun.

Juga hindari cron untuk tugas-tugas yang tidak terkait dengan pemeliharaan sistem.

Gunakan alat yang tepat. Untuk kebutuhan aplikasi - coba gunakan solusi berbasis AMQP.

PS Saya mengerti, cron itu cocok untuk kasus Anda. Di sisi lain, Anda memiliki banyak tugas - jadi cobalah menulis aplikasi penyelia untuk mereka.

— Nikolay Fominyh
sumber

1

Terima kasih atas jawabannya. Bisakah Anda menjelaskan apa yang Anda maksud dengan "aplikasi pengawas"?

— smp7d

Dalam beberapa kata - itu adalah supervisord.org . Program Meta yang mengontrol status dan pelaksanaan proses lainnya. Anda dapat dengan mudah mengembangkan solusi Anda sendiri yang sesuai dengan kebutuhan Anda. Saya punya banyak tugas berkala pada proyek saya dan github.com/ask/django-celery membantu saya keluar dari cron.

— Nikolay Fominyh

Terima kasih, saya akan melihat ke Supervisor. Tujuan menggunakan alat CI adalah untuk mencegah kita dari perlu menulis alat kita sendiri. Alat CI apik seperti yang sudah bisa dilakukan.

— smp7d

1

Kira saya tidak punya perwakilan untuk memberikan suara ini, tapi itu jawaban yang cukup mengerikan - malu mendapat hadiahnya. Apa yang membuat alat menjadi "alat yang tepat"? Bahkan jika ia memiliki semua komponen yang dibutuhkan, itu adalah "alat yang salah" karena ini disebut sistem CI?

— DougW

1

Anda perlu menggunakan bus layanan perusahaan (ESB) untuk jenis tugas ini.

Sekarang latar belakang saya ada di windows / BizTalk, tapi saya yakin semua hal yang sama ada di sisi unix. Apa yang biasanya kita lakukan adalah mengatur proses pada kotak BizTalk yang akan bertugas memulai hal-hal di kotak lain, memantau kemajuan / kesalahan, dan melaporkan kembali status ke portal SharePoint (atau web), atau mengirim email dan seperti itu jika perlu perhatian.

Manfaat dari pendekatan ini adalah bahwa semua konfigurasi dan pengelolaan berbagai proses bisnis Anda berlokasi di pusat, sehingga Anda tahu di mana harus mulai mencari. Perangkat lunak sudah ada yang memungkinkan Anda mengabstraksi bagian pengkodean dari konfigurasi fisik (di BizTalk Anda dapat memprogram melawan 'port' yang logis seperti server sql, dan kemudian di prod, jika kotak sql mengubah lokasi atau ditingkatkan atau apa pun, Anda dapat mengubah port fisik yang dikonfigurasi menggunakan alat admin mereka, sekali lagi, saya yakin ada padanan di sisi unix).

Manfaat daripada menggunakan alat CI akan menjadi hal-hal seperti, jika proses Anda keluar, Anda dapat secara otomatis, mengirim ulang pesan secara fisik dan Anda dapat mengatur lingkungan gagal-berkerumun yang berkelompok, memiliki sistem pencatatan dan pencatatan yang lebih cocok; juga, setelah Anda memiliki sistem di tempat, itu akan memungkinkan Anda untuk mulai merancang organisasi Anda untuk digunakan, atau lebih baik menggunakan SOA. Sisi buruknya adalah bahwa tergantung pada ukuran organisasi Anda, upaya pengembangan mungkin tinggi, dan biaya lisensi mungkin mahal.

— lubang aceinthe
sumber

Mungkin ini bisa diterapkan, tetapi saya tidak yakin ini adalah kasus penerapan alat yang salah seperti CI. Adalah kesan saya bahwa ESB akan digunakan ketika komunikasi atau proses koreografi diperlukan. Dalam hal ini, kami hanya ingin manajemen pusat untuk berbagai proses mandiri. Kami baik-baik saja dengan menjalankan perintah linux kustom melalui manajemen pusat, sehingga agnostisisme OS / Bahasa Pemrograman mungkin berlebihan. Ini mungkin layak dilihat, terima kasih.

— smp7d

Jika Anda adalah toko unix pasti setuju dengan itu, saya tahu IBM memiliki produk di lini websphere mereka, dan ada juga metode web yang bersifat komersial, dan appache memiliki penawaran sumber terbuka; Anda benar dalam arti definisi Anda tentang ESB, sayangnya ESB telah menjadi agak ambigu dalam penggunaannya, tetapi pertimbangkan jika Anda akhirnya ingin menambahkan pelaporan kesalahan terpusat, atau segala jenis pelaporan seperti 'apakah itu berjalan' ke dalam proses Anda yang koreografi.

— aceinthehole

@ smp7d Saya tahu bahwa webMethods Integration Server memiliki dukungan penjadwalan kelas satu. Bekerja dengan baik.

— Robert Grant

1

Secara teoritis masuk akal bagi Anda untuk memiliki satu lokasi untuk mengendalikan semua pekerjaan yang berbeda, namun berdasarkan pengalaman industri yang seperti "Holy Grail" Anda akan memerlukan pekerjaan cron di sini, bash skrip di sana dan skrip cli di sini.

Ada juga mantra "Jika tidak rusak, jangan perbaiki", jadi ketika mereka berjalan lamban, pada awalnya fokus pada mendokumentasikan skrip apa yang telah Anda jalankan, apa yang mereka lakukan dan sistem apa yang mereka sentuh sehingga Anda "tahu "Bagaimana bisnis Anda dijalankan.

Kemudian sebagai strategi jangka panjang menyiapkan sistem terpusat untuk menjalankan pekerjaan, pilih solusi Anda dengan bijak karena Anda harus hidup dengan itu. Kemudian untuk setiap permintaan perubahan, peningkatan, peningkatan, perbaikan bug atau solusi baru yang Anda tambahkan dalam arsitektur bisnis Anda memastikan bahwa tugas yang dijadwalkan dan otomatis ditambahkan ke "solusi kontrol perusahaan" Anda.

Dengan begitu, Anda secara bertahap bermigrasi dari kumpulan skrip ke lingkungan yang lebih ramah perusahaan.

— Stephen Senkomago Musoke
sumber

Ini adalah beberapa pemikiran bagus. Jadi Anda pikir apa yang saya cari tidak ada dan alat CI bukan alternatif yang masuk akal?

— smp7d

Mungkin ada tetapi pragmatisme tentang apa yang Anda gunakan dapat menyebabkan Anda masih memiliki tugas cron dan skrip bash. Namun menggunakan lingkungan CI Anda mungkin menjadi penghambat nantinya karena CI terutama untuk alur kerja pengembangan, namun karena lingkungan dewasa Anda mencari solusi terkait operasi. Kemudian Anda dapat memutuskan untuk memindahkan kontrol versi / CI Anda ke cloud, Anda tidak ingin itu macet karena menjalankan operasi organisasi Anda sehari-hari.

— Stephen Senkomago Musoke

Yah, kami berpikir kami akan menggunakan alat CI terpisah untuk manajemen proses, tapi saya mengerti apa yang Anda katakan.

— smp7d

Karena Anda melihat CI terpisah, lalu mengapa tidak melihat alat yang berfokus pada manajemen proses, pemantauan, dan pelaporan. Dengan begitu Anda memanfaatkan upaya untuk menyiapkan CI untuk mendapatkan alat yang tepat untuk pekerjaan itu, jika gagal, Anda memiliki CI untuk kembali

— Stephen Senkomago Musoke

Saya setuju bahwa ini adalah jalan yang paling masuk akal untuk diambil. Scheduler Scheduler, supervisord.org, dan ESB telah direkomendasikan. Apakah Anda memiliki rekomendasi atau pemikiran tambahan tentang ini? (juga: Ketika saya mengatakan CI terpisah, saya hanya bermaksud menginstal alat kami saat ini dengan mungkin beberapa branding baru ... setup tidak akan menjadi masalah)

— smp7d

0

Dalam sistem perusahaan besar tempat saya bekerja, mereka cenderung menggunakan alat yang dirancang untuk penjadwalan. Yang paling populer yang saya gunakan adalah CA7. Ini memungkinkan Anda untuk memusatkan semua penjadwalan untuk semua sistem Anda.

Cron umumnya digunakan untuk mesin tunggal, meskipun Anda dapat "meretasnya" dengan melakukan panggilan jarak jauh ssh. Namun, itu tidak akan memiliki konsep dependensi dan hal-hal lain. Ketika datang ke tim operasi di mana ruang lingkup mereka bahkan lebih terbatas, yang terbaik adalah alat yang digunakan.

— Archimedes Trajano
sumber

Rekomendasi Anda membawa saya untuk ini ... en.wikipedia.org/wiki/Job_scheduler - Anehnya tidak ada yang pernah disebutkan nama ini untuk alat tersebut. Ini mungkin yang saya cari seolah dirancang untuk melakukan apa yang saya cari, waktu mungkin akan menunjukkan bahwa ia melakukannya lebih baik daripada alat CI. Perlu beberapa penelitian untuk memverifikasi itu.

— smp7d