Ansibleを色々触って本番導入(まだ、途中)を進めて感じたことなどまとめてみた


Ansible(Ansible TowerやAWX)を本番に導入するために色々とやった事や思った事を簡単にまとめてみました。

Ansible初めて聞いて見て感じたこと

Ansibleを最初見て聞いた時に感じた事は Zabbix に似ていると感じた。
もちろん、監視という意味ではなく 自由な感じにいじれる という部分。
個人的にZabbixの魅力は インフラ基盤に捉われない監視システム が作れるところだと思っている。
とても自由度が高く簡単なスクリプトやプログラムを書いて連携させれば標準以上の監視や自動化など構築できる。
Ansibleも同じようにモジュールも自作できて組み込めて普通に動いてしまう。
自分が参画してるプロジェクトでは、巷の運用・監視パッケージ製品では対応できない部分が多々あり作り込む必要があった。
プロジェクトではVMwareやLinuxを使用しており、Ansible標準でLinuxモジュール・VMwareモジュールが提供されている部分もあった事、Playbookやモジュールの標準化ができそうなところが魅力的だと感じ導入を進めてみようと動いた。

Ansibleを触ってみて

Ansibleの存在自体は興味があったので結構前から知っていたが、自分が最初触ったのはAnsible2.3からだった。
早速、提供するサービスの運用で使えるか既存のモジュールを評価してみたが、正直言って期待していたVMwareモジュールはそこまで思っていたものとは違った。
環境に合うもの 環境に合わないもの でいうと 環境に合わないもの が多かったためモジュールをいくつか自作する必要があった。
AnsibleのVMwareモジュールのソースを見るとpyvmomi1で作られているものがほとんどでpyvmomiは監視の作り込みなどで以前から触ってたこともあってVMwareの自作モジュール作成についてはスムーズに行えた。
余談だがGoにもgovmomiがあり監視でパフォーマンスが必要な時はこっちを使っていたこともある。(RubyもPerlもあるので詳細はSDKのドキュメントを参照)

Ansibleを広めるためにやったこと

目的の周知

まずは、以下の目的の周知をした。

  • 運用品質の向上
  • Excel運用の脱却(変更管理の自動化)

運用品質の向上

一つのタスクをこなすのに人間だと2時間位かかるものがあったり、同じタスクを何回も回すものなどあり オペミス提供時間までが長い という課題があった。
基本、自動化をしてしまえば自動化範囲内であれば誰が行っても標準品質で提供できること、提供までのスピードが早くなったり、セルフにすれば利用者が自由にできるので満足度が上がるのでは?と言うこと、セルフでやれるようにすれば今までの運用は手ぶらになるので空いた時間で他のこともできるのでは?などを伝えた。

Excel運用の脱却(変更管理自動化による効率化)

変更管理では いつ だれが どういう目的で どの機器に対して どういう作業をするのか? 結果どうなったか? その他エビデンス(レビューなど) 設定変更後の設定 などを管理する必要があった。
これをExcelでやっていたが、以下の課題がった。

  • Excelの手順作成やハンコリレーにかかる時間がもったいない
  • レビューコメントがメールとかExcel内にあり統一していない
  • レビューシートもExcelで作ったりしてファイルだらけ、過去のレビューを見返すだけでも…
  • 設定の差分管理やExcelファイル自体のバージョン管理がとても手間
  • フォルダージャングルから過去の履歴を追うのは辛い
  • 引き継ぎするのも一苦労
  • etc…

Excel資料作るだけで丸一日潰れるとかもあり、効率化が必要だったため以下を提案した。

  • GitLab
    • GitLabでは いつ だれが どういう目的で どういう作業をするのか? その他エビデンス(レビューなど) 設定変更後の設定 を管理
  • Ansible Tower(AWX)
    • Ansible Tower(AWX)では いつ だれが どの機器に対して(実行し) 結果どうなったか? を管理

一先ずこれでやってみようということになっているが、Linux(ミドルウェア含む)は設定ファイルで管理すればよいのでこの形で問題ないがVMwareをどうしようかと課題(VMのデプロイやNW作成などは問題ないがvCenterやESXiの基盤設定管理など)になっている。
全てAPI経由からやればいいが、Managed Objectの概念を理解しSOAPのAPIを使って実装できる人材はウチだと数少ないため、PowerCLIなど使ってできないか考えている。

仲間集め&教育

社内勉強会などをやって感じたが、Excel SIerにとってはYAMLもプログラム言語と認識されてしまう。
条件分岐 変数 ループ処理 戻り値 を意識して書くことにあまりよろしく思っていないことが感じられた。
そのため、万人受けはまずしないと思ったのでやれる人たちから始めることにした。
若い子たちは興味がありチームは自然と若い子たち数人(+おっさん[自分])で組むことになった。
また、ボスにお願いして若い子達に対してAnsibleの有料トレーニングやプログラム教育をお願いしてお金を出してもらえそうなところまではきている。

Ansibleのモジュール・Playbook開発について

