Azure で Confluence Data Center を管理する
デプロイ方法としての Azure Resource Manager テンプレートに対するアトラシアンのサポートや保守はすでに終了しました。ただし、ご自身の用途に合わせてカスタマイズを行い、Azure に Data Center 製品をデプロイすることは引き続き可能です。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスタにデプロイすることをお勧めします。Kubernetes へのデプロイの詳細をご確認ください。
デプロイメント テンプレートを使用して Confluence Data Center を Azure にデプロイしたら、独自のハードウェア上でアプリケーションを管理する場合と似た方法でアプリケーションを管理できます (bastion ホスト (ジャンプボックス) 経由でノードにアクセスする必要がある場合を除く)。
ジャンプボックスとノードにアクセスするには、以下が必要です。
- セットアップ中に提供された SSH 資格情報
- セットアップ中に提供した Confluence ノード資格情報
- ジャンプボックスの DNS 名または IP アドレス (メニュー > リソース グループ > <自分のリソース グループ> > confluencenat から Azure ポータル経由で取得できます)
- [接続されているデバイス] の
confluencecluster (instance n)行に記載されているノード IP アドレス ([メニュー] > [リソース グループ] > [<自分のリソース グループ>] > [ confluencenat] から Azure ポータル経由で取得できます)。
SSh を介して Azure ジャンプボックスへ接続する
Confluence クラスター ノード、Synchrony ノード、および共有ホーム ディレクトリへ SSH で接続し、構成またはメンテナンス タスクを実行できます。SSH パブリック キー ファイルは安全な場所に保存する必要があります。このキーはジャンプボックス (つまりインスタンス内のすべてのノード) へのキーです。
以下を使用して、ターミナルまたはコマンド ライン経由でジャンプボックスにアクセスします。
$ ssh JUMPBOX_USERNAME@DNS_NAME_OR_IP_ADDRESSデプロイメントの出力セクションで SSH URL を見つけることができます。
ジャンプボックスにアクセスしたら、以下を使用してクラスター内のノードへジャンプできます。
$ ssh NODE_USERNAME@NODE_IP_ADDRESSこの後ノードのパスワードが要求されます。パスワードを入力したら、ノードへ接続されます。
設定ファイルにアクセスする
お客様の Azure デプロイメントでは、独自のハードウェア上のデプロイメントと同じように、一部の構成ファイルの変更が必要となる場合があります。
server.xmlが/opt/atlassian/confluence/confに格納されているsetenv.shが/opt/atlassian/confluence/binに格納されている- ローカル ホーム
confluence.cfg.xmlが/var/atlassian/application-data/confluenceに格納されている - 共有ホーム
confluence.cfg.xmlが/media/atl/confluence/sharedに格納されている
これらのファイルには既存のノードからのみアクセスできます。共有ホーム は、/media/atl/confluence/shared で各ノードにマウントされています (ネットワーク ハード ディスクのイメージ)。そのため、既存のノードから (SSH 経由でログインしている場合)、/media/atl/confluence/shared に移動できます。
これらのファイルへの変更が手動で行われた場合、新しいノードはこれらの変更を取得しません。各ノードで変更を繰り返すか、派生元のファイルが存在する /media/atl/confluence/shared ディレクトリでテンプレートを変更します。次のようにマッピングされます。
server.xmlファイルは/media/atl/confluence/shared/server.xmlから派生しますsetenv.shファイルは/media/atl/confluence/shared/setenv.shから派生します- ローカル ホーム
confluence.cfg.xmlは/media/atl/confluence/shared/home-confluence.cfg.xmlから派生します - 共有ホーム
confluence.cfg.xmlは/media/atl/confluence/shared/shared-confluence.cfg.xmlから派生します
テンプレート ファイルには、デプロイメント スクリプト経由で挿入された値のプレースホルダーが含まれます。これらを削除または変更すると、デプロイメントが破損する可能性があります。ほとんどの場合、これらの設定の多くは、Azure Resource Manager テンプレートから自動生成されるため、これらのファイルを変更する必要はありません。
アップグレード
デプロイメントのアップグレードについて、次の点をご確認ください。
- Confluence Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
- アップグレード中に Confluence Data Center を使用し続ける必要がある場合、サイト メンテナンス用の読み取り専用モードを使用することをおすすめします。ユーザーはページを閲覧することはできますが、作成したり変更したりすることはできません。
- 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Confluence のアップグレードのためのステージング環境の作成方法」には、これを行うための便利なヒントが記載されています。
ローリング アップグレード
Confluence Data Center 7.9 以降、次のバグ修正バージョンに (7.9.0 から 7.9.3 など) ダウンタイムなしでアップグレードできるようになりました。「Confluence をダウンタイムなしでアップグレードする」の手順に従います。
Azure で Confluence をアップグレードする
Confluence のアップグレード プロセスは、独自のハードウェア上でクラスタを実行する場合と同じです。まずはすべてのノード上で Confluence を停止してください。その後1 つのノードをアップグレードし、停止してください。そのノードのインストール ディレクトリをクラスタ内の残りの各ノードへ 1 つずつコピーし、終わったら再起動します。
詳細は、「Confluence Data Center をアップグレードする」を参照してください。
デプロイメント テンプレートの confluenceVersion パラメーターを使用して、既存の Confluence デプロイメントをアップグレードしたり、異なるバージョンを実行している新しいノードをクラスタの残り部分にプロビジョニングしたりすることはできません。
また、ローリング アップグレードを実行することはできません。アップグレードの前に、すべてのノードを停止する必要があります。
オペレーティング システムのアップグレード
Confluence ノードで実行中のオペレーティング システムをアップグレードする必要がある場合は、各ノードに SSH 接続し、sudo apt dist-upgrade (Ubuntu) を実行してから各ノードを再起動する必要があります。
Confluence はサービスとして実行されているため、リブート時に自動的に再起動されます。
Hazelcast によるクラスタ ノードの検出方法により、Jira の場合のように、インスタンスを単純に再イメージ化することはできません。
バックアップと障害からのリカバリ
可能な場合は Azure のネイティブ バックアップ機能を使用することをおすすめします。これによって、データをバックアップし、障害時に簡単に復元できるようにします。
データベースのバックアップ
アトラシアンでは高可用性構成の Azure マネージド データベース インスタンスを使用しています。Azure ではデータベースのバックアップに関する複数の素晴らしいオプションが提供されているため、ニーズに最適かつ費用対効果の高いオプションの選択に時間を割くことをおすすめします。選択したデータベースに対応する、以下の Azure ドキュメントを参照してください。
共有ホームのバックアップ
共有ホームには添付ファイル、プロファイル画像、およびエクスポート ファイルが保存されています。アトラシアンでは一般的な Azure ストレージ アカウントを作成します。これはローカル冗長ストレージ (LRS) で構成されており、一度に複数のデータのコピーが存在することを意味しています。
LRS は、共有ホームの基本的な冗長性戦略を提供します。そのため、定期的なバックアップは必要ありませんが、必要に応じ、スナップショットを使用してポイント イン タイムのバックアップを取得することができます。
Application nodes
アプリケーション ノードは、Azure 仮想マシン スケール セット内の VM です。各アプリケーション ノードには、Confluence インストール ディレクトリと、ログや検索インデックスが含まれるローカル ホーム ディレクトリがあります。
共有ホームと同様に、アプリケーション ノードはローカル冗長ストレージで構成されているため、一度に複数のデータのコピーが存在します。
インストール ディレクトリで設定ファイルを手動でカスタマイズしている場合 (ベロシティ テンプレートなど)、これらも参照用に手動でバックアップしておくことをおすすめします。
Bastion ホスト
この VM はジャンプボックスとして機能するため、バックアップが必要なデータは持ちません。VM が応答しなくなった場合、Azure Portal から再起動できます。
アプリケーション ゲートウェイ
アプリケーション ゲートウェイは高可用性構成です。デフォルトでは 2 インスタンスがデプロイされています。bastion ホストと同様、バックアップする必要はありません。
ディザスタ リカバリ
ディザスタ リカバリ戦略の構築方法については、「Confluence Data Center のディザスタ リカバリ」を参照してください。また、リージョン全体の障害からの復旧に関する Azure ドキュメント「Azure のテクニカル ガイダンス: リージョン全体のサービスの中断から復旧する」も参照してください。