Future Tech Blog
フューチャー技術ブログ
DevOpsカテゴリ

エンプラ&オンプレでもAnsible導入成功したのでユーザー会で発表してきた

エンプラ&オンプレでもAnsible導入成功したのでユーザー会で発表してきた
こんにちは。齋場です。
少し前ですが、弊社でAnsibleを導入した事例をAnsibleユーザ会で発表してきました。(どちらも5minのLTですが) Ansibleを導入したおかげか、PJは問題なくリリースでき、やっと落ち着いたのでブログを書きたいと思います。

キラキラした最新技術をエンプラ&オンプレPJに泥臭ーく導入した話です。

発表内容

  • 2017/8/28(月) 3社共同企画 Ansible 夏祭り
  • 2017/12/21(木) Ansible Night in Tokyo

どちらの内容も多くの皆様に共感いただくことができた気がします。。!!特にエンプラPJでのサーバ管理のツラミについて

そもそもAnsibleとは

Ansible？ な方に対して、軽く説明させていただきます。Ansibleを説明するにはまず、Infrastracture as Codeを説明する必要があります。

Infrastructure as Codeとは

  • Infrastructure as Codeとは「自動実行可能なコードの形でインフラの状態を記述し、インフラ構築を自動化するプロセス」です。
  • インフラ構築を3つに分類すると以下のようになり、それぞれの分類に対応する自動化ツールがあります。

Ansibleとは

  • Ansibleとはオープンソースのサーバ構成管理ツールです。
  • 上図のように主にOS/ミドルウェア設定に主に用いられます。 (実際はサーバ管理だけではなく多くの機能があります)
  • よくAnsibleと比較されるのが以下の2つです。
    • Ansibleはエージェントレスということもあり、比較的に簡単に導入できます
    • あとは定義ファイルの形式がyamlかjsonかの違いというのも大きなポイントです
  • Ansibleの使い方は非常にシンプルです。基本の構成要素は以下になります
    • Invetroyファイル: (管理対象のサーバを定義するファイル)
    • Playbookファイル: (サーバのあるべき状態を定義するファイル)

Ansibleでサーバのあるべき状態をコードとして定義して、Playbookを実行するとサーバは定義した状態に収束します。(冪統性がある)
なんとも便利そうです。これなら数百台あるサーバであっても構築の自動化と高品質な構成管理ができそうですね。 以下のようにInfrastructure as Codeを導入すれば今までの課題が解決することは明らかだと思います。

エンプラ&オンプレへの導入へのチャレンジ!!

ここからが本題です。

導入したいけど、、

Infrastructure as Codeでインフラ構築の自動化！ 高品質な構成管理！ ができるとは言えど、実際導入するのは色々と障壁がありますよね。
以下のような声もPJから聞こえてきそうです。(エンタープライズ&オンプレだと特に)

  • 便利だけど、使うのは(ソースコード書くのは)難しんでしょ？
  • みんながAnsible使えるようにならないといけないんでしょ？
  • 今までの運用手順から変わってしまうんでしょ？
  • セキュリティ面とか大丈夫？

先述しましたが、Ansibleはエージェントレス型であったため障壁はかなり下がりました。 ただ、それだけでは導入はうまくいきませんでした。

エンプラ&オンプレ領域って特に難しい、、??

個人的に、エンプラ&オンプレの領域って、Infrastructure as Codeの導入が一番困難だと思っています。

まず、オンプレ これが相性が悪い。その大きな要因は**Mutable(可変)**であるためです。
クラウドであればサーバを都度破棄して、新規に構築する **”Immutable”**であるので、Infrastructure as Code本来の使い方に準じて利用できると思うのですが、オンプレだと作り直しができない”Mutable”であり、手入れをしながら長く付き合っていくことになります。その点を考慮してInfrastructure as Codeを利用しなければいけません。

(※ オンプレでも仮想マシンで、かつ”Immutable”な使い方をすれば話は別です)
(※ 逆に言えばクラウドでもMutableな使い方をしていると相性悪いと思います)

そして、エンプラ これも相性が悪い。**”制約”とか“いままでの文化”**が導入の大きな障壁になります。簡単に言うなら大きくて動きずらい。

日本ではあまり見かけないのですが、エンプラ&ウェブ系って以下のように比喩されることが多いそうです。**”ユニコーン”と”馬”**って、、なんか納得感。。