開発してて感じたことはモジュールやPlaybookを作り込みすぎると可読性が低くなるので モジュールPlaybook も小さな部品で作って後から 取捨選択 する形が一番綺麗にハマると感じた。
例えば、Ansible Tower(AWX)でPlaybook毎に ジョブテンプレート を作って ワークフローテンプレート で組み合わせていくなど。
ただ、(うちには今の所マッチしてるが)このやり方をそのまま当てはめてしまうと テンプレート数 = Playbook数 になっていまうので環境に合わせて作る必要がある。
運用設計次第でこの部分は変わってくると思う。

課題

今までやった事ない事をやろうとしているので 教育 が一番の課題だと感じている。

どこでも使える標準化は難しい

正直、自動化の標準化はサービスによってケースバイケースで変化していくため大まかな部分(初期構築など)は横展開できるかもしれないが、結局細部は作る必要がある(運用部分は特に)と感じた。
そのため、自分たちで開発・保守していける 個人の力や体制 を整えないと成功率は低いのではないかと思う。

自動化はやることがいっぱい

ここでやろうとしていることだけでも

  • Ansibleを知る必要がある
    • インベントリーやPlaybookの書き方
    • Roleの概念
    • ディレクトリ設計など
  • GitLabを知る必要がある
    • Gitの知識・使い方
    • リポジトリの運用(マージリクエスト出す時の開発ブランチどうするとか、フローとか)
  • Ansible Tower(AWX)を知る必要がある
    • 組織やロールの概念
    • プロジェクト、テンプレート、ワークフローテンプレートの組み合わせなど

を覚える必要がある。(AWXを使う場合はDockerで動くので運用もコンテナを意識する必要がある)
技術が好きで家でも仕事(趣味=仕事)でもやるような人であればいいが、基本そういう人は少ない。
これを解決するには以下のような体制(一つの例)になっていくのかなと感じている。

項目 説明
全部やる人(少数) 設計も実装も実行もやる人達
ある物を組み合わせる 既にある・開発されたモジュールやPlaybookを組み合わせて実行する人達
既にあるワークフローを実行する オペレーターなどを想定

エスカレーションは下から上に行く感じになるかなと。
全部やる人(開発者)と運用者の連携がきちんと取れるフローや体制を取れるよう運用設計する必要がある。

自動化システムの開発・保守

一度作ってしまえば後は放置なんていうのは幻想で、自動化をしても 自動化システムの保守 が必要になってくる。
例えば 見える化 などで実行されたジョブ数があり、失敗したジョブはどれだけで原因の特定と原因がコード(module or Playbook)にあればコードの改修が必要になってくる。
基盤やアプライアンスのバージョンアップによってAPI仕様が一部変わったら追従していく必要もある(自作モジュールを作っている場合)しテストの自動化などでCIを回す必要もある。
今回一通り実装して必要だと思った技術のスキルセットは以下の通りだと思った。

  • 基盤
    • ネットワーク機器(アンダーレイ)
    • サーバ機器
    • ストレージ機器
    • その他アプライアンス
  • 仮想レイヤー
    • vSphereの知識・技術
    • SDNの知識・技術(オーバーレイ)
  • API
    • REST/SOAP APIの知識(アプライアンス、SDN、その他ツール関連)
    • vSPhere API(SOAP)
  • プログラミング
    • Python
    • pyvmomi
    • Ansibleのmodul_utilsの仕様がソースから分かるレベルの知識
    • Ansible Moduleの仕組み
    • その他モジュール関連
  • ツール類など
    • GitLab
    • Ansible
    • Ansible Tower(AWX[Docker])
    • Jenkins/CircleCIなどのCIツール
    • LinuxやOSSミドルウェア

少人数でやっているためフルスタックレベルのスキルが必要だと感じた。
CI関連はまだ整ってないないので進めて行く必要がある。

現状

まだ、一部検証段階のものあるが2時間くらいのタスクは数分で終わるようになり、同じタスクは誰がやっても同じ結果になるところまではこれた。
例えば、SDNの設定やVMのデプロイ、Linux OSの標準セットアップやiptables/SELinuxのルールやミドルウェアの設定ファイルのバージョン管理ができるので切り戻しもバージョン指定でできるようになった。
結果、やってみてかなり作業効率が上がった。
まずは 全部やる人オペレーター でやって行く形にして間の あるものを組み合わせる 部分は徐々にスキルトランスファーをしていく形にしていこうと思っている。
あるものを組み合わせる 人達も慣れれば既存のモジュールを使ってPlaybookを書いていけるようになるとは思っている。

まとめ

  • 自動化をする場合、開発・保守できる人材や体制を社内に持つ必要があると感じた
  • Ansibleのモジュール開発は、Pythonと自動化対象のシステムで使われているAPI仕様が分かっていれば難しくない
  • 自動化ツール(モジュールやPlaybook)を作りっぱなしで終わるのではなく、開発者・運用者と連携した体制やフローを設計する必要がある(DevOps)
  • 運用にはCIも必要だよ
  • 自動化をする範囲にもよるが、物理・論理・OS・ミドルウェアを一元的に自動化しようとするとフルスタックレベルの知識・技術が必要だと感じた
  • 今後は運用者もプログラミングスキルが求められる時代になりつつあると感じた

  1. VMware vSphere APIをバインディングするPythonモジュール 

Leave a Reply

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください