【AWS】EC2にアプリを載せて,ドメイン接続、メール送信、SSL証明書取得の設定行う。(Route53, AmazonSES)
今まで無料で利用出来ていた会社のGitLabが、社員数増加により利用できなくなったため、会社でGitLab専用のサーバーを用意してGitLab self-managed版をインストールして自社で運用することになりました。
AWSの知見を深める良い機会だったので、導入までの全ての構築を任せて貰い、ネットワーク構築, サーバー, ドメイン取得, メール設定等、インフラ資材はほとんどAWSを活用して構築しました。 その時の一連の手順を今後のためにマニュアル化したかった為こちらにまとめることにしました。これからGitLabを自前で運用しようとお考えの方、企業様の参考になれれば幸いです。
※本記事は、今までにサーバーを立てた事ない方やAWSを利用したことない方向けに書いています。説明が細かい分やや長いです...。
GitLabの構築と書いていますが、ここで紹介するRoute53とAmazonSESの設定はGitLabだけでなく他サービスの構築や個人サイト構築時にも有効です。
GitLabを構築する方以外にも参考になれば幸いです。
この記事でやっていくこと
- EC2にGitLabをインストールする。
- Route53を使ってドメインを取得してドメイン名でGitLabにアクセスする。
- SSL証明書を取得してhttps接続でGitLabにアクセスする
- AmazonSESを使ってメール設定を行いメールの送受信を行う。
※上記記事は下記記事の続きです。
目次
- EC2にGitLabをインストールする。
- Route53を使ってドメインを取得してドメイン名でGitLabにアクセスする。
- SSL証明書を取得してhttps接続でGitLabにアクセスする
- AmazonSESを使ってメール設定を行いメールの送受信を行う。
EC2にGitLabをインストールする。
まず、EC2にGitLab(Self-Managed版)をインストールしていきます。
GitLab公式ドキュメントの手順を参考にして進めていきます。
※EC2はUbuntuを利用しています。Ubuntu以外のLinuxをお使いの方は適宜コマンドを変えて進めてください
- 依存パッケージのインストールと設定
下記コマンドを実行します。
公式手順ではこの手順の次にpostfixをインストールするコマンドがありますが、今回はAWSのメール送信機能を使うのでスキップします。
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates
- GitLabパッケージのリポジトリへの追加とインストール
下記コマンドを実行します。
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo apt install -y gitlab-ee
画像のようなGitLabのロゴや「Thank you for installing GitLab!」がコンソールに出力されたらGitLabのインストール成功です!
- GitLabを起動する
出力メッセージにもあるように、下記コマンドを実行するとGitLabインスタンスを実行することができるので実行します。
### GitLabの起動
sudo gitlab-ctl reconfigure
数分待って「gitlab Reconfigured!」が表示されたらGitLabの起動の成功です。
上記画像内のメッセージにもあるように、この時、GitLabのrootユーザーのパスワードが所定のディレクトリに出力されているので書き留めておきます。
このファイルは24時間で消えるので忘れずに!
ubuntu@ip-10-0-1-171:~$ sudo cat /etc/gitlab/initial_root_password
# WARNING: This value is valid only in the following conditions
# 1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).
# 2. Password hasn't been changed manually, either via UI or via command line.
#
# If the password shown here doesn't work, you must reset the admin password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.
Password: *********************************************
# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.
- ブラウザからGitLabにアクセスする。
GitLabの起動をブラウザからから確認します。
まだドメインを取得していないのでグローバルIPアドレスでアクセスします。
アクセス出来ました!これでGitLabのインストールは成功です!
Route53を使ってドメインを取得してドメイン名でGitLabにアクセスする。
続いて、Route53を使ってドメインを取得して行きます。
-
サービスの検索ボックスに「Route53」と検索して、「ダッシュボード」画面に遷移してそのまま「ドメインを登録」画面に遷移します。
-
ドメインが使用可能かを確認します。
今回は「gitlab-sm-test.click」のドメインを取得します。検索欄にドメインを入力して「検索」をクリックします。
使用可能なら「選択」をクリックして、「チェックアウトに進む」をクリックします。
-
料金を確認して連絡先情報を入力します。
「料金」画面に遷移するので、確認できたら「次へ」をクリックします。
※今回作るドメインは説明用ですぐ消すものなので、自動更新はなしにしています。
連絡先情報を入力する画面に遷移するので必要情報を入力して「次へ」をクリックします。
契約内容を確認して「送信」ボタンをクリックします。
ドメイン登録のリクエストが進行している旨のメッセージが表示されたらひとまず登録は完了です。
-
ドメインが利用可能できるまで待つ
ドメインは登録が完了しても、アクセス可能状態になるまで時間がかかります。
ネットで調べてみるとよく「最大で24~72時間」など目にしますが、私は場合10分で利用可能状態になりました。
Route53の「リクエスト」画面から現在のステータスを確認して「成功」になるまで待ちます。
-
ホストゾーン画面でDNSサーバーを編集します。
アクセス可能状態になったら、次に「ホストゾーン」画面でDNSサーバーにDNSレコードを追加します。DNSレコードとは、ドメイン名とIPアドレスの関連づけるために定義するレコードです。
Route53は、登録する新しいドメインごとにホストゾーンを自動的に作成します。ホストゾーン画面で既に「gitlab-sm-test.click」のホストゾーンが作られているはずなので確認して選択します。
「レコード作成」ボタンを押して、
「レコードを作成」画面で必要情報を入力します。
レコード名 → 空白
レコードタイプ → A
値 → あらかじめ取得してあるIPアドレス(今回なら52.68.157.238)
他はデフォルトのままでも問題ありません。入力したら「レコードを作成」ボタンを押します。
レコードが作成された旨のメッセージが表示されたらRoute53内での設定はひとまず完了です。
- ブラウザからドメイン名でサイトにアクセスする。
ドメイン名とIPアドレスの紐づけができているかブラウザからから確認します。
アクセス出来ました!これでドメイン取得・設定は成功です!
SSL証明書を取得してhttps接続でGitLabにアクセスする
次に、Let's Encryptと言う無料のSSL認証局が発行するSSL証明書を取得してhttps化を行っていきます。
公式ドキュメントに、簡単にSSL証明書を取得できる方法が記載されていたため今回はその方法を利用します。
- GitLabの設定ファイルにSSL証明書取得に必要な情報を記載する。
/etc/gitlab/gitlab.rb
を編集してSSL証明書取得に必要な情報を記載していきます。
編集個所は2か所です。
-
external_url
あらかじめexternal_url 'http://gitlab.example.com'
の記載があるのでコメントアウトして、external_url "https://gitlab-sm-test.click"
を追記します。
-
letsencrypt['contact_emails']
証明書は90日ごとに期限切れになります。有効期限が近づいたときにアラートをメールで受信するようにメールアドレスを指定します。
letsencrypt['contact_emails']
のコメントアウトを外して、アラート受信用のメールアドレスを追記します。(ファイルのかなり下のほうにあります。)
- GitLabを再構成してLet's Encryptを有効にする。
下記コマンドでGitLabの再構成が行われると、自動的にLet's Encryptが有効になります。
sudo gitlab-ctl reconfigure
- 念のため証明書を確認する。
再構成が終わってLet's Encryptが有効になるとSSL証明書類が/etc/gitlab/ssl
に配置されます。念のため確認しておきましょう。
SSL証明書の取得成功です!
- sttpsで接続でサイトにアクセスする。
最後に、ブラウザからsttps接続が有効になっていることを確認します。
成功です!
AmazonSESを使ってメール設定を行いメールの送受信を行う。
最後に、AmazonSESを使ってメール設定を行って行きます。
では早速AmazonSESの画面で設定していきましょう。、、、とその前に、一つやっておく事があります。rootユーザーのメールアドレスを変更しておくことです。
Gitlabでは、ユーザーの登録申請をした時の認証のメールはrootユーザーに送信されるようになっていますが、インストール直後のrootユーザーのメアドはadmin@example.com
があらかじめ設定されています。このメアドは実在しないメアドです。今のままだとAmazonSESのメール設定をしてもユーザーの追加ができません。
そこで、ユーザー認証メールを受信するために、rootユーザーのプロフ編集画面からrootユーザーのメアドを存在するメールに変更してあげましょう! が、rootユーザーのアドレス変更時には、変更後アドレスと変更前アドレスの両方にメールが送信されます。今回の検証でAmazonSESは、宛先内に実在しないメアドが一つでも含まれていると全宛先にメールが送信されない ことが確認されました。 変更前アドレスはadmin@example.com
で存在しないアドレスなため、変更後アドレスにも確認用メールが届かずこのままではrootユーザーのアドレス変更もできません。
そこでまず、GmailのSMTPを使います。GmailのSMTPはメール送信時に宛先内に実在しないメアドが一つでも含まれていてもほかの宛先には送信されるので、rootユーザーのアドレス変更時の確認用メールを受信する事ができます。そのメールの確認用リンクをクリックしてrootユーザーのアドレスを変更していきます。
- GmailのSMTP用のパスワードを取得する。
それでは、GmailのSMTPのメール設定を行っていきます。
GitLabのSMTPの利用に必要なものはGmailアドレスとパスワードだけです。ただ、GmailのSMTP用のパスワードには、Gooleアカウントのログインパスワードを利用するのではなくアプリパスワードというものを新たに発行して使用する必要があるのでまずはこのアプリパスワードを取得します。
発行手順は手順を見れば簡単なのでリンクを張っておきます。
最終的に、下記画像のような画面からアプリパスワードが発行されます。
- GitLabの設定ファイルにGmailのSMTPの設定情報を追記する。
アプリパスワードが発行ができたら、公式ドキュメントのメール設定方法を参考に、/etc/gitlab/gitlab.rb
に設定情報を追記していきます。
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "**********@gmail.com" #Gmailアドレス
gitlab_rails['smtp_password'] = "***********" #先ほど入手したアプリパスワード
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'
画像のように追記したら、下記コマンドでGitLabの再構成をしてメール設定を反映させます。
sudo gitlab-ctl reconfigure
gitlab Reconfigured!
が出れば設定完了です。
- GitLab上でrootユーザーのアドレスを変更する。
rootユーザーでGitLabにログインしプロフィール設定画面でメアドを変更していきます。
画像のように「Edit profile」をクリックして設定画面に遷移します。
admin@example.com
から有効なアドレスに変えます。
画面下部にある「Update profile settings」ボタンを押します。ルートパスワードを求められるので入力して変更を確定させます。
プロフィールが更新された旨メッセージが表示されたらいったんは完了です。
変更対象のアドレスに確認メールが届いているか確認してリンクをクリックします。
下記画像のように変更が確認された旨メッセージが表示されたら完了です。
これで、rootユーザーのアドレスが変更されました。ユーザーの登録申請をした時の認証のメールもこれで届くようになりました。続いて、ここからAmazonSES用に設定していきます。
- AmazonSESの画面から「検証済みID」を作成する。
ここからがAmazonSES設定の本番です。
まずは、AmazonSESの画面からGitLab用に「検証済みID」というものを作成していきます。
サービスの検索ボックスに「SES」等と検索して、「Amazon Simple Email Service」を選択します。「検証済みID」画面に遷移して、そのまま右上にある「IDの作成」ボタンを押します。
ID作成に必要な情報を入力していきます。
ID タイプ → ドメイン
ドメイン → 「gitlab-sm-test.click」
ID タイプ → 「Easy DKIM」
DKIM 署名キーの長さ → 「RSA_2048_BIT」
DNS レコードの Route53 への発行 → 「有効化」
DKIM 署名 → 「有効化」
タグは未設定でも問題ありません。入力したら「IDを作成」ボタンを押します。
IDが作成されると、メール設定に必要なDNSレコードがRoute53に自動的に追加されます。
Route53を確認してレコードが追加されていればAmazonSESの設定は完了です。
- AmazonSESのSMTP認証用のユーザー名とパスワードを取得する。
AmazonSESからSMTP認証用のユーザー名とパスワードを取得ししていきます。
AmazonSESの「SMTP 設定」画面内にある「SMTP 認証情報の作成」ボタンを押します。
メール送信に関するIAMユーザーを作成する画面に遷移するので画面下部の「作成」ボタンを押します。
IAMユーザー作成後、認証情報をダウンロードします。
これでSMTP認証に必要な情報は取得できました。
- GitLabの設定ファイルにAmazonSESのSMTPの設定情報を追記する。
アプリパスワードが発行ができたら、公式ドキュメントのメール設定方法を参考に、/etc/gitlab/gitlab.rb
に設定情報を追記していきます。
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "email-smtp.ap-northeast-1.amazonaws.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "**************" #先ほど取得したユーザー名
gitlab_rails['smtp_password'] = "**************************" #先ほど取得したパスワード
gitlab_rails['smtp_domain'] = "gitlab-sm-test.click"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
画像のように追記したら、下記コマンドでGitLabの再構成をしてメール設定を反映させます。
sudo gitlab-ctl reconfigure
gitlab Reconfigured!
が出れば設定完了です。
7. メールを送信する。
これでメール設定が終わりました。最後にユーザー登録してメールが送信されることの確認をします。
メール受信成功!
お疲れ様でした!
これで自分で用意したサーバーでGitLabが運用できるようになりました。
運用中のインスタンスタイプはmediumで問題ないと思いますが、使っていてアクセスできなくなったりしたらlargeに変更してください。また、EC2のボリュームも必要に応じて増やしていってください。
以上になります。最後までご覧いただきありがとうございました。
Discussion