refirio.org

※汎用的なサーバを作成できる EC2 → インスタンス → インスタンスを起動 名前: 「Develop-Web1」など自分で判別しやすい名前を付ける Amazon マシンイメージ (AMI): Amazon Linux 2 AMI インスタンスタイプ: t2.micro キーペア名: 予め作成したキーペア ネットワーク: 必要に応じて選択する サブネット: 必要に応じて選択する パブリックIPの自動割り当て: 有効化 ファイアウォール (セキュリティグループ): 予め作成したセキュリティグループ ストレージ: 8GiB ※「キーペア名」について キーペアはSSHアクセスの際などに使用する 新規に作成してもいいし、既存のものがあれば選択してもいい ※「パブリックIPの自動割り当て」について 「有効化」にすると、インスタンスが停止または削除されるまでのIPアドレスが割り当てられる。「無効化」にすると、IPアドレスが割り当てられない 外部からの直接アクセスが不要な場合、「無効」でいい 自動割り当てされたIPアドレスは、EC2を再起動しても変わらない。いったん停止させてから再度開始すると変わる。変わるのはIPアドレスだけなので、基本的にはSSHやHTTPの接続先さえ変えれば問題ない。固定IPが必要な場合、ElasticIPを使う 内部での通信なら、プライベートIPで通信できる。例えばPHPでHTTPリクエストを行う場合でも「file_get_contents('http://10.0.0.1/')」のように指定できる。プライベートIPは、停止させても変化しないみたい 「インスタンスを起動」ボタンをクリック インスタンスが作成されるまで数分待つ Amazon EC2の使い方【SSHまで全部GUIでできます！】 http://www.synaesthesia.jp/amazon/ec2/introduction.php PoderosaをつかってAmazonEC2に接続 http://saifis.net/?p=116 EC2へpoderosaからログイン http://xoxo-infra.hatenablog.com/entry/2013/02/09/061305 0から始めるAWS入門：VPC編 http://qiita.com/hiroshik1985/items/9de2dd02c9c2f6911f3b EC2 Amazon Linux を立ち上げた時にする初期設定 http://qiita.com/shojimotio/items/79264678e9ea10b6fd19 ■固定IPの取得＆インスタンスに割り当て（固定IPが必要な場合） ※Elastic IP による固定IPについては「Elastic IPs」の項目も参照 EC2 → Elastic IP → Elastic IPを割り当てる 基本的には特に何も変更せず、「割り当て」ボタンを押せばいい 一覧画面に遷移し、IPアドレスが割り当てられたことを確認できる 一覧から、作成したIPアドレスを選択 → アクション → Elastic IP アドレスの関連付け 作成したインスタンスを選択し、「関連付ける」ボタンを押す ■EC2へSSH経由でアクセス ※Poderosaなど、任意のSSHクライアントでアクセスできる 接続先：203.0.113.1（割り当てた固定IP。インスタンスの情報で「IPv4パブリックIP」として確認できる） ユーザ名：ec2-user ポート：22 鍵：作成したキーペア（pemファイル） 接続できない場合、一般的なSSH接続の確認事項に加えて 「EC2を外部からアクセスできるサブネットに配置したか」 「セキュリティグループでIP制限されていないか」 「正しいキーペアを使用しているか」 なども確認する でrootのパスワードを設定する これで、 でrootになれる。rootのパスワードを設定せずに、「sudo su -」でrootになることもできる Amazon Linux AMI の root パスワード (Amazon EC2) http://whatpgcando.blogspot.jp/2011/03/amazon-linux-ami-root-amazon-ec2.html ■amazon-linux-extrasについて 詳細は、後述の「amazon-linux-extras」を参照 ■Webサーバとして最低限の設定例 とりあえずWebサーバとして使えるようにし、ec2-userがSFTPでファイルアップロードできるようにする設定 あらかじめセキュリティグループで、22番ポートと80番ポートのアクセスを許可しておく ・「sudo su -」でrootになる ・必要に応じて日本語設定にしておく ・必要に応じてホスト名を設定しておく（デフォルトでは「ip-10-1-0-87」のようなホスト名。このままでもいい） ・必要に応じてタイムゾーンを設定しておく ・Apacheの場合、以下を設定（PHP5.6を使うならApacheは2.4をインストールする。詳細は Programming.txt を参照） ・nginxの場合、以下を設定 ■認証時のエラーログが記録されないようにする /var/log/secure に以下のようなログが記録される 動作上は問題ないようだが、監視システムなどで異常として検知される可能性はある これは、sshd_config を編集することで記録されないようにできる EC2でsecureログにerror: AuthorizedKeysCommandが出力されるようになった - Qiita https://qiita.com/comefigo/items/e500dc53217b8b55260e AuthorizedKeysCommand と AuthorizedKeysCommandUser は、公開鍵での認証に関する設定らしい この設定を変更することによって、ログインに異常が発生していないかは確認しておく OpenSSH で全ユーザの公開鍵を1ファイルで管理する - meta‘s blog(2017-08-29) https://w.vmeta.jp/tdiary/20170829.html ■EC2を停止 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの停止」 で停止できる 停止しない場合、再度 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの強制停止」 を行うと強制停止になる 強制停止は、停止の操作を行ってからしばらくすると現れるみたい？ 以下は以前の操作手順メモ 今とは少し操作が変更されているみたい 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの停止」 で停止しない場合、再度 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの停止」 を行うと強制停止になる ■EC2のインスタンスタイプを変更 インスタンスタイプを変更するために、いったんインスタンスを停止させる 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの停止」 インスタンスタイプを変更する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの設定」→「インスタンスタイプの変更」 任意のインスタンスタイプを選択して「適用」ボタンを押す インスタンスを開始する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「開始」 18:03に作業を開始してt2.microをt2.smallに変更した場合、 18:03 停止 18:05 性能変更（数秒で完了） 18:08 起動完了 18:10 ステータスチェック完了 くらいの時間だった。 ※スワップを設定している場合、メモリに応じてスワップサイズを見直す ■インスタンスストアボリュームとEBS インスタンスストアはEC2の揮発性ブロックストレージ EBSはデータが永続化されるブロックストレージ サーバを停止すると、インスタンスストアボリュームのデータは無くなる。EBSのデータは保持される インスタンスストアボリュームの方がEBSよりも高速に読み書きできるので、一時的なデータの保持に使用できる インスタンスストアボリュームを使うためには別途設定が必要なので、設定した覚えがないなら原則気にする必要は無さそう インスタンスの停止と起動 - Amazon Elastic Compute Cloud https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Stop_Start.html Amazon EC2 インスタンスストア - Amazon Elastic Compute Cloud https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html EC2の揮発性ストレージ「インスタンスストア」を使ってみよう！ | DevelopersIO https://dev.classmethod.jp/articles/howto-ec2-volatile-block-storage-instance-store/ 【AWS】インスタンスストアとEBSの違いとは？ - Qiita https://qiita.com/satton6987/items/42a4f8c56aa3851120f9 ■EBSのボリュームサイズを変更（ボリュームサイズを直接増やす方法） EBSとは「Elastic Block Store」の略で、EC2向けに設計されたストレージサービス アップデートにより、EC2の再起動なしにボリュームサイズを増やすことができるようになった コンソールからサイズ変更できるようになったが、パーティションの拡張とファイルシステムの拡張はCUI操作が必要 拡張コマンドはOSによって異なるので注意 OS別EBSオンライン拡張方法 | DevelopersIO https://dev.classmethod.jp/articles/expand-ebs-in-online/ XFS利用時のEC2のディスクを拡張する方法 - Qiita https://qiita.com/sand_bash/items/50c1721cc10f48fef804 ボリュームサイズ変更後の Linux ファイルシステムの拡張 - Amazon Elastic Compute Cloud https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html 【遂に来た！】EBS でボリュームサイズを変更できるようになりました（ボリュームタイプ変更も） | DevelopersIO https://dev.classmethod.jp/articles/release-change-ebs-volume-size/ ご存知でしたか？EC2インスタンスは再起動なしにディスクサイズ(EBSボリュームサイズ)を増やせます | DevelopersIO https://dev.classmethod.jp/articles/extending-disk-size-without-reboot/ また、 ・インスタンスタイプが現行世代のインスタンスでなく、かつ旧世代の以下インスタンスファミリーでもない場合 ・C1、C3、CC2、CR1、G2、I2、M1、M3、R3 ・2TiB (2048GiB) 以上のボリュームの場合 ・前回の変更から6時間以内の場合 ・ボリュームサイズを小さくしたい場合 などの場合は利用できないので注意 この場合、このファイル内の「EBSのボリュームサイズを変更（ボリュームをデタッチ＆アタッチして増やす方法）」の方法を参照 現行世代のインスタンスは、以下のページで確認できる インスタンスタイプ - Amazon Elastic Compute Cloud https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/instance-types.html#current-gen-instanc... 以下、実際に8GBのEBSを12GBに拡張したときの手順 おおまかに 1. EBSのスナップショットを作成する 2. AWSコンソールからボリュームのサイズを変更する 3. EC2にSSHで接続し、パーティションの拡張とファイルシステムの拡張を行う という流れになる 各内容の詳細は以下に記載する 作業前の状況は以下のとおり まず、対象となるEBSのスナップショットを作成しておく （必須ではないが、念のためのバックアップ。もしくは、インスタンスのAMIを作成しておく） インスタンス一覧から対象のインスタンスを選択し、「ストレージ」タブからボリュームIDを確認する ボリューム一覧から対象のボリュームを選択し、「スナップショットの作成」を選択する 必要に応じて説明などを入力し、「スナップショットの作成」ボタンをクリックする ボリューム一覧から対象のボリュームを選択し、「ボリュームの変更」を選択する 「サイズ」欄に変更したいサイズを入力する（今回は「8」を「12」に変更した） 以下の確認が表示される 内容を確認して「はい」を選択する ボリューム一覧ですぐに変更を確認できた ボリュームの状態は「使用中 - optimizing (0%)」という表示になり、これは10分ほどで「使用中」になった（30GB→500GBに変更したときに確認） この完了を待たずに引き続きのパーティション拡張作業を行なっても、問題無く進めることができた 「lsblk」の結果でもサイズが増えているが、「df -h」の結果には変化が無い つまり、この時点では拡張後の領域はまだ使用できない 続いて、コンソールからパーティションの拡張を行う さらにファイルシステムの拡張を行う （後述のとおり、ファイルシステムの拡張コマンドはOSによって異なる。以下のxfs_growfsコマンドは Amazon Linux 2 環境での例） これでHDDのサイズが増えた（OSがサイズの増加を認識した） Amazon Linuxの場合、xfs_growfsコマンドの代わりにresize2fsコマンドを使う なお Amazon Linux 2 環境でresize2fsコマンドを使っても、以下のとおりエラーになる 方法はOSごとによって異なるので注意 詳細は以下のページが解りやすい OS別EBSオンライン拡張方法 | DevelopersIO https://dev.classmethod.jp/articles/expand-ebs-in-online/ ■EBSのボリュームサイズを変更（ボリュームをデタッチ＆アタッチして増やす方法） ※アップデートにより、ボリュームをデタッチ＆アタッチせずに増やすことができるようになった 詳細は、このファイル内の「EBSのボリュームサイズを変更（ボリュームサイズを直接増やす方法）」を参照 Amazon EC2編〜EBSボリュームサイズを変更してみよう！Update〜 http://recipe.kc-cloud.jp/archives/8417 http://recipe.kc-cloud.jp/archives/1278 インスタンスを停止させる 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「インスタンスの停止」 ボリュームのスナップショットを作成する 「EC2」→「ボリューム」→ 対象のボリュームを選択 → 「アクション」→「スナップショットの作成」 「Name」と「説明」を入力して「作成」ボタンを押し、しばらく待つ。それぞれ「refirio_net-EBS」と「20160526」などを入力すればいい スナップショットからボリュームを作成する 「EC2」→「スナップショット」→ 対象のボリュームを選択 → 「アクション」→「ボリュームの作成」 必要に応じてサイズやアベイラビリティーゾーンなどを変更する インスタンスからボリュームを付け替える 「EC2」→「ボリューム」→ 対象のボリュームを選択 → 「アクション」→「ボリュームのデタッチ」 続いて新たに作成したボリュームを選択 → 「アクション」→「ボリュームのアタッチ」 「インスタンス」と「デバイス」を入力して「アタッチ」ボタンを押す。デバイスには「/dev/xvda」と入力すればいい インスタンスを開始する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「開始」 11:42に作業を開始して8GiBを16GiBに変更した場合、 11:42 停止＆スナップショット作成 11:50 スナップショット作成完了＆ボリューム作成 11:57 ボリューム作成完了 12:00 新ボリューム作成（比較的すぐに作成された） 12:04 ボリュームをデタッチ＆アタッチ（即座に設定された） 12:05 インスタンスを開始 12:09 完了 くらいの時間だった。サイズが大きいと時間もかかるかも ■定期的にスナップショットを作成する 未検証だが、ライフサイクルマネージャーからライフサイクルポリシーを設定して対応できるみたい EC2のスナップショットを手軽に自動取得する方法 - Qiita https://qiita.com/nkojima/items/3a39c94348e6d743b483 スナップショットからの復元は以下が参考になる 「パターン２：スナップショットからAMIを作成し、インスタンスを起動させる」の方法が容易に対応できそうではある EC2のスナップショットからインスタンスを復元する方法2パターン | ソフトウェア開発のギークフィード https://www.geekfeed.co.jp/geekblog/restore-from-ec2-snapshot/ ■EBSの料金 料金について調べて連携した時の内容 「恐らくこの計算で合っているだろう」というもの ↓ ストレージについて、以下がAmazonによる説明です。 リージョンは「アジアパシフィック（東京）」です。 ハイパフォーマンスブロックストレージの料金 - Amazon EBS の料金 - Amazon Web Services https://aws.amazon.com/jp/ebs/pricing/ 今案件でも採用している「汎用SSD (gp2) ボリューム」について、「1か月にプロビジョニングされたストレージ1GBあたり0.12USD」と書かれています。 仮に「1ドル＝150円」で計算するとして、1GBあたり月額18円ほどとなります。 サーバは2台構成なので「30GB×2台」を「120GB×2台」にした場合、月額1080円（30×2×18）ほどかかっていたものが月額4320円（120×2×18）ほどに増えることになります。 サイズは、AWSでの容量設定画面に「最小: 1GiB、最大: 16384GiB」と書かれていますので、約16TBが最大となります。 ■EC2の停止とEBSの課金 EC2を停止させるとEC2への課金は止まるが、そのEC2のディスクであるEBSへは課金が続けられるので注意 不要になったEBSとスナップショットは削除する 停止したインスタンスの EBS 課金を停止する https://aws.amazon.com/jp/premiumsupport/knowledge-center/ebs-charge-stopped-instance/ ■PINGに応答させる AWS EC2は（デフォルトで）Pingに応答しない - Qiita https://qiita.com/jkr_2255/items/48be7527d88413a4fe71 AWS EC2 で Ping応答を得られるようにする設定 | Check!Site http://www.checksite.jp/aws-ec2-icmp-rule/ AWSのEC2インスタンスをpingで確認できるようにする http://a1-style.net/amazon-web-service/ping-icmp-setting/ ■計画停止 ハードウェアのメンテナンスのため、EC2はまれに計画停止される 止められないサービスの場合、複数台構成にしておく必要がある code.rock: Amazon EC2は、まれに「計画停止」されます http://blog.dateofrock.com/2010/06/degraded-amazon-ec2-instance.html インスタンスの予定されたイベント - Amazon Elastic Compute Cloud http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.htm... 停止の15日ほど前に、以下のメールが送られてくる 「EC2 → イベント」から、計画停止対象のインスタンスを確認できる 「開始時刻」部分でメンテナンスの開始日時を確認できる 以下は実際に計画停止があったときの内容（「EC2 → イベント」に表示されたもの） 26日16時ごろに確認したものなので、「開始時刻」は日本時間で表示されているみたい 21時になったらインスタンスが停止させられるらしい リソース名: web2 リソースタイプ: instance リソース ID: i-0a6899bfecd4XXXXX アベイラビリティーゾーン: ap-northeast-1c イベントタイプ: instance-stop イベントステータス: Scheduled イベントの説明: The instance is running on degraded hardware 開始時刻: 2018年2月26日 21:00:00 UTC+9 所要時間: - イベントの進行状況: 4 時間 48 分 に開始 「EC2 → インスタンス」で対象のインスタンスを選択すると、以下のメッセージが表示されている 「リタイア: このインスタンスは 2018年2月26日 21:00:00 UTC+9 後にリタイアが予定されています。」 さらに「i」マークをクリックすると、以下のメッセージが表示される 「リタイアが予定されているインスタンスは、指定された日付の後シャットダウンされます。 代替インスタンスを作成し、そのインスタンスへの移行を開始することをお勧めします。」 インスタンスを停止させると、「EC2 → イベント」「EC2 → インスタンス」に表示されていた警告は非表示になった AWSではインスタンスを「停止 → 起動」とすると物理的に別の領域にインスタンスが立ち上がる（再起動では同じ領域が使われる） つまり「停止 → 起動」で計画停止を回避できて、「再起動」では回避できない