CCNAの試験に向けて学習中。
復習に見返せるようにメモしていきます。
ほぼ自分の勉強メモです。
過度な期待はしないでください。
前回投稿記事
こちらの ネットワークの自動化【SDNの概要】投稿記事と、
こちらの CiscoのSDNソリューション投稿記事の続きです。
3. ネットワークの自動化 - #### 3-1. プログラマビリティ プログラマビリティとは、プログラム言語を使用してネットワークの管理・運用を行うというものです。
昨今はプログラム言語を駆使して、手動で行っていたタスクを自動で行えるようにする事が
求められています。なぜなら、クラウドサービスの利用拡大やネットワークの複雑化によって
多様なニーズに対応しなければならなくなりました。只、その都度ネットワーク管理者が設定を
行っていては迅速に対応出来ません。そこで注目されているのがネットワークの自動化です。
前回の記事で記載した Cisco DNA Centerもそういった自動化を提供してくれるものに
なります。
3-2. REST APIの概要
REST API（RESTful API とも言います）は、RESTというアプリケーションの設計思想に従って
作成されたAPI※1（Application Programming Interface）です。
※1 APIとは、あるコンピュータプログラム（ソフトウェア）の機能や管理するデータなどを、
外部の他のプログラムから呼び出して利用する為の手順やデータ形式などを定めた規約
さらに詳しい解説は、「API とは」のサイトを参照
■ 3-2-1. REST
REST（ Representational State Transfer）の設計思想は、以下のような項目で
定義されています。
⚫️ クライアント、サーバー、リソースからなるクライアント/サーバーアーキテクチャ※2 で、
要求は HTTP経由で管理される。
⚫️ クライアントとサーバーのやり取りを効率化する、キャッシュの可否を制御出来る。
⚫️ ステートレス・クライアントサーバー通信。要求の間にクライアント情報は格納されず、
各要求は独立しており分離している
⚫️ 標準化された形式で情報を転送する為の、コンポーネント※3 間で統一されたインタフェースである事。
⚫️ 階層化されたシステム構成である事
⚫️ コードオンデマンド※4 である事（任意）
※2 アプリケーション、つまりクライアントをあるコンピュータ上で動作させ、
データベースサーバを別のコンピュータまたは同一のコンピュータ上で動作させる構成
※3 機器やソフトウェア、システムの構成する部品や要素などの事を意味する
※4 実行可能コードを要求されたときにサーバーからクライアントに送信して、
クライアントの機能を拡張する機能
■ 3-2-2. HTTPの概要
多くのREST APIは、HTTPプロトコルを使用しています。これはHTTPが、
クライアント/サーバー型の構成、ステートレス、キャッシュ可否などの機能をサポート
しており、RESTの原則と親和性が高い為です。
HTTPを使用してリソースの操作をする方法は、リソースを識別するURIと、リソースへの
命令であるHTTPメソッドによってなされます。
▶︎ URI
URI※5 は、リソースが存在する位置を示す文字列です。
構造は以下の通りです。
① 使用するプロトコルを表しています。今回は、HTTPを使用しています。
②＋③ リソースを保持しているホストを表しています。名前解決されたホスト名もしくは
IPアドレスが該当します。
④＋⑤ リソースが保持されているホスト内のパスを表しています。
※5 URIは、URLの上位の概念です。URLはリソースの位置を表す識別子ですが、
URL以外にもリソース名前を表すURNがあります。これらを総称して URIといいます。
▶︎ HTTPメソッド
HTTPでは、HTTPメソッド呼ばれるリソースに対して実行したい操作を示すいくつかの
アクションが用意されています。クライアントが指定したHTTPメソッドに応じて、サーバは自身の
リソースに対して、作成・更新・削除などの動作を実行します。
このようなリソースに対して行う主要な動作を、CRUD（クラッド）と呼びます。
Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）のイニシャルを並べた用語。
下記にCRUDそれぞれの動作と、それを実行するHTTPメソッドを示します。
| CRUD | HTTPメソッド | 意味 |
|---|---|---|
| Create | POST/PUT | 作成 |
| Read | GET | 読み取り |
| Update | PUT | 更新 |
| Delete | DELETE | 削除 |
■ 3-2-3. データ形式
クライアントとサーバは、REST APIを通してデータのやり取りを行いますが、
その際双方で扱っているプログラム言語が異なると、受け取ったデータをうまく受け取る事が
出来ません。サーバとクライアント間で正常にデータの受け渡しが出来るようにデータを
汎用的なデータの形式に変換（シリアル化）し通信を行う事が一般的です。
このデータの形式には、JSON、XML、YAMLといったものがあります。
▶︎ JSON
JSON（JavaScript Object Notation）は、人間と機械の双方によって可読性のバランスに
優れたデータ形式です。人間にとってはデータ形式が簡易で読み書きがしやすく、
機械にとっては JSONからプログラム言語の変換が容易に行えます。
Python、PHP、JavaScript、C++、Javaなど様々な言語でサポートされており、JSONを間に挟む事で
各プログラミング言語間のデータの受け渡しがとても簡単に出来ます。
▶︎ XML
XML（eXtensible Markup Language）は、文章の見た目や構造を記述する為の
マークアップ言語の一種です。HTMLと同様のものになります。
特徴として、XMLはデータの内容を記載する「タグ」を自由に設定する事が可能である為、
非常に高い柔軟性を持ちながら、データに意味を持たせる事が出来ます。
▶︎ YAML
YAML（YAML Ain’t Markup Language）は、構造化データを人間の目にわかりやすいように
表現出来るように設計された言語です。XMLなどのマークアップ言語と同じく構造化データを
表現する言語の一つですが、YAMLは自身の名前で言っているようにマークアップ言語ではありません。
YAMLは、マークアップ言語の課題であった、読みにくさを払拭する為のものです。
#### 3-3. 構成管理ツールの自動化 構成管理とは、各ネットワーク機器の設定を意図した状態に保つ事を指します。 ネットワークを安定して稼働させ、各機器間で正しい設定を保つには構成管理を適切に 行う必要があります。
■ 3-3-1. 従来の構成管理の問題点
今迄の管理管理の手順は、
対象デバイスにログイン → 設定コマンドの実行 → copyコマンドで設定を保持
→ 設定した内容をファイルに保存して保管 → 修正を行った場合、設定投入後ファイルを更新保管
と、全ての機器に対して1台ずつ設定を行う必要がありました。機器への設定だけでなく
その後の設定ファイルの管理迄手動で行わなければなりません。
こういった従来の手動で行う従来の手法では、ネットワークの規模が大きくなればなるほど
構成管理で人為的なミスが起こる危険性が高くなります。
こういった人的なミスから構成ドリフト※6 が発生しないように、構成管理を自動化する
構成管理ツールが開発されました。
※6 構成ドリフトとは、管理者間での情報共有の不足やファイル管理の未徹底により、
本来同一の設定が行われるべき機器間で発生する設定の差異を指します。
■ 3-3-2. 構成管理ルーツの概要
構成ツールのアーキテクチャでは、各機器の設定ファイルを共有ファルダで一元管理します。
そして、構成管理ツールをインストールしたサーバが、共有フォルダ上の設定ファイルを参照して
機器に対して設定を行います。
構成管理ツールの導入によって機器の一元管理が可能になる為、従来の手法よりも機器の管理が
しやすくなります。また、構成管理サーバでは機器の設定内容と共有フォルダ内の設定ファイルを
比較する事で、構成ドリフトが発生しているかどうかのチェックを行うことが出来ます。
##### ■ 3-3-3.構成管理ツール（Ansible） Ansibleとは、Red Hat社が開発するオープンソースの構成管理ツールで、 多数の手順書や資料に基づいて対応してきた設定作業や運用管理に関する作業を 自動化する事が出来る構成管理ツールです。
Ansibleの特徴
⚫️ 管理対象となるサーバやネットワーク機器に、エージェント※7 と呼ばれるソフトウェアの
インストールは不要であり、エージェントレスモデルを採用している。
⚫️ 従来の構成管理ツールで手順を記述する際に求められてたプログラミングの知識は不要であり、
YAML形式のテキストファイルで手順を列挙するだけで良い。
⚫️ 構成管理サーバから管理対象となるサーバやネットワーク機器へ設定情報などを送信する
Push型の通信形態
⚫️ プレイバック（Playbook）※8 と呼ばれるファイルを元に、構成管理サーバがPython codeの生成後に
管理対象となるサーバやネットワーク機器に転送してSSHやNETCONF等のプロトコル経由で実行する。
※7 エージェントとは、管理対象サーバのメモリ上に常駐する小さなプログラムです。
管理サーバーからの指示に応じて、管理対象サーバー上でさまざまなジョブタスクを実行します。
※8 プレイブックとは、構成管理の対象のデバイスやAnsibleが実行すべきタスク（コマンド）を
記述するファイル。YAMLを使って記述されている。
その他にも、インベントリ（Inventory）という、管理対象の役割とホスト情報を記述するファイルや
テンプレート（Template）という、複数のデバイスに共通の設定内容について記述するファイルが
あります。これらもYAMLを使って記述されています。
■ 3-3-4.構成管理ツール（Puppet）
Puppetとは、Puppet Labs社が開発するオープンソースの構成管理ツールで、ファイルに記述した
設定内容に応じてOS設定やアプリケーションの構築を自動化するオープンソースです。
Puppet特徴
⚫️ 対象サーバの「あるべき構成」を記述したマニフェストというファイルに記述しておくと、
その構成どおりにインフラを自動的にセットアップする構成管理ソフトウェアです。
Puppet独自の言語で記述しています。
⚫️ 管理対象となるサーバやネットワーク機器に、エージェントと呼ばれるソフトウェアの
インストールが必要なエージェントモデルを採用しているが、プロキシサーバを用いた
外部エージェントモデルに対応している為、Puppetに対応していないIOSバージョンの機器にも
導入が可能です。
⚫️ ネットワーク機器が構成管理サーバから設定を取得するPull型の通信形態を採用しています。
⚫️ Puppetのクライアントであるネットワーク機器は、Puppetのサーバから設定を取得する際、
HTTPやHTTPSを使用してサーバのTCP8140番ポートに接続します。
##### ■ 3-3-5.構成管理ツール（Chef） Chefとは、Chef Software社が開発するオープンソースの構成管理ツールで、 ファイルに記述した設定内容に応じて自動的にユーザーの作成やパッケージのインストール、 設定ファイルの編集などを行う構成管理ツールです。
Chefの特徴
⚫️ 管理対象のデバイスが、Chefに対応していないと使用出来ない。
⚫️ ネットワーク機器が構成管理サーバから設定を取得するPull型の通信形態を採用しています。
⚫️ Chefのクライアントであるネットワーク機器は、Chefのサーバから設定を取得する際、
HTTPやHTTPSを使用してサーバのTCP10002番ポートに接続します。
⚫️ Chef自体はRubyという言語で実装されています。なので、あたかもRubyでプログラミングを
するように、インフラの構成管理※9 をコードによって行えます。
構成管理の最小単位を「リソース（）Resource」、
リソースを纏めたファイルを「レシピ（Recipe）」、
レシピを含め、その他レシピの実行に必要なファイルやデータが纏まったディレクトリを
「クックブック（Cookbook）」として定義しています。
##### ■ 3-3-6.構成管理ツールの特徴比較 以下お表が各構成管理ツールの特徴になります。
| 特徴 | Ansible | Puppet | Chef |
|---|---|---|---|
| Push/Pull | Push | Pull | Pull |
| 使用するプロトコル | SSHやNETCONF | HTTP | HTTP |
| 定義ファイルの名称 | プレイバック | マニュフェスト | レシプとクックブック |
| 定義ファイルの記述形式 | YAML形式 | 独自形式 | Ruby言語 |
| サーバ側の待ち受けポート | なし | 8140/TCP | 10002/TCP |
| エージェントの要否 | 必要なし | 必要 | 必要 |