Facebook、Twitter、EtsyなどのWeb企業がDevOpsについて語るとき、彼らはユニコーンのような魔法の世界に住んでいます。クラウドベースであり、1つのサービスのみを提供することに重点を置いている企業は、共通のプラットフォームを利用して、誰もが同じページで作業できるようにします。
フォード、ゼネラルエレクトリック、ゼネラル・ダイナミクスなどの企業には、多くのチーム、数千の製品とサービス、そして豊富な技術を提供するさまざまなテクノロジーがあります。そのため、チーム全体を共通のページに置くことが困難になり、大きなDevOps転換を実行するのはより大きな課題です。

出典: Where is the “EA” in DevOps?

どのようにして導入したか

今回、PJ(エンプラ&オンプレ)にInfrastructure as Code導入成功したわけですが、やはり一筋縄にはいかないわけで。。ここからは導入の過程で工夫した点をご紹介します。

目指したサーバ管理方法

まず、Infrastructure as Codeを導入することでどのようなサーバ管理方法を実現するかのビジョンを定めました。

1. インフラへの変更はソースコード経由で行い、手作業での変更は原則禁止する
2. 実環境とのソースコードの定義は自動突合を実施し、不整合を検知可能にする

オンプレ(Mutable)だからこその考慮点がこれで、変更履歴を付けずに誰かが手でサーバを葬っちゃうともうInfrastructure as Codeの意味ってなくなっちゃうんですよね。クラウド(Immutable)だと、常に破棄→新規作成の繰り返しなのでこの点は考慮しなくてもよいですから。
私自身も含め「ちょっとの変更だし、あとで直せばよいから手で設定いじっちゃお。変更履歴は適当なメモで」って考えでサーバに変更を加える輩は絶対に存在します。だからこそ、そこを拾えるように実環境とソースコードの自動突合の部分にもこだわりました。

作り上げたフレームワーク

  • こんな感じのフレームワーク(と言っては大げさかもしれませんが)を作りました。
  • Ansibleの使い方だけではなく、PJに導入するために以下も考えました。
    • ビジョン
    • 手順書
    • ワークフロー
  • 構成は以下のようなイメージです。
  • JenkinsとGitlabを駆使して、継続的にAnsible実行&フィードバックができるような仕組みを心掛けました。

後述する”特に工夫したこと”で詳細記載します。

特に工夫したこと

いろいろな面で工夫しました。ほとんどは発表資料に記載しているので、ここでは特に工夫をしたことを紹介します。大きく3つあります。

  • 1. ただ新しい考え方を押し付けるのはダメ。今までの考え方に歩み寄る
  • 2. メンバーみんなにキャッチアップを求められない。みんなが利用できる仕組みを作る
  • 3. あきらめない

1. 考え方を押し付けるのはダメ。今までの考え方に歩み寄る

Ansibleで全部やろうとしない

  • インフラ構築すべてをAnsibleで実装。は理想ですが、ベンダーが構築する部分があったりと、すべてをソースコード化するのは受け入れ側も導入側にもパワーが足りなかったので以下の用途で使用を留めました。しかし、これだけでも効果はかなり大きかったです。
    • ファイル配布
    • ディレクトリ作成
    • ユーザグループ作成
    • パッケージインストール

Ansibleのベストプラクティスが私たちにベストとは限らない

  • Ansibleのベストプラクティスにあえて従わなかったことで今までの考え方に歩み寄りできるようにしました。
  • 私たちが使うAnsibleの構成は下図のように、**”role”=”サーバ種”**となっています。(本来ならば "role"="mysql" とか)
  • また、Ansibleでのファイル管理に関しては、**”動的ファイル(Jinja Templating)”は一切使っていません。**
  • インフラをソースコード化するというプロセスに拒否反応を抱かせないよう、今までの考え方に親和するようにしました。

※ このせいで、taskファイルや静的ファイルが二重管理になってしまいますが、それは後述のtaskファイル自動生成で補うことができました。

2. メンバーみんなにキャッチアップを求められない。みんなが利用できる仕組みを作る

Ansibleファイルが書けない? それならExcelから自動生成しよう

  • 導入当初はAnsibleソースを書けるのは私だけの状態。
  • 他のインフラ構築メンバーにも使ってもらわないと、全然回らないと感じてExcelに書いた定義からAnsibleファイルを自動生成するような仕組みを作りました。
  • AnsibleがわからなくてもExcelという慣れ親しんだインタフェースを設けたことで、Ansibleでの構築はかなり軌道に乗りました。
    ※ Excel1行 → YAML形式 と変換するだけだったので簡単なPythonスクリプトで済んだのも助かりました。

Gitが使えない? それならJenkinsにコミットしてもらおう

  • PJは、Gitを使える人は数人いるかどうか、という状態でした。
  • ただでさえAnsibleという新しいツールを導入するのに、Gitも、、は厳しそうだったのでGit操作はJenkinsに任せることにしました。
  • 歩み寄って、AnsibleファイルもSVNで管理、、、も考えましたがここだけは譲れませんでした。

