概要

  • インフラエンジニアの基本はIaaS構築から! 本記事は、EC2上に起動したLinux OSの構築でやるべきことをまとめた記事となります。対象はOSのベースのみであり、WebサーバーやDBなどミドルウェアの手順については含みません。
  • 対象のディストリビューションは、Amazon Linux 2 or CentOS 7 です。他のディストリビューションであってもやるべき項目は変わりありません(手順が変わります)。また、一般的なオペレーションはコマンドレベルまで記載していない箇所もあります。ご了承ください。
  • なお、本記事に完成はなく、Linux OSの構築で新しい発見があれば都度更新の予定です。

LinuxのOS初期設定

  • 先ず、Linux が起動した後のOS初期設定を記載します。

初期ユーザーのパスワード変更

  • 初期ユーザーのパスワード変更
    • Amazon Linuxの場合は”ec2-user”、CentOSの場合は”centos”(cloudpack-amiの場合は”cloudpack”ですね)
    • 確認のためサインアウト/サインイン

rootのパスワード変更

  • rootのパスワード変更

パッケージの更新

  • yum update
$ sudo yum update

SELinux

  • SELinuxが無効化であることを確認。(セキュリティポリシーによる)
$ getenforce
Disabled

sudoers設定

  • sudoers設定および確認。
  • cloudpack-amiの場合、/etc/sudoers.d/cloudpack に以下のエントリがあるため、cloudpackユーザーはsudo可能、sudoにパスワード不要となる(通常のCentOSはcentosに読み替え)。
cloudpack        ALL=(ALL)       NOPASSWD: ALL

NTP設定(Amazon Time Sync Service)

  • Amazon Time Sync Service(Server:169.254.169.123)が設定され、同期が取れていることを確認する。
$ systemctl status chronyd
● chronyd.service - NTP client/server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-02-25 10:40:28 JST; 1h 40min ago
     Docs: man:chronyd(8)
           man:chrony.conf(5)
 Main PID: 2967 (chronyd)
   CGroup: /system.slice/chronyd.service
           mq2967 /usr/sbin/chronyd

Feb 25 10:40:27 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal systemd[1]: ...
Feb 25 10:40:27 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal chronyd[2967]: ...
Feb 25 10:40:27 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal chronyd[2967]: ...
Feb 25 10:40:28 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal systemd[1]: ...
Feb 25 10:40:45 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal chronyd[2967]: S...
Feb 25 10:40:45 ip-xx-xx-xx-xx.ap-northeast-1.compute.internal chronyd[2967]: T...
Hint: Some lines were ellipsized, use -l to show in full.
$ chronyc tracking
Reference ID    : A9FEA97B (169.254.169.123)
Stratum         : 4
Ref time (UTC)  : Mon Feb 25 03:21:03 2019
System time     : 0.000034801 seconds fast of NTP time
Last offset     : +0.000031882 seconds
RMS offset      : 0.000065280 seconds
Frequency       : 4.703 ppm fast
Residual freq   : +0.016 ppm
Skew            : 0.196 ppm
Root delay      : 0.003376933 seconds
Root dispersion : 0.000516520 seconds
Update interval : 258.8 seconds

Timezone設定

  • 下記サンプルは、TimezoneをJSTからUTCへ変更。(要件に合わせて変更)
$ date
Mon Feb 25 12:28:24 JST 2019
$ timedatectl status
      Local time: Mon 2019-02-25 12:28:36 JST
  Universal time: Mon 2019-02-25 03:28:36 UTC
        RTC time: Mon 2019-02-25 03:28:35
       Time zone: Asia/Tokyo (JST, +0900)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a
$ sudo timedatectl set-timezone UTC
$ timedatectl status
      Local time: Mon 2019-02-25 03:31:21 UTC
  Universal time: Mon 2019-02-25 03:31:21 UTC
        RTC time: Mon 2019-02-25 03:31:20
       Time zone: UTC (UTC, +0000)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a
$ date
Mon Feb 25 03:31:25 UTC 2019

Language設定

  • 下記サンプルでは、デフォルトがEnglishになっていたため、今回は変更なし。(要件に合わせて変更)
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

