Ansibleを使用してクラウドサーバーをセットアップするプロセスを自動化し、高速化します。 パート2:プレイブックの出力、デバッグ、再利用

前の記事で、 ITインフラストラクチャの構成と展開を自動化するための一般的なツールであるAnsibleの調査を開始しました。 AnsibleはInfoboxCloudに正常にインストールされました。作業の原則、基本的なセットアップについて説明します。 記事の最後に、nginxを複数のサーバーにすばやくインストールする方法を示しました。

Ansible InfoboxCloud

この記事では、引き続きAnsibleを探索します。プレイブックの出力を分析し、それらをデバッグして簡単に再利用できるように分離する方法を学びます。



構成管理



最初のプレイブックの解析


前回の記事では、最初のプレイブックの実行から結論を得ました。 分解してみましょう。







事実の収集は、プレイブックの最初のデフォルトタスクです。 タスクは、将来のプレイブックで使用できる変数の形式でサーバーに関する有用なメタデータを収集します。 たとえば、そのような変数は、IPアドレス、OSアーキテクチャ、およびホスト名です。

次のコマンドを使用して、これらの変数を表示できます。

ansible -m setup experiments
      
      



ここで、experimentsはインベントリ内のセクションの名前です。

またはファイルに書き込む

 ansible -m setup experiments >> facts
      
      





以下は、プレイブックの進行状況に応じたTASKタスクです。nginxのインストール、サービスの開始。



プレイブックをもう一度実行してみましょう。

 ansible-playbook playbooks/setup_nginx.yml
      
      









前の出力と比較して、 nginxパッケージインストールタスクは変更されずに完了しました。 ステータスはすでに到達しています:nginxがインストールされています。 nginxサービスはインストール後すぐに開始されるため、両方のケースでnginxサービスを開始するタスクは変更なしで完了しました。 いずれかのサーバーで手動でnginxサービスを停止すると、プレイブックの開始後にサービスが上昇します。







ご覧のとおり、Ansibleシステムの重要なプロパティの1つであるperformed 等性 (任意の値に数回適用すると、常に1回適用した場合と同じ値になる操作)が実行されます。 ほとんどの構成管理システムはこの原則に従い、インフラストラクチャに適用します。



出力の以下のPLAY RECAPセクションを見てみましょう。 変更されたパラメーターは、サーバーのステータスがタスクで変更された回数を示します。 ok- ファクトの収集とともに実行されたタスクの数。



プレイブックをデバッグする


プレイブックのプレイ中に何が起こったのかを理解することは、バグを修正するのに非常に役立ちます。

デバッグ出力には3つのレベルがあります(詳細)。



-v 基本情報を出力します。

 ansible-playbook playbooks/setup_nginx.yml -v
      
      









-vv 。 より詳細な結論。

 ansible-playbook playbooks/setup_nginx.yml -vv
      
      









-vvv 。 最も詳細な結論。

この出力は、リモートホストで一時ファイルを作成してスクリプトをリモートで実行するためにAnsibleが使用するSSHコマンドを識別します。

 ansible-playbook playbooks/setup_nginx.yml -vvv
      
      









デバッグ用に任意のansible変数を出力できます。 これを行うには、次のセクションをプレイブックに追加します。

  - name: Debug debug: msg={{ ansible_distribution }}
      
      





プレイブックを開始すると、この変数の出力が表示されます。 各Ansible変数は、 ansible_プレフィックスで始まります。







別の便利なコマンドは、プレイブックで実行されるすべてのタスクを表示する機能です。 他のプレイブックでプレイする複数のプレイブックがある場合に特に便利です。



 ansible-playbook playbooks/setup_nginx.yml --list-tasks
      
      









プレイブックから特定のタスクのみを実行できます。

 ansible-playbook playbooks/setup_nginx.yml --start-at-task="Debug"
      
      









プレイブックで再利用



タスクまたはタスクのセットが頻繁に使用される場合、他のプレイブックで使用できる個別のファイルとして整理することは理にかなっています。



再利用可能なタスク用のフォルダーを作成します。

 mkdir ~/ansible/playbooks/tasks
      
      





ファイル〜/ ansible / playbooks / tasks / os_update.ymlに OS更新タスクを作成しましょう:

 --- #Update and upgrade apt-based linux - name: Update and upgrade apt-based Linux apt: update-cache=yes state=latest sudo: yes
      
      





〜/ ansible / playbooks / setup_nginx.ymlのOS更新セクションを有効にできます。

 --- - hosts: experiments remote_user: root tasks: - include: tasks/os_update.yml - name: Install nginx package apt: name=nginx update_cache=yes sudo: yes - name: Starting nginx service service: name=nginx state=started sudo: yes
      
      





これで、nginxをインストールする前に、Inventoryのサービス対象サーバー上のUbuntuが更新されます。

nginxを頻繁にインストールする場合は、nginx(〜/ ansible / playbooks / tasks / pkg_nginx_install.yml )を別のタスクにインストールする価値があります。

 --- #Install NGINX package - name: Install nginx package apt: name=nginx update_cache=yes sudo: yes - name: Starting nginx service service: name=nginx state=started sudo: yes
      
      





その結果、私たちのプレイブックは非常にシンプルになります。

 --- - hosts: experiments remote_user: root tasks: - include: tasks/os_update.yml - include: tasks/pkg_nginx_install.yml
      
      





nginx(〜/ ansible / tasks / pkg_nginx_remove.yml )を削除するタスクを書くこともできます:

 --- #Remove NGINX package - name: Stopping nginx service service: name=nginx state=stopped sudo: yes - name: Remove nginx package apt: name=nginx state=removed sudo: yes
      
      





そしてそれを呼び出します(〜/ ansible / playbooks / remove_nginx.yml ):

 --- - hosts: experiments remote_user: root tasks: - include: tasks/pkg_nginx_remove.yml
      
      





 ansible-playbook ~/ansible/playbooks/remove_nginx.yml -i ~/ansible/inventory
      
      





-iを介して、インベントリファイルへのパスを指定します。これにより、ansibleフォルダからだけでなく、ansible-playbookを実行できます。



次の記事では、Ansibleの変数と条件について説明します。 最後に、当社のプレイブックは異なるオペレーティングシステムで正しく動作します。



おわりに



この記事の執筆は、 Learning Ansibleという本と、もちろん公式文書によって大いに助けられました。



Ansibleのすべての実験はInfoboxCloudで行うのが便利です。各仮想サーバーがタスクに必要なリソースの量を正確に設定できるため(CPU / RAM /ディスクは互いに独立)、または自動スケーリングを使用できるからです。



記事に間違いを見つけた場合、著者は喜んで修正します。 PMに連絡するか、それについて電子メールを送信してください。 そこで、後続の記事で取り上げるAnsibleの質問をすることができます。



パート3:変数とインベントリファイル

パート4:モジュールの使用

パート5:local_action、条件、ループ、および役割



成功しました!



All Articles