AnsibleとRundeckを一緒に動作させるのは良い考えですか、どちらか一方を使用するだけで十分ですか？
最近、私はAnsibleを見て、プロジェクトでそれを使いたいと思っています。また、Rundeckを使用して、あらゆる種類の運用作業を実行できる別のツールもあります。私はどちらのツールにも経験がなく、これがそれらについての現在の理解です。
類似点
どちらのツールもエージェントレスで、SSHを使用してリモートサーバーでコマンドを実行します
Rundeckの主なコンセプトは、Ansibleのインベントリと同じNodeです。重要なアイデアは、ターゲットサーバーを定義/管理/グループ化することです
- Rundeckは選択したノードでアドホックコマンドを実行できます。Ansibleはこれも非常に便利に実行できます。
- Rundeckはワークフローを定義し、選択したノードで実行を実行できます。これは、プレイブックを書くことでAnsibleで実行できます
- RundeckはJenkinsなどのCIツールと統合してデプロイ作業を行うことができます。また、Jenkinsジョブを定義してansible-playbookを実行してデプロイ作業を行うこともできます。
異なるポイント
RundeckにはJobという概念がありますが、Ansibleにはありません
RundeckにはJob Schedulerがあり、AnsibleはこれをJenkinsやCronタスクなどの他のツールでのみ実現できます
RundeckにはデフォルトでWeb UIが無料で搭載されていますが、Ansible Towerには料金がかかります
AnsibleとRundeckの両方を使用して、おそらく別の方法で構成/管理/展開作業を行うことができるようです。だから私の質問は：
- これらの2つの補完的なツールですか、それとも異なる目的のために設計されていますか？それらが補完的なツールである場合、AnsiblはChef/Puppet/Slatなどのツールとのみ比較され、Rundeckとは比較されないのはなぜですか？彼らがそうでないのであれば、彼らは非常に多くの同様の機能を持っていますか？
- CI用のJenkinsを使用して、継続的配信パイプラインを構築していますが、どのツール（Ansible/Rundeck）が展開に使用するのに適していますか？
- それらを一緒に使用できる場合、ベストプラクティスは何ですか？
提案や経験の共有は大歓迎です。
TL; DR-CI/CDのJenkinsの環境を考えると、Ansibleのみを使用することをお勧めします。
AnsibleとRundeckの間にかなりのクロスオーバーがあることに気付いたので、各製品が焦点を当てる場所、スタイル、使用に集中することがおそらく最善です。
フォーカス
Rundeckの焦点は、システム管理者が（Webベースの）セルフサービスポータルを構築し、他のシステム管理者と、潜在的には「技術的」/システム管理者の両方にアクセスできるようにすることにあると思います。 RundeckのWebサイトでは、「運用手順をセルフサービスジョブに変えます。他の人に必要な制御と可視性を安全に提供します。」。 Rundeckは、世界に対してより「集中化された」ビューを持っているようにも感じます。ジョブをデータベースにロードすると、そこに住んでいます。
私にとって、Ansibleはdevops用です。したがって、非常に再現性の高い方法で（自己構築）アプリケーションの展開を構築および自動化します。 Ansibleは、独自の製品を構築するソフトウェア開発会社により焦点を当てていると主張します。Ansibleの「プレイブック」はテキストファイルであるため、通常はソース管理に保存され、通常はプレイブックが展開するアプリと一緒に保存されます。
ジョブ作成フォーカス
Rundeckでは、通常、Web UIを介してジョブを作成します。
Ansibleでは、テキストエディターを介してファイルにタスク/プレイブックを作成します。
操作/タスク/ジョブスタイル
Rundeckはデフォルトで必須ですSSH経由で）実行されるスクリプトを記述します。
Ansibleは命令型（つまり、bashステートメントの実行）であると同時に宣言型でもあるため、Apacheを起動するときに、serviceタスクを使用して実行されていることを確認できます。これは、PuppetやChefなどの他の構成管理ツールにより近いものです。
---（複雑なジョブ/スクリプト
Rundeckには、ジョブのワークフローでステップを定義することで別のジョブを実行する機能がありますが、経験から、これは深刻なトップレベルの機能というよりも追加されたように感じます。
Ansibleは、複雑な操作を作成するように設計されています。 running/include/etcはトップレベルの機能です。
実行方法
Rundeckはサーバーアプリです。他の場所（CIなど）からジョブを実行する場合は、cliを呼び出すか、API呼び出しを行う必要があります。
Straight Ansibleはコマンドラインです。
但し書き
Rundeckのクロスオーバーと全体的な柔軟性によりandAnsibleはそれぞれで上記のすべてを達成できます。 RundeckジョブをYAMLまたはXMLにエクスポートし、ソース管理にチェックインすることで、バージョン管理を実現できます。 Towerを使用してAnsibleでWeb UIを取得できます。などなど.
あなたの質問：
補完ツール？
両方を使用してSaaSショップを想像できます：Ansibleを使用してすべての展開アクションを実行し、Rundeckを使用して1回限りのアドホックジョブを実行できます。
ただし、想像することはできますが、出発点としてはお勧めしません。私、私はちょうどAnsibleから始めて、どこまで到達するかを確認します。 本当に一度だけ実行する必要があることに気付いた場合、後でRundeckでレイヤーを作成します。
CI/CD
Ansible：環境は、独自のアプリを展開しているソフトウェアハウスのように聞こえます。おそらく反復可能である必要があります（特に継続的デリバリーの場合）ので、ソース管理でスクリプトをデプロイする必要があります。あなたはシンプルさを望むでしょう、そして、Ansibleは「ただのテキストファイル」です。 Ansibleは分散化されているため、開発者がマシン上で物事を実行できるようにしたいと思います（そうですか？）。
一緒に使用（CI/CDの場合）
AnsibleからRundeckを呼び出す、いや。確かに、それは可能でしょうが、正当な理由を考え出すのに苦労しています。少なくとも、特定のアプリまたはフレームワークに特化した特別な理由ではありません。
RundeckからAnsibleを呼び出す、はい。 Ansibleで反復可能なアドホックコマンドを最初に構築する人を想像できます。それから、コマンドラインなしでこれを呼び出すことができるようにするための少しの要求があることがわかりました（例えば：非技術ユーザー）。しかし、これも環境に固有のものになりつつあります。
私のポイント-rundeckとansible（無料、タワーなし）は異なる種類の仕事をします
Ansible（タワーなし）-構成管理（サーバー/アプリのプロビジョニング、大量の構成更新）
Rundeck-アクセス制御、通知、ジョブ出力などを備えた集中型ジョブスケジューラ（古いログのアーカイブ、スクリプトの実行など）
それはあなたの要件にのみ基づいています。リモートスクリプトの実行とアプリの展開にはrundeckを使用します。プロビジョニングと構成管理をカバーするために、Foremanと統合しました。
予算の制約がある場合は、もう探す必要はありません。ただし、Ansibleの一部の機能を見逃す可能性があります。また、Googleグループはサポートの場合に非常に活発です。
予算をansibleタワーに投資し、他に何も必要ない場合。
この質問が出された時点で、著者はAnsibleが有料のUIのみを提供したと正しく述べました。
UIがオープンソースになりました： [〜＃〜] awx [〜＃〜]
サーバーの標準化が可能になります。
アドホック/運用タスクが実行されます。
これは私が現在使用しているものです。
開発者またはOPSチームのセルフサービスポータルとしてそれらを使用する場合、RBACはRundeckではなくTowerに実装され、よりシンプルで直感的に明確になります。この製品をサポートするチームにとって非常に重要になる可能性があるため、RBACの設定にどれだけの労力と複雑さが必要かを検討してください。
TowerのREST APIは、Rundeckよりも単純で解析しやすいです。
Towerでは、プレイブックタスクごとに個々のイベントを表示できますが、Rundeckではすべてが1つのコンソール出力にスローされます。
Towerの動的インベントリは、パブリッククラウドでの展開に非常に役立ちます。