swap領域を追加する

  • インスタンスにswap領域が構成されていない場合、追加でswap領域を作成する。下記記事を参考に、swap領域を追加する。
LinuxにSwap領域を追加する方法AWSから提供されているLinux のAMI には、Swapが設定されていません(インスタンスタイプにもよる)。今回は、EC2 上に起動したCentOS 7.6 を使用します。Swap領域は後から容易に追加が可能なファイルの形式で追加したいと思います。現...

拡張側のEBSボリュームにFSを作成

  • インスタンスに拡張側のEBSボリュームが構成されている場合、追加のファイルシステムを作成する必要がある。下記記事を参考に、EBSボリュームにファイルシステムを作成する。
EC2 LinuxでEBSボリュームを追加する今回はEC2のLinux環境でEBSボリュームにxfsファイルシステムを追加作成する方法を紹介します。xfs以外のファイルシステムでも参考になると思います。今回はEC2 上に起動したCentOS 7.6 を使用します。基本のEBSではなく、増設のEB...

cloud-init設定

  • 次は、cloud-initの設定を変更します。cloud-initは、Linux OSを初期設定するためのサービスです。
  • Linux OSの構築後、インスタンスのイメージ(AMI)を取得することは一般的かと思います。AMIは、Auto Scalingによるスケールアウト時や単純に2台目以降を複製するケース、あるいは障害からの復旧や人為的ミスから以前の状態を復元するなどの目的で取得します。
  • 下記のcloud-initの設定変更によって、インスタンスの起動時に本記事で設定した内容がデフォルトに戻らないようにします。
  • 以下、設定変更するパラメータの説明です。他のパラメータは必要に応じて、調査・変更ください。
    • ssh_pwauth → “1”を設定して、インスタンス初回起動時に、デフォルトでパスワード認証を選択する(後述の認証方法をどちらに設定するかによる)。
    • preserve_hostname → “true”を設定して、インスタンス初回起動時にホスト名を初期化しない。
    • repo_upgrade: none → “none”を設定して、インスタンス初回起動時にパッケージを更新しない。
    • locale: en_US.UTF-8 → インスタンス初回起動時に設定するlocaleを選択する(前述の設定値に合わせる)。
    • timezone: UTC → インスタンス初回起動時に設定するtimezoneを選択する(前述の設定値に合わせる)。
$ cd /etc/cloud
$ sudo cp -p cloud.cfg cloud.cfg.bak_20190308
$ sudo vi cloud.cfg

* 以下を変更
ssh_pwauth:   1

* 以下を追記
preserve_hostname: true
repo_upgrade: none
locale: en_US.UTF-8
timezone: UTC

NitroベースのインスタンスにKernelパラメータ変更

  • インスタンスタイプがt3やc5、m5などNitroベースのインスタンスを使用する場合、以下Kernelパラメータを変更する。一部のディストリビューションにおいて、NVMe ドライバーのI/O オペレーションタイムアウト変更が推奨されているため。詳細はこちら
$ cat /sys/module/nvme_core/parameters/io_timeout

$ sudo sed -i 's/^nvme_core.io_timeout=.*//g;s/^nvme_core.max_retries=.*//g' /etc/sysctl.conf
$ sudo sed -i '/^GRUB_CMDLINE_LINUX/s/"$/ nvme_core.io_timeout=255 nvme_core.max_retries=128"/'  /etc/default/grub
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
$ sudo yum -y install nvme-cli

← Kernelパラメータが変更されたことを確認
$ cat /sys/module/nvme_core/parameters/io_timeout

ホスト名変更(*)

  • ホスト名を変更する(但し、AMIを取得してAuto Scalingを行う場合は、Auto Scaling時のホスト名を管理するか検討の必要あり)。
$ hostname
ip-xx-xx-xx-xx.ap-northeast-1.compute.internal
$ sudo hostnamectl set-hostname new-hostname
$ hostname
new-hostname

