Azure で Confluence Data Center を管理する

Azure で Confluence Data Center の使用を開始する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

デプロイメント テンプレートを使用して 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 テンプレートから自動生成されるため、これらのファイルを変更する必要はありません。

アップグレード

アトラシアンのエンタープライズ リリースをまだ使用していない場合、そちらへのアップグレードもご検討ください。エンタープライズ リリースでは 2 年間のサポート期間を通じて、重要なバグおよびセキュリティの課題に対する修正が適用されます。これにより、セキュリティや安定性を損ねることなく、アップグレードの頻度を減らすことができます。エンタープライズ リリースは、フィーチャー リリースのリリース頻度でのアップグレードが難しい企業に最適です。

デプロイメントのアップグレードについて、次の点をご確認ください。

  1. Confluence Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
  2. アップグレード中に Confluence Data Center を使用し続ける必要がある場合、サイト メンテナンス用の読み取り専用モードを使用することをおすすめします。ユーザーはページを閲覧することはできますが、作成したり変更したりすることはできません。
  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 は、共有ホームの基本的な冗長性戦略を提供します。そのため、定期的なバックアップは必要ありませんが、必要に応じ、スナップショットを使用してポイント イン タイムのバックアップを取得することができます。

アプリケーション ノード

アプリケーション ノードは、Azure 仮想マシン スケール セット内の VM です。各アプリケーション ノードには、Confluence インストール ディレクトリと、ログや検索インデックスが含まれるローカル ホーム ディレクトリがあります。 

共有ホームと同様に、アプリケーション ノードはローカル冗長ストレージで構成されているため、一度に複数のデータのコピーが存在します。 

インストール ディレクトリで設定ファイルを手動でカスタマイズしている場合 (ベロシティ テンプレートなど)、これらも参照用に手動でバックアップしておくことをおすすめします。 

Bastion ホスト

この VM はジャンプボックスとして機能するため、バックアップが必要なデータは持ちません。VM が応答しなくなった場合、Azure Portal から再起動できます。 

アプリケーション ゲートウェイ

アプリケーション ゲートウェイは高可用性構成です。デフォルトでは 2 インスタンスがデプロイされています。bastion ホストと同様、バックアップする必要はありません。 

ディザスタ リカバリ

ディザスタ リカバリ戦略の構築方法については、「Confluence Data Center のディザスタ リカバリ」を参照してください。また、リージョン全体の障害からの復旧に関する Azure ドキュメント「Azure のテクニカル ガイダンス: リージョン全体のサービスの中断から復旧する」も参照してください。 

最終更新日 2019 年 6 月 28 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.