商用環境にAWXを利用する場合に抱えるべきリスク
はじめに
Ansible TowerとAWXとの違いについては、Red Hat社が下記に記載しています。
本番環境でAWXを使用するのは非推奨と明確に記載されていますが、 何らかの事情でこれを検討しなければならないケースを想定して、 AWXを選定、導入、運用した際に生まれるであろうリスクを想像で書き出してみます。
無論、私はRed Hat社の回し者ではありませんし、AWXを本番環境で使用することを 否定するものでもありません。
想定されるリスク
Red Hat社からのサポートが得られない
障害が発生して調査が必要、バグが見つかったので修正が必要、といった場合に、 Red Hat社から技術支援を得られません。
自分たちでトラブルシューティングを試みる場合、Ansible、AWX、場合によってはPythonに 精通したそれなりのエンジニアリソースが必要です。将来的なAWXのアップグレードを 考慮すると、AWXプロジェクトへのPRも検討が必要です(これはこれで良いことですが)。
最新リリース以外のバージョンにセキュリティパッチが提供されない
万が一セキュリティホールが見つかった場合の対処方法が、アップグレードに 制限される可能性があります。
複数バージョンをまたぐアップグレードのテストが未実施
商用環境において、AWXのような爆速リリースサイクルに、常に追従するのは実質不可能と言って 差し支えないかと思いますので、アップグレードの際は必然的に複数のバージョンを 跨ぐことになるでしょう。
先のセキュリティパッチの件と合わせて考えると、セキュリティ修正を 1つ適用したいがために、異なるバージョンのAWXを再構築、 再構成しなければならない状況が想定されます。
リスクの回避策
上記のリスクは一言で言うと、「何かあったらヤバい」というお話です。 逆に言えば、その"何か"を起こさなければ良いので、 実運用に即して十分にテストしたうえで、AWXをインターネットから隔離し、構築後に構成を変えなければ、 上記のリスクはある程度回避できます。
まとめ
当然、Ansible Towerもバグは存在するでしょうし、AWXも(変な表現ですが、)動かないわけではありません。 そういった意味では、何も起こさない、というよりかは、何か起きたら、という観点で、 リスクについて検討が必要かと思います。
POCや、小規模でハレーションが小さい環境では、AWXで十分という判断もあるでしょう。 逆に、大規模でハレーションが大きい環境だったり、ミッションクリティカルな オペレーションを自動化する場合は、安心と安定をRed Hatから買うべきと考えます。
