CLOSE

whenはいつも見ているぞというお話(全1記事)

Ansibleでサーバー切り離し自動化のはずが、いきなりダウン 「whenはif」の思い込みで起こったループ処理の失敗

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

サーバーの自動切り離しにAnsibleを活用した

市田友宏氏(以下、市田):私、市田と申します。よろしくお願いします。今日は、whenです。みなさんたぶんAnsible使うと、まず一番最初に使うのではないかという構文です。whenについてのやらかし話を紹介したいと思います。

仕事は、某通信キャリアでパケットゲートウェイという、ちょっとマニアックなシステムの開発をやっています。サーバーでもないネットワーク機器でもない装置を、なんとかがんばって自動化をしようという業務をしつつ、開発もしつつ、Ansibleはもう3年ぐらい触っています。

今回のお話ですが、whenです。whenについて、ifとは微妙に違うぞというお話をしたいと思います。

まず私がやりたかったことです。そのうちの1つですが、自分が管理しているサーバーで、障害や作業でメンテナンスするためによく切り離しをします。これをAnsible使って自動で切り離しましょうと。

今までは手でポチポチやっていたのですが、Ansibleで自動で切り離して、手動オぺレーションをなくしていきましょうというのを仕事の1つとしてやっていました。

想定外の挙動でサーバーがダウン

ここの処理ですが、ちょっとフローで簡単に表しています。ユーザーが使っているので、 最初にそのユーザーを追い出さないといけなくて、ユーザーを切断するというPlaybookを書きました。このサーバーは携帯などで使っているサーバーで、100万ぐらいセッションがあるので、けっこう待っていなければいけないんです。

数十分待つのですが、セッションが0になるまで数十分待っていましょうとループ処理を入れて、めでたくセッションがなくなって追い出せたら、最後にサーバーを落としましょうというPlaybookをRoleで作っていました。

やらかしは、このループのところです。ループのところでやらかしてしまいました。このループの処理は、このwith_sequenceというところで、for文みたいな感じで100回やるというループ文を書いています。

私もちょっと知識がないので、これをwhile的に書けるテクニックを持っている方がいらっしゃったら、ぜひ教えてほしいです。

今のところ、for文で100回繰り返して、セッションがなくなったら空回り処理するという動作にしています。このようなループ文を書いてみました。

これに、wait.ymlという名前をつけてみました。実際、このwait.ymlの中はどうしてるかというと、実際数十分待たなければいけないので、1分に区切って、それをひたすらループしています。途中でそのお客さんのセッション数を初期化して、 そのあとにもう1回今いくつぐらいユーザーがいるのかをincludeで取りにいくコマンドを打って、それをblockでつなげて、そのblockに対してwhen文を書いて、セッションが0でなければこのBlock文を実行して、1分待つというのをグルグルやりますと書きました。

数値で比較する時は、取り方が悪いと文字列で取ったりします。このint型でたまにハマるので注意をしましょうというところもあります。

このwhenでBlock文を書いてループして、グルグル待っていましょうというのをRoleとして作って動かしてみました。実際動かしたところ、このループで30分ぐらい待っているはずが、いきなりループ処理が終わってしまって、サーバーが落ちてしまいました。

私はもう顔面蒼白でした(笑)。なんでこのループ処理が動かなかったのかを考えました。

ループ処理が動かなかった原因

これも、数日かかりましたかね。けっこう時間がかかって、このset_factのところがきちんと数値で入っていないかとか、そもそもset_factされていないのではないかとか。そもそもこのwhen文の書き方が悪いのではないかとか、いろいろ考えたのですが、ちょっとわからなくて、シェルスクリプトをif文やfor文で書くとこんな感じなのかなと思い描いていました。

最初にこのBlock文でwhenの条件文を通過してしまえば、あとのタスクのpauseとかset_factとか、このincludeタスクとかが実行されると思っていたのですが、結果的に、Block文の中のwhenというのが、もうif文ではないよというところに気づきました。

ちょっと具体的に、どういう動作をしているのかなというところで、普通書かないのですが、こんな感じで動くのではないかというのをちょっと図解しています。

Block文をwhen文で仕掛けた場合に、上からすべてのタスクに対してwhenがかかるようなイメージです。途中でこのset_factで初期化した段階で、もう0になったので、あとはひたすらwhenが効いてしまって、後続の処理がまったく動かなかったというやらかしです。

私はこのwhenは最初に判断されて、あとはもうBlockの中のタスクは全部動いてくれると思っていたのですが、そうではなくて、Blockに対するタスクというのは、すべてのタスクに対してwhenが効いてしまうという動作だということを、やっと数日かけて気づきました。

ここで原因がわかったので、あとは楽です。途中ですべてが判定されるのであれば、そのBlockのwhenについては、最初は判断させずに、set_factで最後に判定文を入れることで、最初の動作は空回りせずに動くという処理をすることで、無事解決できました。

ちょうど今、このサーバーを落とすというやつを今日の夜やってきたばかりなのですが、きちんと無事動いてくれました。

書き慣れた人ほど思い込みは厳禁

まとめですが、Blockでwhenを使う時は、この条件文定義はかなり要注意です。私も、whenはifだろうと思ってずっと書いていたのですが、書き慣れた人ほどAnsibleはハマるネタがいっぱいあるのではないのかなと思ったりもしました。

あとは、whenはifだろうという勝手な思い込みですね(笑)。これでかなりハマってしまったというお話なので、やはり思い込みは厳禁だなあというのを、今振り返って反省しています。

以上です。ご清聴ありがとうございます。

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

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

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

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

人気の記事

新着イベント

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

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

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