CIツールでプロセスを実行するのは合理的ですか？

私の会社では、さまざまなcronジョブ（複数のシステム上）の泥沼があり、長年の適切な開発とその後の怠慢の結果として、ビジネスを機能させるプロセスを手動で開始しています。

いつか、明らかな理由から、より集中化されたソリューションを考え出す必要があります。

私たちが蹴っているのは、継続的インテグレーションソフトウェア（Jenkins）を使用してこれらのプロセスを実行することです。

私の質問は、他の企業がこれを行っているのですか？これは一般的に受け入れられている慣行ですか？これは、名前に暗黙的に含まれるCIツールの定義と矛盾しませんか？他のオプションはありますか？

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

Jenkinsは、「cronジョブやprocmailジョブなどの外部で実行されるジョブの実行の監視」に焦点を当てていると主張しています。これがまさに私が話していることであるかどうかはわかりません。

私たちはここ数年、ジェンキンスをcronドロップインとして使用していますが、ここに賛否両論があります：

長所

• 多数のサーバーと複数の環境で多数のプロセスを管理している場合、多くのことが簡単になります。すぐに使用できる電子メールアラート、すべての共通ダッシュボード、ログ用のWebインターフェイス、およびジョブを実行するための追加ノードをセットアップする簡単な方法を取得できます。サポートチームは、問題をチェックし、ジョブを再実行するためにこの中心的な場所にあることに特に感謝しています。

• Jenkinsプラグインエコシステムは非常にアクティブで、多くの追加機能を提供します...これは本当にJenkinsの「キラー」機能だと思います。多くの場合、そうするプラグインがあります。私のお気に入りのいくつか：Cron Column、Rebuild、NodeLabel Parameter、Log Parser、およびEmail-ext。

• 高度なスケジューリング/トリガーのサポート：スケジュール構文は基本的にcronであるため、同じ柔軟性がありますが、これはトリガー、REST API、およびGroovy / Java APIによって補完されます

短所

• 障害の中心点：すべてのジョブが1台のサーバーによって開始されるため、そのボックスがダウンして誰も気付かない場合は、Big Trouble。したがって、ソース管理に保存されているすべての構成と同様に、停止をすぐにキャッチするための適切な監視が必要です。元のサーバーをバックアップできない場合でも、ジョブの構成があれば、別の場所にセットアップするのは簡単です。解決までの時間が問題になる場合は、どこかにスタンバイを事前に設定しておくこともおそらく良い考えです。

• 複数の環境（Dev、UAT、Prod）がある場合、通常は各環境で実行されるジョブのバージョンがわずかに異なります。これらすべてのジョブを1つのJenkinsで処理すると、扱いにくくなる可能性があり、それらを手動で構成するのは非常に苦痛になります。この場合、環境ごとに個別のJenkins 'Cron'インスタンスを実行します。インスタンスは、社内展開ツールを使用して自動的にインストールおよび構成されます。そのようなものはないかもしれませんが、同様のことを行う（テンプレートを使用して構成を生成する）オープンソースツールがあります。構成生成の問題を解決できる場合、これによりJenkinsのセットアップとデプロイがはるかに簡単になり、ソース管理ですべてのものを保持しやすくなります。

• Jenkinsをアップグレードすると、特にプラグインで機能が壊れることがあります。最初に新しいバージョンを試してみるまで、ミッションクリティカルなJenkinsインスタンスをアップグレードしないでください。これは、独自のJenkinsインスタンスを備えたミラーDev環境を持つことが非常に便利な場所です。

強調すべきことの1つは、CIにもJenkinsを実際に使用していることですが、これは別のインスタンスです...「cron」インスタンスはジョブ管理専用であり、「CI」インスタンスはCI専用です。懸念を分離することは、物事をよりきれいにするようです。

サイドノートとして、私は自宅のLinuxボックスでcronの代わりにJenkinsを使用しています:)

ちなみに、これは実際にはかなり一般的なジェンキンスのユースケースです。たとえば、Sandia National LabはJenkinsを次のように使用しています：https : //software.sandia.gov/trac/fast/wiki/Hudson

また、これを説明する多数のブログ投稿とチュートリアルがあります。次に例を示します。http： //blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

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

また、これは本当にすべてのCIツールではなく、ジェンキンスにのみ関係していることも付け加えてください。Jenkinsがこれを行うのに適しているからといって、他の人（TeamCity、buildbotなど）が...

CIツールの主なポイントは何かを監視することであるため、ここでの仕事に適切なツールを使用していないと言っていました-通常、ソースコード-そして変更があると、ビルド/デプロイ/何でも開始します。

