この記事は#CloudGarage Advent Calendarの14日目です
前回まででCloudGarage上にJIRA(とConfluence)を構築できました。(その1、その2、その3)
今回は、構築時につまづいたところ、「つまづきそうだな」と思ったところなどを紹介してシリーズを完結しようと思います。
(CloudGarageのAdvent Calendarと言いつつ、CloudGarage関係ない話もあるけど気にしない)
※ 本編には「罠」という単語が登場しますが、「本人の理解不足によるつまづきポイント」くらいの意味で使用しています。
前回まででCloudGarage上にJIRA(とConfluence)を構築できました。(その1、その2、その3)
今回は、構築時につまづいたところ、「つまづきそうだな」と思ったところなどを紹介してシリーズを完結しようと思います。
(CloudGarageのAdvent Calendarと言いつつ、CloudGarage関係ない話もあるけど気にしない)
※ 本編には「罠」という単語が登場しますが、「本人の理解不足によるつまづきポイント」くらいの意味で使用しています。
ポートの罠
CloudGarageの一番のハマりポイントと言えば「ポート」、という統計があります。(サンプル数:1)
JIRAのデフォルトポートは8080ですが、「フロントにnginx立てて80(or 443)でリバースプロキシかますので8080開けてなくてもえぇやろ」と思って8080を開放せずにセットアップを進めた結果、JIRAの初期設定でDBの初期化でnginxのタイムアウトをくらって無事セットアップに失敗しました。
回避方法
■ 8090ポート
Confluenceのデフォルトポートは8090ですが、CloudGarageではコントロールパネルから8090を開放できません。
回避方法
ということで、ハマりそうな(実際にハマったものもある)ポートの罠についてです。(「CloudGarage関係ないやん」という内容もありますが気にしない)
■ 8080ポートJIRAのデフォルトポートは8080ですが、「フロントにnginx立てて80(or 443)でリバースプロキシかますので8080開けてなくてもえぇやろ」と思って8080を開放せずにセットアップを進めた結果、JIRAの初期設定でDBの初期化でnginxのタイムアウトをくらって無事セットアップに失敗しました。
回避方法
- 8080を開けておいて初期設定時はnginxを経由せずに直接JIRAを叩くようにする。
- 初期設定時にタイムアウトしないようにnginxの設定を変更する。
■ 8090ポート
Confluenceのデフォルトポートは8090ですが、CloudGarageではコントロールパネルから8090を開放できません。
回避方法
- Confluenceのポートを8090からコントロールパネルで開放できるポート(例えば8080とか3000とか)に変更してインストールする。
- 8090でインストールした上で、初期設定時にタイムアウトしないようにnginxの設定を変更する。
■ 8091ポート
最近のConfluenceには共同編集という機能があります。
この共同編集機能を有効にした場合、記事の編集時に8091にアクセスしようとします。が、CloudGarageでは8091ポートを(狙い撃ちで)開けられないので共同編集を有効にすると記事の作成画面が死にます。
回避方法
当初の構想では、JIRA用のインスタンスとConfluence用のインスタンスの前にそれぞれロードバランサーを立てて(nginxのリバースプロキシとか無しで)運用しようとか妄想してましたが、使えるロードバランサーは1契約1つだったのでインスタンス内にnginxを立てる運用になりました。
妄想が実現していたとして、↑のポートの罠でひどいことになっていたと思うので結果オーライ
■ SSHの罠
RancherOSはインストール時にSSHの鍵を設定し、その鍵を使用してSSHログインできるようになります。
で、鍵認証を有効にした場合はパスワード認証を無効にするのがサーバー管理の鉄則(#知らんけど)だと思いますが、RancherOSでパスワード認証を無効にする方法がわかりませんでした。誰か教えてください。
■ 再起動時の罠
DBが死んだ時にMackerelからDBサーバーのアラートが飛んできたので、サーバーに入ってdocker-compose upで復旧しようと思ったらdocker-composeがシステム上のどこにもなかったです。
RancherOSはdocker-composeのバイナリを落としてきて/usr/binとかに置いてもマシンを再起動したら消える仕様なんですかね?
(そもそもバイナリ落としてきて配置ってのがRancherOSの流儀に従ってない感ある)
Let's Encryptの更新で認証を行うためには/.well-known/acme-challenge/にアクセスできる必要があるらしいので、「/.well-known/acme-challenge/」にアクセスされたら、初回認証時にwebrootとして指定したディレクトリを返すように、nginxの設定を変更します。
今回のケースではwebrootとして「 / 」を指定しているため、ドキュメントルートは「/usr/share/nginx/html」になります。
具体的な設定はリポジトリにあるconfファイルのテンプレートを参照してください。
「/var/lib/mackerel」をマウントしてホストのIDを永続化し、auto_retirementを有効にせずに運用しているため、mackerel-agentのdocker containerを再起動してもmackerelのダッシュボードでは同じホストとして扱われると思っていましたが、container再起動で同じIDのホストが何台かできていました。
docker containerを再起動した場合でも同じホストとして扱わせるための知見を求めています。
JIRAとConfluenceに同梱されているJREがLet's Encryptに対応していなかったため、解決までに結構な時間を取られました。
詳しくは前回のエントリを確認してください。
Confluenceの日本語フォントの罠
Confluenceには既知の問題として、Confluence のマクロで日本語が表示されないというものがあります。
上記のリンク先の内容に従って設定をしてみましたが、まだ一部おかしいようなので、今後のバージョンアップで解決することを期待しています。
というわけで、CloudGarageをフルに活用してJIRAとConfluenceの環境を構築した際、運用した際の罠(ハマったポイント)でした。
DAPを提供してもらっているので、BOX3/1GBの環境で構築しましたが、DBを別インスタンスに用意すれば、メモリ1GなスペックでもJIRAもConfluenceも(個人で使う分には)快適に動作することがわかったのでCloudGarage様々ですね #ステマ
ということで、「CloudGarage上にJIRA(とConfluence)を構築した話」シリーズはこれでおしまいです。
この先もCloudGarage Advent Calendarをお楽しみください!
なお、このエントリは大都会岡山で書かれたため大都会岡山Advent Calendarの14日目でもありました。
最近のConfluenceには共同編集という機能があります。
この共同編集機能を有効にした場合、記事の編集時に8091にアクセスしようとします。が、CloudGarageでは8091ポートを(狙い撃ちで)開けられないので共同編集を有効にすると記事の作成画面が死にます。
回避方法
- Atlassianのドキュメントを参考にnginxの設定を変更する。
ロードバランサーの罠
罠というよりは仕様ですね。当初の構想では、JIRA用のインスタンスとConfluence用のインスタンスの前にそれぞれロードバランサーを立てて(nginxのリバースプロキシとか無しで)運用しようとか妄想してましたが、使えるロードバランサーは1契約1つだったのでインスタンス内にnginxを立てる運用になりました。
妄想が実現していたとして、↑のポートの罠でひどいことになっていたと思うので結果オーライ
Rancherの罠
JIRAとConfluence用のPostgreSQLを立てているDBサーバーはRancher上でDocker運用していますが、こいつにも罠があります。■ SSHの罠
RancherOSはインストール時にSSHの鍵を設定し、その鍵を使用してSSHログインできるようになります。
で、鍵認証を有効にした場合はパスワード認証を無効にするのがサーバー管理の鉄則(#知らんけど)だと思いますが、RancherOSでパスワード認証を無効にする方法がわかりませんでした。誰か教えてください。
■ 再起動時の罠
DBが死んだ時にMackerelからDBサーバーのアラートが飛んできたので、サーバーに入ってdocker-compose upで復旧しようと思ったらdocker-composeがシステム上のどこにもなかったです。
RancherOSはdocker-composeのバイナリを落としてきて/usr/binとかに置いてもマシンを再起動したら消える仕様なんですかね?
(そもそもバイナリ落としてきて配置ってのがRancherOSの流儀に従ってない感ある)
Let's Encryptの罠
Let's Encryptを導入し、自動更新のコマンドをcrontabに登録して安心していましたが、自動更新に失敗していました。Let's Encryptの更新で認証を行うためには/.well-known/acme-challenge/にアクセスできる必要があるらしいので、「/.well-known/acme-challenge/」にアクセスされたら、初回認証時にwebrootとして指定したディレクトリを返すように、nginxの設定を変更します。
今回のケースではwebrootとして「 / 」を指定しているため、ドキュメントルートは「/usr/share/nginx/html」になります。
具体的な設定はリポジトリにあるconfファイルのテンプレートを参照してください。
Mackerelの罠
DB用インスタンスはRancherOSを使用しているので、mackerel-agentもdockerで稼働しています。「/var/lib/mackerel」をマウントしてホストのIDを永続化し、auto_retirementを有効にせずに運用しているため、mackerel-agentのdocker containerを再起動してもmackerelのダッシュボードでは同じホストとして扱われると思っていましたが、container再起動で同じIDのホストが何台かできていました。
docker containerを再起動した場合でも同じホストとして扱わせるための知見を求めています。
JIRA or Confluenceの罠
JREの罠JIRAとConfluenceに同梱されているJREがLet's Encryptに対応していなかったため、解決までに結構な時間を取られました。
詳しくは前回のエントリを確認してください。
Confluenceの日本語フォントの罠
Confluenceには既知の問題として、Confluence のマクロで日本語が表示されないというものがあります。
上記のリンク先の内容に従って設定をしてみましたが、まだ一部おかしいようなので、今後のバージョンアップで解決することを期待しています。
というわけで、CloudGarageをフルに活用してJIRAとConfluenceの環境を構築した際、運用した際の罠(ハマったポイント)でした。
DAPを提供してもらっているので、BOX3/1GBの環境で構築しましたが、DBを別インスタンスに用意すれば、メモリ1GなスペックでもJIRAもConfluenceも(個人で使う分には)快適に動作することがわかったのでCloudGarage様々ですね #ステマ
ということで、「CloudGarage上にJIRA(とConfluence)を構築した話」シリーズはこれでおしまいです。
この先もCloudGarage Advent Calendarをお楽しみください!
なお、このエントリは大都会岡山で書かれたため大都会岡山Advent Calendarの14日目でもありました。
コメント