カテゴリー: AWS

  • AWS障害発生 – とりあえずのメモ書き

    Service Health Dashboard

    AP-NORTHEAST-1 に障害が発生していて運用中のウェブサーバーにアクセスできず。
    AWS側の対応を待つしかないのですが、別のリージョンに作ったテスト環境があって、インスタンスを立ち上げてみるとこちらは問題なさそう。

    ここしばらくプライベートサブネットにあるDBサーバーのメンテナンスをしていなかったので、NATを作成してupdate。更新が完了したらNATを削除してインスタンスを再起動。

    [2019.08.27]
    (参考)複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする

    [2019.11.21]
    RDSのマスターの異常検知によってフェイルオーバー機能が働いて、リードレプリカがマスターに切り替わっていたようです。WordPressを使って運用しているサイトなのですが、公開ページは問題なくてダッシュボードにログインできない状態になっていました。手動でフェイルオーバーを実行してマスターとスレーブを切り替えて正常に稼働することを確認しました。

  • JAWS-UG愛媛 第18回勉強会 に参加しました

    JAWS-UG愛媛 (日本 Amazon Web Serviceユーザ会愛媛)第18回勉強会
    昨日参加してきました。

    AWS初心者向けハンズオン!
    セキュアでスケーラブルなWordpressのサイトを構築してみよう。

    なかなかのボリュームで、途中で集中力が切れて心が折れそうになりましたが、ほぼ全員が完走という、ものすごく充実した勉強会でした。

    一部、トラップ?があって、その場しのぎの対応でなんとかやり過ごしたのですが、隣に座っていたOさんからのサーバープロセスに関する指摘があってモヤモヤしていたので、ec2インスタンスのみ作り直して確認してみました。

    /var/www/html 以下のファイルの所有が
    apache:apache
    となっている割に、nginx の worker process が nginx ユーザーなので wp-config.php が生成できない?

    と思ったのですが、nginx から php を動かすのに php-fpm を使っていて、



    とすることで wp-config.php の生成も含めて、WordPressの更新ができました。
    というのが本日(23日)午前中の作業。
    で、午後にもう一度ハンズオン用のイメージでインスタンスを作り直したところ、

    html が最初から apache:apache になっていて、難なくWordPressのインストールが完了しました。
    もしかして、この間(午前から午後)にハンズオン用のイメージが修正された?
    ちょっと様子がわからないのですが、今公開されているイメージであれば、WordPressのインストール(wp-config.phpの生成)で引っかかることはなさそうです。

    [追記:2018.12.29]
    自分が使っていたリージョンが間違っていたようです。東京リージョンにあるイメージを使えば問題なさそうです。

  • Cloud9でユーザーを招待 – AWS

    メモ書き程度ですが AWS Cloud9 の環境にIAMユーザーを招待する手順。

    共有用のIAMグループを作成

    グループ名: c9group(任意)
    ポリシー名: AWSCloud9User

    共有用のIAMユーザーを作成

    ユーザー名: c9user(任意)
    ユーザーをグループに追加: c9group(任意)

    Cloud9管理用のIAMユーザーでログイン

    ユーザー名: c9admin(任意)
    所有ポリシー: AWSCloud9Administrator

    cloud9のIDEを開いて、右上の Share をクリック。
    AWS Cloud9 に関するよくある質問 – 環境の共有

    Invite Members に作成したIAMユーザー名を入力して Invite をクリックして進める。

    招待ができたら、共有用のIAMユーザーでログイン。
    cloud9のサービスを開いて Shared with you を選択。

    共有された環境の一覧から Open IDE をクリック。

    以上です。

  • WordPress + AWS S3サイトを独自ドメインでHTTPS対応

    WordPressのメディアをAWSのS3で配信するウェブサイトで、
    HTTPSに対応してみました。(備忘録)

    参考にさせていただきました。感謝。m(..)m
    WordPressサイトをCloudFrontで配信する
    Dot TKで取得した無料ドメインをRoute 53でホストする
    【無料&超簡単】S3と独自ドメインで公開しているサイトをSSL(https)化する
    AWS CloudFrontを使ってWordPressのメディアファイルだけS3に配置する
    案外簡単なAWS上のWordPressのSSL化

    以下、AWSのEC2+RDS+S3でWordPressが動いている前提です。
    example.comを独自ドメインに読みかえてください。

    作業の途中でWordPressのサイトが見えなくなったり、ダッシュボードにログインできなくなったりすることがあります。sshでec2インスタンスにログインして、wp-config.phpが編集できる状態にしておくと良いと思います。

    Route 53の設定

    Route 53コンソールを開く。

    「Create Hosted Zone」
    Domain Name: example.com
    Comment: (適宜入力)
    Type: Public Hosted Zone(デフォルト)

    「Create」して表示されるNSレコードを、独自ドメイン(契約サービス)のDNSとして設定する。

    CloudFrontの設定

    CloudFrontコンソールを開く。

    「Create Distribution」
    Webで「Get Started」

    Alternate Domain Names(CNAMEs): example.com
    と入力して、
    「Request or Import a Certificate with ACM」をクリックすると、
    AWS Certificate Manager のページが開くので、
    「証明書のリクエスト」からドメイン名を追加します。

    ドメイン名: example.com
    と入力して「次へ」
    「DNSの検証」を選択して「確認」を押すと検証のページに遷移します。

    ドメインのDNS設定にCNAMEレコードを追加

    「Route 53 でのレコードの作成」をクリックするとCNAMEが追加されます。

    オリジンの設定 – 独自ドメイン

    Origin Settings
    Origin Domain Name: example.com
    Origin Protocol Policy: HTTPS Only

    オリジンの設定 – EC2

    Origin Settings
    Origin Domain Name: (EC2インスタンスのドメイン).compute.amazonaws.com
    Origin Protocol Policy: HTTP Only

    オリジンの設定 – S3

    Origin Settings
    Origin Domain Name: (バケット名).s3.amazonaws.com

    Behavior – デフォルト

    Path Pattern: Default(*)
    Origin: (EC2インスタンスのドメイン).compute.amazonaws.com
    Viewer Protocol Policy: Redirect HTTP to HTTPS
    Allowed Encryption Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
    Cache Based on Selected Request Headers: All
    Forward Cookies: All
    Query String Forwarding and Caching: Forward all, cache based on all

    Behavior – /wp-admin/*

    Path Pattern: /wp-admin/*
    Origin: (EC2インスタンスのドメイン).compute.amazonaws.com
    Viewer Protocol Policy: Redirect HTTP to HTTPS
    Allowed Encryption Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
    Cache Based on Selected Request Headers: All
    Forward Cookies: All
    Query String Forwarding and Caching: Forward all, cache based on all

    Behavior – /wp-login.php

    Path Pattern: /wp-login.php
    Origin: (EC2インスタンスのドメイン).compute.amazonaws.com
    Viewer Protocol Policy: Redirect HTTP to HTTPS
    Allowed Encryption Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
    Cache Based on Selected Request Headers: All
    Forward Cookies: All
    Query String Forwarding and Caching: Forward all, cache based on all

    Behavior – S3

    Path Pattern: /wp-content/uploads/*
    Origin: S3バケットを選択

    SSL Insecure Content Fixer

    コンテンツのURLにHTTPが混在するとブラウザで警告が出て正しく表示されない場合。
    WordPressのプラグイン SSL Insecure Content Fixer で対処。

    非セキュアコンテンツの修正方法: シンプル
    HTTPS の検出方法: HTTP_CLOUDFRONT_FORWARDED_PROTO (Amazon CloudFront HTTPS キャッシュ済みコンテンツ)

    Offload S3

    WordPressでメディアをS3バケットで公開するためのプラグイン

    Copy Files to S3: ON
    Rewrite File URLs: ON
    CloudFront or Custom Domain: example.com
    Path: wp-content/uploads/
    Year/Month: ON
    Force HTTPS: ON