最近、当社では、展開と継続的統合にAnsibleを使用することにしました。しかし、Ansibleを使い始めたとき、MavenでJavaプロジェクトをビルドするためのモジュール、またはJUnitテストまたはJMeterテストを実行するためのモジュールが見つかりませんでした。
だから、私は疑わしい状態にあります:Ansibleを間違った方法で使用している可能性があります。
Jenkinsを見ると、ビルド、テストの実行、デプロイなどのことができます。 Hudsonで欠けているのは、AWSなどのクラウド環境でインスタンスを作成/削除することです。
それで、一般に、Ansible/Jenkinsを使用する目的は何ですか? CIでは、AnsibleとJenkinsの組み合わせを使用する必要がありますか?
Ansibleの正しい使用法に光を当ててください。
まず、ジェンキンスとハドソンは基本的に同じプロジェクトです。以下では、ジェンキンスと呼びます。 HudsonとJenkinsの選択方法 、 2012年のHudson対Jenkins 、および JenkinsとHudsonの最も顕著な違いはユーザーの観点からですか? その他。
第二に、Ansibleは継続的な統合エンジンであることを意図していません。 (一般的に)gitリポジトリをポーリングせず、正常に失敗するビルドを実行しません。
マシン環境と展開プロセスがvery簡単な場合(Herokuやチームの外部で構成されたアイロンなど)、Jenkinsで十分かもしれません。最終ビルドステップ(またはチェーンステップ)としてデプロイを行うカスタムスクリプトを作成できます。
ビルド/テストする必要なく「デプロイ」するだけでよい場合は、Ansibleで十分かもしれません。たとえば、コマンドラインから、またはAnsible Towerを使用してデプロイを実行できます。これは、小規模プロジェクト、静的サイトなどに最適です。
良い組み合わせは、Jenkinsを使用してアーティファクトを構築、テスト、保存することです。 AnsibleまたはAnsible Towerを呼び出すステップを追加して、実際の展開プロセスを処理します。これにより、Ansibleはmachine構成を処理でき、JenkinsはCIプロセスを処理できます。
Jenkinsの代わりに Thoughtworks Go (Go言語と混同しないでください)を強くお勧めします。その他には、CruiseControl、TravisCI、Integrityが含まれます。
Ansibleは、単なる「洗練されたSSHループ」です。 CIは実行中のソフトウェアだけでなく、成功と失敗の処理方法、通知の受信者、変更がターゲットバージョン管理にどのようにマージされるかのプロセス全体です。
ソフトウェアのみに焦点を当てる場合、CIはコードの変更によってトリガーされるリアクティブスケジューラであり、「ステップ」の典型的なビルド-検証-リリース-展開のシーケンスをトリガーします。
したがって、ソフトウェアに関して、追加の「シュガーリング」なしのAnsibleは、物事を実行するためのツールキットにすぎません。 Ansible(タワーなし)には、この反応的な性質がまったくありません。
AnsibleとCIを結婚したい場合は、できます。
Ansible Towerは非常にAnsible指向のスケジューラですが、CIソフトウェアが必要な場合、必ずしも必要ではないと思います。シェルスクリプトを実行できるCIアプリであれば、Ansibleプレイブックを起動できます。
しかし、Ansible Towerとは異なり、CIツールはすべてのテストフレームワークのテストレポートの表示、通知のトリガーなどを知っています。
Ansibleタワーは、Ansibleコードに触れる多くのグループがいる複雑な環境で意味をなすことができます...真実は、それを支払うための単一の本当の理由を見たことがありません。しかし、マネージャーがWebインターフェースを気に入った場合、「しかし他の人がそれを使用する」ロジックに耐えることはできません。
Ansible Towerのコンセプトは、人形遣いに対応したものだと思います。
:)