新しく EC2 インスタンスを立ち上げたときにやる初期設定

本記事のゴール

本記事では、新しく Amazon EC2 (EC2) インスタンスを立ち上げた際にやる初期設定について解説します。

前提条件

本記事では、「新しく EC2 インスタンスを立ち上げた」状態というのは、EC2 のコンソールに進み、「インスタンスを起動」というボタンを押して立ち上げたもののことを指し、AMI からの復元等は含みません。

また、今回は、OS は Amazon Linux 2 であることを前提にお話しします。
EC2 インスタンス起動時の AMI の選択

既にキーペアを取得して立ち上げた EC2 インスタンスには ec2-user で SSH 接続できる状態になっていると仮定します。

SSH 接続用のユーザの設定

デフォルトユーザの ec2-user のまま運用してもいいのですが、念のため SSH 接続用のユーザを別途用意することとし、ec2-user は今後は使わないこととします。

作業のため、まずはスーパーユーザになります。

$ sudo su -

ユーザーを作成、パスワードを設定します。

# adduser ${ユーザ名}
# passwd ${ユーザ名}

さらに、作成したユーザーを sudo 実行可能にします。こちらの記事にあるとおり、Amazon Linux も Red Hat 系の Linux なのですが、Red Hat 系の場合 sudo 実行可能にするためにはユーザーをグループ wheel に追加すれば良いです。

# usermod -aG wheel ${ユーザ名}

次に、作成したユーザーで SSH 接続可能にします。まずはホームディレクトリ配下に .ssh ディレクトリを作成していきます。

# mkdir /home/${ユーザ名}/.ssh
# chmod 700 /home/${ユーザ名}/.ssh

chmod コマンドでディレクトリへのユーザーのアクセス権を設定するのですが、SSH 接続においてはこのアクセス権の設定がキモになってきます。

次に、SSH 接続の際の鍵を管理するためのファイル authorized_keys を作成していきます。

# touch /home/${ユーザ名}/.ssh/authorized_keys

SSH 接続する手元の PC で、キーペアを作成します。キーペアの作成方法については、Tera Term の場合はこちらの記事を、PuTTY の場合はこちらの記事を参考にしてください。リンクを貼ったどちらの記事も暗号化方式は「SSH-2 RSA」を取っていますが、セキュリティ面では「SSH-2 RSA」方式で鍵を作成していただくのがオススメです。

今、「id_rsa.pub」という公開鍵ができたとします。この公開鍵の内容を、先程の authorized_keys に登録します。

# cat ${id_rsa.pub の置いたディレクトリ}/id_rsa.pub >> /home/${ユーザ名}/.ssh/authorized_keys
# chmod 600 /home/${ユーザ名}/.ssh/authorized_keys

最後に、スーパーユーザーで作業してきましたので作成したディレクトリの所有権を作成したユーザーに変更しておきます。

# chown -R ${ユーザ名}:${ユーザ名} /home/${ユーザ名}/.ssh

ここまでで、いったん ec2-user からはログアウトして、作成したユーザーで改めて SSH 接続してみます。ユーザー名、使用する秘密鍵の設定の変更の上、再度接続します。

まずは SSH 接続できたら第 1 段階は OK、さらに、スーパーユーザーになれるか確認します。

$ sudo su -

ここでスーパーユーザーになれれば OK です。今後はもう ec2-user は使用しませんので、まずは ssh の設定ファイルを書き換えて、ec2-user で SSH 接続できなくしてしまいます。

# vi /etc/ssh/sshd_config
...
DenyUsers ec2-user

ssh の設定ファイルを書き換えたら、ssh を再起動しておきます。

# systemctl restart sshd

まだ、ec2-user は削除されていません。ec2-user はデフォルトではパスワードなしで sudo 実行可能なユーザに指定されているので、

# visudo -f /etc/sudoers.d/90-cloud-init-users
# Created by cloud-init v. 19.3-43.amzn2 on Mon, 03 May 2021 05:52:29 +0000

# User rules for ec2-user
#ec2-user ALL=(ALL) NOPASSWD:ALL

ec2-user に関する sudo の設定を変更しておきます。

タイムゾーンを JST に変更

EC2 インスタンスを立ち上げたばかりですと、タイムゾーンが UTC となっており、日本時間になっておりません。

# date
Mon May 10 09:33:25 UTC 2021

これを日本時間に変えるための手順は 2 つで、まずは /etc/localtime に日本を指定します。

# cp -p /usr/share/zoneinfo/Japan /etc/localtime

その上で、/etc/sysconfig/clock を以下のように書き換えます。

# vi /etc/sysconfig/clock
ZONE="Asia/Tokyo"
UTC=False

これで、EC2 インスタンスの時間を日本時間に変更できました。

# date
Mon May 10 18:36:22 JST 2021

パッケージの更新

インストール済みのパッケージを最新化しておきます。

# yum update -y

日本語環境への変更

日本語環境への変更は、システムファイル /etc/sysconfig/i18n を書き換えるだけです。

# vi /etc/sysconfig/i18n
LANG="ja_JP.UTF-8"

不要なサービスの停止

Amazon Linux にも、他の OS と同様デフォルトでいくつかのサービスプロセスが走っており、これらのサービスについて全て利用する人はほとんどいないと思います。このような利用しない、不要なサービスについては、CPU やメモリの計算リソースだけでなく、ログファイルを吐き出したりしてディスクを消費する要因にもなりますので、この段階で止めておきます。

