システム構成ツール

システム構成ツールの必要性と導入メリットについて解説します。

最終更新日:2024年02月07日

システム構成ツールの必要性と導入メリット

ITシステムを構築するにあたり、サーバーへのOSインストール、ルーターなどネットワーク機器の設定が、インフラ構築作業では必要です。

しかし近年ではさらにシステムの大規模化やクラウド化が進んだり、マイクロサービスアーキテクチャによる処理の分散化が進行したりしてきました。その中で、アプリケーションのコンテナ化や、DevOpsの進化により、アプリケーションの開発からデプロイ(本番環境への配置)が高速になり、短期間にアプリケーションがリリースされるようになってきました。

管理すべきサーバーやアプリケーション、コンテナなどの数が増大し、さらに開発から運用までの期間も短縮されたことで、以前のように手作業で1台ずつ設定作業をしていては、サービスの提供や運用管理が間に合わなくなったり、人的エラーが発生したりしてしまうリスクが出てきました。

こうしたニーズやリスク低減に対応するために各種設定作業もコード化しておいて、作業を自動化しようという取り組みが行われるようになります。こうした作業のコード化を、Infrastructure as Code(IaC)と呼んでいます。

作業を自動化することで、

  • サーバー設定などのプロビジョニング作業を標準化できる
  • より効率よく、ミスなく作業ができる
  • 台数が多くなっても短時間で作業が可能になる
  • 同じ設定を間違えずに行える

などのメリットが生まれます。

*冪等性(べきとうせい)

設定作業を何度も実行しても同じ結果が得られる特徴のことを「冪等性(べきとうせい)、idempotency」と呼びます。

構成管理ツールには、正規表現によるパターンマッチングを行い無駄な設定を追加しないようにする機能や、設定は行わずテストを行うdry run機能などがあり、誤った設定や余分な設定を行わないような工夫がされています。

冪等性が確保されることで、システムが大きくスケールした際にも、設定ミスを回避したり、作業負荷を軽減することが可能になります。

Ansibleの概要

作業の自動化を実行するには、構成管理ツールを使用します。

構成管理ツールには、いろいろなソフトウェアが存在します。Puppet, Chef, Salt, Ansibleなどが広く使用されています。

このうち、PuppetやChefなどは管理対象となるマシンにエージェントと呼ばれるクライアントソフトウェアをインストールし常時稼働させておく必要があります。それに対し、Ansibleでは(Linuxを含むUnix系OSの場合) SSH接続が可能であれば、管理対象のマシンにエージェントを常駐させておく必要がないため、エージェントレスな構成管理ツールと呼ばれています。

Ansibleはオープンソースで開発・公開が進められている構成管理ツールで、Python言語で記述されています。

YAMLという所定のフォーマットで記述された二つの設定ファイル(構成を定義したテキストファイル)に従って、サーバーやネットワークデバイスなどの設定を自動的に実行できます。

Ansible の動作環境は以下のようになっています。

  • 設定ターゲットを定義するインベントリファイル(Inventory file)
  • 設定作業を記述するプレイブック(Playbook)
  • 処理の最小単位(Module)

Ansibleのコマンドを実行すると、インベントリファイルに定義したホストにPlaybookがPythonスクリプトに変換されます。そして、変換されたスクリプトと、処理を実行するためのModuleがターゲットのホストに転送され、転送先のホストでPlaybookの記述にしたがって、各種処理や設定が実行されます。

Ansibleの動作イメージ

さらに構成管理だけでなく、アプリケーションの配置(デプロイ)や、コンテナの構成などにも対応するようになってきています。

ローカル環境へのAnsibleのインストールと対象ホストの設定

AnsibleをCentOS7にインストールするには、まずEPELリポジトリを追加します。これはAnsibleがCentOSの公式リポジトリに含まれていないためです。

# yum install epel-release

リポジトリを追加したら、yumコマンドでansibleをインストールします。

# yum install ansible

すると、/etc/ansible/ansible.cfgに設定ファイルが生成されます。そして、Ansibleを実行するホストを定義するには、この設定ファイルでinventoryの定義行の先頭の#を削除して有効化します。

inventory = /etc/ansible/hosts # 先頭のシャープを取ります。

続いて、/etc/ansible/hostsに、Ansibleで設定を行うホストの情報を記述します。

[www1]
192.168.1.10

複数台を指定するには1行に一つのホストの情報を入力します。

 Ansible Playbookの設定と実行

YAMLは各行に、「キー: 値」というフォーマットで設定を記述していきます。

例えば、Ansibleで構成を行うホストにhttpdをインストールするには、playbook.ymlに以下の記述を行います。

- hosts: www1
  remote_user: root

  tasks:
  - name: yum install
    yum: name=httpd

