構成管理ツールは、展開ツールとして使用するのに適切ですか？

質問に対する私の答えの裏側：DevOpsはどのようにしてソフトウェアエスクローの手順を改善するのに役立つのですか？テンシバイには質問がありました：

人形やシェフの上にカピストラーノを必要とするものは何ですか？

私の回答は、ノアギブスの記事「カピストラーノとシェフの両方が必要ですか？」へのリンクを投稿することでした。。個人的には、次のことを行うのが最も適切であるというノアの見解に同意します。

• デプロイメントには、Capistranoなどの専門のデプロイメントツールを使用します。
• 構成管理には、Chefなどの専門の構成管理ツールを使用します。

各タイプのツールがタスクを完了するために使用する基本的なアプローチは非常に異なります。

• 構成管理ツール -システムの望ましい状態を作成および維持するためのものであり、本質的にべき等です。構成管理ツールの例には、Chef、Puppet、Ansible、PowerShell DSC、Salt Stackなどがあります。

• 導入ツール - ホスティング環境にソフトウェアのバージョンを配信することに関するもので、複数のマシンでソフトウェアの複数のバージョンを維持し、どのバージョンが「最新」であるかを管理する機能を提供します。これらは本質的に必須です。デプロイメントツールの例には、Capistrano、Octopus Deploy、Deployer、およびCommand.ioがあります。

構成管理ツールはデプロイメントツールの仕事を実行できると思います。ターゲットのソフトウェアバージョンを維持する必要がないため、不変インフラストラクチャの場合は、これらが仕事に最も適したツールです。

質問： Chef、Ansible、Puppetなどの構成管理ツールは、べき等モデルと命令モデルの両方を実行できる程度に成熟していますか？

このような状況では、一般的なアドバイスをすぐに適用できます。その仕事に適したツールを使用してください。

しかし、今日では、ソフトウェアツールがほとんど関連のある分野に機能を拡張し、実際にツールセットになるという、最も凶悪な傾向を無視することはできません。

たとえば、多くのファイル管理ツールには画像表示機能が含まれており、多くの画像処理ツールにはファイル管理機能が含まれています。ファイルを移動したり、どちらのツールでも画像を表示したりできます。

このため、主な機能/機能が異なる場合でも、ソフトウェア開発プロセスの全体を複数のツール（セット）でカバー/オーバーラップさせることが可能です。

つまり、具体的には、特定のプロセスで実現したい正確な機能と、コンテキスト内で 1つのツールまたは他のツールがどれだけうまく機能するかにかかっています。主観性/好み/利便性が含まれています。

この質問を主に意見に基づいて行う;）

構成管理ツールは、システムを既知の状態にするために使用されます。展開ツールは、新しいプログラムファイルとプログラムデータをシステムに展開します。結局のところ、どちらのタイプのツールも次のいくつかの組み合わせを実行します。

• システムの現在の状態を確認します。
• システムにファイルを転送します。
• 永続データを追加または変更します（例：構成ファイル、データベースデータ、レジストリ設定）
• プログラムを起動または再起動します。

構成管理ツールには、システムの状態を指定する宣言型言語があります。展開ツールには、システムに処理を指示する命令型言語があります。DevOps担当者は両方を行う必要があります。

デプロイメントツールCapistranoを使用すると、その言語を使用してシステムにWebサーバーがアクティブであることを確認するよう指示するのは不便です。コマンドを発行してWebサーバーを再起動し、別のコマンドを発行してWebサーバーが起動しているかどうかを確認する必要があります。Webサーバーを既知の状態にするのは簡単ではありません。

構成管理ツールAnsibleを使用すると、Webサーバーを再起動するのが不便です。言語を使用すると、Webサーバーを「起動」するように指示できますが、特に再起動する場合は、その状態を「再起動」に設定する必要があります。ただし、Webサーバーが再起動されたかどうかを確認する簡単な方法はありません。これは、1回限りの操作を可能にするためのAnsibleの策略です。

一部の人々は、1つのツールで両方のタイプのジョブを実行し、ラフなエッジに対処することを好みます。他の人々は、ほとんど同じことをするために2つのツールを持つことを好みますが、荒削りではありません。質問に答えるために、「適切さ」は好みの問題です。この回答はその理由を説明しています。

