CLOSE

本当にあった怖い話 Ansible SaaS運用編(全1記事)

Ansible SaaS運用で起きたAPサーバーの上書き 巨大ワークフローテンプレートで本当にあった怖い話

Ansibleユーザーのコミュニティミートアップ「Ansible Night」がオンラインで開催されました。今回は、Ansibleの最新技術キャッチアップとあわせて、Ansible利用時にやらかした話、ハマった(けどこうやって解決した)話を共有する場となりました。じろ氏は、Ansible SaaS運用で起こった事故について発表しました。

自動化の環境はAWSで動くWebシステム

じろ氏:「本当にあった怖い話 Ansible SaaS運用編~大いなる力には大いなる責任が伴う~」というタイトルで、じろが発表します。よろしくお願いします。

最初に、これは実際にAnsibleを使って起きた事故です。本当にすごくしょうもない事故ですが、今のところ有効な再発防止策がないので、もしいい案があればハッシュタグ付きでツイートしてもらえたらと思います。そのあと、私が起こしたわけではありませんが若干脚色して話そうと思います。

(スライドを指して)こちらが自動化している環境です。特徴としては、AWS上で動くWebシステムで、1つの共有OSにそれぞれいろいろな顧客別のデータベースとアプリケーションが入っていて、Webの入口だけ分かれているような仕組みです。これは契約ごとにどんどん増えて、多い時は同時に月2契約くらい増えることもありました。

これはどうやってAnsibleを使っているかというと、include_varsです。顧客ごとの環境定義ファイルのようなものをvarsファイルとして作っています。AWSなら、VPCやSecurityGroup、Route53 CloudWatchのような定義ファイルです。Webなら、httpdやSSLの証明書。APなら、EARファイルやserver.xml、Javaのプロパティファイル。DBなら、データベース名など。

共通OS部分には追加するユーザーや起動サービスが変数として格納されていて、それをAnsible Tower実行時にinclude_varsで読み込んで、Playbookが実行されます。(スライドを指して)この一番下が増えるという意味です。

これは本当に、いろいろなことをやっています。トータルでは25ノードくらい、ワークフローのテンプレートがジョブテンプレートを何個か組み合わせてやっているような、巨大なワークフローテンプレートです。

巨大なワークフローテンプレートで起きた事故

そしてある日、このワークフローを使っていて事件が起きました。どこで起きたのか。こちらは少し脚色しています。というのも、APサーバーのXMLをテンプレートモジュールを使って展開するところで、誤って既存環境のserver.xmlのパスを書いてしまったんです。

そうすると何が起きるか。サーバーが見ているDBの参照先が変更されて、とんでもないことになりました。実際は、APサーバーが再起動しないとXMLはすぐに反映されません。すごく問題になったかというとそれほどではありませんが、これはいわゆる事故です。

この事故はどうすれば防げたのか。現時点では有効な手段を思いつきませんが、本当に「そもそも共有のOSは自動化に向いていない」と思っています。

政治的な理由でこうなってしまったので、なんともしょうがないのですが、やはり1つの環境変更が全体や既存に影響します。これが共通OSではなく個別OSなら、include_varsではなくhost_varsを使うことになるので、わりと全体への影響は下がったのではないでしょうか。コーディングの範囲ではどうしようもないと思います。

暫定の再発防止策「大いなる力には大いなる責任が伴います」

ほかにも、変更箇所が多いので変数も多いです。1環境あたり120個あるので、Varsファイルを使ってYAMLですべて入念に指差しチェックしても、たぶん限界というか、絶対にミスは起きると思います。

それを防ぐために既存環境との変数重複チェックツールを作るのは、あまり実装イメージが湧きません。Excelからvarsを自動で生成するようなマクロも考えてみましたが、そもそもExcel入力を間違えたら意味がないので、根本的な再発防止策にはならないと思っているところです。

(スライドを指して)これはちょっと恥ずかしい。現時点での暫定の再発防止策として、おふざけで書いていますが、「大いなる力には大いなる責任が伴います」。どっかで見たぞみたいなところもあると思いますが、このような文言を加えることによって、実行前にもう一度変数を確認することが、今現時点で取り得た最善の手だと思っています。

大事なのは自動化においていかにミスを防ぐ環境を作れるか

まとめです。やはり、コーディングだけではなく、自動化でいかにミスを防ぐ環境を作るかが非常に大事だと思っています。特に今の環境は、オンプレで動いていたレガシーなものをそのままAWSに持っていったようなところがあるので、マイクロサービスではありませんが、やはりいろいろな機能を分離して、あまりほかに影響しない仕組みが大事だと思っています。

自動化は大事だし便利だと思いますが、使い方を間違えると環境破壊にもつながるツールなので、やはり「大事なのは責任感」というオチがあると思います。

また、いい案をお待ちしています。私の発表は以上です。ご清聴ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

  • じろ

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!