Ansible Tower のアップグレード - 赤帽エンジニアブログ

みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。

毎月何か書くはずだったのですが2月はとても時間が過ぎるのが早く、結局28日の夜になりました。

今回は Ansible Tower のアップグレードについてお話します。

Ansible Tower のライフサイクル

最近は5月と11月にリリースが出て、1年半後にEOL(End Of Life)となる流れが続いています。いま最新版の3.8については、2年間サポートするものとなりました。3.x 系としての最終版となることが予定されています。

access.redhat.com

3.6 は5月にEOLとなってサポートを提供できなくなります。以前の記事にも書きましたが、3.7 ではアーキテクチャを刷新して大きくパフォーマンスの改善が行われましたので、まだお使いのお客様には少しでも早くバージョンアップをご検討いただきたいところです。

rheb.hatenablog.com

3.6 まで使われていた RabbitMQ は安定稼働させることが難しく、これまでさまざまなトラブルを経験してきました。ようやく捨てることができることになって我々サポートエンジニアも一つ大きな肩の荷を降ろせると喜ばしく思っています。

バックアップに含まれるもの

アップデートのためには、まずはバックアップを取っていただくことをお勧めします。

Ansible Tower のバックアップはインストール時に使った setup.sh を使いまして、setup.sh -b コマンドで取ることができます。そのバックアップには、このような内容が含まれています。

PostgreSQL データベースのダンプファイル
/etc/tower/ にある設定ファイル (DBへの接続情報など)
/var/lib/awx/projects/ ディレクトリに格納されている「手動」プロジェクト
/var/lib/awx/venv/ に作成した virtualenv 環境 (awx, ansible を除く)

この4点目で注意なのですが、Ansible Tower が提供する標準の Ansible Engine のための virtualenv 環境 (/var/lib/awx/venv/ansible) に Python モジュールを追加して構成されている場合であっても、バックアップは取られません。必要なときには再度 pip でインストールする必要があります。

こちらのドキュメントにも記載しておりますのでご覧ください。わたしが書いたものです。

access.redhat.com

バックアップから戻すときには、Ansible Tower をまず構成してから setup.sh -r コマンドで戻します。Ansible Tower を構成してからというのがポイントで、新しく別にインストールした場合であっても戻すことができます。もちろん既存の Tower にそのまま戻していただくこともできます。

リストア時の注意

Ansible Tower のバックアップからのリストアは、同じバージョンのものからしか行うことができません。

アップデートと一緒に構成も変えたいときは、まず同じ Tower のバージョンで構築してからバックアップをリストアし、そこからアップデートしていただくという流れになります。

RHEL 7 から 8 への移行

Ansible Tower 3.8 は RHEL 7 をサポートする最後のバージョンとなりました。

まだまだ自動化の対象が RHEL 8 に移行できないということも多いとは思いますが、Tower はその外側から基本的には SSH だけで接続して操作するというものですので、Ansible Tower だけでも RHEL 8 にして使っていただくことをご検討いただきたいです。

RHEL 7 でお使いの Tower を RHEL 8 にしていただくためにはこのような方法になります。

RHEL 7 の Tower でバックアップを取得する (setup.sh -b)
RHEL 8 を新規構築するか、RHEL 8 に直接(in-place)アップデートする
setup.sh を実行する
setup.sh -r でバックアップからリストアする
(可能であれば) Tower を最新版にアップグレードする

RHEL 7 を RHEL 8 に直接アップデートする方法についてはこちらのドキュメントをご確認ください。

access.redhat.com

このとき、新規構築した場合でも RHEL をアップデートした場合でも、Ansible Tower としては基本的に再構築と同じ扱いになります。リストア処理の中で再構築した状態を収集しつつ、バックアップから戻して再度きちんと構成しなおすという流れになります。

また、virtualenv に作った Ansible Engine の実行環境については、Python の実行環境の違いからそのままでは動作しませんので、再度作っていただく必要があります。実行環境についてはこちらもご覧ください。

rheb.hatenablog.com

シングル構成からクラスタ構成へ

バックアップからリストアするときに構成を変えてもよいということで、シングル構成で作った Tower をクラスタ構成にすることについても同じ方法で実施いただけます。

シングル構成でバックアップ (setup.sh -b)
クラスタ構成用にインベントリを編集してインストールを実行 (setup.sh)
(別に構築したのであれば) バックアップからリストアする (setup.sh -r)
(RHEL 7 から 8 へ移行した場合は) virtualenv を再構成する
(可能であれば) Tower を最新版にアップグレードする

Ansible Tower はさまざまな構成を取ることができますが、それまで運用されていたジョブテンプレートやインベントリなどの情報をそのまま引き継いで、クラスタ構成に拡張するなどができるようになっています。

シングル構成 (Ansible Tower と PostgreSQL が同居)
シングル構成 + 外部DB
クラスタ構成(3台〜20台) + 外部DB

最初は小さく始めていただくところからだと思いますが、お使いになるうちに自動化の対象が拡大してきたり、ジョブ実行のパフォーマンスを上げたいということが出てくると思います。バックアップを取って新しく構築して戻す、という流れで基本的にはそのまま移行していただけます。

インスタンスグループについて

ここまでは isolated node については触れませんでしたが、Ansible Tower はクラスタ構成や isolated node の構成のためのインスタンスグループの設定についても PostgreSQL データベースに保存して管理しています。構成の異なるバックアップからリストアしたい場合には、リストア処理の中できちんと対応していますので安心してリストアすることができます。具体的には、このような流れでリストアを実行します。