3. あきらめない

絶対にサーバを手で葬らせない

あとは執念です。。

“環境がカオスになったのを直していく苦労 >>>>>>>>>>> Ansibleを導入する苦労”
であると私は確信していたので最後まであきらめませんでした。

「このディレクトリ、時間ないので手で作っちゃってもいいですか？」
「新しい設定ファイル必要になったので、手で作っちゃっていいですか？」

他のインフラ構築メンバーからそんな声がたくさん聞こえてきます。たとえ作業をし終わった後でもAnsibleのソースコード化をしないと、その構築範囲は構成管理ができなくなります。それでは意味がありません。なので、Ansibleを使える人だけで人が行った手作業をソースコード化を継続するのが非常に大変でした。。しかし、あきらめてはダメです。(途中からExcelソース自動化を導入したのでだいぶ楽にはなりましたが、軌道にのるまでは辛かった)
※Ansibleは冪統性があるので、いったん手で作業したところをソースコード化しても問題ない

分かってもらえるまで説明する

インフラチームにはすんなり受け入れられたのですが、チーム全体にInfrastructure as Codeという全く新しい考え方をわかってもらうのもなかなか時間がかかりました。
しかし、開発だけではなく運用でも使っていってもらうためには保守・運用チーム含めチーム全体に考え方を理解してもらう必要があります。これもあきらめてはダメです。そのためにチーム各所に何度も何度もプレゼンを行いました。
Ansibleは簡単に使いやすいとは言え、いままでのサーバ管理の考え方とはガラッと変わってしまうため、最初のほうは？ が連発ですが、継続的に普及活動を行ったので腹落ちして理解してもらえたと思います。資料にも記載しましたが、上の人から攻めていくのがおすすめです。あとは、実演して見せることも。

  • 導入のために作った説明資料の数々
  • 併せてDevOps勉強会も実施しました

導入の成果

なによりPJが無事にリリースできたのが大きな成果でしたが、以下も功績が非常に大きかったです。

作業自動化

今までサーバへの変更は以下のような**”ネ伸Excel”で手順を書いて、レビューしてもらって、手作業で実施していたものが、Ansibleによって自動化できました。これにより、工数も大きく削減できましたし、ヒューマンエラーもなくなりました。なにより、手順書作るのも、作業実施するのもとにかく“楽”**になりましたね。

  • 今までの手順書と新しい手順書

構成管理

今まではSVNのExcel上でしかできていなかったMWやOSの設定ファイル、またディレクトリの権限の構成管理は、ソースコードとして管理できるようになりました。(ファイル、ディレクトリのパーミッション含め)
アプリの世界では当たり前ですが、コミットメッセージに変更の経緯も残せますし、Gitのマージリクエストで承認依頼も出せます。当たり前のことがやっとできるようになったって感じです。
また、Git上にファイルをすべて管理しているので各サーバに入って設定値確認、なんて効率の悪いことは一切必要ありません。

  • Postfixの設定を変更した際の例

補足：導入までの時間

導入までの歩みをまとめてみました。開発(Dev)は一人でガンガン作りこんでいってしまえばよいだけなのでそんなに大変ではありませんでしたが、運用(Ops)でも使えるように、いろいろな関係者を巻き込んでいくのはなかなか骨が折れました。ただ、保守・運用チームが積極的に協力してくれたので、なんとか運用でも使えるようになるまでこぎつけることができました。感謝です。

最後に

Ansibleのようなツールはどんどん新しいものが出てきて、日に日に便利になっていきます。
私たちのPJは”ユニコーン”ではないので工夫と時間がかなり必要ですが、それでもその恩恵を受けることはできます。
実際に導入までこぎつけて、**”先進的なツール”と”今までのPJのやり方や文化”、これをどう結びつけるかが重要だと感じました。**

また、ここまでの仕組みを整えられたのもPJメンバーの協力があったからだと感じています。
この仕組み作りの重要性を理解し「どんどんやっちゃっていいよー」とGOをくれたリーダーに感謝です。
また、一緒にワークフローを検討し運用での利用の仕組みを整えてくれた保守・運用チームにも感謝です。
勉強会の交流会や、Twitterでは「Ansible広めたいけど、チームの誰も賛同してくれない」と言っている人はたくさんいました。(うちっていい会社ですね！ )

と言っても、まだまだこの仕組みは使い始められて間もないのでこれからさらに改良を重ねていきたいと考えています。

(注意)
資料に”おじさん”という表現がありますが、プレゼンでのウケを狙ったものです。本当は”おじさん”とか思っていません。