Ansible Playbook YAML フォーマッター
ガイド
Ansible Playbook YAML フォーマッター
任意のAnsible playbookまたはタスクファイルを貼り付け、常にフォーマットされたYAMLを返し、タスクキーを標準的な順序(name → module → args → loop → when → register → notify)に並べます。ツールは、プレイブックかタスクリストかを自動検出し、構造を検証し、ansible-lintスタイルのヒントを表示します——FQCNモジュール名、missing changed_when, command-instead-of-module、およびlegacy yes/no truthy値——そのため、あなたのプレイブックは最初の試行でレビューを通過します。
使用方法
- あなたのAnsible YAMLを入力ボックスに貼り付けます——フル
playbook.yml、ロールのtasks/main.yml、または任意のタスクリスト。 - 離脱 タスクキーの並びを再順序化 を有効にすると、標準的なansible-lintキー順序に従って適用し、無効にすると元の順序を維持します。
- 保持 Ansible構造の検証 プレイ/タスク構造チェックを有効にする(missing
hosts、モジュールを持たないタスク、不正なblock). - トグル ansible-lintのスタイルヒントを表示 をベストプラクティスのアドバイスとして提供します——FQCNモジュール名、missing names、およびidempotency警告。
- フォーマットされた出力をコピーするか、または
playbook.yml.
機能
- 標準的なタスクキー順序 –
nameから、モジュール、そしてargs,loop,when,register,notify——ansible-lintが期待する順序に並べます。 - プレイブックとタスクリストの検出 – プレイブックが検出された場合、自動的にプレイレベルの順序(
hosts,vars,pre_tasks,tasks,post_tasks,handlers)を適用します。 - ブロック / リスク / エイリアスを認識 – ネストされたブロックスタイルのタスクを再順序化しても、その意味を破壊しません。
- 構造検証 – プレイがmissing
hosts、モジュールを持たないタスク、不正なリスト、および不明なプレイレベルキーをフラグします。 - FQCNヒント –
ansible.builtin.aptをbareaptに置き換えることを提案します。fqcn[action-core]. - Idempotencyヒント –
command/shellが実行されない場合を警告します。changed_when,creates、 またはremoves. - command-instead-of-module検出 – shell-outされたパッケージインストール、systemctlコール、gitクローン、pipインストールが、第一クラスのモジュールを持っていることを検出します。
- legacy truthy検出 –
yes/no/on/off値がtrue/false(yaml[truthy]). - べきであるべきであることをフラグします。 Deprecated loop警告
with_items,with_dict–loop:. - ブラウザ内で完全に動作 、および仲間たちを強調し、
よくある質問
-
– 何もアップロードされません;あなたのインベントリとシークレットはローカルに残ります。
ansible-lintがタスクキーの順序にどう関心を持つのか?
name一貫したキー順序はプレイブックをスキャンしやすくします:タスクの意図(loop,when,register,notify)が最初に読まれ、その後モジュールが実行するアクション、そしてその引数、そして制御フロー( -
)が続きます。チームのすべてのメンバーが同じ順序を遵守する場合、diffは実際の変更に集中し、レビュー者はタスクを一目でパターンマッチできます。
FQCNとは何ですか?モジュールにFQCNを使用する理由は?
namespace.collection.moduleFQCNはFully Qualified Collection Name(完全なコレクション名)を指し、完全なansible.builtin.aptパス、例えばaptではなく、単に -
です。Ansible 2.10以降、モジュールがコレクションに分かれました。複数のコレクションが同じ短い名前のモジュールを提供する場合、単純な名前は曖昧に解釈されます。FQCNは解釈を明確にし、すべてのモジュールのソースを記述し、プレイブックがコレクションの順序変更に影響されないよう保護します。
の
with_*loop: を with_items: に使うべき時機は?loop:lookupベースのループは最初のイテレーション方法でしたが、ループとlookupプラグインを結びつけるため、組み立て性を制限します。loop_controlキーワード(2.5で導入)は、リストを直接取り込み、インデックス、ラベル、および一時停止とスムーズに組み合わせます。シンプルなリストイテレーションでは常にloop:を好むべきです;必要なパターンがまだcleanwith_*の同等がない場合のみ、loopに回帰します。 -
YAML 'yes' がAnsibleで古びたのはなぜですか?
YAML 1.1では
yes,no,on,off,trueと、falseが論理値として扱われました。YAML 1.2では論理値をtrue/falseに限定しました。将来の互換性と明確性を維持し、特にYAML値がAnsible以外のツールで消費される場合、ansible-lintのyaml[truthy]ルールはtrueとfalseを使用することを推奨しています。厳密な論理値を使用することで、文字列yesをデータとして必要とする場合の驚きを回避できます。 -
command/shellタスクでchanged_whenを宣言するべき理由は?
Ansibleはモジュールの返却データを確認して、システムが変更されたかどうかを判断します。モジュールはそれらを自ら知ることができず、成功した実行を変更と見なすため、idempotencyチェックが嘘をつきます。changed_whenを宣言(または
command,shellと、rawを使用)することで、実際の変更条件——特定の終了コード、出力パターン、またはファイルマーカー——を明確に記述できます。結果として、idempotentなプレイブックは静かになり、diffがより正確になります。changed_whenは2026年6月8日に追加されましたcreates/removesプレイブック.yml、ロール、またはタスクリストをここに貼り付けます
恵 スコアボードが到着しました!
スコアボード ゲームを追跡する楽しい方法です。すべてのデータはブラウザに保存されます。さらに多くの機能がまもなく登場します!
