回答:
私はAnsibleを使用したことはありませんでしたが、数週間以来、シェルスクリップと比較して、Ansibleがどれほど優れているかを把握しようとしています。多くの失敗した試行の後-最も明白な質問の1つに答えることでドキュメントが失敗することを証明します-私は最終的にそれを得たと思います：
では、紹介ビデオを見て、潜在的な新規ユーザーとしてランダムにAnsible ansの紹介資料を見てみましょう。熟練したシェルプログラマーがすぐに作成できるものと比較しましょう。
私の結論は、シェルスクリプト上で、Ansibleは基本的に1.システムが望ましい状態に一致することをチェックする可能性、2。監視機能を含むと思われる有料システムであるAnsible Towerと統合する機能です。不変のサーバーパターンを実装する場合など、いくつかの重要なケースでは、ポイント1はおそらくあまり有用ではないため、リストはかなり薄くなります。
私の結論は、Ansibleがシェルスクリプトよりも優れているという利点は、ドキュメントに記載されているように、利用可能なモジュールで十分にカバーされている少数の楽観的なケースでは理にかなっているが、一般的なケースでは小さいか、仮説的でさえあるということです。熟練したシェルプログラマーにとって、これらの利点は、トレードオフの他の側面によって相殺される可能性が最も高いでしょう。
しかし、これはおそらく、紹介資料がどれほど悪いかを証明しているだけかもしれません！
あるクイックスタートビデオが。それは…と主張するページから始まります。これらは実際には主張ではなく、箇条書きリストであり、プレゼンテーションで批判的な判断を一時停止するために一般的に使用されるアーティファクトです。
1.1人間が読める自動化–仕様は技術文書であり、どのように
name: upgrade all packages
yum:
name: '*'
state: latest
シェルスクリプトで見つかった対応するyum呼び出しよりも読みやすいですか？さらに、AppleScriptと連絡を取った人は誰でも、「人間が読める自動化」と読むと笑って死にます。
1.2特別なコーディングスキルは必要ありません–正式な仕様を書かない場合のコーディングとは何ですか？彼らは条件、変数を持っているので、どうやってコーディングしないのですか？そして、なぜ私はプログラムできないものが必要なのでしょうか？文は不正確です！
1.3順番に実行されるタスク–まあ、コードゴルフ愛好家の中には、タスクを無秩序に実行する言語を知っている人もいるかもしれませんが、順番にタスクを実行することは例外的ではありません。
1.4すぐに生産性を向上させる–熟練したシェルプログラマーが生産性を向上させました。この反論は、最初の議論と同じくらい深刻です。
アーティファクトを販売するための人気のあるセールスマンのトリックは、人々を欺いて、彼らがこれらのアーティファクトの「力」を手に入れると信じ込ませることです。車や等張性飲料の広告の歴史は、説得力のある例のリストを提供するはずです。
ここでは、Ansibleは「アプリの展開」を実行できますが、シェルスクリプトは確実に「構成管理」を実行できますが、これは機能ではなくツールの目的の単なる説明であり、少し気取っているように見えますが例はありませんGNU Parallelができることを超えて。
コラムを埋めるために、彼らは3つの異なる方法でこれがsshだけを必要とすることを書きました。誰もが知っているように、これはデーモンであり、世界構成管理に浸透しているこれらのエージェントとは関係ありません！
ビデオの残りの部分では、インベントリ（サーバーなどのリソースの静的リスト）を紹介し、3つのサーバーに同時にApacheを展開する方法を示します。これは、リソースが非常に動的であり、クラウドプロバイダーが提供するコマンドラインツールによって列挙され、パイプ|演算子を使用してシェル関数によって消費される作業方法とは実際には一致しません。また、Apacheを3つのサーバーに同時に展開するのではなく、マスターインスタンスイメージを作成し、それを使用して、正確なレプリカの1つである3つのインスタンスを起動します。したがって、議論の「オーケストレーション」の部分はあまり適切に見えません。
EC2はAmazonのコンピューティングサービスであり、EC2とのやり取りはいくつかのAnsibleモジュールによってサポートされています。（他の一般的なクラウドコンピューティングプロバイダーも提供されています）：
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
対応するシェルスクリプトは、JSONで置き換えられたYAMLと本質的に同じです。
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
またはJSONバージョン
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
どちらのバージョンも基本的に同じです。ペイロードの大部分は、YAMLまたはJSON構造の初期化値の列挙です。
このガイドの大部分は本当に興味深い機能を示していません：変数を紹介します（IIRC、シェルスクリプトにも変数があります！）、Ansibleモジュールがmysqlを処理するため、「mysqlユーザーを作成する方法XYの特権を使用して」のように終了します
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
「どうすればansibleでXYの特権を持つmysqlユーザーを作成できますか」を検索すると、
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
違いはおそらくあまり意味がありません。そのページでは、Ansibleにテンプレートメタプログラミング言語があることもわかります
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
これを見ると、たまたま快適な領域にいることになります。宣言型言語のためのこの種の単純なメタプログラミングは、BSD Makefilesとまったく同じ理論的パラダイムです！私はどの広範囲にプログラムされているために起こる（私はYAMLパーサを介して、私のプレイブックを実行することはできませんので、この抜粋ショーたちYAMLファイルでの作業の約束が破られていることなど）。また、Ansibleが評価順序の微妙な技術を議論する必要があることも示しています。変数を言語の「宣言部」で拡張するか、言語の「命令」メタ部で拡張するかを決定する必要があります。ここでは、シェルプログラミングがより簡単であり、明示的 evalまたは外部スクリプトソーシングを除き、メタプログラミングはありません。仮想シェルの抜粋は次のようになります
enumerate_group 'monitoring' | {
while read host; do
…
done
}
Ansibleバリアントと比較した場合の複雑さはおそらく許容範囲です。言語のプレーンで規則的な退屈な構成要素を使用するだけです。
最後に、Ansibleの最初の実際に興味深い機能であることが判明しました。「Ansibleリソースは、desired-stateのモデルです。そのため、サービスの開始、パッケージのインストールなどをテストする必要はありません。Ansibleは、これらが宣言的に正しいことを保証するシステムです。代わりに、あなたのプレイブックでこれらのことを主張してください。」今では少し面白くなり始めていますが、
利用可能なモジュールによって容易に実装される少数の標準的な状況は別として、私はテストを実装するビットを自分でフィードする必要があります。
インストールの適合性の確認は、不変のサーバーパターンが実装されているコンテキストではあまり重要ではない場合があります。実行中のすべてのシステムは通常、マスターイメージ（インスタンスイメージまたはdockerイメージ）から生成され、更新されることはありません。代わりに新しい。
Ansibleの紹介資料は、保守性の問題を無視しています。本質的に型システムがないため、シェルスクリプトはJavaScript、Lisp、またはPythonの保守容易性を備えています。大規模なリファクタリングは、広範な自動テストスイート、または少なくとも簡単な対話型テストを可能にする設計によってのみ成功します。とは言っても、シェルスクリプトはシステム構成と保守の共通語ですが、ほぼすべてのプログラミング言語にはシェルへのインターフェイスがあります。したがって、シェル構成ビットのさまざまなビットを一緒に接着するために使用することにより、高度な言語の保守性の利点を活用することは完全に実行可能です。OCamlについては、Rashellを書きました これは、サブプロセスの共通の相互作用パターンの手を本質的に提供します。これにより、構成スクリプトのOCamlへの変換は本質的に簡単になります。
Ansibleの側面では、プレイブックの非常に弱い構造とメタプログラミング機能の存在により、シェルスクリプトの場合と同様に状況が本質的に悪くなります。マイナス点は、Ansibleの単体テストの書き方が明らかでないことです。 、およびアドホックな高レベル言語を導入するという議論はまねることができません。
Ansibleのドキュメントは、べき等の設定手順を記述する必要性に注意を喚起します。より正確には、ステップシーケンスabaをabに簡略化できるように構成ステップを記述する必要があります。つまり、構成ステップを繰り返す必要はありません。これは、dem等性よりも強い条件です。Ansibleでは、プレイブックで任意のシェルコマンドを使用できるため、Ansible自体は、このより強力な条件が尊重されることを保証できません。これは、プログラマーの規律にのみ依存しています。
この方法で言えば、Ansibleに固有の利点がある場合でも、使い慣れたツール（この場合はシェルスクリプト）を使用する利点を上回る必要があります。私はそれに対する明確な答えがあるとは思わない。
チームがシェルでAnsibleが提供するものを達成できる場合：
その後、彼らはおそらく彼らが知っていることに固執することができます。
結局のところ、BASHで「ガード」を実装できます。さまざまなサーバー構成タスクを解決するためのBASHの既存の多くの作業を見つけることができます（基本的には、Dockerfileの90％がbashインストールコードです）。Ansible / Salt / Chef-Zeroが提供するものにかなり近づくことができます。実際に既存のソリューション全体をこれらのツールに移植する必要はありません。
NIH（ここでは発明されていません）の傾向と、より堅牢なソリューションを支持する確立された適切なスクリプトを捨てるというバランスの取れた行為です。
念頭に置いておく必要がある最後の考慮事項は、チームにさらに多くの人を採用しようとすると、テクノロジースタックがどのように評価されるかです。Ansibleの経験を持つ人を見つけるのは、特定の自家製スクリプトCMツールの経験がある人を見つけるよりもはるかに簡単です。これは厳密に技術的な考慮事項ではなく、文化的な考慮事項です。独自のAnsibleを発明する奇妙な組織になりたいですか、それとも仕事に適したツールを見つける合理的な組織になりたいですか？これらの決定は、才能を引き出す能力に影響します。
上記の答えはその一部をカバーしていますが、重要な要素の1つである収束設計を逃しています。少し前にhttps://coderanger.net/thinking/でChefのコンテキストでこれについていくつかの言葉を書きましたが、短いバージョンはbashスクリプトは一連の指示であり、Ansibleプレイブック（またはChefレシピ、Salt状態など）は、目的の状態の説明です。そこに到達するために必要な手順ではなく、必要な状態を文書化することで、より多くの開始状態に対処できます。これは、かなり前にCFEngineで概説されたPromise Theoryの中心であり、私たち（構成管理ツール）がすべてコピーしてからの設計です。
tl; dr Ansibleコードはあなたが望むことを示し、bashコードは物事を行う方法を示します。
リモートホストでansibleプレイブックを実行する際の問題が少なくなることに注意してください。それがansibleを実行する主な理由です。シェルスクリプトを使用している場合でも、リモートホストへのscp'ingのスクリプトを作成する方法が必要です。
それは2019年であり、私はほんの数日を賢明な学習曲線に費やしました、そしてここに絶対的な真実があります：Ansibleはトラブルの価値がない。
それは終了しておらず、Windows上では実行されず、YAMLの設定と誤解を招くエラーメッセージの組み合わせが目を出血させます。それはほとんど故意にひどいようで、私はそれを真剣に意味します。それは明らかに、redhat sysadminsのフラストレーションのある開発者側プロジェクトの成果です。おそらくヒップスター。
プロビジョニング以外の機能を必要とせず、特定の1つのOSでのみプロビジョニングする場合。残念なことに、まともなshell.scriptを書きます。
今のところ、プロジェクト全体は、初心者がRTFMに告げられ、なぜグラフィック設定を構成するためのGUIを書けないのかを尋ねたために馬鹿にされた初期のLinuxフォーラムを思い出させます。あなたはそれを取得しないのですか？あなたは窓に固執する必要があります...多分私は..幸せなVI-ing。
Dockerを使用します。何よりも。Dockerはとてつもなくシンプルで強力です。
しかし、既存のスズを絶対にプロビジョニングする必要がある場合はどうでしょうか？本当の選択肢は何ですか？
まあ...まだありません。しかし、私はあなたにこれを約束します、ansibleが良くならない限り、すぐにあります。ファンボーイがどれだけ力を入れても、それが失敗であることを許しても... 10分の5の努力だからです。
bashスクリプトをSCPで作成し、トラブルを回避します。