翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon EC2 の AL2 Amazon EC2 **注記** AL2 は Amazon Linux の最新バージョンではなくなりました。AL2023 は AL2 の後継です。詳細については、[AL2023 ユーザーガイドの「AL2 と AL2](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html)023 の比較」および[「AL2023 でのパッケージの変更](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html)のリスト」を参照してください。 [AL2023 ](https://docs.aws.amazon.com/linux/al2023/ug/) **Topics** + [AL2 AMI を使用して Amazon EC2 インスタンスを起動する AL2](#launch-ec2-instance) + [Systems Manager を使用して最新の AL2 AMI を検索する](#find-latest-al2-using-systems-manager) + [Amazon EC2 インスタンスに接続する](#connect-to-amazon-linux-limits-ec2) + [AL2 AMI ブートモード](#default-boot-mode-al2) + [パッケージリポジトリ](#package-repository) + [AL2 での cloud-init の使用](amazon-linux-cloud-init.md) + [AL2 インスタンスを設定する](configure-ec2-instance.md) + [ユーザー提供カーネル](UserProvidedKernels.md) + [AL2 AMI リリース通知](linux-ami-notifications.md) + [AL2 MATE デスクトップ接続を設定する](amazon-linux-ami-mate.md) + [AL2 チュートリアル](al2-tutorials.md) ## AL2 AMI を使用して Amazon EC2 インスタンスを起動する AL2 AL2 AMI を使用して Amazon EC2 インスタンスを起動できます。 AL2 詳細については、[「ステップ 1: インスタンスを起動する](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-launch-instance)」を参照してください。 ## Systems Manager を使用して最新の AL2 AMI を検索する Amazon EC2 は、インスタンスの起動時に使用できる、 AWS が管理する AWS Systems Manager パブリック AMIs のパブリックパラメータを提供します。たとえば、EC2-provided パラメータ`/aws/service/ami-amazon-linux-latest/amzn2-ami-kernel-default-hvm-x86_64-gp2`はすべてのリージョンで使用でき、常に特定のリージョンの AL2 AMI の最新バージョンを指します。 を使用して最新の AL2023 AMI を検索するには AWS Systems Manager、「AL2023 の開始方法」を参照してください。 [ AL2023](https://docs.aws.amazon.com/linux/al2023/ug/get-started.html) Amazon EC2 AMI のパブリックパラメータは、次のパスから使用できます。 `/aws/service/ami-amazon-linux-latest` 次の AWS CLI コマンドを実行すると、現在の AWS リージョン内のすべての Amazon Linux AMIs のリストを表示できます。 ``` aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest --query "Parameters[].Name" ``` **パブリックパラメータを使用してインスタンスを作成するには** 次の例では、EC2-providedパブリックパラメータを使用して、最新の AL2 AMI を使用して`m5.xlarge`インスタンスを起動します。 このパラメータをコマンドで指定するには、`resolve:ssm:public-parameter` 構文を使用します。`resolve:ssm` は標準のプレフィクス、`public-parameter` はパブリックパラメータのパスと名前です。 この例では、`--count` パラメータと `--security-group` パラメータは含まれていません。`--count` はデフォルトで 1 になります。デフォルトの VPC とデフォルトのセキュリティグループがある場合は、これらが使用されます。 ``` aws ec2 run-instances --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-kernel-default-hvm-x86_64-gp2 --instance-type m5.xlarge --key-name MyKeyPair ``` 詳細については、[「 ユーザーガイド」の「パブリックパラメータ](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-public-parameters.html)の使用」を参照してください。 *AWS Systems Manager * **Amazon Linux 2 AMI 名について** Amazon Linux 2 AMI 名は、次の命名スキームを使用します。 `amzn2-ami-[minimal-][kernel-{5.10,default,4.14}]-hvm-{x86_64,aarch64}-{ebs,gp2}` + **最小** AMIs、イメージサイズを減らすために、プリインストールされたパッケージのセットが最小限に抑えられています。 + **kernel-VERSION** は、それぞれの AMI にプリインストールされているカーネルバージョンを決定します。 + `kernel-5.10` は Linux カーネルバージョン 5.10 を選択します。*これは AL2 に推奨されるカーネルバージョンです。* + `kernel-default` は、AL2 に推奨されるデフォルトカーネルを選択します。これは kernel-5.10 のエイリアスです。 + `kernel-4.14` は Linux カーネルバージョン 4.14 を選択します。*これは、古い AMI リリースとの互換性のためにのみ提供されます。新しいインスタンスの起動には、このバージョンを使用しないでください。この AMI がサポートされなくなることが予想されます。* + AMI 名の特別なセットは、特定のカーネルを参照せずに存在します。これらの AMIs は kernel-4.14 のエイリアスです。*これらの AMIsは、古い AMI リリースとの互換性のためにのみ提供されています。この AMI 名を新しいインスタンスの起動に使用しないでください。これらの AMIsることを期待します。* + **x86\$164/aarch64** は、AMI を実行する CPU プラットフォームを決定します。Intel および AMD ベースの EC2 インスタンスには x86\$164 を選択します。EC2 Graviton インスタンスの aarch64 を選択します。 + **ebs/gp2** は、それぞれの AMI を供給するために使用される EBS ボリュームタイプを決定します。リファレンスについては、[「EBS ボリュームタイプ](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)」を参照してください。*常に gp2 を選択します。* ## Amazon EC2 インスタンスに接続する Amazon Linux インスタンスに接続するには、SSH、EC2 Instance Connect など AWS Systems Manager Session Manager、いくつかの方法があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Linux インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)」を参照してください。 **SSH ユーザーと **sudo**** Amazon Linux では、デフォルトでリモート`root`セキュアシェル (SSH) は許可されません。また、ブルートフォース攻撃を防ぐためにパスワード認証は無効になっています。Amazon Linux インスタンスへの SSH ログインを有効にするには、起動時にキーペアをインスタンスに提供する必要があります。インスタンスを起動するときに使用するセキュリティグループで、SSH アクセスを許可するよう設定する必要もあります。デフォルトでは、SSH を使用してリモートでログインできるアカウントは のみです`ec2-user`。このアカウントには **sudo**権限もあります。リモート`root`ログインを有効にする場合は、キーペアとセカンダリユーザーに依存するよりも安全性が低いことに注意してください。 ## AL2 AMI ブートモード AL2 AMIs にはブートモードパラメータが設定されていません。AL2 AMIs から起動されたインスタンスは、インスタンスタイプのデフォルトのブートモード値に従います。詳細については、*Amazon EC2 ユーザーガイド*」の[「ブートモード](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html)」を参照してください。 ## パッケージリポジトリ この情報は AL2 に適用されます。AL2023 の詳細については、Amazon Linux 2[AL2023の「AL2023 でのパッケージとオペレーティングシステムの更新の管理](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。 ** AL2 および AL1 は、各 Amazon EC2 AWS Region でホストされているオンラインパッケージリポジトリで使用するように設計されています。リポジトリはすべてのリージョンに存在し、**yum** 更新ツールを使用してアクセスできます。各リージョンでリポジトリをホストしているため、データ転送料金なしで、更新を迅速にデプロイできます。 **重要** AL1 の最新バージョンは 2023 年 12 月 31 日に EOL に達し、2024 年 1 月 1 日以降、セキュリティアップデートやバグ修正は行われません。詳細については「[Amazon Linux AMI のサポート終了](https://aws.amazon.com//blogs/aws/update-on-amazon-linux-ami-end-of-life/)」を参照してください。 インスタンスのデータやカスタマイズを保存する必要がない場合は、現在の AL2 AMI を使用して新しいインスタンスを起動できます。インスタンスのデータまたはカスタマイズを保持する必要がある場合は、Amazon Linux パッケージリポジトリを使用してそれらのインスタンスを維持できます。これらのリポジトリには、更新されたすべてのパッケージが含まれます。実行中のインスタンスにこれらの更新を適用するよう選択できます。AMI および更新パッケージの以前のバージョンは、新しいバージョンがリリースされても引き続き使用できます。 **注記** Amazon EC2 インスタンスでインターネットアクセスなしでパッケージを更新およびインストールするには、「AL[AL1, AL2または AL2023 を実行している Amazon EC2 インスタンスでインターネットアクセスなしで yum を更新するか、パッケージをインストールするにはどうすればよいですか？」を参照してください。](https://repost.aws/knowledge-center/ec2-al1-al2-update-yum-without-internet) パッケージをインストールするには、次のコマンドを使用します。 ``` [ec2-user ~]$ sudo yum install package ``` Amazon Linux に必要なアプリケーションが含まれていない場合は、Amazon Linux インスタンスにアプリケーションを直接インストールできます。Amazon Linux はパッケージ管理yumに RPMs と を使用します。これは新しいアプリケーションをインストールする最も直接的な方法です。多くのアプリケーションが中央の Amazon Linux リポジトリで利用可能なので、最初にアプリケーションがそのリポジトリで利用できるかどうかを確認する必要があります。そこから、これらのアプリケーションを Amazon Linux インスタンスに追加できます。 実行中の Amazon Linux インスタンスにアプリケーションをアップロードするには、**scp** または **sftp** を使用し、インスタンスにログインしてアプリケーションを設定します。組み込みの cloud-init パッケージから **PACKAGE\$1SETUP** アクションを使用して、インスタンスの起動時にアプリケーションをアップロードすることもできます。詳細については、[AL2 での cloud-init の使用](amazon-linux-cloud-init.md) を参照してください。 ### セキュリティ更新 セキュリティ更新は、 パッケージリポジトリを使用して提供されます。セキュリティ更新と更新された AMI セキュリティアラートの両方が [Amazon Linux セキュリティセンター](https://alas.aws.amazon.com)で公開されます。 AWS セキュリティポリシーの詳細については、またはセキュリティの問題を報告するには、「[AWS クラウドのセキュリティ](https://aws.amazon.com/security/)」を参照してください。 AL1 および AL2 は、起動時に重要または重要なセキュリティ更新プログラムをダウンロードしてインストールするように設定されています。この設定にはカーネルの更新は含まれません。 AL2023 では、AL1 および AL2 と比較してこの設定が変更されました。AL2023 のセキュリティアップデートの詳細については、*「Amazon Linux 2023 ユーザーガイド*」の[「セキュリティアップデートと機能](https://docs.aws.amazon.com/linux/al2023/ug/security-features.html)」を参照してください。 起動後にユースケースに必要な更新を行うことをお勧めします。例えば、起動時にすべての更新プログラム (セキュリティ更新プログラムだけでなく) を適用したり、各更新プログラムを評価してシステムに適用可能な更新プログラムのみを適用したりできます。これは、cloud-init 設定 `repo_upgrade` を使用して制御されます。次の cloud-init 設定のスニペットは、インスタンス初期化に渡すユーザーデータテキストで設定を変更する方法を示しています。 ``` #cloud-config repo_upgrade: security ``` `repo_upgrade` の有効な値は次のとおりです。 `critical` まだ適用されていない緊急のセキュリティ更新プログラムを適用します。 `important` まだ適用されていない緊急および重要なセキュリティ更新プログラムを適用します。 `medium` まだ適用されていない緊急、重要、中レベルのセキュリティ更新プログラムを適用します。 `low` 低レベルのセキュリティ更新プログラムを含む、まだ適用されていないセキュリティ更新プログラムをすべて適用します。 `security` Amazon によってセキュリティ更新としてマークされた保留中のクリティカルまたは重要な更新を適用します。 `bugfix` Amazon によってバグフィックスとしてマークされた更新を適用します。バグフィックスは大きなサイズの更新セットで、セキュリティ更新および他のさまざまな小さなバグに対する修正が含まれます。 `all` 分類に関係なく、使用できる適切な更新すべてを適用します。 `none` 起動時に更新をインスタンスに適用しません。 **メモ** Amazon Linux は、更新を としてマークしません`bugfix`。Amazon Linux からセキュリティに関連しない更新を適用するには、 を使用します`repo_upgrade: all`。 `repo_upgrade` のデフォルトの設定は security です。つまり、ユーザーデータに異なる値を指定しない場合、デフォルトでは、Amazon Linux はその時点でインストールされているパッケージの起動時に、セキュリティ更新を実行します。Amazon Linux は、インストール済みのパッケージに更新がある場合も、`/etc/motd` ファイルを使用して、ログイン時に利用可能な更新の数を一覧表示して通知します。これらの更新をインストールするには、インスタンスで **sudo yum upgrade** を実行する必要があります。 ### リポジトリの設定 AL1 および AL2 AMIs は、セキュリティ更新を除き、AMI の作成時に利用可能なパッケージのスナップショットです。元の AMI にはないが、実行時にインストールされたパッケージは、利用可能な最新バージョンになります。AL2 で利用可能な最新のパッケージを取得するには、 を実行します**yum update -y**。 **トラブルシューティングのヒント** `t3.nano` などのナノインスタンスタイプで **yum update** の実行中に `cannot allocate memory` エラーが発生した場合は、更新を有効にするためにスワップ領域を割り当てる必要がある場合があります。 AL2023 では、AL1 および AL2 と比較してリポジトリ設定が変更されました。AL2023 リポジトリの詳細については、「[パッケージおよびオペレーションシステムアップデートの管理](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。 AL2023 までのバージョンは、Amazon Linux の 1 つのマイナーバージョンから次のバージョンにローリングする更新の継続的なフロー (*ローリングリリース*とも呼ばれます) を提供するように設定されていました。ベストプラクティスとして、古い AMI を起動して更新を適用するのではなく、AMI を利用可能な最新の AMIs に更新することをお勧めします。 AL1 から AL2 へ、または AL2 から AL2023 AL2へなど、主要な Amazon Linux バージョン間でインプレースアップグレードはサポートされていません。詳細については、「[Amazon Linux の入手可能性](what-is-amazon-linux.md#amazon-linux-availability)」を参照してください。 # AL2 での cloud-init の使用 cloud-init パッケージは、Canonical によって構築されたオープンソースアプリケーションであり、Amazon EC2 などのクラウドコンピューティング環境で Linux イメージをブートストラップするときに使用されます。Amazon Linux には、カスタマイズされたバージョンの cloud-init が含まれています。これにより、起動時にインスタンスに発生するアクションを指定できます。インスタンスの起動時に、ユーザーデータフィールドを使用して必要なアクションを cloud-init に渡すことができます。つまり、さまざまなユースケースに対して共通の AMI を使用し、起動時にその AMI を動的に設定できます。Amazon Linux は、ec2 ユーザーアカウントの初期設定を実行するためにも cloud-init を使用します。 詳細については、「[cloud-init ドキュメント](http://cloudinit.readthedocs.org/en/latest/)」を参照してください。 Amazon Linux は、`/etc/cloud/cloud.cfg.d` と `/etc/cloud/cloud.cfg` にある cloud-init アクションを使用します。独自の cloud-init アクションファイルを `/etc/cloud/cloud.cfg.d` に作成することができます。このディレクトリ内のすべてのファイルは、cloud-init で読み取られます。それらは辞書と同じ順序に読み取られ、後のファイルは以前のファイルの値を上書きします。 cloud-init パッケージは、起動時にインスタンスのこれらの (およびその他の) 共通の設定タスクを実行します。 + デフォルトのロケールを設定。 + ホスト名を設定。 + ユーザーデータの解析と処理。 + ホスト プライベート SSH キーの生成。 + 容易にログインおよび管理できるように、ユーザーのパブリック SSH キーを `.ssh/authorized_keys` に追加する。 + パッケージ管理のためにリポジトリを準備する + ユーザーデータで定義されたパッケージアクションの処理。 + ユーザーデータにあるユーザースクリプトを実行します。 + インスタンスストアボリュームをマウントする (該当する場合) + デフォルトでは、`ephemeral0` インスタンスストアボリュームがある場合は `/media/ephemeral0` にマウントされ、有効なファイルシステムが含まれます。それ以外の場合は、マウントされません。 + デフォルトでは、インスタンスに関連付けられたスワップボリュームがマウントされます (`m1.small`および`c1.medium`インスタンスタイプの場合のみ)。 + 次の cloud-init ディレクティブを使用して、デフォルトのインスタンスストアボリュームマウントを上書きすることができます。 ``` #cloud-config mounts: - [ ephemeral0 ] ``` マウントをより詳細にコントロールするには、cloud-init ドキュメントの「[マウント](http://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts)」を参照してください。 + TRIM をサポートするインスタンスストアボリュームは、インスタンスの起動時にはフォーマットされないため、マウントする前にパーティション化してフォーマットする必要があります。詳細については、[「インスタンスストアボリュームTRIMのサポート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html#InstanceStoreTrimSupport)」を参照してください。`disk_setup` モジュールを使用して、起動時にインスタンスストアボリュームをパーティションおよびフォーマットすることができます。詳細については、cloud-init ドキュメントの「[Disk Setup](http://cloudinit.readthedocs.io/en/latest/topics/modules.html#disk-setup)」を参照してください。 ## サポートされているユーザーデータ形式 cloud-init パッケージは、さまざまな形式のユーザーデータ処理をサポートしています。 + Gzip + ユーザーデータが gzip 圧縮されている場合、cloud-init はデータを解凍し、適切に処理します。 + MIME マルチパート + MIME マルチパートファイルを使用して、複数のデータタイプを指定できます。たとえば、ユーザーデータスクリプトとクラウド設定タイプの両方を指定できます。マルチパートファイルのパートの形式が、サポートされている形式のいずれかの場合、そのパートは cloud-init で処理できます。 + Base64 デコード + ユーザーデータが base64 でエンコードされている場合、cloud-init は、デコードされたデータをサポートされているタイプの 1 つとして理解できるかどうかを決定します。デコードされたデータを認識できる場合、データをデコードし、適切に処理します。認識できない場合、base64 データは変更されません。 + ユーザーデータスクリプト + 「`#!`」または「`Content-Type: text/x-shellscript`」で始まります。 + このスクリプトは、初回の起動サイクル時に `/etc/init.d/cloud-init-user-scripts` によって実行されます。これは起動プロセスの後半 (初期設定アクションが実行された後) に実行されます。 + インクルードファイル + 「`#include`」または「`Content-Type: text/x-include-url`」で始まります。 + このコンテンツはインクルードファイルです。ファイルには URL の一覧 (1行に1つの URL) が含まれます。各 URL が読み取られ、そのコンテンツが同じルールセットを使用して渡されます。URL から読み取られたコンテンツは gzip 圧縮され、MIME マルチパート、またはプレーンテキスト形式になります。 + クラウド設定データ + 「`#cloud-config`」または「`Content-Type: text/cloud-config`」で始まります。 + このコンテンツはクラウド設定データです。 + アップスタートジョブ (AL2 ではサポートされていません) + 「`#upstart-job`」または「`Content-Type: text/upstart-job`」で始まります。 + このコンテンツは のファイルに保存され`/etc/init`、アップスタートは他のアップスタートジョブと同様にコンテンツを消費します。 + クラウドブートフック + 「`#cloud-boothook`」または「`Content-Type: text/cloud-boothook`」で始まります。 + このコンテンツはブートフックデータです。このデータは `/var/lib/cloud` にあるファイルに保存され、すぐに実行されます。 + これは最初に使用可能な [hook] (フック) です。1 回だけ実行するためのメカニズムはありません。ブートフックは自身でこの点に対処する必要があります。環境変数 `INSTANCE_ID` でインスタンス ID が指定されています。この変数を使用して、インスタンスあたり1つのブートフックデータのセットを提供します。 # AL2 インスタンスを設定する AL2 インスタンスが正常に起動してログインしたら、そのインスタンスを変更できます。特定のアプリケーションのニーズを満たすためにインスタンスを設定するには、多くの方法があります。ここでは、初めて作業する場合の一般的なタスクについて説明します。 **Topics** + [一般的な設定シナリオ](#instance-configuration-scenarios) + [AL2 インスタンスでソフトウェアを管理する](managing-software.md) + [Amazon EC2 AL2 インスタンスのプロセッサ状態制御](processor_state_control.md) + [AL2 の I/O スケジューラ](io-scheduler.md) + [AL2 インスタンスのホスト名を変更する](set-hostname.md) + [AL2 インスタンスで動的 DNS を設定する](dynamic-dns.md) + [AL2 の ec2-net-utils を使用してネットワークインターフェイスを設定する](ec2-net-utils.md) ## 一般的な設定シナリオ Amazon Linux のベースのディストリビューションには、基本的なサーバー操作に必要なソフトウェアパッケージとユーティリティが含まれています。ただし、さまざまなソフトウェアリポジトリでさらに多くのソフトウェアパッケージを利用できます。また、ソースコードから、さらに多くのパッケージソースコードを作成できます。これらの場所からソフトウェアをインストールし、作成する方法についての詳細は、[AL2 インスタンスでソフトウェアを管理する](managing-software.md) を参照してください。 Amazon Linux インスタンスには、`ec2-user` が事前設定されていますが、スーパーユーザー権限を持たない他のユーザーを追加することがあります。ユーザーの追加と削除の詳細については、*Amazon EC2 ユーザーガイド*」の[Linux「インスタンスでユーザーを管理する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/managing-users.html)」を参照してください。 お客様がネットワークを所有し、それにドメイン名を登録している場合、インスタンスのホスト名を変更して、そのドメインに含まれる一部としてインスタンスを識別できます。また、システムプロンプトを変更して、より意味のある名前を表示することもできます。ホスト名設定を変更する必要はありません。詳細については、[AL2 インスタンスのホスト名を変更する](set-hostname.md)を参照してください。動的 DNS サービスプロバイダを使用するようにインスタンスを設定できます。詳細については、[AL2 インスタンスで動的 DNS を設定する](dynamic-dns.md)を参照してください。 Amazon EC2 でインスタンスを起動するとき、起動後にそのインスタンスにユーザーデータを渡し、一般的な設定タスクを実行したり、スクリプトを実行したりできます。2 つのタイプのユーザーデータを Amazon EC2 に渡すことができます。cloud-init ディレクティブとシェルスクリプトです。詳細については、*Amazon EC2 * [ユーザーガイド」の「起動時にLinuxインスタンスでコマンド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)を実行する」を参照してください。 # AL2 インスタンスでソフトウェアを管理する Amazon Linux のベースのディストリビューションには、基本的なサーバー操作に必要なソフトウェアパッケージとユーティリティが含まれています。 この情報は AL2 に適用されます。AL2023 の詳細については、Amazon Linux 2[AL2023の「AL2023 でのパッケージとオペレーティングシステムの更新の管理](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。 ** ソフトウェアは、最新の状態に維持することが重要です。Linux ディストリビューションの多くのパッケージは頻繁に更新されます。これにより、バグが修正され、機能が追加されて、セキュリティ上の弱点に対する防御措置が行われます。詳細については、「[AL2 インスタンスのインスタンスソフトウェアを更新する](install-updates.md)」を参照してください。 デフォルトでは、AL2 インスタンスは、次のリポジトリを有効にして起動します。 + `amzn2-core` + `amzn2extra-docker` これらのリポジトリには、 によって更新される多くのパッケージがありますが AWS、インストールするパッケージが別のリポジトリに含まれている可能性があります。詳細については、「[AL2 インスタンスにリポジトリを追加する](add-repositories.md)」を参照してください。有効なリポジトリでパッケージを検索してインストールする方法については、「[AL2 インスタンスでソフトウェアパッケージを検索してインストールする](find-install-software.md)」を参照してください。 リポジトリに保管されているソフトウェアパッケージで、すべてのソフトウェアが利用できるわけではありません。一部のソフトウェアは、そのソースコードからインスタンスでコンパイルする必要があります。詳細については、「[AL2 インスタンスでソフトウェアをコンパイルする準備をする](compile-software.md)」を参照してください。 AL2 インスタンスは、yum パッケージマネージャーを使用してソフトウェアを管理します。yum パッケージマネージャはソフトウェアをインストール、削除、更新し、各パッケージのすべての依存関係を管理できます。 **Topics** + [AL2 インスタンスのインスタンスソフトウェアを更新する](install-updates.md) + [AL2 インスタンスにリポジトリを追加する](add-repositories.md) + [AL2 インスタンスでソフトウェアパッケージを検索してインストールする](find-install-software.md) + [AL2 インスタンスでソフトウェアをコンパイルする準備をする](compile-software.md) # AL2 インスタンスのインスタンスソフトウェアを更新する ソフトウェアは、最新の状態に維持することが重要です。Linux ディストリビューションのパッケージは頻繁に更新されます。これにより、バグが修正され、機能が追加されて、セキュリティ上の弱点に対する防御措置が行われます。最初に Amazon Linux インスタンスを起動して接続する際、セキュリティ上の目的から、ソフトウェアパッケージを更新するように促すメッセージが表示される場合があります。このセクションでは、システム全体またはパッケージを 1 つだけ更新する方法を紹介します。 この情報は AL2 に適用されます。AL2023 の詳細については、Amazon Linux 2[AL2023の「AL2023 でのパッケージとオペレーティングシステムの更新の管理](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。 ** AL2 の変更と更新の詳細については、[AL2 リリースノート](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html)」を参照してください。 AL2023 への変更と更新の詳細については、「[AL2023 リリースノート](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html)」を参照してください。 **重要** Amazon Linux 2 AMI を使用する EC2 インスタンスを IPv6 専用サブネットに起動した場合は、インスタンスに接続して `sudo amazon-linux-https disable` を実行する必要があります。これにより、AL2 インスタンスが http パッチサービスを使用して、IPv6 経由で S3 の yum リポジトリに接続できるようになります。 **AL2 インスタンスのすべてのパッケージを更新するには** 1. (オプション) シェルウィンドウで **screen** セッションを開始します。時折、ネットワークが遮断され、インスタンスへの SSH 接続が切断されることがあります。この状態が長時間におよぶソフトウェア更新中に発生した場合、インスタンスは混乱した状態になりますが、その復元は可能です。**screen** セッションを開始しておけば、接続が遮断された場合でも更新を続行でき、後で問題なくセッションに再接続できます。 1. セッションを開始するには **screen** コマンドを実行します。 ``` [ec2-user ~]$ screen ``` 1. セッションが中断された場合、インスタンスにログインし直し、利用できる画面を表示します。 ``` [ec2-user ~]$ screen -ls There is a screen on: 17793.pts-0.ip-12-34-56-78 (Detached) 1 Socket in /var/run/screen/S-ec2-user. ``` 1. **screen -r** コマンドと前のコマンドのプロセス ID を使用して、画面に再接続します。 ``` [ec2-user ~]$ screen -r 17793 ``` 1. **screen** の使用が終わったら、**exit** コマンドを使用してセッションを閉じます。 ``` [ec2-user ~]$ exit [screen is terminating] ``` 1. **yum update** コマンドを実行します。オプションで、`--security` フラグを追加すれば、セキュリティ更新のみを適用できます。 ``` [ec2-user ~]$ sudo yum update ``` 1. 表示されたパッケージを確認したら、「**y**」と入力して Enter キーを押し、この更新を受け入れます。システムのパッケージをすべて更新するには数分かかります。実行中、**yum** 出力には更新のステータスが表示されます。 1. (オプション) [インスタンスを再起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)して、更新から最新のパッケージとライブラリを使用していることを確認します。カーネルの更新は、再起動が発生するまでロードされません。`glibc` ライブラリを更新した後も再起動が必要です。サービスを制御する更新の場合は、更新を取得するにはサービスの再起動で十分かもしれませんが、システムを再起動することで、それ以前のすべてのパッケージとライブラリの更新を確実に完了できます。 **AL2 インスタンスで 1 つのパッケージを更新するには** システム全体ではなく、1 つのパッケージ (とその依存関係) を更新するには、この手順を使用します。 1. 更新するパッケージの名前を指定した **yum update** コマンドを実行します。 ``` [ec2-user ~]$ sudo yum update openssl ``` 1. 表示されたパッケージ情報を確認したら、「**y**」と入力して Enter キーを押し、この更新を受け入れます。時折、解決する必要があるパッケージ依存関係ある場合、リストには複数のパッケージがあります。実行中、**yum** 出力には更新のステータスが表示されます。 1. (オプション) [インスタンスを再起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html)して、更新から最新のパッケージとライブラリを使用していることを確認します。カーネルの更新は、再起動が発生するまでロードされません。`glibc` ライブラリを更新した後も再起動が必要です。サービスを制御する更新の場合は、更新を取得するにはサービスの再起動で十分かもしれませんが、システムを再起動することで、それ以前のすべてのパッケージとライブラリの更新を確実に完了できます。 # AL2 インスタンスにリポジトリを追加する この情報は AL2 に適用されます。AL2023 の詳細については、「Amazon Linux 2[023 ユーザーガイド」の「AL2023 のバージョニングされたリポジトリによる確定的なアップグレード](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)」を参照してください。 ** デフォルトでは、AL2 インスタンスは、次のリポジトリを有効にして起動します。 + `amzn2-core` + `amzn2extra-docker` これらのリポジトリには、Amazon Web Services が更新するさまざまなパッケージが用意されていますが、別のリポジトリで、インストールしたいパッケージが見つかる可能性もあります。 **yum** で異なるリポジトリからパッケージをインストールには、`/etc/yum.conf` ファイル、または `repository.repo` ディレクトリにあるお客様の `/etc/yum.repos.d` ファイルに、リポジトリ情報を追加する必要があります。これは手動で行えますが、ほとんどの yum リポジトリのリポジトリ URL で、独自の `repository.repo` ファイルが提供されています。 **既にインストールされている yum レポジトリを調べるには** 次のコマンドで、インストール済みの yum リポジトリを表示します。 ``` [ec2-user ~]$ yum repolist all ``` 生成される出力には、インストール済みのリポジトリが一覧表示され、それぞれのステータスが報告されます。有効なリポジトリには、そこに含まれているパッケージの数が表示されます。 **yum リポジトリを /etc/yum.repos.d に追加するには** 1. `.repo` ファイルの場所を検索します。場所は、追加しているリポジトリによって異なります。この例では、`.repo` ファイルは、`https://www.example.com/repository.repo` にあります。 1. **yum-config-manager** コマンドを使用してリポジトリを追加します。 ``` [ec2-user ~]$ sudo yum-config-manager --add-repo https://www.example.com/repository.repo Loaded plugins: priorities, update-motd, upgrade-helper adding repo from: https://www.example.com/repository.repo grabbing file https://www.example.com/repository.repo to /etc/yum.repos.d/repository.repo repository.repo | 4.0 kB 00:00 repo saved to /etc/yum.repos.d/repository.repo ``` リポジトリをインストールしたら、次の手順で説明するように有効にする必要があります。 **yum リポジトリを /etc/yum.repos.d で有効にするには** **yum-config-manager** フラグを付けて `--enable repository` コマンドを使用します。次のコマンドを使用すると、Fedora プロジェクトの Extra Packages for Enterprise Linux (EPEL) リポジトリが有効になります。デフォルトでは、このリポジトリは Amazon Linux AMI インスタンスの `/etc/yum.repos.d` にありますが、有効になっていません。 ``` [ec2-user ~]$ sudo yum-config-manager --enable epel ``` 詳細およびこのパッケージの最新バージョンのダウンロードについては、[https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL) を参照してください。 # AL2 インスタンスでソフトウェアパッケージを検索してインストールする パッケージ管理ツールを使用して、ソフトウェアパッケージを検索してインストールできます。Amazon Linux 2 では、デフォルトのソフトウェアパッケージ管理ツールは ですYUM。AL2023 では、デフォルトのソフトウェアパッケージ管理ツールは DNF です。詳細については、*「Amazon Linux 2023 ユーザーガイド*」の[「パッケージ管理ツール](https://docs.aws.amazon.com/linux/al2023/ug/package-management.html)」を参照してください。 ## AL2 インスタンスでソフトウェアパッケージを検索する **yum search** コマンドを使用すると、設定したリポジトリで利用できるパッケージの説明を検索できます。これは特に、インストールするパッケージの正確な名前がわからない場合に便利です。キーワード検索をコマンドに追加します。複数の単語を検索するには、引用符で検索クエリを囲みます。 ``` [ec2-user ~]$ yum search "find" ``` 以下は出力の例です。 ``` Loaded plugins: extras_suggestions, langpacks, priorities, update-motd ============================== N/S matched: find =============================== findutils.x86_64 : The GNU versions of find utilities (find and xargs) gedit-plugin-findinfiles.x86_64 : gedit findinfiles plugin ocaml-findlib-devel.x86_64 : Development files for ocaml-findlib perl-File-Find-Rule.noarch : Perl module implementing an alternative interface to File::Find robotfindskitten.x86_64 : A game/zen simulation. You are robot. Your job is to find kitten. mlocate.x86_64 : An utility for finding files by name ocaml-findlib.x86_64 : Objective CAML package manager and build helper perl-Devel-Cycle.noarch : Find memory cycles in objects perl-Devel-EnforceEncapsulation.noarch : Find access violations to blessed objects perl-File-Find-Rule-Perl.noarch : Common rules for searching for Perl things perl-File-HomeDir.noarch : Find your home and other directories on any platform perl-IPC-Cmd.noarch : Finding and running system commands made easy perl-Perl-MinimumVersion.noarch : Find a minimum required version of perl for Perl code texlive-xesearch.noarch : A string finder for XeTeX valgrind.x86_64 : Tool for finding memory management bugs in programs valgrind.i686 : Tool for finding memory management bugs in programs ``` 引用符で囲まれた複数の単語検索クエリは、正確なクエリに一致する結果のみを返します。予想されたパッケージが表示されない場合、キーワードを 1 つに絞って検索し、結果をスキャンします。キーワードの同義語を試して、検索の幅を広げることもできます。 AL2 のパッケージの詳細については、以下を参照してください。 + [AL2 Extras ライブラリ](al2-extras.md) + [パッケージリポジトリ](ec2.md#package-repository) ## AL2 インスタンスにソフトウェアパッケージをインストールする AL2 では、yum パッケージ管理ツールは、有効なすべてのリポジトリでさまざまなソフトウェアパッケージを検索し、ソフトウェアのインストールプロセスの依存関係を処理します。AL2023 にソフトウェアパッケージをインストールする方法については、*「Amazon Linux 2023 ユーザーガイド*」の[「パッケージとオペレーティングシステムの更新の管理](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html)」を参照してください。 **リポジトリからパッケージをインストールするには** **yum install *package*** コマンドを使用します。この際、*package* はインストールするソフトウェアの名前に置き換えます。例えば、**links** テキストベースウェブブラウザをインストールするには、次のコマンドを入力します。 ``` [ec2-user ~]$ sudo yum install links ``` **ダウンロードした RPM パッケージファイルをインストールするには** また、**yum install** を使用して、インターネットからダウンロードした RPM パッケージファイルをインストールすることもできます。その場合には、リポジトリのパッケージ名の代わりに、RPM ファイルのパス名をインストールコマンドに追加します。 ``` [ec2-user ~]$ sudo yum install my-package.rpm ``` **インストールされているパッケージを一覧表示するには** インスタンスにインストールされているパッケージを一覧表示するには、次のコマンドを使用します。 ``` [ec2-user ~]$ yum list installed ``` # AL2 インスタンスでソフトウェアをコンパイルする準備をする オープンソースのソフトウェアは、事前コンパイルされていないインターネットで使用できます。これらは、パッケージリポジトリからダウンロードできます。入手したソフトウェアパッケージがソースコードであり、自分でコンパイルする必要があると判明することがあります。システムが AL2 および Amazon Linux でソフトウェアをコンパイルできるようにするには、、**make**、 **gcc**などのいくつかの開発ツールをインストールする必要があります**autoconf**。 ソフトウェアのコンパイルはすべての Amazon EC2 インスタンスで必要なタスクではないため、そのようなツールはデフォルトでインストールされていません。ただし、「Development Tools」という名前のパッケージグループで利用でき、**yum groupinstall** コマンドでインスタンスに簡単に追加されます。 ``` [ec2-user ~]$ sudo yum groupinstall "Development Tools" ``` ソフトウェアのソースコードパッケージは、多くの場合、tarball と呼ばれる圧縮アーカイブファイルの形で ([https://github.com/](https://github.com/) や [http://sourceforge.net/](https://sourceforge.net/) などのウェブサイトから) ダウンロードできます。通常、これらの tarball には `.tar.gz` というファイル拡張子が付いています。これらのアーカイブは **tar** コマンドで解凍できます。 ``` [ec2-user ~]$ tar -xzf software.tar.gz ``` ソースコードパッケージを解凍したら、ソースコードディレクトリで `README` ファイルまたは `INSTALL` ファイルを探します。これらのファイルに、ソースコードのコンパイルとインストールに関する詳細な指示があります。 **Amazon Linux パッケージのソースコードを取得するには** Amazon Web Services は、保守管理されているパッケージのソースコードを提供します。**yumdownloader --source** コマンドを使用して、インストールされているパッケージのソースコードをダウンロードできます。 **yumdownloader --source *package*** コマンドを実行して、*package* のソースコードをダウンロードします。例えば、`htop` パッケージのソースコードをダウンロードするには、次のコマンドを入力します。 ``` [ec2-user ~]$ yumdownloader --source htop Loaded plugins: priorities, update-motd, upgrade-helper Enabling amzn-updates-source repository Enabling amzn-main-source repository amzn-main-source | 1.9 kB 00:00:00 amzn-updates-source | 1.9 kB 00:00:00 (1/2): amzn-updates-source/latest/primary_db | 52 kB 00:00:00 (2/2): amzn-main-source/latest/primary_db | 734 kB 00:00:00 htop-1.0.1-2.3.amzn1.src.rpm ``` ソース RPM の場所は、コマンドを実行したディレクトリにあります。 # Amazon EC2 AL2 インスタンスのプロセッサ状態制御 C ステートはアイドル時のコアのスリープレベルを制御します。C ステートはC0 (コアがアクティブで、命令を実行している最も浅い状態) から始まる番号が付けられ、C6 (コアの電源がオフになっている最も深いアイドル状態) まで移行します。 P ステートはコアに希望するパフォーマンス (CPU 周波数) を制御します。P ステートはP0 (コアが Intel Turbo Boost Technology を使用して可能であれば周波数を上げることができる最高パフォーマンスの設定) から始まる番号が付けられ、P1 (最大限のベースライン周波数をリクエストする P ステート) から P15 (最小限の周波数) まで移行します。 プロセッサのパフォーマンスの安定性を向上させたり、レイテンシーを減らしたり、インスタンスを特定のワークロード用に調整するために、C ステートまたは P ステートの設定を変更したいと思う場合があるかもしれません。デフォルトの C ステートおよび P ステートの設定はほとんどの作業負荷に対して最適なパフォーマンスを提供します。ただし、アプリケーションにおいて、より高いシングルコアまたはデュアルコアの周波数でレイテンシーを軽減したい場合、またはバースト的な Turbo Boost 周波数よりも低い周波数でより安定したパフォーマンスを維持することを優先する場合、これらのインスタンスで利用可能な C ステートまたは P ステートを試みることを考慮してください。 オペレーティングシステムがプロセッサの C ステートと P ステートを制御する機能を提供する Amazon EC2 インスタンスタイプについては、[Amazon EC2 ユーザーガイド」の「Amazon EC2 インスタンスのプロセッサステートコントロール](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/processor_state_control.html)」を参照してください。 *Amazon EC2 * 以下のセクションでは、プロセッサのさまざまなステート設定と、設定の効果をモニタリングする方法について説明します。これらの手順は 用に記述され、Amazon Linux に適用されますが、Linux カーネルバージョン 3.9 以降の他の Linux ディストリビューションでも機能する可能性があります。 **注記** このページの例では、以下を使用しています。 プロセッサの周波数と C ステート情報を表示する **turbostat** ユーティリティ。**turbostat** ユーティリティは Amazon Linux でデフォルトで使用できます。 ワークロードをシミュレートする **stress** コマンド。**stress** をインストールするには、まず **sudo amazon-linux-extras install epel** を実行して EPEL リポジトリを有効にし、次に **sudo yum install -y stress** を実行します。 出力に C ステート情報が表示されない場合は、コマンド (**--debug**) に **sudo turbostat --debug stress **** オプションを含めます｡ **Topics** + [最大 Turbo Boost 周波数による最高パフォーマンス](#turbo-perf) + [深い C ステートの制限による高パフォーマンスと低レイテンシー](#c-states) + [変動性が最も低いベースラインパフォーマンス](#baseline-perf) ## 最大 Turbo Boost 周波数による最高パフォーマンス これは、Amazon Linux AMI のデフォルトのプロセッサのステート制御設定であり、ほとんどのワークロードにお勧めします。この設定では、変動性を抑え、最高パフォーマンスを実現します。非アクティブなコアは深いスリープ状態になることができるため、シングルまたはデュアルコアプロセスが Turbo Boost の潜在能力を最大限に引き出すために必要な発熱量の余裕を実現できます。 次の例は、2 個のコアでアクティブに処理を実行する `c4.8xlarge` インスタンスが Turbo Boost の最大周波数に到達した状況を示しています。 ``` [ec2-user ~]$ sudo turbostat stress -c 2 -t 10 stress: info: [30680] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [30680] successful run completed in 10s pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 5.54 3.44 2.90 0 9.18 0.00 85.28 0.00 0.00 0.00 0.00 0.00 94.04 32.70 54.18 0.00 0 0 0 0.12 3.26 2.90 0 3.61 0.00 96.27 0.00 0.00 0.00 0.00 0.00 48.12 18.88 26.02 0.00 0 0 18 0.12 3.26 2.90 0 3.61 0 1 1 0.12 3.26 2.90 0 4.11 0.00 95.77 0.00 0 1 19 0.13 3.27 2.90 0 4.11 0 2 2 0.13 3.28 2.90 0 4.45 0.00 95.42 0.00 0 2 20 0.11 3.27 2.90 0 4.47 0 3 3 0.05 3.42 2.90 0 99.91 0.00 0.05 0.00 0 3 21 97.84 3.45 2.90 0 2.11 ... 1 1 10 0.06 3.33 2.90 0 99.88 0.01 0.06 0.00 1 1 28 97.61 3.44 2.90 0 2.32 ... 10.002556 sec ``` この例では、vCPU 21 と 28 が最大 Turbo Boost 周波数で実行され、他のコアは `C6` スリープ状態になることで電力を節約し、実行中のコアに電力と発熱の余裕を持たせています。vCPU 3 と 10 (それぞれ vCPU 21 および 28 とプロセッサコアを共有する) は `C1` ステートであり、命令を待っています。 以下の例では、18 個のコアはすべてアクティブに処理を実行しているため、Turbo Boost の最大周波数のための余裕はありませんが、すべてのコアが「all core Turbo Boost」の速度である 3.2 GHz で実行されています。 ``` [ec2-user ~]$ sudo turbostat stress -c 36 -t 10 stress: info: [30685] dispatching hogs: 36 cpu, 0 io, 0 vm, 0 hdd stress: info: [30685] successful run completed in 10s pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 99.27 3.20 2.90 0 0.26 0.00 0.47 0.00 0.00 0.00 0.00 0.00 228.59 31.33 199.26 0.00 0 0 0 99.08 3.20 2.90 0 0.27 0.01 0.64 0.00 0.00 0.00 0.00 0.00 114.69 18.55 99.32 0.00 0 0 18 98.74 3.20 2.90 0 0.62 0 1 1 99.14 3.20 2.90 0 0.09 0.00 0.76 0.00 0 1 19 98.75 3.20 2.90 0 0.49 0 2 2 99.07 3.20 2.90 0 0.10 0.02 0.81 0.00 0 2 20 98.73 3.20 2.90 0 0.44 0 3 3 99.02 3.20 2.90 0 0.24 0.00 0.74 0.00 0 3 21 99.13 3.20 2.90 0 0.13 0 4 4 99.26 3.20 2.90 0 0.09 0.00 0.65 0.00 0 4 22 98.68 3.20 2.90 0 0.67 0 5 5 99.19 3.20 2.90 0 0.08 0.00 0.73 0.00 0 5 23 98.58 3.20 2.90 0 0.69 0 6 6 99.01 3.20 2.90 0 0.11 0.00 0.89 0.00 0 6 24 98.72 3.20 2.90 0 0.39 ... ``` ## 深い C ステートの制限による高パフォーマンスと低レイテンシー C ステートは非アクティブ時のコアのスリープレベルを制御します。C ステートを制御して、システムのレイテンシーとパフォーマンスを調整することができます。コアをスリープ状態にするには時間がかかります。また、スリープ状態のコアによって、別のコアが高い周波数で動作するための余裕が生まれますが、そのスリープ状態にあるコアが再び稼働し処理を実行するのにも時間がかかります。例えば、ネットワークパケットの中断を処理するように割り当てられたコアがスリープ状態である場合、その中断の処理に遅延が生じる可能性があります。より深い C ステートを使用しないようにシステムを設定できます。これにより、プロセッサの応答のレイテンシーは減少しますが、他のコアの Turbo Boost 用の余裕も減少します。 深いスリープ状態を無効にする一般的なシナリオとして、Redis データベースアプリケーションがあります。このアプリケーションは、最速のクエリ応答時間を実現するために、データベースをシステムメモリ内に格納します。 **AL2 で深いスリープ状態を制限するには** 1. 適切なエディタで `/etc/default/grub` ファイルを開きます。 ``` [ec2-user ~]$ sudo vim /etc/default/grub ``` 1. `GRUB_CMDLINE_LINUX_DEFAULT` 行を編集し `intel_idle.max_cstate=1` と `processor.max_cstate=1` のオプションを追加します。これにより、アイドル状態にあるコアの最も深い C ステートとして `C1` を設定します。 ``` GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 intel_idle.max_cstate=1 processor.max_cstate=1" GRUB_TIMEOUT=0 ``` `intel_idle.max_cstate=1` オプションでは、インテルベースのインスタンスで C ステート制限が設定され、また、`processor.max_cstate=1` オプションでは、AMD ベースのインスタンスで C ステート制限が設定されます。両方のオプションを設定に追加しておくと安心です。これにより、インテルと AMD のインスタンスに対し、共通の方法で目的の動作を設定することができます。 1. ファイルを保存し、エディタを終了します。 1. 起動設定を再構築するには、次のコマンドを実行します。 ``` [ec2-user ~]$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg ``` 1. 新しい kernel オプションを有効にするためにインスタンスを再起動します。 ``` [ec2-user ~]$ sudo reboot ``` **Amazon Linux AMI で深いスリープ状態を制限するには** 1. 適切なエディタで `/boot/grub/grub.conf` ファイルを開きます。 ``` [ec2-user ~]$ sudo vim /boot/grub/grub.conf ``` 1. 最初のエントリの `kernel` 行を編集して `intel_idle.max_cstate=1` と `processor.max_cstate=1` オプションを追加し、アイドル状態のコアの最も深い C ステートに `C1` を設定します。 ``` # created by imagebuilder default=0 timeout=1 hiddenmenu title Amazon Linux 2014.09 (3.14.26-24.46.amzn1.x86_64) root (hd0,0) kernel /boot/vmlinuz-3.14.26-24.46.amzn1.x86_64 root=LABEL=/ console=ttyS0 intel_idle.max_cstate=1 processor.max_cstate=1 initrd /boot/initramfs-3.14.26-24.46.amzn1.x86_64.img ``` `intel_idle.max_cstate=1` オプションでは、インテルベースのインスタンスで C ステート制限が設定され、また、`processor.max_cstate=1` オプションでは、AMD ベースのインスタンスで C ステート制限が設定されます。両方のオプションを設定に追加しておくと安心です。これにより、インテルと AMD のインスタンスに対し、共通の方法で目的の動作を設定することができます。 1. ファイルを保存し、エディタを終了します。 1. 新しい kernel オプションを有効にするためにインスタンスを再起動します。 ``` [ec2-user ~]$ sudo reboot ``` 次の例では、2 つのコアが「all core Turbo Boost」コア周波数でアクティブに処理を実行している `c4.8xlarge` インスタンスを示します。 ``` [ec2-user ~]$ sudo turbostat stress -c 2 -t 10 stress: info: [5322] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [5322] successful run completed in 10s pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 5.56 3.20 2.90 0 94.44 0.00 0.00 0.00 0.00 0.00 0.00 0.00 131.90 31.11 199.47 0.00 0 0 0 0.03 2.08 2.90 0 99.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 67.23 17.11 99.76 0.00 0 0 18 0.01 1.93 2.90 0 99.99 0 1 1 0.02 1.96 2.90 0 99.98 0.00 0.00 0.00 0 1 19 99.70 3.20 2.90 0 0.30 ... 1 1 10 0.02 1.97 2.90 0 99.98 0.00 0.00 0.00 1 1 28 99.67 3.20 2.90 0 0.33 1 2 11 0.04 2.63 2.90 0 99.96 0.00 0.00 0.00 1 2 29 0.02 2.11 2.90 0 99.98 ... ``` この例では、vCPU 19 および 28 のコアは 3.2 GHz で実行中であり、その他のコアは `C1` C ステートで、命令を待機しています。稼働中のコアは Turbo Boost の最大周波数には到達していませんが、非アクティブなコアはより深い `C6` C ステートにある場合と比べて、新しいリクエストに迅速に応答します。 ## 変動性が最も低いベースラインパフォーマンス P ステートによってプロセッサの周波数の変動性を抑制することができます。P ステートはコアに希望するパフォーマンス (CPU 周波数) を制御します。ほとんどのワークロードでは、Turbo Boost をリクエストする、P0 でパフォーマンスが向上します。ただし、Turbo Boost 周波数が有効であるときに発生する可能性があるバースト的なパフォーマンスではなく、安定したパフォーマンスになるようにシステムを調整することもできます。 Intel Advanced Vector Extensions (AVX または AVX2) のワークロードは低い周波数でもパフォーマンスに優れ、AVX 命令はより多くの処理能力を使用できます。Turbo Boost を無効にして、プロセッサをより低い周波数で実行すると、使用される処理能力が抑えられ、より安定した速度が維持されます。AVX のインスタンス設定とワークロードの最適化の詳細については、[インテルのウェブサイト](https://www.intel.com/content/www/us/en/developer/articles/technical/the-intel-advanced-vector-extensions-512-feature-on-intel-xeon-scalable.html?wapkw=advanced%20vector%20extensions)を参照してください。 CPU がアイドル状態のドライバは P ステートを制御します。最近の世代の CPU には、以下のようにカーネルレベルでの対応が可能な、更新された CPU アイドルドライバが必要です。 + Linux カーネルバージョン 6.1 以降 – Intel Granite Rapids (R8i など) をサポート + Linux カーネルバージョン 5.10 以降 – AMD Milan をサポート (M6a など) + Linux カーネルバージョン 5.6 以降 – Intel Icelake (M6i など) をサポート 実行中のシステムのカーネルが CPU を認識するかどうかを確認するには、次のコマンドを実行します。 ``` if [ -d /sys/devices/system/cpu/cpu0/cpuidle ]; then echo "C-state control enabled"; else echo "Kernel cpuidle driver does not recognize this CPU generation"; fi ``` このコマンドの出力により、サポートが不十分であることを確認した場合は、カーネルをアップグレードすることをお勧めします。 このセクションでは、深いスリープ状態を制限し、(`P1` P ステートをリクエストすることにより) Turbo Boost を無効にすることで、これらのタイプのワークロードに対して、低レイテンシーを提供し、プロセッサ速度の変動性を最低限に抑える方法を説明します。 **深いスリープ状態を制限し、AL2 で Turbo Boost を無効にするには** 1. 適切なエディタで `/etc/default/grub` ファイルを開きます。 ``` [ec2-user ~]$ sudo vim /etc/default/grub ``` 1. `GRUB_CMDLINE_LINUX_DEFAULT` 行を編集し `intel_idle.max_cstate=1` と `processor.max_cstate=1` のオプションを追加します。これにより、アイドル状態にあるコアの最も深い C ステートとして `C1` を設定します。 ``` GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 intel_idle.max_cstate=1 processor.max_cstate=1" GRUB_TIMEOUT=0 ``` `intel_idle.max_cstate=1` オプションでは、インテルベースのインスタンスで C ステート制限が設定され、また、`processor.max_cstate=1` オプションでは、AMD ベースのインスタンスで C ステート制限が設定されます。両方のオプションを設定に追加しておくと安心です。これにより、インテルと AMD のインスタンスに対し、共通の方法で目的の動作を設定することができます。 1. ファイルを保存し、エディタを終了します。 1. 起動設定を再構築するには、次のコマンドを実行します。 ``` [ec2-user ~]$ grub2-mkconfig -o /boot/grub2/grub.cfg ``` 1. 新しい kernel オプションを有効にするためにインスタンスを再起動します。 ``` [ec2-user ~]$ sudo reboot ``` 1. `P1` P ステートによってプロセッサ速度の変動性を抑える必要がある場合は、次のコマンドを実行して Turbo Boost を無効にします。 ``` [ec2-user ~]$ sudo sh -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo" ``` 1. ワークロードが終了したら、次のコマンドで Turbo Boost を再度有効にすることができます。 ``` [ec2-user ~]$ sudo sh -c "echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo" ``` **Amazon Linux AMI で深いスリープ状態を制限し、Turbo Boost を無効にするには** 1. 適切なエディタで `/boot/grub/grub.conf` ファイルを開きます。 ``` [ec2-user ~]$ sudo vim /boot/grub/grub.conf ``` 1. 最初のエントリの `kernel` 行を編集して `intel_idle.max_cstate=1` と `processor.max_cstate=1` オプションを追加し、アイドル状態のコアの最も深い C ステートに `C1` を設定します。 ``` # created by imagebuilder default=0 timeout=1 hiddenmenu title Amazon Linux 2014.09 (3.14.26-24.46.amzn1.x86_64) root (hd0,0) kernel /boot/vmlinuz-3.14.26-24.46.amzn1.x86_64 root=LABEL=/ console=ttyS0 intel_idle.max_cstate=1 processor.max_cstate=1 initrd /boot/initramfs-3.14.26-24.46.amzn1.x86_64.img ``` `intel_idle.max_cstate=1` オプションでは、インテルベースのインスタンスで C ステート制限が設定され、また、`processor.max_cstate=1` オプションでは、AMD ベースのインスタンスで C ステート制限が設定されます。両方のオプションを設定に追加しておくと安心です。これにより、インテルと AMD のインスタンスに対し、共通の方法で目的の動作を設定することができます。 1. ファイルを保存し、エディタを終了します。 1. 新しい kernel オプションを有効にするためにインスタンスを再起動します。 ``` [ec2-user ~]$ sudo reboot ``` 1. `P1` P ステートによってプロセッサ速度の変動性を抑える必要がある場合は、次のコマンドを実行して Turbo Boost を無効にします。 ``` [ec2-user ~]$ sudo sh -c "echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo" ``` 1. ワークロードが終了したら、次のコマンドで Turbo Boost を再度有効にすることができます。 ``` [ec2-user ~]$ sudo sh -c "echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo" ``` 次の例では、2 つの vCPU が、Turbo Boost を使用せずに、ベースラインコア周波数でアクティブに処理を実行している `c4.8xlarge` インスタンスを示します。 ``` [ec2-user ~]$ sudo turbostat stress -c 2 -t 10 stress: info: [5389] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd stress: info: [5389] successful run completed in 10s pk cor CPU %c0 GHz TSC SMI %c1 %c3 %c6 %c7 %pc2 %pc3 %pc6 %pc7 Pkg_W RAM_W PKG_% RAM_% 5.59 2.90 2.90 0 94.41 0.00 0.00 0.00 0.00 0.00 0.00 0.00 128.48 33.54 200.00 0.00 0 0 0 0.04 2.90 2.90 0 99.96 0.00 0.00 0.00 0.00 0.00 0.00 0.00 65.33 19.02 100.00 0.00 0 0 18 0.04 2.90 2.90 0 99.96 0 1 1 0.05 2.90 2.90 0 99.95 0.00 0.00 0.00 0 1 19 0.04 2.90 2.90 0 99.96 0 2 2 0.04 2.90 2.90 0 99.96 0.00 0.00 0.00 0 2 20 0.04 2.90 2.90 0 99.96 0 3 3 0.05 2.90 2.90 0 99.95 0.00 0.00 0.00 0 3 21 99.95 2.90 2.90 0 0.05 ... 1 1 28 99.92 2.90 2.90 0 0.08 1 2 11 0.06 2.90 2.90 0 99.94 0.00 0.00 0.00 1 2 29 0.05 2.90 2.90 0 99.95 ``` vCPU 21 および 28 のコアは、ベースラインプロセッサ速度の 2.9 GHz でアクティブに処理を実行し、すべての非アクティブなコアも、`C1` C ステートのベースライン速度で実行され、すぐに命令を受け付けることができます。 # AL2 の I/O スケジューラ I/O スケジューラは、I/O リクエストをソートおよびマージし、処理される順序を決定する Linux オペレーティングシステムの一部です。 I/O スケジューラは、シーク時間が長くなる可能性があり、コロケーションされた要求をマージするのが最適である磁気ハードドライブなどのデバイスにとって特に有益です。I/O スケジューラは、ソリッドステートデバイスや仮想化環境ではあまり影響しません。これは、ソリッドステートデバイスの場合、シーケンシャルアクセスとランダムアクセスが異なることがなく、仮想化環境ではホストが独自のスケジューリング層を提供するためです。 このトピックでは、Amazon Linux I/O スケジューラについて説明します。他の Linux ディストリビューションで使用される I/O スケジューラの詳細については、それぞれのドキュメントを参照してください。 **Topics** + [サポートされているスケジューラ](#supported-schedulers) + [デフォルトスケジューラ](#default-schedulers) + [スケジューラを変更する](#change-scheduler) ## サポートされているスケジューラ Amazon Linux では、次の I/O スケジューラがサポートされています。 + `deadline` — *期限日* I/O スケジューラは I/O リクエストをソートし、最も効率的な順序で処理します。これにより、各 I/O リクエストの開始時間が保証されます。また、長い間保留中であった I/O リクエストの優先度も高くなります。 + `cfq` — *完全公平キュー*(CFQ) I/O スケジューラは、プロセス間で I/O リソースを公平に割り当てようとします。I/O リクエストをソートし、プロセスごとのキューに挿入します。 + `noop` — *オペレーションなし* (noop) I/O スケジューラは、すべての I/O リクエストを FIFO キューに挿入し、それらを単一のリクエストにマージします。このスケジューラは、リクエストの並べ替えを行いません。 ## デフォルトスケジューラ [オペレーションなし (noop)] は Amazon Linux のデフォルトの I/O スケジューラです。このスケジューラは、次の理由で使用されます。 + 多くのインスタンスタイプは、基盤となるホストがインスタンスのスケジュールを実行する仮想化デバイスを使用します。 + ソリッドステートデバイスは、I/O スケジューラの利点の影響が少ない多くのインスタンスタイプで使用されます。 + これは侵襲性の低い I/O スケジューラであり、必要に応じてカスタマイズできます。 ## スケジューラを変更する I/O スケジューラを変更すると、スケジューラによって一定時間内に完了する I/O リクエストが増減するかどうかに基づいて、パフォーマンスが向上または低下することがあります。これは、ワークロード、使用されているインスタンスタイプの生成、アクセスされるデバイスのタイプに大きく依存します。使用する I/O スケジューラを変更する場合は、**iotop** などのツールを使用し、I/O パフォーマンスを測定し、その変更がユースケースにとって有益かどうかを判断することをお勧めします。 デバイスの I/O スケジューラは、`nvme0n1` を例にした次のコマンドで確認できます。インスタンスの `/sys/block` に表示されているデバイスを使って、次のコマンドの `nvme0n1` を置き換えます。 ``` $ cat /sys/block/nvme0n1/queue/scheduler ``` デバイスの I/O スケジューラを設定するには、次のコマンドを使用します。 ``` $ echo cfq|deadline|noop > /sys/block/nvme0n1/queue/scheduler ``` 例えば、*xvda* デバイスの I/O スケジューラを `noop` から `cfq` に設定するには、次のコマンドを使用します。 ``` $ echo cfq > /sys/block/xvda/queue/scheduler ``` # AL2 インスタンスのホスト名を変更する プライベート VPC 内でインスタンスを起動すると、Amazon EC2 によってゲスト OS ホスト名が割り当てられます。Amazon EC2 によって割り当てられるホスト名のタイプは、サブネット設定によって異なります。EC2 ホスト名の詳細については、[Amazon EC2 ユーザーガイド」の「Amazon EC2 インスタンスのホスト名タイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html)」を参照してください。 *Amazon EC2 * IPv4 アドレスで IP ベースの命名を使用するように構成された EC2 インスタンスの典型的な Amazon EC2 のプライベート DNS 名は、`ip-12-34-56-78.us-west-2.compute.internal` のような形式になります。この名前は内部ドメイン、サービス (この例では、`compute`)、リージョン、そしてプライベート IPv4 アドレスで構成されます。インスタンスにログインしたとき、このホスト名の一部がシェルプロンプトで表示されます (`ip-12-34-56-78` など)。Amazon EC2 インスタンスを停止し、再起動するたびに (Elastic IP アドレスを使用していない限り)、パブリック IPv4 アドレスが変わり、パブリック DNS 名、システムホスト名、シェルプロンプトも変わります。 **重要** この情報は、Amazon Linux に適用されます。その他のディストリビューションの情報については、各ドキュメントを参照してください。 ## システムホスト名の変更 インスタンスの IP アドレスにパブリック DNS 名を登録している場合 (`webserver.mydomain.com` など)、インスタンスがそのドメインに含まれているものとして識別されるように、システムホスト名を設定できます。また、シェルプロンプトが変更され、 によって指定されたホスト名ではなく、この名前の最初の部分が表示されます AWS (例: `ip-12-34-56-78`)。パブリック DNS 名を登録していない場合でもホスト名は変更できますが、プロセスが少し違います。 ホスト名の更新内容を維持するには、`preserve_hostname` cloud-init 設定が `true` に設定されていることを確認してください。この設定を編集または追加するには、次のコマンドを実行します。 ``` sudo vi /etc/cloud/cloud.cfg ``` `preserve_hostname` 設定が一覧表示されない場合は、ファイルの末尾に次のテキスト行を追加します。 ``` preserve_hostname: true ``` **システムホスト名をパブリック DNS 名に変更するには** パブリック DNS 名を登録している場合、この手順を行います。 1. + AL2 の場合: **hostnamectl** コマンドを使用して、完全修飾ドメイン名 ( など) を反映するようにホスト名を設定します**webserver.mydomain.com**。 ``` [ec2-user ~]$ sudo hostnamectl set-hostname webserver.mydomain.com ``` + Amazon Linux AMI の場合: インスタンスで、お好みのテキストエディタを使用して `/etc/sysconfig/network` 設定ファイルを開き、`HOSTNAME` エントリを変更して、完全修飾ドメイン名 (**webserver.mydomain.com** など) を反映させます。 ``` HOSTNAME=webserver.mydomain.com ``` 1. インスタンスを再起動し、新しいホスト名を取得します。 ``` [ec2-user ~]$ sudo reboot ``` または、Amazon EC2 コンソールを使用して再起動することもできます (**[Instances (インスタンス)**] ページでインスタンスを選択し、[**Instance state (インスタンスの状態)**]、[**Reboot instance (インスタンスの再起動)**] の順に選択します)。 1. インスタンスにログインして、ホスト名が更新されていることを確認します。メッセージには、新しいホスト名が表示されるはずです (最初の「.」まで)。**hostname** コマンドで完全修飾ドメイン名が表示されます。 ``` [ec2-user@webserver ~]$ hostname webserver.mydomain.com ``` **パブリック DNS 名なしでシステムホスト名を変更するには** 1. + AL2 の場合: **hostnamectl** コマンドを使用して、目的のシステムホスト名 ( など) を反映するようにホスト名を設定します**webserver**。 ``` [ec2-user ~]$ sudo hostnamectl set-hostname webserver.localdomain ``` + Amazon Linux AMI の場合: インスタンスで、お好みのテキストエディタで `/etc/sysconfig/network` 設定ファイルを開き、`HOSTNAME` エントリを変更して、希望するシステムホスト名を反映させます (例: **webserver**)。 ``` HOSTNAME=webserver.localdomain ``` 1. お好みのテキストエディタで `/etc/hosts` ファイルを開き、下の例と一致する **127.0.0.1** で始まるエントリを変更します。ホスト名は自分のホスト名に置換します。 ``` 127.0.0.1 webserver.localdomain webserver localhost4 localhost4.localdomain4 ``` 1. インスタンスを再起動し、新しいホスト名を取得します。 ``` [ec2-user ~]$ sudo reboot ``` または、Amazon EC2 コンソールを使用して再起動することもできます (**[Instances (インスタンス)**] ページでインスタンスを選択し、[**Instance state (インスタンスの状態)**]、[**Reboot instance (インスタンスの再起動)**] の順に選択します)。 1. インスタンスにログインして、ホスト名が更新されていることを確認します。メッセージには、新しいホスト名が表示されるはずです (最初の「.」まで)。**hostname** コマンドで完全修飾ドメイン名が表示されます。 ``` [ec2-user@webserver ~]$ hostname webserver.localdomain ``` また、ユーザーデータを指定してインスタンスを設定するなど、よりプログラム的なソリューションを実装することもできます。インスタンスが Auto Scaling グループの一部である場合、ライフサイクルフックを使用してユーザーデータを定義できます。詳細については、「AWS CloudFormation ユーザーガイド」の「[Run commands on your Linux instance at launch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)」(起動時に Linux インスタンスでコマンドを実行する) および「[Lifecycle hook for instance launch](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-autoscaling-lifecyclehook.html#aws-resource-autoscaling-lifecyclehook--examples--Lifecycle_hook_for_instance_launch)」(インスタンス起動のライフサイクルフック) を参照してください。 ## ホスト名に影響を与えずにシェルプロンプトを変更する インスタンスのホスト名を変更せずに、 が提供するプライベート名 ( など**webserver**) よりも便利なシステム名 AWS ( など`ip-12-34-56-78`) を表示する場合は、シェルプロンプト設定ファイルを編集して、ホスト名の代わりにシステムニックネームを表示できます。 **シェルプロンプトをホストニックネームに変更するには** 1. `/etc/profile.d` で、`NICKNAME` と呼ばれる環境変数を設定するファイルを作成して、シェルプロンプトに表示する値を設定します。例えば、システムニックネームを **webserver** に設定するには、次のコマンドを実行します。 ``` [ec2-user ~]$ sudo sh -c 'echo "export NICKNAME=webserver" > /etc/profile.d/prompt.sh' ``` 1. お好みのテキストエディタ (`/etc/bashrc` や `/etc/bash.bashrc` など) で、**vim** (Red Hat) または **nano** (Debian/Ubuntu) ファイルを開きます。エディタのコマンドで **sudo** を使用する必要があります。`/etc/bashrc` および `/etc/bash.bashrc` は `root` が所有するためです。 1. ファイルを編集し、ホスト名の代わりにニックネームを表示するようにシェルプロンプト変数 (`PS1`) を変更します。`/etc/bashrc` または `/etc/bash.bashrc` でシェルプロンプトを設定する次の行を見つけます (以下には、コンテキストを示すため前後の行も表示されています。`[ "$PS1"` で始まる行を探してください)。 ``` # Turn on checkwinsize shopt -s checkwinsize [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@\h \W]\\$ " # You might want to have e.g. tty in prompt (e.g. more virtual machines) # and console windows ``` その行の `\h` (`hostname` を表す記号) を `NICKNAME` 変数の値に変更します。 ``` # Turn on checkwinsize shopt -s checkwinsize [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\u@$NICKNAME \W]\\$ " # You might want to have e.g. tty in prompt (e.g. more virtual machines) # and console windows ``` 1. (オプション) シェルウィンドウのタイトルを新しいニックネームに設定するには、次の手順を完了します。 1. `/etc/sysconfig/bash-prompt-xterm` という名前のファイルを作成します。 ``` [ec2-user ~]$ sudo touch /etc/sysconfig/bash-prompt-xterm ``` 1. 次のコマンドを使用して、ファイルを実行可能にします。 ``` [ec2-user ~]$ sudo chmod +x /etc/sysconfig/bash-prompt-xterm ``` 1. お好みのテキストエディタ (`/etc/sysconfig/bash-prompt-xterm` や **vim** など) で、**nano** ファイルを開きます。エディタのコマンドで **sudo** を使用する必要があります。`/etc/sysconfig/bash-prompt-xterm` は `root` が所有するためです。 1. 次の行をファイルに追加します。 ``` echo -ne "\033]0;${USER}@${NICKNAME}:${PWD/#$HOME/~}\007" ``` 1. ログアウトしてから再度ログインし、新しいニックネーム値を取得します。 ## 他の Linux ディストリビューションのホスト名の変更 このページの手順は、Amazon Linux のみで使用するためのものです。他の Linux ディストリビューションの詳細については、各ドキュメントおよび次の記事を参照してください。 + [RHEL 7 または Centos 7 を実行するプライベート Amazon EC2 インスタンスに静的ホスト名を割り当てる方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/linux-static-hostname-rhel7-centos7/) # AL2 インスタンスで動的 DNS を設定する EC2 インスタンスを起動すると、パブリック IP アドレスとパブリックドメインネームシステム (DNS) が割り当てられます。それらを使用してインターネットからインスタンスにアクセスできます。Amazon Web Services ドメインには数多くのホストが存在するため、これらのパブリック名はそれぞれの名前を一意にするために、かなり長くする必要があります。一般的な Amazon EC2 パブリック DNS 名は`ec2-12-34-56-78.us-west-2.compute.amazonaws.com`、Amazon Web Services ドメイン、サービス (この場合は `compute`)、 AWS リージョン、およびパブリック IP アドレスの形式で構成される のようになります。 動的 DNS サービスはそのドメイン領域内でカスタムの DNS ホスト名を提供します。この名前は覚えやすく、ホストのユースケースとの関連性が高くなっています。また、これらのサービスは一部は無料で提供されています。Amazon EC2 では動的 DNS プロバイダを利用できます。また、インスタンスを起動するたびに、パブリック DNS 名に関連付けられている IP アドレスを更新するようにインスタンスを設定できます。プロバイダは数多く存在します。また、プロバイダを選択し、それぞれのプロバイダで名前を登録する方法については本ガイドの範囲外です。 **Amazon EC2 で動的 DNS を使用するには** 1. 動的 DNS サービスプロバイダにサインアップし、そのサービスでパブリック DNS 名を登録します。この手順では、[noip.com/free](https://www.noip.com/free) の無料サービスを例として使用します。 1. 動的 DNS 更新クライアントを設定します。動的 DNS サービスプロバイダを選び、そのサービスでパブリック DNS 名を登録したら、その DNS 名をインスタンスの IP アドレスにポイントします。多くのプロバイダ ([noip.com](https://noip.com) を含む) では、この操作をウェブサイトのアカウントページから手動で実行できるようにしています。ただし、ソフトウェア更新クライアントもサポートしています。EC2 インスタンスで更新クライアントが動作している場合は、シャットダウン後に再起動したときに IP アドレスが変わるたびに動的 DNS レコードが更新されます。この例では、noip2 クライアントをインストールします。このクライアントは、[noip.com](https://noip.com)が提供するサービスで動作します。 1. Extra Packages for Enterprise Linux (EPEL) リポジトリを有効にして、`noip2`クライアントにアクセスします。 **注記** AL2 インスタンスには、EPEL リポジトリの GPG キーとリポジトリ情報がデフォルトでインストールされています。詳細、およびこのパッケージの最新バージョンをダウンロードするには、[https://fedoraproject.org/wiki/EPEL](https://fedoraproject.org/wiki/EPEL) を参照してください。 ``` [ec2-user ~]$ sudo amazon-linux-extras install epel -y ``` 1. `noip` パッケージをインストールします。 ``` [ec2-user ~]$ sudo yum install -y noip ``` 1. 設定ファイルを作成します。メッセージが表示されたら、ログインおよびパスワード情報を入力して、その後に続く質問に答え、クライアントを設定します。 ``` [ec2-user ~]$ sudo noip2 -C ``` 1. noip サービスを有効にします。 ``` [ec2-user ~]$ sudo systemctl enable noip.service ``` 1. noip サービスを開始します。 ``` [ec2-user ~]$ sudo systemctl start noip.service ``` このコマンドを使用すると、クライアントが起動します。クライアントは前に作成した設定ファイル (`/etc/no-ip2.conf`) を読み、選択したパブリック DNS 名の IP アドレスを更新します。 1. 更新クライアントが動的 DNS 名に正しい IP アドレスを設定したことを確認します。DNS レコードの更新には数分かかります。その後、この手順で設定したパブリック DNS 名により、SSH を使用してインスタンスに接続します。 # AL2 の ec2-net-utils を使用してネットワークインターフェイスを設定する Amazon Linux 2 AMIs には、ec2-net-utils と呼ばれる AWSによってインストールされた追加のスクリプトが含まれている場合があります。これらのスクリプトはオプションで、ネットワークインターフェイスの設定を自動化します。これらのスクリプトは AL2 でのみ使用できます。 **注記** Amazon Linux 2023 の場合、 `amazon-ec2-net-utils`パッケージは `/run/systemd/network` ディレクトリにインターフェイス固有の設定を生成します。詳細については、「 Amazon Linux 2023 ユーザーガイド」の「[ネットワーキングサービス](https://docs.aws.amazon.com/linux/al2023/ug/networking-service.html)」を参照してください。 まだインストールされていない場合は、次のコマンドを使用してパッケージを AL2 にインストールするか、インストール済みで追加の更新が利用可能な場合は更新します。 ``` $ yum install ec2-net-utils ``` ec2-net-utils には、以下のコンポーネントが含まれます。 udev ルール (`/etc/udev/rules.d`) 実行中のインスタンスにネットワークインターフェイスがアタッチ、デタッチ、または再アタッチされたときに、そのネットワークインターフェイスを特定し、ホットプラグスクリプトが実行されることを確認します (`53-ec2-network-interfaces.rules`)。MAC アドレスをデバイス名にマッピングします (`75-persistent-net-generator.rules` を生成する `70-persistent-net.rules`)。 ホットプラグスクリプト DHCP での使用に適したインターフェイス設定ファイルを生成します (`/etc/sysconfig/network-scripts/ifcfg-eth`*N*)。また、ルート設定ファイルも生成します (`/etc/sysconfig/network-scripts/route-eth`*N*)。 DHCP スクリプト ネットワークインターフェイスが新しい DHCP リースを受け取るたびに、このスクリプトがインスタンスメタデータに対し、Elastic IP アドレスを求めるクエリを実行します。これにより、各 Elastic IP アドレスごとに、そのアドレスからのアウトバンドトラフィックが正しいネットワークインターフェイスを使用するよう、ルーティングポリシーデータベースにルールが追加されます。また、各プライベート IP アドレスを、セカンダリアドレスとしてネットワークインターフェイスに追加します。 **ec2ifup** ethN (`/usr/sbin/`) 標準の **ifup** の機能を拡張します。このスクリプトが設定ファイル `ifcfg-eth`*N* および `route-eth`*N* を書き換えた後、**ifup** を実行します。 **ec2ifdown** ethN (`/usr/sbin/`) 標準の **ifdown** の機能を拡張します。このスクリプトがルーティングポリシーデータベースからネットワークインターフェイスのルールをすべて削除した後、**ifdown** を実行します。 **ec2ifscan** (`/usr/sbin/`) まだ設定されていないネットワークインターフェイスを探して、それらを設定します。 このスクリプトは、ec2-net-utils の初期リリースでは提供されていません。 ec2-net-utils によって生成された設定ファイルをリストするには、以下のコマンドを使用します。 ``` $ ls -l /etc/sysconfig/network-scripts/*-eth? ``` オートメーションを無効にするには、対応する `ifcfg-eth`*N* ファイルに `EC2SYNC=no` を追加します。例えば、eth1 インターフェイスの自動化を無効にするには、以下のコマンドを使用します。 ``` $ sed -i -e 's/^EC2SYNC=yes/EC2SYNC=no/' /etc/sysconfig/network-scripts/ifcfg-eth1 ``` オートメーションを完全に無効にするには、次のコマンドを使用してパッケージを削除できます。 ``` $ yum remove ec2-net-utils ``` # ユーザー提供カーネル Amazon EC2 インスタンスでカスタムカーネルが必要な場合は、必要としているものに近い AMI を使用して開始し、インスタンスでカスタムカーネルをコンパイルして、新しいカーネルを参照するようにブートローダーを更新します。このプロセスは AMI が使用する仮想化タイプによって異なります。詳細については、*Amazon EC2 ユーザーガイド*」の[「Linux AMI 仮想化タイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)」を参照してください。 **Topics** + [HVM AMIs (GRUB)](#HVM_instances) + [AMIs の準仮想化 (PV-GRUB)](#Paravirtual_instances) ## HVM AMIs (GRUB) HVM インスタンスボリュームは実際の物理ディスクのように扱われます。起動プロセスは、パーティション分割ディスクとブートローダーを備えるベアメタルオペレーティングシステムの起動プロセスに似ています。ブートローダーでは、現在サポートされているすべての Linux ディストリビューションを使用できます。最も一般的なブートローダーは GRUB または GRUB2 です。 起動が遅くなるため、デフォルトでは GRUB はインスタンスのコンソールに出力を送信しません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスコンソール出力](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshoot-unreachable-instance.html#instance-console-console-output)」を参照してください。カスタムカーネルをインストールする場合は、GRUB 出力を有効にすることを検討してください。 フォールバックカーネルを指定する必要はありません。ただし、新しいカーネルをテストする場合は、フォールバックを設定することをお勧めします。GRUB では、新しいカーネルにエラーがあった場合に別のカーネルにフォールバックできます。フォールバックカーネルを設定すると、新しいカーネルが見つからない場合でも、インスタンスを起動できます。 Amazon Linux 用のレガシー GRUB では `/boot/grub/menu.lst` を使用します。GRUB2 for AL2 は を使用します`/etc/default/grub`。ブートローダーでデフォルトカーネルを更新する方法の詳細については、ご使用の Linux ディストリビューションのドキュメントを参照してください。 ## AMIs の準仮想化 (PV-GRUB) 準仮想化 (PV) 仮想化を使用する AMIs、起動プロセス中に *PV-GRUB* と呼ばれるシステムを使用します。PV-GRUB は、パッチが適用されたバージョンの GNU GRUB 0.97 を実行する準仮想化ブートローダーです。インスタンスを起動すると、PV-GRUB では起動プロセスが開始され、お客様のイメージの `menu.lst` ファイルが指定するカーネルがチェーンロードされます。 PV-GRUB は標準の `grub.conf` または `menu.lst` コマンドを認識しますこれにより、現在サポートされているすべての Linux ディストリビューションとともに利用できます。Ubuntu 10.04 LTS、Oracle Enterprise Linux、CentOS 5.x など、古いディストリビューションでは特別な「ec2」や「xen」カーネルパッケージが必要です。新しいディストリビューションでは、デフォルトのカーネルパッケージに必要なドライバーが含まれています。 最新の準仮想 AMI では、デフォルトで PV-GRUB AKI を使用します (Amazon EC2 Launch Wizard Quick Start メニューで利用できるすべての準仮想 Linux AMI が含まれています)。そのため、使用するカーネルにディストリビューションとの互換性がある場合、インスタンスで別のカーネルを使用するために必要な追加の手順はありません。インスタンスでカスタムカーネルを実行する最適な方法としては、必要としているものに近い AMI を使用して開始し、インタンスでカスタムカーネルをコンパイルして、そのカーネルを使用して起動するように `menu.lst` ファイルを変更します。 AMI のカーネルイメージが PV-GRUB AKI であることを確認できます。次の [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) コマンドを実行して (ご使用のカーネルイメージ ID に置き換えます)、`Name` フィールドが `pv-grub` で始まっているかどうかを確認します。 ``` aws ec2 describe-images --filters Name=image-id,Values=aki-880531cd ``` **Topics** + [PV-GRUB の制約事項](#pv-grub-limitations) + [Configuring GRUB](#configuringGRUB) + [Amazon PV-GRUB カーネルイメージ ID](#AmazonKernelImageIDs) + [PV-GRUB の更新](#UpdatingPV-GRUB) ### PV-GRUB の制約事項 PV-GRUB には次の制約事項があります。 + PV-GRUB の 64 ビットバージョンを使用して 32 ビットカーネルを起動したり、PV-GRUB の 32 ビットバージョンを使用して 64 ビットカーネルを起動したりすることはできません。 + PV-GRUB AKI の使用時には、Amazon ラムディスクイメージ (ARI) を指定できません。 + AWS は、PV-GRUB が EXT2, EXT3, EXT4、XFS、ReiserFS のファイルシステム形式で動作することをテストおよび検証しました。その他のファイルシステム形式では動作しない場合があります。 + PV-GRUB は、gzip、bzip2、lzo、xz 圧縮形式を利用して圧縮されたカーネルを起動できます。 + Cluster AMI は PV-GRUB をサポートせず、また、必要としません。完全ハードウェア仮想化 (HVM) が使用されるためです。準仮想インスタンスは PV-GRUB を使用して起動します。一方、HVM インスタンスボリュームは実際のディスクのように扱われ、その起動プロセスはパーティション分割ディスクとブートローダーを備えるベアメタルオペレーティングシステムの起動プロセスに似ています。 + PV-GRUB バージョン 1.03 以前では、GPT パーティショニングをサポートしません。MBR パーティショニングがサポートされています。 + Amazon Elastic Block Store (Amazon EBS) で Logical Volume Manager (LVM) を使用する場合、LVM の外側に別の起動パーティションが必要です。その場合、LVM で論理ボリュームを作成できます。 ### 準仮想化 AMIs 向けの GRUB の設定 PV-GRUB を起動するには、GRUB `menu.lst` ファイルがイメージに含まれている必要があります。このファイルの最も一般的な場所は `/boot/grub/menu.lst` です。 次の例は、PV-GRUB AKI を使用して AMI を起動する `menu.lst` 設定ファイルです。この例では、Amazon Linux 2018.03 (この AMI の元のカーネル) と Vanilla Linux 4.16.4 ([https://www.kernel.org/](https://www.kernel.org/) の Vanilla Linux カーネルの新しいバージョン) の 2 つのカーネルエントリが選択できます。Vanilla エントリは、この AMI の元々のエントリからコピーされました。`kernel` と `initrd` パスは新しい場所に更新されました。`default 0` パラメータは、ブートローダーをそれが検出した最初のエントリ (この場合、Vanilla エントリ) にポイントします。`fallback 1` パラメータは、最初のエントリの起動に問題が発生した場合、次のエントリにブートローダーをポイントします。 ``` default 0 fallback 1 timeout 0 hiddenmenu title Vanilla Linux 4.16.4 root (hd0) kernel /boot/vmlinuz-4.16.4 root=LABEL=/ console=hvc0 initrd /boot/initrd.img-4.16.4 title Amazon Linux 2018.03 (4.14.26-46.32.amzn1.x86_64) root (hd0) kernel /boot/vmlinuz-4.14.26-46.32.amzn1.x86_64 root=LABEL=/ console=hvc0 initrd /boot/initramfs-4.14.26-46.32.amzn1.x86_64.img ``` `menu.lst` ファイルにフォールバックカーネルを指定する必要はありません。ただし、新しいカーネルをテストするときは、フォールバックを設定することをお勧めします。PV-GRUB では、新しいカーネルにエラーがあった場合に別のカーネルにフォールバックできます。フォールバックカーネルを設定すると、新しいカーネルが見つからない場合でもインスタンスを起動できます。 PV-GRUB は、次の場所で `menu.lst` をチェックします。その際、それが検出した最初の場所が利用されます。 + `(hd0)/boot/grub` + `(hd0,0)/boot/grub` + `(hd0,0)/grub` + `(hd0,1)/boot/grub` + `(hd0,1)/grub` + `(hd0,2)/boot/grub` + `(hd0,2)/grub` + `(hd0,3)/boot/grub` + `(hd0,3)/grub` PV-GRUB 1.03 以前では、このリストの最初の 2 つの場所うちの 1 つのみがチェックされることに注意してください。 ### Amazon PV-GRUB カーネルイメージ ID PV-GRUB AKI は、アジアパシフィック (大阪) を除くすべての Amazon EC2 リージョンで利用できます。32 ビットと 64 ビットの両方のアーキテクチャタイプに AKI があります。最新の AMI では、デフォルトで PV-GRUB AKI が使用されます。 すべてのバージョンの PV-GRUB AKI がすべてのインスタンスタイプと互換性があるとは限らないため、常に最新バージョンの PV-GRUB AKI を使用することをお勧めします。次の [describe-images](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-images.html) コマンドを使用し、現在のリージョンの PV-GRUB AKI のリストを取得します。 ``` aws ec2 describe-images --owners amazon --filters Name=name,Values=pv-grub-*.gz ``` PV-GRUB は、`ap-southeast-2` リージョンで利用できる唯一の AKI です。このリージョンにコピーする AMI が、このリージョンで利用できる PV-GRUB のバージョンを使用していることを確認してください。 各リージョンの現在の AKI ID は次のとおりです。新しい AMI は、hd0 AKI を使用して登録します。 **注記** hd00 AKI は、以前に利用可能であったリージョンでの下位互換性のために引き続き提供されます。 **ap-northeast-1、アジアパシフィック (東京)** | イメージ ID | イメージ名 | | --- | --- | | aki-f975a998 | pv-grub-hd0\$11.05-i386.gz | | aki-7077ab11 | pv-grub-hd0\$11.05-x86\$164.gz | **ap-southeast-1、アジアパシフィック (シンガポール) リージョン** | イメージ ID | イメージ名 | | --- | --- | | aki-17a40074 | pv-grub-hd0\$11.05-i386.gz | | aki-73a50110 | pv-grub-hd0\$11.05-x86\$164.gz | **ap-southeast-2、アジアパシフィック (シドニー)** | イメージ ID | イメージ名 | | --- | --- | | aki-ba5665d9 | pv-grub-hd0\$11.05-i386.gz | | aki-66506305 | pv-grub-hd0\$11.05-x86\$164.gz | **eu-central-1、欧州 (フランクフルト)** | イメージ ID | イメージ名 | | --- | --- | | aki-1419e57b | pv-grub-hd0\$11.05-i386.gz | | aki-931fe3fc | pv-grub-hd0\$11.05-x86\$164.gz | **eu-west-1、欧州 (アイルランド)** | イメージ ID | イメージ名 | | --- | --- | | aki-1c9fd86f | pv-grub-hd0\$11.05-i386.gz | | aki-dc9ed9af | pv-grub-hd0\$11.05-x86\$164.gz | **sa-east-1、南米 (サンパウロ)** | イメージ ID | イメージ名 | | --- | --- | | aki-7cd34110 | pv-grub-hd0\$11.05-i386.gz | | aki-912fbcfd | pv-grub-hd0\$11.05-x86\$164.gz | **us-east-1、US East (N. Virginia)** | イメージ ID | イメージ名 | | --- | --- | | aki-04206613 | pv-grub-hd0\$11.05-i386.gz | | aki-5c21674b | pv-grub-hd0\$11.05-x86\$164.gz | **us-gov-west-1、 AWS GovCloud (米国西部)** | イメージ ID | イメージ名 | | --- | --- | | aki-5ee9573f | pv-grub-hd0\$11.05-i386.gz | | aki-9ee55bff | pv-grub-hd0\$11.05-x86\$164.gz | **us-west-1、米国西部 (北カリフォルニア)** | イメージ ID | イメージ名 | | --- | --- | | aki-43cf8123 | pv-grub-hd0\$11.05-i386.gz | | aki-59cc8239 | pv-grub-hd0\$11.05-x86\$164.gz | **us-west-2、米国西部 (オレゴン)** | イメージ ID | イメージ名 | | --- | --- | | aki-7a69931a | pv-grub-hd0\$11.05-i386.gz | | aki-70cb0e10 | pv-grub-hd0\$11.05-x86\$164.gz | ### PV-GRUB の更新 すべてのバージョンの PV-GRUB AKI がすべてのインスタンスタイプと互換性があるとは限らないため、常に最新バージョンの PV-GRUB AKI を使用することをお勧めします。また、古いバージョンの PV-GRUB はすべてのリージョンで使用できるわけではないため、旧バージョンを使用する AMI を、そのバージョンをサポートしないリージョンにコピーした場合、カーネルのイメージを更新するまで、その AMI から起動されたインスタンスを起動できなくなります。次の手順を使用してインスタンスの PV-GRUB のバージョンを確認し、必要に応じて更新します。 **PV-GRUB のバージョンを確認するには** 1. インスタンスのカーネル ID を見つけます。 ``` aws ec2 describe-instance-attribute --instance-id instance_id --attribute kernel --region region { "InstanceId": "instance_id", "KernelId": "aki-70cb0e10" } ``` このインスタンスのカーネル ID は、`aki-70cb0e10` です。 1. このカーネル ID のバージョン情報を表示します。 ``` aws ec2 describe-images --image-ids aki-70cb0e10 --region region { "Images": [ { "VirtualizationType": "paravirtual", "Name": "pv-grub-hd0_1.05-x86_64.gz", ... "Description": "PV-GRUB release 1.05, 64-bit" } ] } ``` このカーネルイメージは PV-GRUB 1.05 です。PV-GRUB のバージョンが最新バージョン ([Amazon PV-GRUB カーネルイメージ ID](#AmazonKernelImageIDs) を参照) でない場合、次の手順を使用して更新する必要があります。 **PV-GRUB のバージョンを更新するには** インスタンスが古いバージョンの PV-GRUB を使用している場合は、最新バージョンに更新する必要があります。 1. [Amazon PV-GRUB カーネルイメージ ID](#AmazonKernelImageIDs) で、使用するリージョンとプロセッサアーキテクチャーの最新の PV-GRUB AKI を特定します。 1. インスタンスを停止します。使用されるカーネルイメージを変更するには、インスタンスを停止する必要があります。 ``` aws ec2 stop-instances --instance-ids instance_id --region region ``` 1. インスタンスに使用するカーネルイメージを変更します。 ``` aws ec2 modify-instance-attribute --instance-id instance_id --kernel kernel_id --region region ``` 1. インスタンスを再起動します。 ``` aws ec2 start-instances --instance-ids instance_id --region region ``` # AL2 AMI リリース通知 新しい Amazon Linux AMI がリリースされた場合に通知を受取るには、Amazon SNS を使用して申し込みできます。 AL2023 の通知のサブスクライブの詳細については、*「Amazon Linux 2023 ユーザーガイド*」の[「新しい更新に関する通知の受信](https://docs.aws.amazon.com/linux/al2023/ug/receive-update-notification.html)」を参照してください。 **注記** AL1 の標準サポートは 2020 年 12 月 31 日に終了しました。AL1 メンテナンスサポートフェーズは 2023 年 12 月 31 日に終了しました。AL1 EOL とメンテナンスサポートの詳細については、ブログ記事「Update [on Amazon Linux AMI end-of-life](https://aws.amazon.com/blogs/aws/update-on-amazon-linux-ami-end-of-life/)」を参照してください。 **Amazon Linux の通知をサブスクライブするには** 1. Amazon SNS コンソール（[https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)）を開きます。 1. ナビゲーションバーで、必要に応じて、リージョンを [**米国東部 (バージニア北部)**] に変更します。購読する SNS 通知が作成されたリージョンを選択する必要があります。 1. ナビゲーションペインで、[**Subscriptions**]、[**Create subscription**] の順に選択します。 1. [**サブスクリプションの作成**] ダイアログボックスで、次の操作を行います。 1. [AL2] **トピック ARN** の場合は、次の Amazon リソースネーム (ARN) をコピーして貼り付けます**arn:aws:sns:us-east-1:137112412989:amazon-linux-2-ami-updates**。 1. [Amazon Linux] [**トピックの ARN**] には、以下の Amazon リソースネーム (ARN) **arn:aws:sns:us-east-1:137112412989:amazon-linux-ami-updates** をコピーして貼り付けます。 1. [**Protocol**] で [**Email**] を選択します。 1. [**エンドポイント**] に、通知を受信するために使用できる E メールアドレスを入力します。 1. [**サブスクリプションを作成**] を選択します。 1. AWS 「通知 - サブスクリプションの確認」という件名の確認メールが届きます。メールを開いて [**Confirm subscription**] を選択して受信登録を完了します。 AMI がリリースされるごとに、対応するトピックの受信者に通知が送信されます。このような通知を停止するには、以下の手順を使用してサブスクリプション解除します。 **Amazon Linux の通知の受信登録を解除するには** 1. Amazon SNS コンソール（[https://console.aws.amazon.com/sns/v3/home](https://console.aws.amazon.com/sns/v3/home)）を開きます。 1. ナビゲーションバーで、必要に応じて、リージョンを [**米国東部 (バージニア北部)**] に変更します。SNS 通知が作成されたリージョンを使用する必要があります。 1. ナビゲーションペインで、[**サブスクリプション**] を選択し、サブスクリプションを選択したら、[**アクション**]、[**サブスクリプションの削除**] の順に選択します。 1. 確認を求めるメッセージが表示されたら、[**削除**] を選択します。 **Amazon Linux AMI の SNS メッセージ形式** SNS メッセージのスキーマは次のとおりです。 ``` { "description": "Validates output from AMI Release SNS message", "type": "object", "properties": { "v1": { "type": "object", "properties": { "ReleaseVersion": { "description": "Major release (ex. 2018.03)", "type": "string" }, "ImageVersion": { "description": "Full release (ex. 2018.03.0.20180412)", "type": "string" }, "ReleaseNotes": { "description": "Human-readable string with extra information", "type": "string" }, "Regions": { "type": "object", "description": "Each key will be a region name (ex. us-east-1)", "additionalProperties": { "type": "array", "items": { "type": "object", "properties": { "Name": { "description": "AMI Name (ex. amzn-ami-hvm-2018.03.0.20180412-x86_64-gp2)", "type": "string" }, "ImageId": { "description": "AMI Name (ex.ami-467ca739)", "type": "string" } }, "required": [ "Name", "ImageId" ] } } } }, "required": [ "ReleaseVersion", "ImageVersion", "ReleaseNotes", "Regions" ] } }, "required": [ "v1" ] } ``` # AL2 MATE デスクトップ接続を設定する [MATE デスクトップ環境](https://mate-desktop.org/)は、AMI にあらかじめインストールおよび設定されています。説明は次のとおりです。 "`.NET Core x.x, Mono x.xx, PowerShell x.x, and MATE DE pre-installed to run your .NET applications on Amazon Linux 2 with Long Term Support (LTS).`" 環境には、コマンドラインの使用を最小限に抑えて AL2 インスタンスを管理するための直感的なグラフィカルユーザーインターフェイスが用意されています。このインタフェースでは、アイコン、ウィンドウ、ツールバー、フォルダ、壁紙、デスクトップウィジェットなどのグラフィカルな表現が使用されています。一般的なタスクを実行するために、組み込みの GUI ベースのツールを使用することができます。例えば、ソフトウェアの追加と削除、更新プログラムの適用、ファイルの整理、プログラムの起動、システムの状態のモニタリングのためのツールが用意されています。 **重要** `xrdp` は、AMI にバンドルされているリモートデスクトップソフトウェアです。デフォルトでは、`xrdp` は、自己署名の TLS 証明書を使用してリモートデスクトップセッションを暗号化します。 AWS も`xrdp`メンテナンス担当者も、本番環境で自己署名証明書を使用することを推奨していません。代わりに、適切な認証局 (CA) から証明書を取得し、インスタンスにインストールします。TLS の設定については、`xrdp` wiki の「[TLS セキュリティレイヤー](https://github.com/neutrinolabs/xrdp/wiki/TLS-security-layer)」を参照してください。 **注記** xrdp の代わりに仮想ネットワークコンピューティング (VNC) サービスを使用する場合は、[「AL2Knowledge Center を実行する Amazon EC2 インスタンスに GUI をインストールする方法](https://repost.aws/knowledge-center/ec2-linux-2-install-gui) AWS 」の記事を参照してください。 ## 前提条件 このトピックに示すコマンドを実行するには、 AWS Command Line Interface (AWS CLI) または をインストールし AWS Tools for Windows PowerShell、 AWS プロファイルを設定する必要があります。 **オプション** 1. のインストール AWS CLI – 詳細については、「 *AWS Command Line Interface ユーザーガイド*[」の「 AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html)のインストール」および[「設定の基本](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html)」を参照してください。 1. Tools for Windows PowerShell のインストール — 詳細については、「*AWS Tools for PowerShell ユーザーガイド*」の「[AWS Tools for Windows PowerShellのインストール](https://docs.aws.amazon.com/powershell/latest/userguide/pstools-getting-set-up.html)」と「[共有認証情報](https://docs.aws.amazon.com/powershell/latest/userguide/shared-credentials-in-aws-powershell.html)」を参照してください。 **ヒント** を完全にインストールする代わりに AWS CLI、 から直接起動するブラウザベースの事前認証済みシェル[AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html)に を使用できます AWS マネジメントコンソール。[サポートされている AWS リージョン](https://docs.aws.amazon.com/cloudshell/latest/userguide/supported-aws-regions.html)をチェックして、作業しているリージョンで使用可能であることを確認します。 ## RDP 接続の設定 以下の手順に従って、ローカルマシンから MATE デスクトップ環境を実行している AL2 インスタンスへのリモートデスクトッププロトコル (RDP) 接続を設定します。 1. AMI 名に MATE を含む AL2 用 AMI の ID を取得するには、ローカルコマンドラインツールから [describe-images](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-images.html) コマンドを使用できます。コマンドラインツールをインストールしていない場合は、 AWS CloudShell セッションから直接次のクエリを実行できます。CloudShell からシェルセッションを起動する方法の詳細については、「[[Getting started with AWS CloudShel]](https://docs.aws.amazon.com/cloudshell/latest/userguide/getting-started.html)」( CloudShell の使用方法) を参照してください。Amazon EC2 コンソールでは、インスタンスを起動し、AMI 検索バーに `MATE` と入力すると、MATE が含まれている AMI を見つけることができます。MATE がプリインストールされた AL2 クイックスタートが検索結果に表示されます。 ``` aws ec2 describe-images --filters "Name=name,Values=amzn2*MATE*" --query "Images[*].[ImageId,Name,Description]" [ [ "ami-0123example0abc12", "amzn2-x86_64-MATEDE_DOTNET-2020.12.04", ".NET Core 5.0, Mono 6.12, PowerShell 7.1, and MATE DE pre-installed to run your .NET applications on Amazon Linux 2 with Long Term Support (LTS)." ], [ "ami-0456example0def34", "amzn2-x86_64-MATEDE_DOTNET-2020.04.14", "Amazon Linux 2 with .Net Core, PowerShell, Mono, and MATE Desktop Environment" ] ] ``` 用途に合った AMI を選択します。 1. 前のステップで特定した AMI を使用して EC2 インスタンスを起動します。ポート 3389 へのインバウンド TCP トラフィックを許可するようにセキュリティグループを設定します。セキュリティグループの設定の詳細については、「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。この設定により、RDP クライアントを使用してインスタンスに接続できます。 1. [SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) を使用してインスタンスに接続します。 1. インスタンス上のソフトウェアとカーネルを更新します。 ``` [ec2-user ~]$ sudo yum update ``` 更新が完了したら、インスタンスを再起動し、更新から最新のパッケージとライブラリが使用されていることを確認します。カーネルの更新は、再起動するまでロードされません。 ``` [ec2-user ~]$ sudo reboot ``` 1. インスタンスに再接続し、Linux のインスタンスで次のコマンドを実行して、`ec2-user` のパスワードを設定します。 ``` [ec2-user ~]$ sudo passwd ec2-user ``` 1. 証明書ファイルとキーをインストールする 証明書とキーがすでにある場合は、証明書とキーを以下のように `/etc/xrdp/` ディレクトリにコピーします。 + 証明書 - `/etc/xrdp/cert.pem` + キー — `/etc/xrdp/key.pem` 証明書とキーがない場合は、次のコマンドを使用して`/etc/xrdp`ディレクトリに証明書とキーを作成します。 ``` $ sudo openssl req -x509 -sha384 -newkey rsa:3072 -nodes -keyout /etc/xrdp/key.pem -out /etc/xrdp/cert.pem -days 365 ``` **注記** このコマンドは 365 日間有効な証明書を生成します。 1. インスタンスに接続するコンピュータで RDP クライアントを開きます (Microsoft Windows を実行するコンピュータのリモートデスクトップ接続など)。ユーザー名として「`ec2-user`」と入力し、前のステップで設定したパスワードを入力します。 **Amazon EC2 インスタンスで `xrdp` を無効にするには** Linux インスタンスで次のコマンドのいずれかを実行することにより、いつでも `xrdp` を無効にすることができます。次のコマンドは、X11 サーバーを使用して MATE を使用する能力に影響を及ぼすものではありません。 ``` [ec2-user ~]$ sudo systemctl disable xrdp ``` ``` [ec2-user ~]$ sudo systemctl stop xrdp ``` **Amazon EC2 インスタンスで `xrdp` を有効にするには** MATE デスクトップ環境を実行している AL2 インスタンスに接続`xrdp`できるように を再度有効にするには、Linux インスタンスで次のいずれかのコマンドを実行します。 ``` [ec2-user ~]$ sudo systemctl enable xrdp ``` ``` [ec2-user ~]$ sudo systemctl start xrdp ``` # AL2 チュートリアル 以下のチュートリアルでは、AL2 を実行する Amazon EC2 インスタンスを使用して一般的なタスクを実行する方法を示します。動画チュートリアルについては、[AWS の講習動画とラボ](https://www.aws.training/)を参照してください。 AL2023 の手順については、[「Amazon Linux 2023 ユーザーガイド」の「チュートリアル](https://docs.aws.amazon.com/linux/al2023/ug/tutorials-al2023.html)」を参照してください。 ** **Topics** + [チュートリアル: AL2 に LAMP サーバーをインストールする](ec2-lamp-amazon-linux-2.md) + [チュートリアル: AL2 で SSL/TLS を設定する](SSL-on-amazon-linux-2.md) + [チュートリアル: AL2 で WordPress ブログをホストする](hosting-wordpress.md) # チュートリアル: AL2 に LAMP サーバーをインストールする 次の手順は、PHP と [MariaDB](https://mariadb.org/about/) (MySQL のコミュニティ開発フォーク) をサポートする Apache ウェブサーバーを AL2 インスタンス (LAMP ウェブサーバーまたは LAMP スタックと呼ばれることもあります) にインストールするのに役立ちます。このサーバーを使用して静的ウェブサイトをホストしたり、データベースとの情報の読み取りと書き込みを行う動的な PHP アプリケーションをデプロイしたりできます。 **重要** Ubuntu や Red Hat Enterprise Linux などの別のディストリビューションに LAMP ウェブサーバーを設定しようとすると、このチュートリアルの通りにはなりません。AL2023 については、[AL2023 に LAMP サーバーをインストールする](https://docs.aws.amazon.com//linux/al2023/ug/ec2-lamp-amazon-linux-2023.html)」を参照してください。Ubuntu については、Ubuntu コミュニティドキュメントの [ApacheMySQLPHP](https://help.ubuntu.com/community/ApacheMySQLPHP) を参照してください。その他のディストリビューションについては、それぞれのドキュメントを参照してください。 **オプション: オートメーション を使用してこのチュートリアルを完了する** 以下のタスクの代わりに AWS Systems Manager Automation を使用してこのチュートリアルを完了するには、[AWS Docs-InstallALAMPServer-AL2 Automation ](https://console.aws.amazon.com/systems-manager/automation/execute/AWSDocs-InstallALAMPServer-AL2)ドキュメントを実行します。 **Topics** + [ステップ 1: LAMP サーバーを準備する](#prepare-lamp-server) + [ステップ 2: LAMP サーバーをテストする](#test-lamp-server) + [ステップ 3: データベースサーバーをセキュリティで保護する](#secure-mariadb-lamp-server) + [ステップ 4: (オプション) phpMyAdmin をインストールする](#install-phpmyadmin-lamp-server) + [トラブルシューティング](#lamp-troubleshooting) + [関連トピック](#lamp-more-info) ## ステップ 1: LAMP サーバーを準備する **前提条件** + このチュートリアルでは、インターネットからアクセスできるパブリック DNS 名を持つ AL2 を使用して新しいインスタンスを既に起動していることを前提としています。詳細については、*Amazon EC2 ユーザーガイド* の [インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) を参照してください。また、セキュリティグループを設定して、SSH (ポート 22)、HTTP (ポート 80)、HTTPS (ポート 443) 接続を有効にしている必要もあります。これらの前提条件の詳細については、*Amazon EC2 ユーザーガイド*」の[「セキュリティグループルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)」を参照してください。 + 次の手順では、AL2 で利用可能な最新の PHP バージョンをインストールします。現在は です`php8.2`。このチュートリアルで説明されている以外の PHP アプリケーションを使用する場合は、`php8.2` と互換性を確認する必要があります。 **LAMP サーバーを準備するには** 1. [インスタンスに接続します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)。 1. すべてのソフトウェアパッケージが最新の状態であることを確認するため、インスタンスでソフトウェアの更新を実行します。この処理には数分かかりますが、最新の更新とバグ修正を確実に適用することが重要です。 `-y` オプションを指定すると、確認メッセージを表示せずに更新をインストールします。インストール前に更新を検査する場合は、このオプションを省略できます。 ``` [ec2-user ~]$ sudo yum update -y ``` 1. `mariadb10.5` Amazon Linux Extras リポジトリをインストールして、MariaDB パッケージの最新バージョンを取得します。 ``` [ec2-user ~]$ sudo amazon-linux-extras install mariadb10.5 ``` `sudo: amazon-linux-extras: command not found` というエラーが表示された場合、インスタンスは Amazon Linux 2 AMI で起動されていません (おそらく、代わりに Amazon Linux AMI を使用しています)。次のコマンドを使用して、Amazon Linux のバージョンを表示できます。 ``` cat /etc/system-release ``` 1. `php8.2` Amazon Linux Extras リポジトリをインストールして、AL2 のPHPパッケージの最新バージョンを取得します。 ``` [ec2-user ~]$ sudo amazon-linux-extras install php8.2 ``` 1. これでインスタンスが最新状態になったので、Apache ウェブサーバー、MariaDB、および PHP ソフトウェアパッケージをインストールできます。yum インストールコマンドを使用すると、複数のソフトウェアパッケージと関連するすべての依存関係を同時にインストールできます。 ``` [ec2-user ~]$ sudo yum install -y httpd ``` 次のコマンドを使用して、これらのパッケージの現在のバージョンを表示できます。 ``` yum info package_name ``` 1. Apache ウェブサーバーを起動します。 ``` [ec2-user ~]$ sudo systemctl start httpd ``` 1. **systemctl** コマンドを使用して、システムがブートするたびに Apache ウェブサーバーが起動するように設定します。 ``` [ec2-user ~]$ sudo systemctl enable httpd ``` **httpd** が有効であることは、次のコマンドを実行して確認できます。 ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` 1. インバウンド HTTP (ポート 80) 接続をインスタンスに許可するセキュリティルールを追加していない場合には、このルールを追加します。デフォルトでは、起動時に [**launch-wizard-*N***] セキュリティグループがインスタンスに設定されます。このグループには SSH 接続を許可する単一のルールが含まれます。 1. Amazon EC2 コンソール ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)) を開きます。 1. [**インスタンス**] を選択し、該当するインスタンスを選択します。 1. [**セキュリティ**] タブで、インバウンドルールを表示します。次のルールが表示されます。 ``` Port range Protocol Source 22 tcp 0.0.0.0/0 ``` **警告** `0.0.0.0/0` を使用すると、すべての IPv4 アドレスからインスタンスへの、SSH によるアクセスが許可されます。これはテスト環境で短時間なら許容できますが、実稼働環境で行うのは安全ではありません。本番環境では、特定の IP アドレスまたは特定のアドレス範囲にのみ、インスタンスへのアクセスを限定します。 1. セキュリティグループのリンクを選択します。[「セキュリティグループにルールを追加する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」の手順を使用して、次の値を持つ新しいインバウンドセキュリティルールを追加します。 + [**Type**]: HTTP + [**Protocol**]: TCP + **[Port Range**]: 80 + [**Source**]: Custom 1. ウェブサーバーをテストします。ウェブブラウザで、インスタンスのパブリック DNS アドレス (またはパブリック IP アドレス) を入力します。`/var/www/html` にコンテンツがない場合、Apache テストページが表示されます。インスタンスのパブリック DNS は、Amazon EC2 コンソールを使用して取得できます ([**Public DNS**] 列を確認します。この列が表示されない場合は、[**Show/Hide Columns**] (歯車型のアイコン) をクリックして、[**Public DNS**] を選択します)。 インスタンスのセキュリティグループに、ポート 80 での HTTP ラフィックを許可するルールが含まれていることを確認します。詳細については、「[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」を参照してください。 **重要** Amazon Linux を使用していない場合は、それらの接続を許可するようにインスタンスのファイアウォールを設定する必要があるかもしれません。ファイアウォールの設定方法の詳細については、ディストリビューション用のドキュメントを参照してください。 ![\[サーバーのテストでは、Apache テストページが表示されます。\]](http://docs.aws.amazon.com/ja_jp/linux/al2/ug/images/apache_test_page_al2_2.4.png) Apache **httpd** は、Apache ドキュメントルートと呼ばれるディレクトリに維持されるファイルを提供します。Amazon Linux Apache ドキュメントルートは `/var/www/html` であり、デフォルトでは root によって所有されます。 `ec2-user` アカウントがこのディレクトリで複数のファイルを操作することを許可するには、ディレクトリの所有権とアクセス許可を変更する必要があります。このタスクを行うには、複数の方法があります。このチュートリアルでは、`ec2-user` を `apache` グループに追加し、`apache` ディレクトリの所有権を `/var/www` グループに付与し、グループへの書き込み権限を割り当てます。 **ファイルの許可を設定するには** 1. ユーザー (この場合は `ec2-user`) を `apache` グループに追加します。 ``` [ec2-user ~]$ sudo usermod -a -G apache ec2-user ``` 1. ログアウトし、再度ログインして新しいグループを選択し、メンバーシップを確認します。 1. ログアウトします (**exit** コマンドを使用するか、ターミナルウィンドウを閉じます)。 ``` [ec2-user ~]$ exit ``` 1. `apache` グループのメンバーシップを検証するには、インスタンスに再接続して次のコマンドを実行します。 ``` [ec2-user ~]$ groups ec2-user adm wheel apache systemd-journal ``` 1. `/var/www` とそのコンテンツのグループ所有権を `apache` グループに変更します。 ``` [ec2-user ~]$ sudo chown -R ec2-user:apache /var/www ``` 1. グループの書き込み許可を追加して、これからのサブディレクトにグループ ID を設定するには、`/var/www` とサブディレクトのディレクトリ許可を変更します。 ``` [ec2-user ~]$ sudo chmod 2775 /var/www && find /var/www -type d -exec sudo chmod 2775 {} \; ``` 1. グループ書き込み許可を追加するには、`/var/www` とサブディレクトリのファイル許可を再帰的に変更します。 ``` [ec2-user ~]$ find /var/www -type f -exec sudo chmod 0664 {} \; ``` ここで、`ec2-user` (および `apache` グループの将来のメンバー) は、Apache ドキュメントルートでファイルを追加、削除、編集できるようになります。したがって、静的ウェブサイトや PHP アプリケーションなどのコンテンツを追加できます。 **ウェブサーバーを保護するには (オプション)** HTTP プロトコルを実行するウェブサーバーは、送受信したデータのトランスポートセキュリティを提供しません。ウェブブラウザを使用して HTTP サーバーに接続すると、閲覧した URL、受信したウェブページのコンテンツ、送信した HTML フォームの内容 (パスワードなど) はすべて、ネットワーク経路上のだれでも傍受できるようになります。ウェブサーバーを保護するためのベストプラクティスとして、SSL/TLS 暗号化でデータを保護する HTTPS (HTTP Secure) のサポートをインストールしてください。 サーバーで HTTPS を有効にする方法については、「[チュートリアル: AL2 で SSL/TLS を設定する](SSL-on-amazon-linux-2.md)」を参照してください。 ## ステップ 2: LAMP サーバーをテストする サーバーがインストールおよび実行されており、ファイルのアクセス許可が正しく設定されている場合、`ec2-user` アカウントは、インターネットから使用できる `/var/www/html` ディレクトリに PHP ファイルを作成できます。 **LAMP サーバーをテストするには** 1. Apache ドキュメントルートで PHP ファイルを作成します。 ``` [ec2-user ~]$ echo "" > /var/www/html/phpinfo.php ``` このコマンドを実行しようとしたときに「許可が拒否されました」というエラーが表示された場合は、ログアウトし、再度ログインして、[ファイルの許可を設定するには](#setting-file-permissions-2) で設定した正しいグループ許可を取得します。 1. ウェブブラウザで、作成したファイルの URL を入力します。この URL は、インスタンスのパブリック DNS アドレスにスラッシュとファイル名を追加したものです。次に例を示します。 ``` http://my.public.dns.amazonaws.com/phpinfo.php ``` PHP 情報ページが表示されるはずです。 ![\[LAMP サーバーのテストでは、PHP 情報ページが表示されます。\]](http://docs.aws.amazon.com/ja_jp/linux/al2/ug/images/phpinfo7.2.10.png) このページが表示されない場合は、前のステップで `/var/www/html/phpinfo.php` ファイルが正しく作成されたことを確認します。次のコマンドで、必要なパッケージがすべてインストールされたことを確認することもできます。 ``` [ec2-user ~]$ sudo yum list installed httpd mariadb-server php-mysqlnd ``` 必要なパッケージのいずれかが出力に表示されていない場合は、**sudo yum install *package*** コマンドを使ってインストールします。また、`php7.2` と `lamp-mariadb10.2-php7.2` のエキストラが **amazon-linux-extras** のコマンド出力で有効になっていることを確認してください。 1. `phpinfo.php` ファイルを削除します。これは有用な情報であることもありますが、セキュリティ上の理由から、インターネット上で公表しないでください。 ``` [ec2-user ~]$ rm /var/www/html/phpinfo.php ``` これで、完全に機能する LAMP ウェブサーバーを設定しました。`/var/www/html` の Apache ドキュメントルートにコンテンツを追加する場合、そのコンテンツはインスタンスのパブリック DNS アドレスで表示できます。 ## ステップ 3: データベースサーバーをセキュリティで保護する MariaDB サーバーのデフォルトのインストールには、テストおよび開発に役立ついくつかの機能がありますが、実稼働サーバーでは無効にするか削除する必要があります。**mysql\$1secure\$1installation** コマンドを使用すると、ルートパスワードを設定し、安全でない機能をインストールから削除する手順が案内されます。MariaDB サーバーを使用する予定がない場合でも、この手順を実行することが推奨されます。 **MariaDB サーバーをセキュリティで保護するには** 1. MariaDB サーバーを起動します。 ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. **mysql\$1secure\$1installation** を実行します。 ``` [ec2-user ~]$ sudo mysql_secure_installation ``` 1. プロンプトが表示されたら、ルートアカウントのパスワードを入力します。 1. 現在のルートパスワードを入力します。デフォルトでは、ルートアカウントにはパスワードが設定されていません。Enter キーを押します。 1. 「**Y**」と入力してパスワードを設定し、安全なパスワードを 2 回入力します。安全なパスワード作成の詳細については、「[https://identitysafe.norton.com/password-generator/](https://identitysafe.norton.com/password-generator/)」を参照してください。このパスワードは必ず安全な場所に保管します。 MariaDB のルートパスワードの設定は、データベースを保護するための最も基本的な手段にすぎません。データベース駆動型アプリケーションを構築またはインストールする必要がある場合、通常はそのアプリケーションのデータベースサービスユーザーを作成します。ルートアカウントは、データベース管理以外には使用しないでください。 1. 「**Y**」と入力して匿名ユーザーアカウントを削除します。 1. 「**Y**」と入力してリモートルートログインを無効にします。 1. 「**Y**」と入力してテストデータベースを削除します。 1. 「**Y**」と入力して権限テーブルを再ロードし、変更を保存します。 1. (オプション) MariaDB サーバーをすぐに使用する予定がない場合は、これを停止します。再び必要になったときには再起動できます。 ``` [ec2-user ~]$ sudo systemctl stop mariadb ``` 1. (オプション) ブート時に毎回 MariaDB サーバーを起動させる場合は、次のコマンドを入力します。 ``` [ec2-user ~]$ sudo systemctl enable mariadb ``` ## ステップ 4: (オプション) phpMyAdmin をインストールする [phpMyAdmin](https://www.phpmyadmin.net/) は、EC2 インスタンスで MySQL データベースを表示して編集するために使用できる、ウェブベースのデータベース管理ツールです。Amazon Linux インスタンスで `phpMyAdmin` をインストールして設定するには、以下の手順に従ってください。 **重要** Apache で SSL/TLS を有効にしていない場合、LAMP サーバーへのアクセスに `phpMyAdmin` を使用することは推奨されません。そのようにすると、データベース管理者のパスワードや他のデータは、インターネット上を安全ではない状態で送信されます。開発者によるセキュリティ関連の推奨事項については、「[Securing your phpMyAdmin installation](https://docs.phpmyadmin.net/en/latest/setup.html#securing-your-phpmyadmin-installation)」を参照してください。EC2 インスタンスでのウェブサーバーの保護に関する一般的な情報については、「[チュートリアル: AL2 で SSL/TLS を設定する](SSL-on-amazon-linux-2.md)」を参照してください。 **pMyAdmin をインストールするには** 1. 必要な依存ファイルをインストールします。 ``` [ec2-user ~]$ sudo yum install php-mbstring php-xml -y ``` 1. Apache を再起動します。 ``` [ec2-user ~]$ sudo systemctl restart httpd ``` 1. `php-fpm` を再起動します。 ``` [ec2-user ~]$ sudo systemctl restart php-fpm ``` 1. `/var/www/html` で Apache ドキュメントルートに移動します。 ``` [ec2-user ~]$ cd /var/www/html ``` 1. [https://www.phpmyadmin.net/downloads](https://www.phpmyadmin.net/downloads) で最新の phpMyAdmin リリース用のソースパッケージを選択します。ファイルディレクトリをインスタンスにダウンロードするには、次の例のようにリンクをコピーして **wget** コマンドに貼り付けます。 ``` [ec2-user html]$ wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz ``` 1. `phpMyAdmin` フォルダを作成し、次のコマンドでパッケージを展開します。 ``` [ec2-user html]$ mkdir phpMyAdmin && tar -xvzf phpMyAdmin-latest-all-languages.tar.gz -C phpMyAdmin --strip-components 1 ``` 1. *phpMyAdmin-latest-all-languages.tar.gz* Tarball を削除します。 ``` [ec2-user html]$ rm phpMyAdmin-latest-all-languages.tar.gz ``` 1. (オプション) MySQL サーバーが実行中ではない場合は、今すぐ起動します。 ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. ウェブブラウザで、phpMyAdmin のインストール URL を入力します。この URL は、インスタンスのパブリック DNS アドレス (または、パブリック IP アドレス) にスラッシュとインストールディレクトリを追加してものです。次に例を示します。 ``` http://my.public.dns.amazonaws.com/phpMyAdmin ``` phpMyAdmin ログインページが表示されます。 ![\[phpMyAdmin インストールの URL を入力すると、phpMyAdmin ログイン画面が表示されます。\]](http://docs.aws.amazon.com/ja_jp/linux/al2/ug/images/phpmyadmin_login.png) 1. 前に作成した `root` ユーザー名と MySQL のルートパスワードを使って、phpMyAdmin インストールにログインします。 インストールは、サービス開始前に設定する必要があります。次の手順に従って、設定ファイルを手動で作成することから始めるのをお勧めします。 1. 最小の設定ファイルから開始するには、お気に入りのテキストエディタを使用して新しいファイルを作成し、`config.sample.inc.php` の内容をそのファイルにコピーします。 1. `index.php` を含む phpMyAdmin ディレクトリに、ファイルを `config.inc.php` として保存します。 1. 追加のセットアップについては、phpMyAdmin のインストール手順の「[セットアップスクリプトの使用](https://docs.phpmyadmin.net/en/latest/setup.html#using-the-setup-script)」セクションにある「ファイル作成後の手順」を参照してください。 phpMyAdmin の使用に関する情報は、「[phpMyAdmin ユーザーガイド](http://docs.phpmyadmin.net/en/latest/user.html)」を参照してください。 ## トラブルシューティング このセクションでは、新しい LAMP サーバーの設定時に発生する可能性がある一般的な問題の解決案を提供します。 ### ウェブブラウザを使用してサーバーに接続できません。 以下のチェックを行って、Apache ウェブサーバーが実行されていて、アクセス可能であるかどうかを確認します。 + **ウェブサーバーが実行されていますか?** **httpd** が有効であることは、次のコマンドを実行して確認できます。 ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` **httpd** プロセスが実行されていない場合は、[LAMP サーバーを準備するには](#install_apache-2) に記載されているステップを繰り返します。 + **ファイアウォールは正しく設定されていますか?** インスタンスのセキュリティグループに、ポート 80 での HTTP ラフィックを許可するルールが含まれていることを確認します。詳細については、「[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」を参照してください。 ### HTTPS を使用してサーバーに接続できない 以下のチェックを行って、Apache ウェブサーバーが HTTPS をサポートするように設定されているかどうかを確認します。 + **ウェブサーバは正しく設定されていますか?** Apache をインストールすると、サーバーは HTTP トラフィック用に設定されます。HTTPS をサポートするには、サーバーで TLS を有効にし、SSL 証明書をインストールします。詳細については、「[チュートリアル: AL2 で SSL/TLS を設定する](SSL-on-amazon-linux-2.md)」を参照してください。 + **ファイアウォールは正しく設定されていますか?** インスタンスのセキュリティグループに、ポート 443 で HTTPS トラフィックを許可するルールが含まれていることを確認します。詳細については、[「セキュリティグループにルールを追加する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」を参照してください。 ## 関連トピック インスタンスへのファイルの転送、またはウェブサーバーへの WordPress ブログのインストールの詳細については、次のドキュメントを参照してください。 + [を使用して Linux インスタンスにファイルを転送するWinSCP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#Transfer_WinSCP)。 + [SCP クライアントを使用して Linux インスタンスにファイルを転送する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html#linux-file-transfer-scp)。 + [チュートリアル: AL2 で WordPress ブログをホストする](hosting-wordpress.md) このチュートリアルで使用されているコマンドおよびソフトウェアの詳細については、次のウェブページを参照してください。 + Apache ウェブサーバー: [http://httpd.apache.org/](http://httpd.apache.org/) + MariaDB データベースサーバー: [https://mariadb.org/](https://mariadb.org/) + PHP プログラミング言語: [http://php.net/](http://php.net/) + `chmod` コマンド: [https://en.wikipedia.org/wiki/Chmod](https://en.wikipedia.org/wiki/Chmod) + `chown` コマンド: [https://en.wikipedia.org/wiki/Chown](https://en.wikipedia.org/wiki/Chown) ウェブサーバーのドメイン名の登録、または、既存のドメイン名をこのホストに移す方法についての詳細は、『*Amazon Route 53 デベロッパーガイド*』の「[Amazon Route 53 のドメインとサブドメインの作成と移行](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/creating-migrating.html)」を参照してください。 # チュートリアル: AL2 で SSL/TLS を設定する Secure Sockets Layer/Transport Layer Security (SSL/TLS) は、ウェブサーバーとウェブクライアントの間に、転送中のデータが傍受されないように保護する、暗号化されたチャネルを確立します。このチュートリアルでは、AL2 および Apache ウェブサーバーを使用する EC2 インスタンスで SSL/TLS のサポートを手動で追加する方法について説明します。このチュートリアルでは、ロードバランサーを使用していないことを前提としています。Elastic Load Balancing を使用している場合は、代わりに [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) の証明書を使用して、ロードバランサーで SSL オフロードを設定できます。 歴史的経緯から、ウェブの暗号化は、単純に SSL と呼ばれることが少なくありません。ウェブブラウザでは今でも SSL がサポートされていますが、後継プロトコルである TLS プロトコルの方が攻撃を受けにくくなります。AL2 は、デフォルトですべてのバージョンの SSL のサーバー側のサポートを無効にします。[セキュリティ標準化団体](https://www.ssl.com/article/deprecating-early-tls/)は、TLS 1.0 は安全でないとみなしています。TLS 1.0 および TLS 1.1 は、2021 年 3 月に正式に[非推奨になりました](https://datatracker.ietf.org/doc/rfc8996/)。このチュートリアルは、TLS 1.2 を有効にすることを前提としたガイダンスです。TLS 1.3 は 2018 年に最終化され、基盤となる TLS ライブラリ (このチュートリアルでは OpenSSL) がサポートされているため、有効に設定されている限り、AL2 で利用できます。[クライアントは 2023 年 6 月 28 日までに TLS 1.2 以降をサポートしている必要があります](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/)。最新の暗号化基準の詳細については、「[RFC 7568](https://tools.ietf.org/html/rfc7568)」および「[RFC 8446](https://tools.ietf.org/html/rfc8446)」を参照してください。 このチュートリアルでは、現代のウェブ暗号化を単に TLS と呼びます。 **重要** これらの手順は、AL2 での使用を目的としています。また、新しい Amazon EC2 インスタンスを使用して開始するものと仮定します。別のディストリビューションを実行している EC2 インスタンス、または古いバージョンの AL2 を実行しているインスタンスを設定しようとすると、このチュートリアルの一部の手順が機能しない場合があります。Ubuntu については、[Ubuntu 上の OpenSSL](https://help.ubuntu.com/community/OpenSSL) に関するコミュニティドキュメントを参照してください。Red Hat Enterprise Linux については、以下を参照してください。[Apache HTTP Web サーバーの設定](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/setting-apache-http-server_deploying-different-types-of-servers)。その他のディストリビューションについては、それぞれのドキュメントを参照してください。 **注記** または、 AWS Nitro Enclaves に AWS Certificate Manager (ACM) を使用することもできます。これは、 AWS Nitro Enclaves で Amazon EC2 インスタンスで実行されているウェブアプリケーションとサーバーでパブリックおよびプライベートの SSL/TLS 証明書を使用できるようにするエンクレーブアプリケーションです。Nitro Enclavesは、SSL/TLS 証明書やプライベートキーなどの機密性の高いデータを保護し、安全に処理するために、分離されたコンピューティング環境を作成できる Amazon EC2 の機能です。 Nitro Enclaves 向け ACM では、Amazon EC2 Linux インスタンスで実行する **nginx** を使用することで、プライベートキーの作成、証明書とプライベートキーの配布、および証明書の更新を実行します。 Nitro Enclaves 向け ACM を使用するには、エンクレーブ対応の Linux インスタンスを使用する必要があります。 詳細については、[AWS 「Nitro Enclaves とは」を参照してください。](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html) [AWS Certificate Manager Nitro Enclaves ユーザーガイド](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave-refapp.html)*AWS の Nitro Enclaves* 用 および 。 **Topics** + [前提条件](#ssl_prereq) + [ステップ 1: サーバーで TLS を有効にする](#ssl_enable) + [ステップ 2: CA 署名証明書を取得する](#ssl_certificate) + [ステップ 3: セキュリティ設定をテストして強化する](#ssl_test) + [トラブルシューティング](#troubleshooting) ## 前提条件 このチュートリアルを開始する前に、次のステップを完了してください。 + Amazon EBS ベースの AL2 インスタンスを起動します。詳細については、*Amazon EC2 ユーザーガイド* の [インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) を参照してください。 + インスタンスが以下の TCP ポートで接続を受け付けるようにセキュリティグループを設定します。 + SSH (ポート 22) + HTTP (ポート 80) + HTTPS (ポート 443) 詳細については、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループのルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)」を参照してください。 + Apache ウェブサーバーをインストールします。step-by-stepの手順については、[「チュートリアル: AL2 に LAMP ウェブサーバーをインストールする](ec2-lamp-amazon-linux-2.md)」を参照してください。必要なのは httpd パッケージおよび対応する従属コンポーネントのみです。PHP および MariaDB に関連する手順は無視してかまいません。 + ウェブサイトの識別と認証を行うため、TLS の公開鍵基盤 (PKI) ではドメインネームシステム (DNS) を使用します。EC2 インスタンスを使用してパブリックウェブサイトをホストするには、ウェブサーバーのドメイン名を登録するか、既存のドメイン名を Amazon EC2 ホストに移す必要があります。これについては、ドメイン登録および DNS ホスティングに関するサードパーティのサービスが多数存在します。[Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) を使用することもできます。 ## ステップ 1: サーバーで TLS を有効にする **オプション: オートメーション を使用してこのチュートリアルを完了する** 以下のタスクの代わりに AWS Systems Manager 自動化を使用してこのチュートリアルを完了するには、[自動化ドキュメント](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-Configure-SSL-TLS-AL2/)を実行します。 この手順では、自己署名デジタル証明書を使用して AL2 で TLS を設定するプロセスについて説明します。 **注記** 自己署名証明書はテスト用であり、本稼働環境では使用できません。インターネットに自己署名証明書を公開すると、サイトへの訪問者にセキュリティ警告が表示されます。 **サーバーで TLS を有効にするには** 1. [インスタンスに接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)し、Apache が実行されていることを確認します。 ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` 返される値が「enabled」でない場合、Apache を起動し、システムブート時に毎回起動されるように設定します。 ``` [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd ``` 1. すべてのソフトウェアパッケージが最新の状態であることを確認するため、インスタンスでソフトウェアの更新を実行します。この処理には数分かかりますが、最新の更新とバグ修正を確実に適用することが重要です。 **注記** `-y` オプションを指定すると、確認メッセージを表示せずに更新をインストールします。インストール前に更新を検査する場合は、このオプションを省略できます。 ``` [ec2-user ~]$ sudo yum update -y ``` 1. これでインスタンスが最新状態になったため、Apache モジュール `mod_ssl` をインストールして TLS サポートを追加します。 ``` [ec2-user ~]$ sudo yum install -y mod_ssl ``` 次のファイルがインスタンスに作成されました。このファイルは、セキュアサーバーの設定とテスト用の証明書の作成に使用します。 + `/etc/httpd/conf.d/ssl.conf` mod\$1ssl の設定ファイル。このファイルには、暗号化キーと証明書の場所、許可する TLS プロトコル、受け入れる暗号化アルゴリズムを Apache に指示する*ディレクティブ*が含まれています。 + `/etc/pki/tls/certs/make-dummy-cert` サーバーホスト用の自己署名 X.509 証明書とプライベートキーを生成するためのスクリプト。この証明書は、TLS を使用するように Apache が正しくセットアップされているかどうかをテストする場合に役立ちます。アイデンティティは証明されないため、本稼働環境では使用しないでください。本稼働環境で使用すると、ウェブブラウザで警告が表示されます。 1. テスト用に自己署名のダミー証明書とキーを生成するためのスクリプトを実行します。 ``` [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt ``` `/etc/pki/tls/certs/` ディレクトリに新しいファイル `localhost.crt` が生成されます。指定されたファイル名は、**SSLCertificateFile** の `/etc/httpd/conf.d/ssl.conf` ディレクティブで割り当てたデフォルトの名前と一致します。 このファイルには、自己署名証明書と証明書のプライベートキーのいずれも含まれます。Apache では、証明書とキーを PEM 形式にする必要があります。これは、次の短縮化された例のように、"BEGIN" 行と "END" 行で囲まれた Base64 エンコードの ASCII 文字で構成されます。 ``` -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE----- ``` ファイル名および拡張子は利便性のためであり、機能には影響しません。例えば、`cert.crt` または `cert.pem` などのファイル名で証明書を呼び出すことができます。ただし、`ssl.conf` ファイルの関連ディレクティブが同じ名前を使用している場合に限ります。 **注記** デフォルトの TLS ファイルを独自にカスタマイズしたファイルに置き換える場合は、PEM 形式であることを確認してください。 1. ルートユーザーとしてお好みのテキストエディタ (**vim**、**nano**など) を使用して `/etc/httpd/conf.d/ssl.conf` ファイルを開き、次の行をコメントアウトします。ダミーの自己署名証明書にも同じキーが含まれているためです。次のステップに進む前にこの行をコメントアウトしないと、Apache サービスは起動に失敗します。 ``` SSLCertificateKeyFile /etc/pki/tls/private/localhost.key ``` 1. Apache を再起動します。 ``` [ec2-user ~]$ sudo systemctl restart httpd ``` **注記** 前述のとおり、TCP 443 番ポートが EC2 インスタンスでアクセス可能であることを確認してください。 1. Apache ウェブサーバーではポート 443 経由で HTTPS (セキュア HTTP) がサポートされるようになっています。これをテストするには、ブラウザの URL バーに、**https://** というプレフィックスを指定して、EC2 インスタンスの IP アドレスまたは完全修飾ドメイン名を入力します。 信頼されていない自己署名ホスト証明書を使用してサイトに接続しようとしているため、ブラウザには一連のセキュリティ警告が表示されることがあります。これの警告を無視し、サイトに進みます。 サーバーで TLS を正しく設定できていれば、Apache のデフォルトのテストページが開きます。これで、ブラウザとサーバーの間でやり取りされるすべてのデータが暗号化されるようになります。 **注記** サイト訪問者に対して警告画面が表示されないようにするには、暗号化だけではなく、サイト所有者のパブリック認証を行うための信頼された CA 署名証明書を取得する必要があります。 ## ステップ 2: CA 署名証明書を取得する CA 署名証明書を取得するには、次の手順に従います。 + プライベートキーから証明書署名リクエスト (CSR) を作成します。 + 作成した CSR を認証機関 (CA) に送信します。 + 署名付きホスト証明書を入手する + 証明書を使用するように Apache を設定します 自己署名 TLS X.509 ホスト証明書は、暗号化技術上は CA 署名証明書と同じです。これらの相違は数学的なものではなく、社会的なものです。CA では、最低でもドメイン所有権を検証してから申請者に証明書を発行することを保証しています。そのため、各ウェブブラウザには、ブラウザベンダーが信頼する CA のリストが含まれています。X.509 証明書は主に、プライベートサーバーキーに対応するパブリックキーと、このパブリックキーに暗号で関連付けられている CA による署名で構成されています。HTTPS 経由でブラウザがウェブサーバーに接続すると、サーバーは、信頼された CA のリストをブラウザが確認できるように、証明書を提示します。Signerがリストに含まれている場合や、他の信頼された署名者の*信頼チェーン*を通じてアクセス可能である場合、ブラウザはサーバーと、高速暗号化データチャネルのネゴシエーションを行い、ページをロードします。 証明書には、リクエストの確認作業が必要であり、一般的に費用がかかるため、各社を比較することをお勧めします。いくつかの CA では、基本レベル証明書が無料で提供されます。これらの CA で最も注目すべきは [Let's Encrypt](https://letsencrypt.org/) プロジェクトです。このプロジェクトでは、証明書の作成および更新プロセスの自動化もサポートしています。Let's Encrypt 証明書の使用の詳細については、「[Certbot の取得](https://eff-certbot.readthedocs.io/en/stable/install.html)」を参照してください。 商業グレードのサービスを提供する予定がある場合は、[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は良い選択肢です。 ホスト証明書の基盤にはキーがあります。2019 年時点で、[政府](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)および[業界グループ](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf)は、2030 年まで、ドキュメントを保護するための RSA キーに 2048 ビットの最小キー (モジュロ) サイズを使用することを推奨しています。AL2 で OpenSSL によって生成されるデフォルトのモジュラスサイズは 2048 ビットで、CA 署名証明書での使用に適しています。次の手順では、モジュラスサイズを大きくする、別の暗号化アルゴリズムを使用するなど、キーのカスタマイズが必要な場合のオプションのステップを提供しています。 **重要** CA 署名ホスト証明書を取得するための手順は、登録およびホスト済みの DNS ドメインを所有している場合を除き、使用しません。 **CA 署名証明書を取得するには** 1. [インスタンスに接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)して、/etc/pki/tls/private/ に移動します。サーバーの TLS 用プライベートキーは、このディレクトリに格納されます。既存のホストキーを使用して CSR を生成する場合は、ステップ 3 に進みます。 1. (オプション) 新しいプライベートキーを生成します。キー設定のいくつかのサンプルを次に示します。生成されたキーのどれもウェブサーバーで機能しますが、実装されるセキュリティの強度とタイプはそれぞれ異なります。 + **例 1:** デフォルトの RSA ホストキーを作成します。結果として生成されるファイル **custom.key** が、2048 ビットの RSA プライベートキーです。 ``` [ec2-user ~]$ sudo openssl genrsa -out custom.key ``` + **例 2:** これより大きなモジュラサイズを使用して、より強力な RSA キーを作成します。結果として生成されるファイル **custom.key** が、4096 ビットの RSA プライベートキーです。 ``` [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096 ``` + **例 3:** パスワードで保護された 4096 ビット暗号化 RSA キーを作成します。結果のファイル、**custom.key** は、AES-128 暗号で暗号化された 4096 ビットの RSA プライベートキーです。 **重要** キーを暗号化するとセキュリティを強化できますが、暗号化キーにはパスワードが必要であるため、暗号化に依存するサービスを自動的に開始することはできません。このキーを使用するたびに、SSH 接続でパスワード (前述の例では、"abcde12345") を指定する必要があります。 ``` [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096 ``` + **例 4:** 非 RSA 暗号を使用してキーを作成します。RSA 暗号化は、2 つの大きな素数の積に基づくパブリックキーのサイズのために、比較的遅くなる可能性があります。ただし、非 RSA 暗号化方式を使用する TLS 用のキーを作成することも可能です。同等レベルのセキュリティを提供する場合は、楕円曲線の計算に基づいたキーのほうが小さく計算処理も高速です。 ``` [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey ``` 結果は、prime256v1 (OpenSSL でサポートされる "名前付き曲線") を使用した 256 ビットの楕円曲線プライベートキーです。暗号化強度は ([NIST](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) によると) 2048 ビットの RSA キーよりやや優れています。 **注記** すべての CA で、楕円曲線ベースのキーに対して RSA キーと同じレベルのサポートが提供されているわけではありません。 新しいプライベートキーには、制限の厳しい所有権とアクセス権を設定します (所有者 = root、グループ = root、所有者のみの読み取り/書き込み)。コマンドは次の例のようになります。 ``` [ec2-user ~]$ sudo chown root:root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key ``` 上記のコマンドにより、次のような結果が得られます。 ``` -rw------- root root custom.key ``` 適切なキーを作成し、設定できたら、CSR を作成できます。 1. 好みのキーを使用して CSR を作成します。次の例では **custom.key** を使用しています。 ``` [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem ``` OpenSSL によりダイアログが開かれ、次の表に示されている情報の入力が求められます。基本的なドメイン検証済みホスト証明書については、[**共通名**] 以外のフィールドはすべてオプションです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/linux/al2/ug/SSL-on-amazon-linux-2.html) 最後に、OpenSSL により、オプションのチャレンジパスワードが求められます。このパスワードは CSR と、ユーザーと CA の間のトランザクションのみに適用されるため、このフィールドと、もう 1 つのオプションフィールドである、オプションの会社名については、CA の推奨事項に従ってください。CSR のチャレンジパスワードは、サーバー操作には影響しません。 結果として生成されるファイル **csr.pem** には、パブリックキー、パブリックキーのデジタル署名、入札したメタデータが含まれています。 1. CA に CSR を送信します。この作業は通常、テキストエディタで CSR ファイルを開く動作と、内容をウェブフォームにコピーする動作で構成されています。このとき、証明書に適用する 1 つ以上のサブジェクト代替名 (SAN) を指定するように求められることがあります。共通名が **www.example.com** の場合、有効な SAN は **example.com** になります (逆も同様です)。サイトへの訪問者がこれら名前のいずれかを入力すると、エラーなしの接続が提示されます。CA のウェブフォームで許可される場合は、SAN のリストに共通名を含めます 一部の CA では自動的に含められます。 リクエストが承認されると、CA によって署名された新しいホスト証明書が届きます。CA の信頼チェーンを完成するために必要な、追加の証明書が含まれている*中間証明書*ファイルをダウンロードするよう指示されることもあります。 **注記** 多様な用途向けに複数の形式のファイルを送信してくる CA もあります。このチュートリアルでは、PEM 形式の証明書ファイルのみ使用してください。PEM 形式のファイルには通常、`.pem` または `.crt` ファイル拡張子が使用されます (ただし、常にこれらの拡張子が使用されるわけではありません)。どのファイルを使用すべきかわからない場合は、テキストエディタでファイルを開き、以下の行で始まる 1 つ以上のブロックを含むファイルを見つけてください。 ``` - - - - -BEGIN CERTIFICATE - - - - - ``` ファイルの末尾は次のような行になっている必要があります。 ``` - - - -END CERTIFICATE - - - - - ``` 以下に示すように、コマンドラインでファイルをテストすることもできます。 ``` [ec2-user certs]$ openssl x509 -in certificate.crt -text ``` これらの行がファイルに表示されていることを確認してください。`.p7b`、`.p7c`、または類似のファイル拡張子で終了するファイルは使用しないでください。 1. 新しい CA 署名証明書と任意の中間証明書を `/etc/pki/tls/certs` ディレクトリに配置します。 **注記** EC2 インスタンスに新しい証明書をアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、またはメモ帳など) をローカルコンピュータとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] アクセス許可が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。 `/etc/pki/tls/certs` ディレクトリ内から、ファイルの所有権、グループ、およびアクセス許可の設定が、制限の厳しい AL2 のデフォルト (所有者 = ルート、グループ = ルート、所有者のみの読み取り/書き込み) と一致していることを確認します。以下の例では、使用するコマンドを示しています。 ``` [ec2-user certs]$ sudo chown root:root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt ``` これらのコマンドによって、次の結果が得られます。 ``` -rw------- root root custom.crt ``` 中間証明書ファイルのアクセス権は、比較的厳しくありません (所有者 = root、グループ = root、所有者による書き込み可、グループによる読み取り可、その他による読み取り可)。以下の例では、使用するコマンドを示しています。 ``` [ec2-user certs]$ sudo chown root:root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt ``` これらのコマンドによって、次の結果が得られます。 ``` -rw-r--r-- root root intermediate.crt ``` 1. CSR の作成に使用したプライベートキーを `/etc/pki/tls/private/` ディレクトリに配置します。 **注記** EC2 インスタンスにカスタムキーをアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、メモ帳など) をローカルコンピュータとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] アクセス許可が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。 `/etc/pki/tls/private` ディレクトリ内から、次のコマンドを使用して、ファイルの所有権、グループ、およびアクセス許可の設定が、制限の厳しい AL2 のデフォルト (所有者 = ルート、グループ = ルート、所有者のみの読み取り/書き込み) と一致することを確認します。 ``` [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key ``` これらのコマンドによって、次の結果が得られます。 ``` -rw------- root root custom.key ``` 1. 新しい証明書とキーファイルに合わせるには、`/etc/httpd/conf.d/ssl.conf` を編集します。 1. CA 署名のホスト証明書のパスとファイル名を Apache の `SSLCertificateFile` ディレクティブで指定します。 ``` SSLCertificateFile /etc/pki/tls/certs/custom.crt ``` 1. 中間証明書ファイル (この例では `intermediate.crt`) を受け取ったら、Apache の `SSLCACertificateFile` ディレクティブを使用して、次のファイルのパスとファイル名を指定します。 ``` SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt ``` **注記** 一部の CA では、ホスト証明書と中間証明書を組み合わせて 1 つのファイルを作成するため、この `SSLCACertificateFile` ディレクティブは必要ありません。CA が提供している手順を参照してください。 1. プライベートキー (この例では `custom.key`) のパスとファイル名を Apache の `SSLCertificateKeyFile` ディレクティブで指定します。 ``` SSLCertificateKeyFile /etc/pki/tls/private/custom.key ``` 1. `/etc/httpd/conf.d/ssl.conf` を保存して、Apache を再起動します。 ``` [ec2-user ~]$ sudo systemctl restart httpd ``` 1. サーバーをテストするには、ブラウザの URL バーにドメイン名を入力し、プレフィックス `https://` を指定します。ブラウザによって、エラーが生成されることなく、HTTPS 経由でテストページがロードされます。 ## ステップ 3: セキュリティ設定をテストして強化する TLS が運用可能になりパブリックに公開されたら、実際の安全性をテストする必要があります。セキュリティセットアップの詳細な分析を無料で行うことのできる [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) などのオンラインサービスを使用すると簡単です。その結果に基づき、受け入れるプロトコル、優先する暗号化方式、除外する暗号化方式を制御することによって、デフォルトのセキュリティ設定を強化するかどうかを決定できます。詳細については、「[Qualys のスコアの計算方法](https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide)」を参照してください。 **重要** サーバーのセキュリティを確保するには、実際のテストが非常に重要です。小さな設定エラーによって、深刻なセキュリティ侵害やデータの損失が生じる可能性があります。調査や新たな脅威に応じて、推奨されるセキュリティ管理方法は常に変化するため、適切なサーバー管理を行うには、定期的なセキュリティ監査が不可欠です。 [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) のサイトで、サーバーの完全修飾ドメイン名を **www.example.com** という形式で入力します。約 2 分後に、サイトに関するグレード (A から F) と、結果の詳細な内訳が届きます。次の表は、AL2 のデフォルトの Apache 設定と同じ設定で、デフォルトの Certbot 証明書を持つドメインのレポートをまとめたものです。 | | | | --- |--- | | 総合評価 | B | | 証明書 | 100% | | プロトコルサポート | 95% | | キー交換 | 70% | | 暗号強度 | 90% | 概要は設定がほとんど正常であることを示していますが、詳細レポートでは、いくつかの潜在的な問題が指摘されています。重大度の高い順に以下に示します。 **RC4 暗号は、特定の古いブラウザでの使用がサポートされています。**暗号は、暗号化アルゴリズムの計算の中核です。TLS データストリームの暗号化に使用される高速の暗号化方式である RC4 は、いくつかの[重大な脆弱性](http://www.imperva.com/docs/hii_attacking_ssl_when_using_rc4.pdf)を持つことで知られています。従来のブラウザをサポートするもっともな理由がない限り、この暗号化方式を無効にする必要があります。 ✗**旧バージョンの TLS がサポートされています。**設定では TLS 1.0 (すでに廃止されています) と TLS 1.1 (廃止予定) がサポートされています。2018 年以降は、TLS 1.2 のみ推奨されています。 **前方秘匿性は完全にサポートされていません。**[前方秘匿性](https://en.wikipedia.org/wiki/Forward_secrecy)は、プライベートキーから派生した一時 (エフェメラル) セッションキーを使用して暗号化を行う、アルゴリズムの機能です。これは、攻撃者がウェブサーバーの長期的なプライベートキーを所有していても、HTTPS データを復号できないことを意味します。 **TLS 設定を修正し、将来への対応性を確保するには** 1. 設定ファイル `/etc/httpd/conf.d/ssl.conf` を開き、行頭に \$1 を付けて以下の行をコメントアウトしてください。 ``` #SSLProtocol all -SSLv3 ``` 1. 次のディレクティブを追加します。 ``` #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 ``` このディレクティブにより、SSL バージョン 2、3、および TLS バージョン 1.0、1.1 が明示的に無効化されます。これで、サーバーでは、TLS 1.2 以外を使用した、クライアントとの暗号化された接続の受け入れが拒否されます。ディレクティブに含める指定が多くなるほど、サーバーの動作に対する設定内容が明確に伝わります。 **注記** このようにして、TLS バージョン 1.0 および 1.1 を無効にすると、ごく一部の古くなったウェブブラウザによるサイトへのアクセスがブロックされるようになります。 **許可された暗号のリストを変更するには** 1. 設定ファイル `/etc/httpd/conf.d/ssl.conf` で、**SSLCipherSuite** ディレクティブを含むセクションを探し、行頭に \$1 を付けて既存の行をコメントアウトします。 ``` #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 ``` 1. 明示的な暗号スイートと、前方秘匿性を優先し、安全でない暗号を禁止する暗号順序を指定します。ここで使用される `SSLCipherSuite` ディレクティブは、[Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)の出力に基づいています。これは、お客様のサーバーで実行されている特定のソフトウェアに合わせて TLS 設定を調整します。まず、以下のコマンドの出力を使用して、Apache と OpenSSL のバージョンを確認します。 ``` [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl ``` 例えば、返された情報が Apache 2.4.34 および OpenSSL 1.0.2 である場合、これをジェネレーターに入力します。"最新" 互換性モデルを選択すると、`SSLCipherSuite` ディレクティブが作成されます。このディレクティブは、積極的にセキュリティを適用しますが、ほとんどのブラウザで使用できます。ソフトウェアで最新互換性モデルがサポートされていない場合は、ソフトウェアを更新するか、"中間" の構成を選択します。 ``` SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ``` 選択された暗号化方式の名前には、*ECDHE* が含まれています (*Elliptic Curve Diffie-Hellman Ephemeral* の略語です)。*ephemeral* は前方秘匿性を示します。また、これらの暗号化方式では、RC4 はサポートされていません。 デフォルトや、内容が見えない簡単なディレクティブに依存するのではなく、暗号化方式の明示的なリストを使用することをお勧めします。 生成されたディレクティブを `/etc/httpd/conf.d/ssl.conf` にコピーします。 **注記** ここでは読みやすくするために数行に分けて示していますが、このディレクティブは、`/etc/httpd/conf.d/ssl.conf` にコピーする際に、暗号化方式名の間をコロンのみ (スペースなし) で区切り、1 行に指定する必要があります。 1. 最後に、次の行について、行頭の \$1 を削除してコメント解除します。 ``` #SSLHonorCipherOrder on ``` このディレクティブは、(この場合) 前方秘匿性をサポートするものも含めて、ランクの高い暗号化方式を優先するようサーバーに強制します。このディレクティブが有効になると、サーバーは、セキュリティの弱い暗号化方式に戻る前に、セキュリティが強力な接続を確立しようとします。 これらの手順がいずれも完了したら、変更内容を `/etc/httpd/conf.d/ssl.conf` に保存し、Apache を再起動します。 [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) でドメインをもう一度テストすると、RC4 脆弱性やその他の警告は解決し、次のようなサマリレポートが出力されます。 | | | | --- |--- | | 総合評価 | A | | 証明書 | 100% | | プロトコルサポート | 100% | | キー交換 | 90% | | 暗号強度 | 90% | OpenSSL の更新ごとに、新しい暗号化方式が導入され古い暗号化方式のサポートが削除されます。EC2 AL2 インスタンスup-to-date保ち、[OpenSSL](https://www.openssl.org/) からのセキュリティに関する発表を監視し、テクニカルメディアで新しいセキュリティエクスプロイトのレポートに注意してください。 ## トラブルシューティング + **パスワードを指定しないと Apache ウェブサーバーが起動しません** これは、パスワードで保護された暗号化プライベート サーバー キーをインストールした場合は正常な動作です。 暗号化とパスワードの要件をキーから削除できます。デフォルトディレクトリに `custom.key` という暗号化プライベート RSA キーがあり、そのパスワードが **abcde12345** であるとすると、EC2 インスタンスで次のコマンドを実行し、このキーの非暗号化バージョンを生成してください。 ``` [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo systemctl restart httpd ``` パスワードが求められずに Apache が起動するようになります。 + **sudo yum install -y mod\$1ssl を実行するとエラーが発生します。** SSL に必要なパッケージをインストールすると、次のようなエラーが表示されることがあります。 ``` Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64 ``` これは通常、EC2 インスタンスが AL2 を実行していないことを意味します。このチュートリアルでは、公式の AL2 AMI から新しく作成されたインスタンスのみをサポートします。 # チュートリアル: AL2 で WordPress ブログをホストする 次の手順は、AL2 インスタンスに WordPress ブログをインストール、設定、保護するのに役立ちます。このチュートリアルは、WordPress ブログをホストするウェブサーバーを完全に制御する (これは従来のホスティングサービスでは一般的なことではありません) という点で、Amazon EC2 を使用するための優れた手引きになります。 サーバーに対するソフトウェアパッケージの更新とセキュリティパッチの維持は、お客様の責任となります。ウェブサーバー設定と直接やり取りする必要のない、より自動化された WordPress インストールの場合、この CloudFormation サービスには WordPress テンプレートが用意されており、すぐに開始することもできます。詳細については、 *AWS CloudFormation ユーザーガイド*の「[開始方法](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.Walkthrough.html)」を参照してください。データベースが疎結合化された高可用性のソリューションが必要な場合は、*AWS Elastic Beanstalk デベロッパーガイド*の「[高可用性の WordPress ウェブサイトをデプロイする](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html)」を参照してください。 **重要** これらの手順は、AL2 での使用を目的としています。その他のディストリビューションの詳細については、各ドキュメントを参照してください。このチュートリアルの多くの手順は、Ubuntu インスタンスには使用できません。Ubuntu インスタンスでの WordPress のインストールについては、Ubuntu のドキュメントの「[WordPress](https://help.ubuntu.com/community/WordPress)」を参照してください。[CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-wordpress-launch-instance.html) を使用して、Amazon Linux、macOS、または Unix システムでこのタスクを実行することもできます。 **Topics** + [前提条件](#hosting-wordpress-prereqs) + [WordPress のインストール](#install-wordpress) + [次のステップ](#wordpress-next-steps) + [ヘルプ\$1 パブリック DNS 名が変更されたため、ブログが壊れました](#wordpress-troubleshooting) ## 前提条件 このチュートリアルでは、「」のすべてのステップに従って、PHP とデータベース (MySQL または MariaDB) をサポートする機能的なウェブサーバーで AL2 インスタンスを起動していることを前提としています[チュートリアル: AL2 に LAMP サーバーをインストールする](ec2-lamp-amazon-linux-2.md)。このチュートリアルでは、セキュリティグループで `HTTP` および `HTTPS` トラフィックを許可するように設定する手順や、ウェブサーバー用にファイルアクセス許可が正しく設定されていることを確認する手順も示します。セキュリティグループへのルールの追加の詳細については、「[セキュリティグループへのルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)」を参照してください。 Elastic IP アドレス (EIP) は、WordPress ブログのホストに使用しているインスタンスに関連付けることを強くお勧めします。これにより、インスタンスのパブリック DNS アドレスが変更されて、インストールが破損することを防止できます。ドメイン名を所有していてそのドメインをブログに使用する場合、EIP アドレスをポイントするようにドメイン名の DNS レコードを更新できます (これを行うには、ドメイン名レジストラに問い合わせてください)。実行中のインスタンスに関連付けられた EIP アドレスを無料で 1 つ取得できます。詳細については、*「Amazon EC2 ユーザーガイド」*の[「Elastic IP アドレス」](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)を参照してください。 ブログのドメイン名がまだない場合は、Route 53 にドメイン名を登録し、そのドメイン名にインスタンスの EIP アドレスを関連付けることができます。詳細については、*Amazon Route 53 デベロッパーガイド* の「[Amazon Route 53 を使用したドメイン名の登録](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)」を参照してください。 ## WordPress のインストール **オプション: オートメーション を使用してこのチュートリアルを完了する** 以下のタスクの代わりに AWS Systems Manager 自動化を使用してこのチュートリアルを完了するには、[自動化ドキュメント](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-HostingAWordPressBlog/)を実行します。 インスタンスに接続して、WordPress インストールパッケージをダウンロードします。 **WordPress インストールパッケージをダウンロードして解凍するには** 1. **wget** コマンドを使って、最新の WordPress インストールパッケージをダウンロードします。次のコマンドを実行すると、最新リリースが必ずダウンロードされます。 ``` [ec2-user ~]$ wget https://wordpress.org/latest.tar.gz ``` 1. インストールパッケージを解凍します。インストールフォルダは、`wordpress` という名前のフォルダに解凍されます。 ``` [ec2-user ~]$ tar -xzf latest.tar.gz ``` **WordPress インストール用にデータベースユーザーとデータベースを作成するには** WordPress インストールは、ブログの投稿、ユーザーコメントなどの情報をデータベースに格納する必要があります。この手順を実行すると、ブログのデータベースを作成するのに役立ち、このデータベースに対して情報の読み取りや保存を許可されたユーザーにも有用です。 1. データベースサーバーを起動します。 + ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. データベースサーバーに `root` ユーザーとしてログインします。メッセージが表示されたら、データベース `root` パスワードを入力します。これは通常の `root` システムパスワードと異なることもあれば、データベースサーバーのセキュリティ確保を実行していない場合は、空のときもあります。 データベースサーバーのセキュリティを確保していない場合、セキュリティ確保を行うことは重要です。詳細については、 [MariaDB サーバーをセキュリティで保護するには](ec2-lamp-amazon-linux-2.md#securing-maria-db) (AL2) を参照してください。 ``` [ec2-user ~]$ mysql -u root -p ``` 1. MySQL データベースのユーザーとパスワードを作成します。WordPress インストールは、これらの値を使って、MySQL データベースと通信を行います。 ユーザー用に強力なパスワードを作成してください。パスワードに一重引用符 (') を使用しないでください。この文字は前述のコマンドを中断させるためです。既存のパスワードを再利用しないでください。また、このパスワードは必ず安全な場所に保管してください。 一意のユーザー名とパスワードを入力して、次のコマンドを入力します。 ``` CREATE USER 'wordpress-user'@'localhost' IDENTIFIED BY 'your_strong_password'; ``` 1. データベースを作成します。`wordpress-db` など、データベースにはわかりやすい名前を使用します。 **注記** 次のコマンドのデータベース名を囲む区切り記号は、「バックティック」と呼ばれています。バックティック (```) キーは通常、標準キーボードの `Tab` キーの上に配置されています。バックティックは必ずしも必要ではありませんが、データベース名では使用できない文字 (ハイフンなど) の代わりに使用できます。 ``` CREATE DATABASE `wordpress-db`; ``` 1. データベースに対して、以前作成した WordPress ユーザーに対する完全な権限を付与します。 ``` GRANT ALL PRIVILEGES ON `wordpress-db`.* TO "wordpress-user"@"localhost"; ``` 1. すべての変更を有効にするため、データベース権限をフラッシュします。 ``` FLUSH PRIVILEGES; ``` 1. `mysql` クライアントを終了します。 ``` exit ``` **wp-config.php ファイルの作成と編集を行うには** WordPress インストールフォルダには、`wp-config-sample.php` という名前の構成ファイル例が格納されています。この手順では、このファイルをコピーして、特定の構成に合うように編集します。 1. `wp-config-sample.php` ファイルを `wp-config.php` という名前でコピーします。この操作を実行すると、新しい構成ファイルが作成され、元のファイルがバックアップとしてそのまま保持されます。 ``` [ec2-user ~]$ cp wordpress/wp-config-sample.php wordpress/wp-config.php ``` 1. お好みのテキストエディタ (`wp-config.php`、**nano** など) を使って **vim** ファイルを編集し、インストール用の値を入力します。お好みのテキストエディタがない場合、`nano` が初心者に適しています。 ``` [ec2-user ~]$ nano wordpress/wp-config.php ``` 1. `DB_NAME` を定義する行を探して、`database_name_here` を [Step 4](#create_database) の [WordPress インストール用にデータベースユーザーとデータベースを作成するには](#create_user_and_database) で作成したデータベース名に変更します。 ``` define('DB_NAME', 'wordpress-db'); ``` 1. `DB_USER` を定義する行を探して、`username_here` を [Step 3](#create_database_user) の [WordPress インストール用にデータベースユーザーとデータベースを作成するには](#create_user_and_database) で作成したデータベースユーザーに変更します。 ``` define('DB_USER', 'wordpress-user'); ``` 1. `DB_PASSWORD` を定義する行を探して、`password_here` を [Step 3](#create_database_user) の [WordPress インストール用にデータベースユーザーとデータベースを作成するには](#create_user_and_database) で作成した強力なパスワードに変更します。 ``` define('DB_PASSWORD', 'your_strong_password'); ``` 1. `Authentication Unique Keys and Salts` というセクションを見つけます。これらの `KEY` と `SALT` の値は、WordPress ユーザーがローカルマシンに保存したブラウザクッキーに対する暗号化レイヤーを提供します。基本的に、ここで長くてランダムな値を指定すると、サイトのセキュリティが向上します。[https://api.wordpress.org/secret-key/1.1/salt/](https://api.wordpress.org/secret-key/1.1/salt/) にアクセスして、ランダムに生成されるキーセット値を取得し、`wp-config.php` ファイルにコピーして貼り付けることができます。PuTTY 端末にテキストを貼り付けるには、テキストを貼り付ける場所にカーソルを置き、PuTTY 端末内でマウスを右クリックします。 セキュリティキーの詳細については、「[https://wordpress.org/support/article/editing-wp-config-php/\$1security-keys](https://wordpress.org/support/article/editing-wp-config-php/#security-keys)」にアクセスしてください。 **注記** 次の値はサンプル専用です。これらの値を実際のインストールには使わないでください。 ``` define('AUTH_KEY', ' #U$$+[RXN8:b^-L 0(WU_+ c+WFkI~c]o]-bHw+)/Aj[wTwSiZ)Y |;(^[Iw]Pi+LG#A4R?7N`YB3'); define('NONCE_KEY', 'P(g62HeZxEes|LnI^i=H,[XwK9I&[2s|:?0N}VJM%?;v2v]v+;+^9eXUahg@::Cj'); define('AUTH_SALT', 'C$DpB4Hj[JK:?{ql`sRVa:{:7yShy(9A@5wg+`JJVb1fk%_-Bx*M4(qc[Qg%JT!h'); define('SECURE_AUTH_SALT', 'd!uRu#}+q#{f$Z?Z9uFPG.${+S{n~1M&%@~gL>U>NV.|Y%Ug4#I^*LVd9QeZ^&XmK|e(76miC+&W&+^0P/'); define('NONCE_SALT', '-97r*V/cgxLmp?Zy4zUU4r99QQ_rGs2LTd%P;|_e1tS)8_B/,.6[=UK` で始まるセクションを見つけます。 ``` # # Possible values for the Options directive are "None", "All", # or any combination of: # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews # # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you. # # The Options directive is both complicated and important. Please see # http://httpd.apache.org/docs/2.4/mod/core.html#options # for more information. # Options Indexes FollowSymLinks # # AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # Options FileInfo AuthConfig Limit # AllowOverride None # # Controls who can get stuff from this server. # Require all granted ``` 1. 上のセクションの `AllowOverride None` 行を `AllowOverride All` に変更します。 **注記** このファイルには複数の `AllowOverride` 行があります。必ず `` セクションの行を変更してください。 ``` AllowOverride All ``` 1. ファイルを保存し、テキストエディタを終了します。 **PHP グラフィック描画ライブラリを AL2 にインストールするには** PHP 用の GD ライブラリを使用すると、イメージを変更することができます。ブログのヘッダーイメージをトリミングする必要がある場合は、このライブラリをインストールします。インストールするバージョンの phpMyAdmin は、このライブラリの特定の最小バージョン (バージョン 7.2 など) を必要とする場合があります。 次のコマンドを使用して、PHP グラフィック描画ライブラリを AL2 にインストールします。例えば、LAMP スタックをインストールする一環として amazon-linux-extras から php7.2 をインストールした場合、このコマンドは PHP グラフィック描画ライブラリのバージョン 7.2 をインストールします。 ``` [ec2-user ~]$ sudo yum install php-gd ``` インストールしたバージョンを検証するには、次のコマンドを使用します。 ``` [ec2-user ~]$ sudo yum list installed php-gd ``` 出力例を次に示します。 ``` php-gd.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 ``` **Apache ウェブサーバーのファイル許可を修正するには** WordPress で使用できる機能の中には、Apache ドキュメントルートへの書き込み権限が必要なものがあります (管理画面を使った、メディアのアップロードなど)。まだ適用していない場合は、次のグループメンバーシップとアクセス許可を適用します (詳細については、「」を参照してください[チュートリアル: AL2 に LAMP サーバーをインストールする](ec2-lamp-amazon-linux-2.md))。 1. `/var/www` とそのコンテンツのファイル所有権を `apache` ユーザーに付与します。 ``` [ec2-user ~]$ sudo chown -R apache /var/www ``` 1. `/var/www` とそのコンテンツのグループ所有権を `apache` グループに付与します。 ``` [ec2-user ~]$ sudo chgrp -R apache /var/www ``` 1. `/var/www` およびそのサブディレクトリのディレクトリ許可を変更してグループの書き込み許可を設定し、将来のサブディレクトリにグループ ID を設定します。 ``` [ec2-user ~]$ sudo chmod 2775 /var/www [ec2-user ~]$ find /var/www -type d -exec sudo chmod 2775 {} \; ``` 1. `/var/www` およびそのサブディレクトリのファイル許可を繰り返し変更します。 ``` [ec2-user ~]$ find /var/www -type f -exec sudo chmod 0644 {} \; ``` **注記** WordPress を FTP サーバーとして使用する場合も、これよりも制限の少ないグループ設定が必要になります。これを実行するには、「[WordPress で推奨されている手順とセキュリティ設定](https://wordpress.org/support/article/changing-file-permissions/)」を参照してください。 1. Apache ウェブサーバーを再起動して、新しいグループと許可を有効にします。 + ``` [ec2-user ~]$ sudo systemctl restart httpd ``` **AL2 で WordPress インストールスクリプトを実行する** WordPress をインストールする準備ができました。使用するコマンドは、オペレーティングシステムによって異なります。この手順のコマンドは、AL2 で使用するためのものです。 1. **systemctl** コマンドを使って、`httpd` サービスとデータベースサービスがシステムブート時に起動することを確認します。 ``` [ec2-user ~]$ sudo systemctl enable httpd && sudo systemctl enable mariadb ``` 1. データベースサーバーが実行中であることを確認します。 ``` [ec2-user ~]$ sudo systemctl status mariadb ``` データベースサービスが実行されていない場合は、起動します。 ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. Apache ウェブサーバー (`httpd`) が実行中であることを確認します。 ``` [ec2-user ~]$ sudo systemctl status httpd ``` `httpd` サービスが実行されていない場合は、起動します。 ``` [ec2-user ~]$ sudo systemctl start httpd ``` 1. ウェブブラウザで WordPress ブログの URL を入力します (インスタンスのパブリック DNS アドレス、または `blog` フォルダに続くアドレス)。WordPress インストールスクリプトが表示されます。WordPress のインストールに必要な情報を入力します。[**WordPress のインストール**] を選択して、インストールを完了します。詳細については、WordPress のウェブサイトの [Step 5: Run the Install Script](https://wordpress.org/support/article/how-to-install-wordpress/#step-5-run-the-install-script) を参照してください。 ## 次のステップ WordPress ブログをテストしたら、設定の更新を検討します。 **カスタムドメイン名を使用する** EC2 インスタンスの EIP アドレスに関連付けられたドメイン名がある場合、EC2 パブリック DNS アドレスの代わりにその名前を使用するようにブログを設定できます。詳細については、WordPress ウェブサイトの「[サイトの URL の変更](https://wordpress.org/support/article/changing-the-site-url/)」を参照してください。 **ブログを設定する** 読者にパーソナライズされた体験を提供するため、さまざまな[テーマ](https://wordpress.org/themes/)や[プラグイン](https://wordpress.org/plugins/)を使用するようにブログを設定できます。ただし、インストールプロセスで問題が発生してブログ全体が失われることがあります。インストール中に問題が発生した場合もブログを復元できるように、テーマやプラグインを員ストーする前にインスタンスのバックアップ Amazon マシンイメージ (AMI) を作成しておくことを強くお勧めします。詳細については、[「独自の AMI を作成する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)」を参照してください。 **容量を増やす** WordPress ブログが人気になり処理能力やストレージを増やす必要がある場合は、次のステップを検討してください。 + インスタンスストレージ領域を拡張する。詳細については、「Amazon EBS ユーザーガイド」の「[Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)」を参照してください。 + MySQL データベースを [Amazon RDS](https://aws.amazon.com/rds) に移動して、サービスが持つ容易にスケールする機能を活用する。 **インターネットトラフィックのネットワークパフォーマンスを向上させる** ブログにより世界中のユーザーからのトラフィックが増加すると予想される場合は、[AWS Global Accelerator](https://aws.amazon.com/global-accelerator) をご検討ください。Global Accelerator を使用すると、ユーザーのクライアントデバイスと AWSで実行中の WordPress アプリケーションとの間で、インターネットトラフィックのパフォーマンスを向上でき、低レイテンシーを実現できます。Global Accelerator は、 [AWS グローバルネットワーク](https://aws.amazon.com/about-aws/global-infrastructure/global_network/)を使用して、クライアントに最も近い AWS リージョンの正常なアプリケーションエンドポイントにトラフィックを誘導します。 **WordPress の詳細** WordPress の詳細については、「[http://codex.wordpress.org/](http://codex.wordpress.org/)」にある WordPress Codex ヘルプ文書を参照してください。 インストールのトラブルシューティングの詳細については、[「一般的なインストールの問題](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems)」を参照してください。 WordPress ブログのセキュリティを強化する方法については、[「WordPress の強化](https://wordpress.org/support/article/hardening-wordpress/)」を参照してください。 WordPress ブログをup-to-date状態に保つ方法については、[WordPress の更新](https://wordpress.org/support/article/updating-wordpress/)」を参照してください。 ## ヘルプ\$1 パブリック DNS 名が変更されたため、ブログが壊れました WordPress のインストールは、EC2 インスタンスのパブリック DNS アドレスを使用して自動的に設定されます。インスタンスを停止および再開した場合、パブリック DNS アドレスが変更され (Elastic IP アドレスに関連付けられている場合を除く)、ブログが存在しなくなった (または別の EC2 インスタンスに割り当てられた) アドレスにあるリソースを参照することになるため、ブログは機能しなくなります。問題の詳細な説明と考えられる解決策については、[「サイト URL の変更](https://wordpress.org/support/article/changing-the-site-url/)」を参照してください。 WordPress のインストールでこの問題が発生した場合は、WordPress の**wp-cli**コマンドラインインターフェイスを使用する以下の手順でブログを復元できる場合があります。 ****wp-cli** を使用して WordPress のサイト URL を変更するには** 1. SSH を使って EC2 インスタンスに接続します。 1. インスタンスの古いサイト URL と新しいサイト URL を書き留めます。古いサイト URL は、WordPress をインストールした時点での EC2 インスタンスのパブリック DNS 名と考えられます。新しいサイト URL は、EC2 インスタンスの現在のパブリック DNS 名です。古いサイト URL が不明な場合、次のコマンドで **curl** を使用して調べることができます。 ``` [ec2-user ~]$ curl localhost | grep wp-content ``` 古いパブリック DNS 名への参照が出力に表示されます。次に例を示します (古いサイト URL は赤色になっています)。 ``` ``` 1. 次のコマンドを使って **wp-cli** をダウンロードします。 ``` [ec2-user ~]$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar ``` 1. 次のコマンドを使って、WordPress インストールの古いサイト URL を検索し、置き換えます。EC2 インスタンスの古いサイト URL と新しいサイト URL、および WordPress のインストールパス (通常は `/var/www/html` または `/var/www/html/blog`) を置き換えます。 ``` [ec2-user ~]$ php wp-cli.phar search-replace 'old_site_url' 'new_site_url' --path=/path/to/wordpress/installation --skip-columns=guid ``` 1. ウェブブラウザで、WordPress ブログの新しいサイト URL を入力し、サイトが再び正しく動作していることを確認します。そうでない場合は、[「サイト URL の変更](https://wordpress.org/support/article/changing-the-site-url/)」と[「一般的なインストールの問題](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems)」を参照してください。