管理者以外のユーザーを作成

  • 管理者以外のユーザー(例:develop)を作成し、認証のための秘密鍵を準備する。(要件に合わせて変更)
  • 必要に応じて、作成したユーザーに管理者権限を付与する。前述のsudoers設定を参照すること。
  • ユーザー作成後、秘密鍵を使用してログインできることを確認する(パスフレーズを指定した場合は、ログイン時にパスフレーズも入力すること)。
$ sudo groupadd -g 500 develop
$ cat /etc/group
$ sudo useradd -u 500 -g develop -c develop -d /home/develop -s /bin/bash develop
$ cat /etc/passwd
$ id -a develop
$ sudo passwd develop

$ sudo su - develop
$ mkdir .ssh
$ chmod g-w .ssh

$ ls -lad .ssh
drwxr-xr-x 2 develop develop 61 Mar  6 03:50 .ssh

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/develop/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/develop/.ssh/id_rsa.
Your public key has been saved in /home/develop/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:VwBbtcHe2e8aMKZnCP5t92pMtd3WbTdBz9RcNYBQpuB develop@ip-xx-xx-xx-xx.ap-northeast-1.compute.internal
The key's randomart image is:
+---[RSA 2048]----+
|     o.   ...++  |
|    E .  . +.=o+ |
| . o +  . o.=.+..|
|. . . =.  .o .=. |
|.  o O +S.  .  =.|
|..  = X .   + . o|
|o.   + o   . + . |
|..  o         .  |
|  ..             |
+----[SHA256]-----+

$ cat id_rsa.pub >> ~/.ssh/authorized_keys
$ chmod 600 authorized_keys
$ ls -la
total 12
drwxr-xr-x 2 develop develop   61 Mar  6 03:50 .
drwx------ 3 develop develop   95 Mar  6 03:40 ..
-rw------- 1 develop develop  435 Mar  6 03:50 authorized_keys
-rw------- 1 develop develop 1766 Mar  6 03:48 id_rsa
-rw-r--r-- 1 develop develop  435 Mar  6 03:48 id_rsa.pub

Linuxのユーティリティをインストール

  • wgetやjqなど使用頻度の高いユーティリティをインストールする。
$ sudo yum install wget

EC2 管理ツールのインストール/セットアップ

  • 次に、EC2 の管理に必要なツール類をインストールする。

AWS CLI のインストール

  • AWS CLI をインストールする。AMIによっては、デフォルトでインストール済み。
  • 下記サンプルでは、インストール済みであることを確認している。
$ which aws
/bin/aws
$ aws --version
aws-cli/1.16.69 Python/2.7.5 Linux/3.10.0-957.1.3.el7.x86_64 botocore/1.12.59
  • 初期ユーザーおよび追加にて作成したユーザーのそれぞれにおいて、AWS CLI のセットアップを実施する。
$ aws configure

SSM Agentのインストール

  • SSM Agent をインストールする。AMIによっては、デフォルトでインストール済み。
  • 下記サンプルでは、インストール済みであることを確認している。
# systemctl status amazon-ssm-agent
● amazon-ssm-agent.service - amazon-ssm-agent
   Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-02-25 01:40:42 UTC; 1h 57min ago
 Main PID: 3615 (amazon-ssm-agen)
   CGroup: /system.slice/amazon-ssm-agent.service
           mq3615 /usr/bin/amazon-ssm-agent

Feb 25 03:10:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:11:05 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:15:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:20:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:20:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:25:46 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:25:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:30:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:30:59 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Feb 25 03:35:57 ip--xx-xx-xx.ap-northeast-1.compute.internal amazon-ssm-agent[3615]: ...
Hint: Some lines were ellipsized, use -l to show in full.

CloudWatch Agent のインストール

  • SSM(Systems Manager)のRun Commandを使用して、CloudWatch Agent をインストールする
  • AWS-ConfigureAWSPackage
    • Action: Install
    • Name: AmazonCloudWatchAgent
  • 事前に、EC2のロールにAmazonSSMFullAccessがアタッチされていることを確認する。
  • CloudWatch Agentがインストールされたことを確認する。また、サービスの自動起動を有効にして、サービスを開始する。