ただし、これらのツールはスケジュールされたジョブを実行できるため（たとえばTeamCity が実行します）、誰もいないときに（たとえば）Webサイトを展開できます。そのため、実際には、実行するすべてのタスクの単一の中央リストを作成することをお勧めします。また、これらのジョブを実行するタイミングと頻度をツールで決定できる必要があります。

もう1つの利点は、システムをリモートで監視できることです（希望する場合）。

ですから、バランスをとって、それは賢明なことだと思います。

cronはすでにニーズに適したツールのようです。システムの文書化から始めることをお勧めします。さまざまなシステムを監査し、どのプロセスがどのマシンで実行されるかの包括的なリストを作成します。

次に、これらすべてのcronプロセスを実行する専用マシンを指定することを検討してください。これがどのマシンであるかを文書化し、それを制御するための適切な管理者権限を割り当ててください。そのマシンにすべてのcronjobを配置すると、さまざまな自動化されたプロセスの中央制御点が得られます。

私の腸の反応は同じです。ジョブスケジューラの仕事をするために、スケジュールの概念を持つツールを使用しています。

あなたは自分の仕事が何であるかについて言及していませんが、CRONについての言及はそれらがシェルスクリプトなどであると推測させます。そこにはオープンソースと商用のジョブスケジューラパッケージがあります。バッチスケジューラと呼ばれることもあります。一部のユーザーはCRONをラップして、より使いやすくします。Quartzスケジューラーなど、ジョブの強力な管理を行うものもありますが、Javaクラスとして実装する必要があります。これを潜在的に使用し、Javaラッパーを使用してさまざまなスクリプトへのランタイム呼び出しをラップすることができます。さらに調べれば、たくさんの選択肢が見つかると思います。

ビルドに関係しない定期的なタスクの実行にCIを使用しないでください。

また、システムメンテナンスに関係のないタスクについては、cronを使用しないでください。

適切なツールを使用します。アプリケーションのニーズについては、AMQPベースのソリューションを使用してみてください。

PSなるほど、そのcronはあなたのケースに合っています。一方、あなたは多くのタスクを持っています-そのため、スーパーバイザーアプリを作成してみてください。

このタイプのタスクには、エンタープライズサービスバス（ESB）を使用する必要があります。

現在、私の背景はwindows / BizTalkにありますが、同等のものはすべてUNIX側にも存在するはずです。通常は、BizTalkボックスでプロセスを設定します。このプロセスは、他のボックスでの処理を開始し、進行状況/エラーを監視し、SharePoint（またはWeb）ポータルにステータスを報告するか、電子メールと注意が必要な場合など。

このアプローチの利点は、さまざまなビジネスプロセスの構成と管理がすべて中央に配置されるため、どこから始めればよいかがわかることです。物理構成からコーディング部分を抽象化するソフトウェアが既に存在します（BizTalkでは、SQLサーバーのような論理的な「ポート」に対してプログラムできます。SQLボックスが場所を変更したり、アップグレードされたりした場合は、prodでプログラムできます。管理ツールを使用して、構成済みの物理ポートを変更できます。これも、Unix側に同等のものがあると確信しています。

CIツールを使用することの利点は、プロセスでエラーが自動的に発生した場合、メッセージを物理的に再送信し、より適切な記録およびログシステムを備えたクラスター化されたフェールオーバー環境をセットアップできることです。また、システムを導入すると、使用する組織の設計を開始したり、SOAをより有効に活用したりできます。欠点は、組織の規模によっては開発の労力が高くなり、ライセンスコストが非常に高くなる可能性があることです。

理論的には、すべての異なるジョブを制御するための単一の場所があることが理にかなっていますが、「聖杯」のような業界の経験に基づいて、ここでcronジョブ、bashスクリプト、およびcliスクリプトが必要になります。

「壊れていない場合は修正しないでください」というマントラもあります。そのため、彼らはどんどん進んでいますが、最初に実行しているスクリプト、実行しているスクリプト、システムに触れて、「知っている」 「ビジネスの運営方法。

次に、長期的な戦略として、ジョブを実行するための集中型システムをセットアップします。ソリューションは適切に選択する必要があります。次に、ビジネスアーキテクチャ内に追加する変更要求、機能強化、アップグレード、バグ修正、または新しいソリューションごとに、スケジュールされ自動化されたタスクが「エンタープライズコントロールソリューション」に追加されるようにします。

そうすることで、スクリプトのバッチからより企業に優しい環境に徐々に移行できます。

私が使用した大企業システムでは、スケジューリング用に設計されたツールを使用する傾向があります。私が使用した中で最も人気のあるものはCA7です。これにより、すべてのシステムのすべてのスケジューリングを集中化できます。

cronは通常、単一のマシンに使用されますが、sshリモート呼び出しを行うことで「ハック」できます。ただし、依存関係などの概念はありません。範囲がさらに制限されている運用チームに関しては、ツールを使用することが最善です。