前の記事で書いたように Redmine の移行ができたので、あとはサーバーとしてあれこれ設定しておきます。
主に、過去に行った作業の繰り返しですが、メモなので大目に見てください。
雑多な設定
- SSH ポートの変更
- システムアップデート
- ロケール変更
- タイムゾーン変更
- 日本語環境の設定
- NTPサーバー変更
を行っています。過去の
blog.mori-soft.com
を参考にして設定しました。
ただ、NTPについては、この設定だけでは再起動時に再設定するのみだったと気づいたので、cronで定期的に更新するようにしました。
/etc/cron.d/ntpdate を下記のように作成しました。
5 */4 * * * root /usr/sbin/ntpdate-debian -s 2> /dev/null
（参考）
Ubuntuサーバの管理 | Think IT（シンクイット）
ntpdateで時刻を自動的に合わせる - 試験運用中なLinux備忘録・旧記事
SSL 自己証明証明書のインストール
過去に作った証明書を割り当てておきます（独自ドメインのサブドメインでアクセスするため）。作ったときの記事はこちらになります。
以前作ったオレオレ証明書をそのまま流用するなら、適切な場所にコピーすればいいだけです。場所の情報などは下記を参照してください。
Bitnami Redmine Stack for AWS Cloud
/opt/bitnami/apache2/conf ディレクトリにコピーします。
コピーするファイルは２つ。
/opt/bitnami/apache2/conf/server.crt
/opt/bitnami/apache2/conf/server.key
というふうにファイルをコピーして、所有者とパーミッションを修正しておきます。
bitnami@ip-172-30-0-93:/opt/bitnami/apache2/conf$ sudo chown root:root server.crt
bitnami@ip-172-30-0-93:/opt/bitnami/apache2/conf$ sudo chown root:root server.key
bitnami@ip-172-30-0-93:/opt/bitnami/apache2/conf$ sudo chmod 600 server.crt
bitnami@ip-172-30-0-93:/opt/bitnami/apache2/conf$ sudo chmod 600 server.key
とすれば終わりです。
なお、ファイル名が異なる場合は、 /opt/bitnami/apache2/conf/bitnami/bitnami.conf 中のファイル名を変更する必要があります。
Elastic IP の割り当て
既存のサーバーに割り当てているElastic IP を新サーバーに割り当てます。
既存サーバーは、結構昔（2012年ごろ）に立ち上げたため、EC2 Classic のインスタンスでした。このため、新サーバーへ割り当てなおすにあたり、Elastic IP を VPC に移行するという操作が必要になりました。
docs.aws.amazon.com
移行後は、このElastic IP を新サーバーへ割り当てれば終わりです。
なお、VPCの場合は、インスタンスを停止してもElastic IP の関連付けが解除されることはないので、過去にやったように、起動時にElastic IP を自動で割り当てるなどの処理は不要になりました。
一応、一度インスタンスを停止して、再開後、独自ドメイン名でアクセスできることを確認しておきます。
Security Group の自動変更
以前、Security Group の自動更新を設定した際は、EC2 CLI ツールをインストールしていました。
でも、最近は、AWS CLI ツールを使うのがおすすめの様です。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/CommandLineReference/Welcome.htmldocs.aws.amazon.com
せっかくなので、ここでは、AWS CLI ツールをインストールして、これを使って操作します。ちなみに、 AWS CLI ツールはpython製のようです（EC2 CLI ツールはJava製）。
インストール手順はamazonのドキュメントにも載っていますが、これだと、作業ユーザーのホームディレクトリ以下にインストールされるので別の方法をとります。
ネットを調べてみると、CentOSでAWS CLI をインストールする方法がありました。
http://kumonchu.com/aws/aws-cli-centos/
標準のパッケージマネージャを使って、pipをインストールして、それから、awscliをインストールしています。Ubuntuでも同様にできると思います。
探してみます。
bitnami@ip-172-30-0-73:~$ apt-cache search python-pip
python-pip - alternative Python package installer
python-pipeline - iterator pipelines for Python
python-pip-whl - alternative Python package installer
bitnami@ip-172-30-0-73:~$
ありますね。インストールします。
bitnami@ip-172-30-0-73:~$ sudo apt-get update
bitnami@ip-172-30-0-73:~$
bitnami@ip-172-30-0-73:~$ sudo apt-get install python-pip
AWS CLI も探します
bitnami@ip-172-30-0-73:~$ pip search awscli
awscli-plugin-endpoint - Endpoint plugin for AWS CLI
aws-s3-url2uri - Make awscli s3 commands work with URL
awscli-cwlogs - AWSCLI CloudWatch Logs plugin
awsclpy - Chain AWSCLI commands in Python.
awscli-keyring - AWS command line credentials from OS X Keychain and other keyrings.
awscli - Universal Command Line Environment for AWS.
bitnami@ip-172-30-0-73:~$
見つかりました。インストールします。
bitnami@ip-172-30-0-73:~$ sudo pip install awscli
確認します。
bitnami@ip-172-30-0-73:~$ which aws
/usr/local/bin/aws
bitnami@ip-172-30-0-73:~$
bitnami@ip-172-30-0-73:~$ aws --version
aws-cli/1.11.71 Python/2.7.6 Linux/3.13.0-115-generic botocore/1.5.34
bitnami@ip-172-30-0-73:~$
問題なさそうですね。とりあえず簡易設定を行います。
bitnami@ip-172-30-0-73:~$ aws configure
AWS Access Key ID [None]: AWS IAM のアクセスキー
AWS Secret Access Key [None]: AWS IAM のシークレットキー
Default region name [None]: ap-northeast-1
Default output format [None]:
bitnami@ip-172-30-0-73:~$
IAM はEC2操作用に作成したユーザーを使っています。
一応、内容を確認しておきます。
bitnami@ip-172-30-0-73:~/.aws$ cat config
[default]
region = ap-northeast-1
bitnami@ip-172-30-0-73:~/.aws$ cat credentials
[default]
aws_access_key_id = AWS IAM のアクセスキー
aws_secret_access_key = AWS IAM のシークレットキー
bitnami@ip-172-30-0-73:~/.aws$
適当なコマンドを実行してみて問題なく動作することも確認できました。
肝心な、Security Group の自動変更のやり方ですが、基本的には以前と同じです。ただ、スクリプトで使うAPIをAWS CLI 用に修正しました。
サーバー間のバックアップ
さくらインターネットで公開しているHPのデータを、Redmineのサーバーへバックアップしていました。
なので、新サーバーにも同様にバックアップを行います。
といっても、新しくやったことはなくて、こちらの記事の設定を確認して、バックアップが動作することをチェックしただけです。
S3へのバックアップ
また、定期的に HP の内容をS3へもバックアップしています。
いままでは、こちらの記事と同様に、s3cmd を使っていたのですが、この機にawscliを使う形に変更しました。
処理する内容は基本的に同じで、サーバー間のバックアップで取ったファイルをtarでまとめたものを、月に一度S3に保存するというものです。
なお、IAMユーザーは、EC2用とS3用で分けています。
自動スナップショットとローテーション
自動スナップショットとローテーションも過去記事を参考に再設定します。
やってることは同じですが、 AWS CLI を使うように変更します。
なお、実行スクリプトでは、 API の結果を処理して、既存のスナップショットの数やIDを調べているのですが、 AWS CLI の場合は、JMESPATH というのを使って処理ができるそうです。
aws — AWS CLI 1.18.197 Command Reference
使い方は下記などを参照してください。
http://dev.classmethod.jp/cloud/aws/aws-cli-filter-and-query-howto/
AWS CLI の query による絞り込み - Qiita
JMESPathでソートや部分一致も | AWSコスト削減・IaaSインフラ構築のシンプライン株式会社
セキュリティアップデートの自動実行
過去記事と同様に、Ubuntu 14.04 でもセキュリティアップデートの自動実行を行います。
既に、 unattended-upgrades パッケージがインストール済みだったので、自動実行の設定だけ行います。
sudo dpkg-reconfigure -plow unattended-upgrades
なお、セキュリティアップデートの設定を下記のように行いました。
/etc/apt/apt.conf.d/50unattended-upgrads ファイルへ下記を追記
Unattended-Upgrade::Mail "xxxxx@mori-soft.com";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
/etc/apt/apt.conf.d/20auto-upgrades ファイルへ下記を追記
APT::Periodic::AutocleanInterval "6";
また、サーバーにメール送信環境がなかったため、メール送信設定を s3fsが予期せずアンマウントされた場合への対策 - プログラマーのメモ書き に参考を行いました(sSMTP と mailutils を使った送信）。
（参考）
qiita.com
Cloud watch
以前、ディスクの空き容量が不足してひどい目にあったので、CloudWatch を設定して監視します。やり方は過去記事と同じです。
Amazon CloudWatch Monitoring Scripts for Linux の説明ページが切れていたので、下記に再掲しておきます。
docs.aws.amazon.com
スクリプトのダウンロード元
AWS Code
redmine のバックアップ
せっかく新しいサーバーに移行したので、redmine の添付ファイルとdbの内容をバックアップするようにします。
やり方は、redmine のデータのバックアップを cron で毎日定期的に行うようにするだけです。また、それを月に一度、S3に保管します。
既存サーバーの停止
ここまで行えば、あとは既存サーバーを停止するだけです。当面は、既存サーバーを停止したままインスタンスは残しておき、何かあれば、再度起動できるようにします。
ただ、新サーバーにて運用を開始しているので、既存サーバーの Elastic IP の自動割り当てだけ解除しておきます。
終わりに
いろいろと設定していたら、予想以上に時間がかかってしまいましたが、一応これで新サーバーにて運用できそうです。
にしても、 t2.nano は思ったより快適ですね。今回の目的であれば、十分使えそうです。
更新履歴
2017/4/14 セキュリティアップデートの自動実行の記述で、autoremove/autoclean/メール送信環境の設定 を追記しました