$ yum list installed | grep cloudwatch
amazon-cloudwatch-agent.x86_64          1.208036.0-1                   installed
$ systemctl status amazon-cloudwatch-agent
● amazon-cloudwatch-agent.service - Amazon CloudWatch Agent
   Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
$ sudo systemctl enable amazon-cloudwatch-agent
Created symlink from /etc/systemd/system/multi-user.target.wants/amazon-cloudwatch-agent.service to /etc/systemd/system/amazon-cloudwatch-agent.service.
$ sudo systemctl start amazon-cloudwatch-agent
$ systemctl status amazon-cloudwatch-agent
● amazon-cloudwatch-agent.service - Amazon CloudWatch Agent
   Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-02-25 11:18:39 UTC; 2s ago
 Main PID: 10548 (start-amazon-cl)
   CGroup: /system.slice/amazon-cloudwatch-agent.service
           tq10548 /opt/aws/amazon-cloudwatch-agent/bin/start-amazon-cloudwat...
           mq10562 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-age...

Feb 25 11:18:39 ip--xx-xx-xx.ap-northeast-1.compute.internal systemd[1]: Star...
Hint: Some lines were ellipsized, use -l to show in full.

CloudWatch Agent のセットアップ(*)

  • 以下記事を参考に、CloudWatch Agent をセットアップする。
はじめに目的EC2インスタンス上のLinuxサーバーが個々に持つログを収集して、CloudWatch Logsに集約すること。CloudWatchを使って、各EC2インスタンスのカスタムメトリクスを監視すること。前提条件Linuxに、amazon-ssm-agentがインストールされていること。EC2イン...

OSのネットワーク/セキュリティ関連の設定

鍵認証からパスワード認証に変更(セキュリティポリシーによる)

  • プライベートのサブネットに配置したEC2は、鍵認証からパスワード認証に認証方法を変更する場合もある。
  • 認証方法を変更後、パスワードを使用してログインできることを確認する(パスワード認証に変更後、初期ユーザーでのログイン不可を回避するため、必ず初期ユーザーのパスワードを変更後に実施すること)。
$ cd /etc/ssh
$ sudo cp -p  sshd_config sshd_config.org
$ ls -l sshd_config*
-rw------- 1 root root 3905 Mar  7 09:50 sshd_config
-rw------- 1 root root 3905 Mar  7 09:50 sshd_config.org

$ sudo vi sshd_config

※下記に変更↓
PasswordAuthentication yes
PubkeyAuthentication no

$ systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-03-07 09:50:18 UTC; 25min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 7947 (sshd)
   CGroup: /system.slice/sshd.service
           mq7947 /usr/sbin/sshd -D
$ sudo systemctl restart sshd

sshの暗号方式からcbcモードを無効化(セキュリティポリシーによる)

  • EC2がPublic Subnetに配置されている場合、念のためsshの暗号化方式を強化。
Linuxセキュリティ強化: sshの暗号方式からcbcモードを無効化する前提条件Linux のセキュリティ強化の設定を紹介します。今回は、SSHで使われる暗号方式について、CBCモード(Cipher Block Chaining)を無効化し、CTRモード(CounTR )など別のモードを使うように変...

ADに登録(*)

  • システムでADサービスを利用する場合は、Linux をADに登録する。
  • 以下記事を参考に、ADに登録する。
Linux OSのAD登録方法前提条件AWSでは手軽にADサービスを利用することができます。本投稿では、マネージド型の Microsoft Active DirectoryにLinux OSを登録する手順を記載します。OSのバージョンは、Cent OS 7 となります。Microsoft ADサービスを立ち上げる方法は...

ミドルウェアのインストール(*)

ミドルウェアのインストール

  • システムの要件に応じて、各種ミドルウェアやツールをインストールする。

AMI を使った横展開

  • 構築後にAMIを取得し、新たなサーバーに横展開 or Auto Scalingによる スケールアウトを実施する。なお、横展開後にサーバーごとに変更が必要と思われる箇所を(*)にて、マークする。参考にして頂きたい。

元記事はこちら

EC2のLinux構築でやるべきこと