サービスの管理については、以下のコマンドで実施できます。

# ntsysv
ntsysv での表示例

以下がサービス一覧です。画面上、「*」で有効になっているものには○、無効のものには✕をつけています。○から✕に変更するものについては赤字にしているので、変更してみてください。

#サービス名記述デフォルト変更後
networkネットワーク接続するためのもの。
2amazon-ssm-agent.serviceAWS Systems Manager (SSM) のエージェント。SSM にリソース更新、管理、設定させる。
3amzn2-early-relabel-modules.service詳細は不明。
4arp-ethers.servicearp コマンドを使用するためのもの。arp コマンドは非推奨ということで、OFF のままに。
5atd.serviceat (指定した時刻に指定したコマンドを実行する) ツール。
6auditd.service操作ログの収集・監査をするためのデーモン。
7blk-availability.serviceLVM のミラーデバイスを管理するサービス。LVM 使用でもミラーリングしていないのであれば特に不要
8chrony-wait.serviceシステムクロックを同期するために chrony を待つようだが、詳細は不明。
9chronyd.service時刻同期サービス。
10cloud-config.servicecloud-init を構成するツール。
11cloud-final.service同上
12cloud-init-local.service同上
13cloud-init.service同上
14console-getty.serviceターミナル関連の何かと思われるが、詳細は不明。
15console-shell.service同上
16crond.service定期タスク実行ツール cron。
17debug-shell.serviceデバッグ、リカバリ用の機能。
18dm-event.socketデバイスのマッピングを行っているサービス。
19dmraid-activation.serviceベンダー固有のドライバをインストールせずに、RAID デバイスをサポートするもの。
20ec2-instance-connect.serviceEC2 Instance Connect を使うためのもの。
21ec2net-scan.service詳細は不明。
22gssproxy.serviceGss-proxy を使うためのもの。
23hibagent.serviceハイバネーション (メモリの中身をディスクに一時退避して停止、起動を行う) を行うためのもの。
24irqbalance.service割り込み要求 (IRQ) を複数CPUで分散する。マルチプロセッサになると必要になる。
25kpatch.service新しいカーネルを再起動せずに、実行中のカーネルに必要なパッチを当てる。
26libstoragemgmt.service外部ストレージアレイ管理プラグイン。
27lvm2-lvmetad.socketLVM 利用のためのもの。
28lvm2-lvmpolld.socket同上
29lvm2-monitor.service同上
30mdmonitor.serviceソフトウェア RAID モニタ機能。
31mysqld.serviceMySQL サーバー。
32nfs-blkmap.serviceNFS を使うためのもの。
33nfs-rquotad.service同上
34nfs-server.service同上
35nfs.service同上
36nginx.serviceNginx。
37php-fpm.servicephp-fpm。
38plymouth-halt.servicePlymouth はグラフィカル起動サービス。
39plymouth-kexec.service同上
40plymouth-poweroff.service同上
41plymouth-quit-wait.service同上
42plymouth-quit.service同上
43plymouth-read-write.service同上
44plymouth-reboot.service同上
45plymouth-start.service同上
46postfix.serviceメールサーバーとしてサーバーを使う場合に必要になる。
47psacct.serviceプロセスアクティビティを監視するためのユーティリティ。
48rdisc.serviceルーターとして動作させる時に経路管理を行うためのもの。
49rhel-autorelabel-mark.service基幹系のサービス。
50rhel-autorelabel.service同上
51rhel-configure.service同上
52rhel-dmesg.service同上
53rhel-domainname.service同上
54rhel-import-state.service同上
55rhel-loadmodules.service同上
56rhel-readonly.service同上
57rngd-wake-threshold.serviceハードウェア乱数関連のサービス。詳細は不明。
58rngd.serviceハードウェア乱数のサービス。
59rpc-rquotad.serviceNFS によりリモートマシンにマウントされている、 ローカルファイルシステムのユーザー quota 値を返す RPC サーバー。
60rpcbind.serviceRPC ベースのサービスで接続を確立するもの。
61rpcbind.socket同上
62rsyncd.serviceサーバー間のファイル同期に使われる。複数台サーバーを考えていないので、いったん無効のままに。
63rsyncd.socket同上
64rsyslog.serviceシステムログに使用。
65sshd.serviceSSH サービス。
66sshd.socketSSH のポートを開けるためのもの。Amazon Linux では sshd でポートを開けているようなので、こちらは不要。
67sysstat.serviceサーバーのリソース監視のためのツール。
68systemd-bootchart.serviceLinux の起動をグラフで記録する bootchart のためのもの。
69systemd-readahead-collect.service起動時のディスク使用パターン収集サービス。
70systemd-readahead-drop.service同上
71systemd-readahead-replay.service同上
72tcsd.serviceTPM (セキュリティチップ) 開発ツールのためのもの。
73update-motd.servicemessage of the day (motd)とは、Linux サーバーにログインした時に表示されるバナーのことで、これを日次で更新している。

ネクストアクション

EC2 インスタンスを立ち上げたときの初期設定について解説しました。次回は、WordPress サイトの高速化について取り組んでみたいと思います。

タイトルとURLをコピーしました