TL; DR：Ansbileを使用するだけで、構成ツールとデプロイメントツールの両方になります:)

デプロイメントにはいくつかのタイプがあります。

• アプリケーションベース（ファイル、アーカイブパッケージ）

• コンテナベース（VM、Habitat、LXC、Dockerを含む）

• 関数ベース（マイクロサービス/ラムダ/関数）

この場合、サーバー上のアプリケーションの更新についてのみ説明します。

展開するには、次の2つのことを行う必要があります。

1. 正しいファイルまたはパッケージをサーバーに移動する必要があります。
2. 構成とサービスの状態を変更する必要があります。

（1）では、複数の戦略を使用できます。

• アーティファクトリポジトリ/同期
• パッケージリポジトリ/パッケージマネージャー
• バージョン管理システム/更新+コンパイル（オプション）
• ファイル転送プロトコル（scp、rsync、ftp）
• 導入ツール

（2）の場合、次を使用できます。

• 構成管理ツール
• 導入ツール

したがって、デプロイメントツールはデプロイメントをすべて1つにまとめる方法ですが、常に最良の戦略であるとは限りません。場合によっては、これらの方法を組み合わせて展開する必要があります。ほとんどの場合、少なくともサーバー上ですでにパッケージマネージャーを使用しています。とにかく、おそらく構成ツールを実行します。一部の構成ツールの問題は、複数のサーバー間での適切なオーケストレーションでしたが、現在ChefとPuppetでさえ、それを非常にうまく行うことができます。Ansibleは常にこれに長けています。

個人的な経験から、私はすべての組み合わせを使用しましたが、現在は展開にCapistranoを、構成管理にAnsible syncを、ファイル転送にVCSおよびパッケージリポジトリを使用していますが、Capistranoに問題があり、Capistranoからデプロイメント、メンテナンス、構成管理の両方でAnsibleに統合します。

アプリケーションの展開は、多くの副問題があるため、特定するのが難しいものです。構成管理システムは、収束して「システムの望ましい状態は何か」と連動するモデリングタスクに優れています。アプリのデプロイのコンテキストでは、これはマシンへのビットのデプロイ、構成ファイルの管理、システムサービスのセットアップなどに最適です。それが極端に悪いのは、本質的に手続き型のこと、特にデータベースの移行とサービスの再起動です。私は通常、収束ロジックをChefに配置し、外部の手続き型ツール（通常は私の場合はFabric）に残りの数ビットを処理させ、実際の収束をシーケンス処理させます。

したがって、基本的には、両方の得意な部分に両方を使用する必要があります。

ソフトウェアとコードを既存のサーバーまたはDockerコンテナー内にデプロイする場合、答えは比較的簡単です。いいえ、両方は必要ありませんが、別のツールまたはユーティリティが価値を追加し、ジョブに適したツールであれば、両方が必要になる場合がありますただし、サーバーとオペレーティングシステムを展開する場合、状況はさらに複雑になります。

DevOpsの考え方の付加価値の1つは、インフラストラクチャをコードとして扱い、非常に柔軟な環境で仮想マシンまたはベアメタルを頻繁に展開または破棄することです。構成管理システムでは、サーバーのネットブートとキックスタートを簡単に行うことができず、展開中や展開後、場合によってはライセンスや資格などのリポジトリ、パッケージ、更新/パッチを管理できません。

アマゾンウェブサービスの場合、これはほとんどの場合APIでかなり便利に管理できますが、私たち自身のデータセンターを管理する必要がある私たちにとって、これはオプションではありません。この理由のためにフォアマン（及びプロジェクトこの再ブランドレッドハット）バンドルすることが必要見出したKatello、Candlepin展開する際に一緒にこのようなAnsible、フォアマン又は人形のように構成マネージャをKatelloシナリオ。

そのため、社内のDev側でのソフトウェアコードの展開に構成管理ツールを使用することで問題を回避できる可能性がありますが、Ops側では、答えが「いいえ、構成管理ツールではない」という場合があります。展開ツールとして使用するのに適しています。」そうすることは、ホイールの重大な再発明を必要とし、実用的ではありません。代わりに、構成管理ツールを使用して、別のツールで展開を開始する必要があります。