Typesafe Configを使って環境設定を切り替えしてみる
Blog
APIでネットワークを自動化するAXC
NetOpsCoding Advent Calendar2016 の12/9分の記事として投稿させて頂きました。
こんにちは。アドテクスタジオでネットワークエンジニアをしている山本 孔明です。アドテクスタジオのプライベートクラウドは少数のインフラメンバーで運営されており、そのためタスクの自動化を押し進めています。本日は、その一部を担う仕組みであるAXCを紹介したいと思います。
自動化と表現するのは語弊があるかもしれません。プライベートクラウドとして必要な操作を簡略化して公開してユーザに操作してもらっている訳ですから、セルフサービス化と記載した方が正しいかもしれません。弊社では2014年からこのAXCを使ってインフラを運用しています。
AXCとは
さて、タイトルにあるAXCという聞き慣れないキーワードですが、Adtech Studio X Cloudの略称です。アドテクスタジオは20個以上の広告プロダクトの集合体です。その中の多くの広告プロダクトが利用するプライベートクラウドの変更作業には、多大な労力を伴います。そのため、申請を元にした旧来のインフラ業務を極力減らしセルフサービス化を進めています。今時の言葉を使うと、アジリティ（俊敏性）の向上・インフラエンジニアのオペレーション負荷の軽減効果が見込めます。
以下のように簡素化されたコマンドで実行できるようになっています。
|
1 2 3 4 5 6 7 8 9 |
PC$ axc nodelist +-----------+-----------+---------+-------------+ | ADDRESS | NAME | SESSION | DESCRIPTION | +===========+===========+=========+=============+ | 10.1.1.1 | web01 | enabled | | +-----------+-----------+---------+-------------+ | 10.2.1.1 | db01 | enabled | | +-----------+-----------+---------+-------------+ |
これがなんで嬉しいの？という点を以下にまとめておきました。
- 学習コストが低い（アプリケーションの開発者が固有のコマンド・GUI操作を覚える必要がない）
- 簡単にJOBに組み込んだりすることが可能
- 思い立ったときにすぐインフラの操作ができる
今時の言葉を使うと、アジリティ（俊敏性）の向上・インフラエンジニアのオペレーション負荷の軽減効果が見込めます。
という訳です。
AXCの裏側
AXCはクライアントサーバモデルになっており、クライアントにはPython製のAXCがインストールされます。AXCはクライアントの入出力の制御とAPIコールの生成を行っており、実際にネットワーク機器を操作するのは図中のAXC API Gateway(以下、API Gateway)です。
先ほどのnodelistを例に挙げると、1と5がAXC、2から4がAPI Gatewayが担っています。
- nodelistをAPIコールに変換
- クライアントから送られてきた情報を元に認証
- APIコールを操作対象の機器用のAPIコールへ変換
- 操作対象からの返り値を元にエラー処理とAXCへの返り値を生成
- 返り値を元に整形して標準出力へ
API Gatewayについて
API GatewayはPythonのWEB Application FramewarkであるFlaskを元に作成しています。FLASKは軽量でとても使い勝手が良く、今回の用途（APIをルーティングする）にも適しています。今だと他にはFalconあたりを選定しても良いかもしれません。
なんでAPI Gatewayのようなものが途中にあるのか疑問に思った方もいるかもしれません。理由は以下の通りです。
- 各ネットワーク機器の認可・認証レベルの差を吸収するため
- 認証情報をクライアント側で保持しないようにするため
- ネットワーク機器による操作の違いを吸収するため
- クライアントのバージョンアップを極力実施しないようにするため
- ネットワーク機器側の仕様変更による影響をクライアント側に隠蔽するため
ネットワーク機器の実装によっては権限の付与について、APIを叩く時はAdmin権限が必要であったり、そもそもパーティショニングの概念がないものも多数あります。クライアント側に多くの情報を持たせるのはセキュリティ上好ましくありません。また、インストールされた全てのAXCに対してバージョンアップを行わずとも、API Gatewayの変更で吸収できるシチュエーションもあるのでユーザ影響のある改修を極力避けるという意味でも活躍してくれています。
API Gatewayの仕組み
API Gatewayはとてもシンプルに作られています。先ほど記載したFlaskを中心として以下のコンポーネントで構成されています。
- Nginx
- FLASK
- Gunicorn
- 操作用script
この範囲内においてはFLASKはとてもシンプルで扱いやすいです。以下が公式から抜粋したサンプルコードです。
|
1 2 3 4 5 6 7 8 9 10 |
from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello World!" if __name__ == "__main__": app.run() |
実際には@app.route内のPATHを叩いた後に各ネットワーク機器の操作用scriptを呼び出しています。操作用scriptはAPIが用意されているものであればAPIを呼び出し、APIが用意されていなければexpectで力技だったり・・・、複数の設定をまとめる必要がある場合も同様に、エラーハンドリングをしながら必要な処理を実行しています。その辺りの複雑な処理はクライアント側には実装せずAPI Gatewayが担っています。
API GatewayからはAXCにシンプルなJSONを返すようにしています。
どんなことをしている？
以下の操作を権限に合わせて公開しています。もちろん。VLAN作成など複数箇所に同時に実施するものはaxc vlan create 1111 --resion NW-Aのように、基盤名と共にデプロイすることで同時に対象機器へ設定が反映されます。
- Loadbalancerの操作（VIP設定、Pool設定、Node設定、ステータス・リスト表示など）
- SVI作成、VLAN作成、VLANアサイン
- ACLの追加
- OpenStack Neutron / Novaの一部設定
- VPNユーザの作成
- jenkins / zabbixの操作
今後の課題とまとめ
負荷が高かった申請作業はAXCに取り込むことができました。操作簡素化という観点ではまだ作業は残っているため、ユーザのリクエストに応じて機能実装を進めていく予定です。
Author
komei
