AWS で Jira Data Center を管理する
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
AWS 上の Jira Data Center で作業する際は、ノードの追加や既存の Jira インスタンスのアップグレードで環境を拡張したり、SSH を介して接続することができます。
カスタム DNS 名の設定
AWS 上で Jira Data Center をデプロイする場合、Amazon のロード バランサーを示す既定のドメイン名を取得します。これを使用して Jira にアクセスすることになります。このドメイン名はロード バランサーの名前と AWS のリージョンによって異なりますが、一般には "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com" のようになります。これは、より使い慣れた形式 (例: jira.atlassian.com) に変更できます。これを行うには、Quick Start の [Existing DNS (optional)] パラメーターに独自のドメイン名を入力します。これを実行するにはドメイン名が必要です。ドメイン名を持っていない場合はこちらから登録できます。
カスタム DNS 名を設定するには:
- Quick Start を使用して Jira をデプロイする際には、[Existing DNS (optional)] パラメーターに自身のドメイン名 (FQDN) を入力します。この名前は、Jira が使用する Web サーバーである Apache Tomcat の
proxyNameパラメーターに保存されます。すべてのノードがこのドメイン名を使用します。 - デプロイメント後、Amazon のロード バランサーのアドレスがわかったら、ドメイン名と関連付けます。これを行うには、DNS サービスを使用して、ソースおよびターゲット URL を入力する CNAME レコードを作成し、エイリアスを作成する必要があります。「カスタム ドメイン名をロード バランサー名と関連づける」を参照してください。
Jira をデプロイ済みの場合も、スタックで使用されるパラメーターを変更し、インスタンス タイプまたはドメイン名にすることができます。「リソース プロパティを変更する」を参照してください。
スケーリング (拡張および縮小)
同期ノード起動は、アプリによって強制されるようになりました。詳細については、「バージョン 9.1 における Jira 起動のインデックス管理の変更点」を参照してください。
Jira のインデックス管理に関する今後の変更について詳しくは、「Data Center ロードマップ」をご確認ください。
クラスター内のノードの数を変更するには:
- AWS マネジメント コンソールにサインインし、ナビゲーション バーのリージョン セレクタを使用してデプロイメントに対応した AWS リージョンを選択し、https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。
- デプロイメントの [Stack name] をクリックします。これにより、デプロイメントのスタック情報が表示されます。ここで、[Update] をクリックします。
- [Select Template] ページで [Use current template] を選択したままにし、[Next] を選択します。
- [Specify Details] ページで、[Parameters] セクションの [Cluster nodes] に移動します。ここで、次のパラメーターに対して希望する数のアプリケーション ノードを設定します。
- Minimum number of cluster nodes
- Maximum number of cluster nodes
- クリックしてスタックを更新します。
Auto Scaling の無効化について
クラスタの最小ノード数と最大ノード数が同じであるため、Auto Scaling が事実上無効化されています。
クラスタ ノードの最小数と最大数に異なる値を設定すると、Auto Scaling が有効になります。これにより、システム負荷に基づいてクラスタのサイズが動的にスケーリングされます。
ただし、Auto Scaling は無効化したままにすることをおすすめします。現時点では、Auto Scaling はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。
SSH 経由でノードに接続する
AWS Systems Manager の Sessions Manager を使用して、デプロイメントでノードレベルの構成または保守タスクを実行できます。このブラウザベースのターミナルでは、SSH キーや Bastion ホストを使用せずにノードにアクセスできます。詳細については、「Session Manager の開始方法」を参照してください。
Bastion ホスト経由でのアクセス
Bastion ホストをデプロイ済みの場合、それを経由してノードにアクセスすることもできます。これを実行するには、SSH 秘密鍵ファイル (Key Name パラメータに指定した PEM ファイル) が必要です。このキーはデプロイ内のすべてのノードにアクセスできるため、安全な場所に保管するようにします。
この Bastian ホストは、デプロイの内部サブネットの任意のインスタンスへの ”踏み台” として機能します。つまり、まず Bastion ホストに接続し、そこからデプロイ内の任意のインスタンスにアクセスします。
Bastion ホストの公開 IP は、デプロイの ATL-BastionStack スタックの BastionPubIp 出力です。このスタックは、デプロイの Atlassian Standard Infrastructure (ASI) にネストされています。Bastion ホストにアクセスするには、次の例のように、ユーザー名として ec2-user を使用します。
ssh -i keyfile.pem ec2-user@<BastionPubIp>
ec2-user は、 sudo アクセスを持ちます。root による SSH アクセスは許可されません。
バックアップ
スナップショットを使用して Jira Software Data Center のバックアップを作成する、AWS のネイティブ バックアップ機能を使用することをおすすめします。詳しくは、「AWS バックアップ」を参照してください。
AWS への既存のインスタンスの移行
- データベースを PostgreSQL に移行します。
- 既存のホーム ディレクトリとデータベースのバックアップを作成します。
- バックアップ ファイルをファイル サーバー EC2 インスタンスにコピーします。
- ファイル サーバーの
/media/atl/jira/sharedでバックアップ ファイルを展開します。 pg_restoreを使用して、バックアップ ファイルに含まれる PostgreSQL データベースのダンプを RDS インスタンスにリストアします。