設定する先(hosts)とPlaybookファイルを記述したら、以下のようにansible-playbookコマンドを実行して設定作業を実行します。

$ ansible-playbook -i inventory playbook.yml

設定するターゲットのrootユーザーのsshログインのパスワードを求められるので入力するとPlaybookから自動生成されたPythonスクリプトが転送され、実行されます。

このようにして、設定対象となるホストと、設定処理の手順をあらかじめ記述しておくことで、各種設定を自動的に実行することができます。

システムの構成変更の自動化

Ansibleなどの構成管理ツールを用いると、既存のサーバーの設定変更だけでなく、コンテナの管理や設定変更などにも対応できます。

仮想サーバー・コンテナの払い出し

Ansibleは、Dockerコンテナのイメージの作成、Kubernetesへの展開などが可能になります。例えば、ansible-benderやAnsible Operatorなどがあります。

コンテナの作成、起動だけであればDocker Composerでも実現できますが、上記のようなツールを用いると、あらかじめ記述しておいたPlaybookにしたがって設定作業も実行することができるのが利点です。

他にも、以下のような操作を実行できます。

  • 既存イメージ、またはスクラッチからコンテナを生成する
  • 既存コンテナまたはDockerfileからイメージを生成する
  • コンテナのrootディレクトリをマウント・アンマウントして操作できるようにする
  • コンテナやイメージを削除する
  • ローカルコンテナをリネームする(別名をつける)

アプリケーションのリリース

構成管理ツールを用いると、仮想マシンの生成だけでなく、アプリケーションを配布したり、もしくはアプリケーションを含むコンテナイメージからコンテナを生成し、アプリケーションを提供したりすることができます。

Ansibleを用いる場合は、Playbookに記述した手順で、

  • 既存のサーバーにアプリケーションを配布して実行する
  • 新たに仮想マシンを生成や起動し、アプリケーションの配置や設定ファイルの読み込みなどを行う
  • アプリケーションを内包しているコンテナからイメージを生成して実行する

などの手順でアプリケーションを配布、リリースできます。

ネットワーク機器のステータス取得・設定変更

Ansibleなどの構成管理ツールはネットワーク機器の設定や、ステータス取得などにも対応しています。

各デバイスに対応した管理機能は、Ansible Network Moduleと呼ばれ、Ansible最新版(執筆時点では2.9)には数百ものネットワークモジュールが用意されています。

日本でもよく知られているデバイスには、以下のようなネットワークモジュールが提供されています。

  • A10(ロードバランサ)
  • Aruba(アクセスポイント)
  • F5(ロードバランサ) BigIPなどの製品
  • Fortios(ファイアウォール) FortiGate
  • Ios(Cisco製品、各種スイッチやルーター)
  • Junos(Juniper製ネットワークデバイス)
ネットワークモジュール一覧(Ansibleの公式ドキュメントより)

https://docs.ansible.com/ansible/latest/modules/list_of_network_modules.html

そして、Playbookに記述する設定には、

  • config (設定)
  • command (実行する設定コマンド)
  • facts (収集された設定情報)

などがあります。

ネットワーク機器の情報を参照する例

Ansibleのhostsファイルでは一つのネットワークデバイスを定義します。

[router]
10.0.10.110

次はPlaybookを作成します。以下の例では、ルーターのバージョン情報を取得し、テキストファイルに出力しています。ファイル名を「show_ver.yml」としています。

- hosts: router
  gather_facts: no
  tasks:
  - name: sh ver
    raw : "show ver"
    register: show_ver
  - name: sh ver output
    local_action: shell /bin/echo "{{ show_ver.stdout }}" > /home/cisco/ansible/shver_{{ inventory_hostname }}.txt

ホスト情報とPlaybookの作成を終えたら、ansible-playbookコマンドを実行します。

$ ansible-playbook -i hosts show-ver.yml --ask-pass
PLAY [router] *********************************
TASK: [sh ver] ***********************************************
ok: [10.0.10.110]
TASK: [sh ver output] ****************************************
changed: [10.0.10.110 -> 127.0.0.1]

PLAY RECAP ********************************************
10.0.10.110    : ok=2    changed=1    unreachable=0    failed=0

shver_10.0.10.110.txtのファイルの内容を確認すると、以下のようにルーターのOSのバージョンを確認できます。以上のようにしてサーバーだけでなく、ネットワーク機器の情報を取得したり、設定を実行することができます。

Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Experimental Version 15.4(20140730:011659) [lucylee-pi25-2 107]

執筆者紹介

・太田 俊哉

・井上 博樹

このドキュメントは、LinuCレベル2の学習用の教材から抜粋して作成されたものです。教材全体は以下のPDFファイルをご覧ください。
LinuCレベル2学習教材

ページトップへ