20200211のAWSに関する記事は25件です。

WordPressで作成した記事をS3に連携しエンドポイントでホスティングする

はじめに

最終的には以下のような構成を目指して構築します。
WordPress Architecture.jpg

構築作業の覚書としてQiita記事を作成しておきます。
また、この記事ではWordPressからS3に連携し、S3のエンドポイントでホスティングするまでを記載しています。
WordPress Architecture_1.png
その先のCDN、DNS部分はまた別の記事で。

本アーキテクチャのメリット

  • ColoudFrontを使用するので負荷に強い
  • サーバー容量も気にしなくて良い(訳ではないが、EC2に直接配置するよりはまし)
  • Route53は可用性100%

構築難易度とかは一旦無視していますが、メリットが非常に大きいです。
ただし、その分コストはかかりますので「ランニングコストは1円もかけたくない!」という特殊な事情があれば話は別です。

WordPressからS3に連携しHelloWorldページを閲覧できるようにする

EC2インスタンスの作成

WordPress本体を稼働させれるためのEC2を構築していきます。
今回はbitnamiのAMIを使用します。
https://bitnami.com/

1. AMIの選択

  • AWS Marketplaceタブを選択
  • wordpressで検索
  • WordPress Certified by Bitnami and Automatticを選択 AMI.png

2. インスタンスタイプの選択

今回は無料枠で使用したいこともあったのでt2.microで作成

3. インスタンスの設定

そのまま。

4. ストレージの追加

そのまま。

5. タグの追加

そのまま。

6. セキュリティグループを設定

そのまま。(最終的には必ず設定が必要だが、一旦無視する)

これでWordPressが使用できるようになるのでパブリックIPを使用してアクセスできることを確認します。

ログイン → http://#{パブリックIP}/wp-login.php
初期記事(HelloWorld) → http://#{パブリックIP}/

WordPressへの初回ログイン

WordPressの初期IDはuserで固定なのですが、パスワードは自力で調べる必要があります。
以下を参考にパスワードを調べログインします。
https://aws.amazon.com/jp/getting-started/tutorials/launch-a-wordpress-website/
 → ステップ 3: Web サイトを変更する

IAMの作成

WordPressのプラグインであるStaicPressを使用しますが、アクセスキーが必要になるので専用のIAMを作成します。
ポリシーはS3FullAccessのみアタッチします。
IAM.png

S3バケットの作成

適当な名前でバケットを作成します。

バケットポリシー

以下のとおり設定します。

 {
  "Id": "Policy1573970170037",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1573970167621",
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::#{バケット名}",
      "Principal": {
        "AWS": [
          "arn:aws:iam::#{AIMのユーザー名}"
        ]
      }
    }
  ]
}

ホスティング設定

作成したバケットをホスティングします。
S3のコンソールから、[作成したバケット名] > [プロパティ] > [Static website hosting]と選択し、以下のような設定を行う。
S3hosting.png

StaticPressをインストールする

以下の記事を参考にさせていただきました。
https://qiita.com/Ichiro_Tsuji/items/c6a52ec0ee95ead42f68

記事内でプラグインをインストールするために下記ディレクトリ配下に移動する手順がありますが、ディレクトリが存在していないという現象に遭遇しました。

/var/www/vhosts/i-xxxxxxxx/wp-content/plugins

調べてみると、bitnamiのAMIの場合はパスが異なり、下記となるそうです。

/opt/bitnami/apps/wordpress/htdocs/wp-content/plugins

https://docs.bitnami.com/virtual-machine/how-to/troubleshoot-wordpress-issues/

インストール後再実行を行うとS3に記事が連携され、S3のエンドポイントでアクセスするとHelloWorldを確認できます。
HelloWorld.png

参考文献

参考にさせていただきました。ありがとうございました。
WordPress + StaticPress S3で静的WebサイトをS3でホストする

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

設計、資料作成に活躍、クラウドサービスアイコン集

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【rails】credentials.yml.encについて

はじめに

初学者がポートフォリオ作成でハマったことをメモします。
AWSにデプロイする際credentials.yml.encでハマったので箇条書きでメモしておきます。

credentials.yml.encについて

・秘密情報を保持するためのファイル。
・configディレクトリに作成される。
・rails newで作られる。
・暗号化されておりgithubで管理出来る。
・復号化する為には同じくrails newで作成されるconfig/master.keyを使う。
・master.keyを削除してしまった場合はcredentials.yml.envを削除した後sudo EDITOR=vim rails credentials:editで新しいcredentials.yml.envとmaster.keyを作成する。
・リポジトリーをcloneした場合master.keyはコピーされていない為、master.keyをコピぺする必要がある。
・直接エディタから編集する事ができない。vimを使って編集可能。 $ EDITOR=vim bin/rails credentials:edit
・デフォルトでコメントアウトがついている為注意。
・master.keyが共有できない環境では環境変数:RAILS_MASTER_KEYを指定する。

参考にした記事

https://qiita.com/yamamoto_shuji/items/5afd9ffe13f36ff29677
https://qiita.com/scivola/items/cc06ddbfd94d3118f693

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PythonでCloudWatchのデータを取得してみた

きっかけ

CloudWatchのダッシュボードでサーバーの状態を確認する日々。
出社したらまずダッシュボードを順番に確認してー・・・って、めんどくさい!:persevere:
ダッシュボードの情報を一気に取得したい!
よし、Pythonで書こう!

PythonでCloudWatch情報を取得

Boto3のget_metric_statistics()を使ったら良さそう。
公式ドキュメント通りに、まずはBoto3でCloudWatchを読み込む準備をする。

import boto3
client = boto3.client('cloudwatch')

get_metric_statistics()は以下のように使うようだ。

response = client.get_metric_statistics(
           Namespace = 'string',
           MetricName = 'string',
           Dimensions = [
             {
               'Name': 'string',
               'Value': 'string'
             },
           ],
           StartTime = datetime(2020, 2, 11),
           EndTime = datetime(2020, 2, 11),
           Period = 123,
           Statistics = [
             'SampleCount'|'Average'|'Sum'|'Minimum'|'Maximum',
           ])

Namespace

AWS/EC2とかAWS/ElastiCacheとかAWS/RDSとか。
CloudWatchのグラフ化したメトリクスタブの詳細情報にマウスカーソルを合わせると表示される情報の一番上に書かれたものです。
CloudWatch.png

MetricName

CPUUtilizationとかMemoryUtilizationとかDiskSpaceAvailableとか。
CloudWatchのグラフ化したメトリクスタブの詳細情報にマウスカーソルを合わせると表示される情報の上から2番目、区切り線の上に書かれたものです。

Dimensions

InstanceIdとかCacheClusterIdとかDBInstanceIdentifierとか。
CloudWatchのグラフ化したメトリクスタブの詳細情報にマウスカーソルを合わせると表示される情報の区切り線の下に書かれたものです。(区切り線の下は全てDimensions情報)
上の例のようにDimensionsは以下の形で書きます。
Dimensions=[{'Name': 'string', 'Value': 'string'}]
なので具体的には
Dimensions=[{'Name': 'InstanceId', 'Value': 'i-xxxxxxxxxxx'}] や
Dimensions=[{'Name': 'Role', 'Value': 'WRITER'}, {'Name': 'DBClusterIdentifier', 'Value': 'xxxxxxxxxxx'}]
のような形になります。

Period

期間を秒数で書きます。なので
1分 → 60
5分 → 300
24時間 → 86400

Statistics

統計を書きます。

レスポンス

get_metric_statistics()のレスポンスは以下のようになります。

{'Label': 'CPUUtilization', 'Datapoints': [{'Timestamp': datetime.datetime(2020, 2, 10, 19, 8, tzinfo=tzutc()), 'Maximum': 6.66666666666667, 'Unit': 'Percent'}], 'ResponseMetadata': {'RequestId': 'xxxxxxxxxxx', 'HTTPStatusCode': 200, ...(省略)

なので
値はresponse['Datapoints'][0][Statisticsで指定した値(上のレスポンスだとMaximum)]
値の単位はresponse['Datapoints'][0]['Unit']
あたりを使えばいい感じに出来そうです。

実際に書いたもの(一部)

毎日CloudWatchで目視確認をしていたので、今回のスクリプトではスクリプト実行日時から過去24時間分を取得するようにします。
スクリプトが出来たらcronで定期実行してもいいかもしれません。

import boto3
from datetime import datetime, timedelta

client = boto3.client('cloudwatch')

def get_metric_statistics(name_space, metric_name, dimensions_values, statistic):
    # CloudWatch情報の取得
    response = client.get_metric_statistics(
               # CPU使用率の場合`AWS/EC2`が入る
               Namespace = name_space,
               # CPU使用率の場合`CPUUtilization`が入る
               MetricName = metric_name,
               # `[{'Name': 'InstanceId', 'Value': instance_id}]`が入る
               Dimensions = dimensions_values,
               # 開始日時を`スクリプト実行日時 - 1日`で指定
               StartTime = datetime.now() + timedelta(days = -1),
               # 終了日時を`スクリプト実行日時`で指定
               EndTime = datetime.now(),
               # 24時間を指定
               Period = 86400,
               # `Maximum`が入る
               Statistics = [statistic]
               )

    # 出力文作成
    response_text = name_space + ' ' + metric_name + statistic + ': ' + str(response['Datapoints'][0][statistic]) + ' ' + response['Datapoints'][0]['Unit']
    print(response_text)

# 出力対象メトリクス
instance_id = 'i-xxxxxxxxxxx'
# CPU使用率
get_metric_statistics('AWS/EC2', 'CPUUtilization', [{'Name': 'InstanceId', 'Value': instance_id}], 'Maximum')
# メモリ使用率
get_metric_statistics('System/Linux', 'MemoryUtilization', [{'Name': 'InstanceId', 'Value': instance_id}], 'Maximum')

出力結果

AWS/EC2 CPUUtilizationMaximum: 6.66666666666667 Percent
System/Linux MemoryUtilizationMaximum: 18.1909615159559 Percent

まとめ

PythonスクリプトからCloudWatchの情報を取得してみました。
今回はDatapointsが一つしかないパターンで行いましたが、期間の指定によっては複数個の出力になります。
その場合はループ処理でいい感じに必要なデータを狙い撃ちしてください。

We're hiring!

AIチャットボットを開発しています。
ご興味ある方は Wantedlyページ からお気軽にご連絡ください!

参考記事

Boto3 Docs CloudWatch

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MackerelのアラートをAWS Event Bridgeに通知してみる

はじめに

AWSのEventBridgeで、外部Saasからの通知を受け取れると記載があったので、試してみました。
Meckerel初めて使うので、お作法は良く分かっていません。。。

事前準備

EC2インスタンスをMackerelの監視対象に

  • EC2インスタンスを適当な設定で構築
    • OSはAmazonLinux 2
    • Public IPを振る(NAT Gateway等があれば不要)
  • EC2にログインし、Mackerelエージェントをインストール、APIKEYも設定しておく
curl -fsSL https://mackerel.io/file/script/amznlinux/setup-all-yum-v2.sh | MACKEREL_APIKEY='AABBCCDD' sh
※APIKEYはお使いの環境によって異なるので注意

*************************************
     Done! Welcome to Mackerel!
*************************************
※上記が表示されたらOK
  • MackerelのUIで監視対象になっているか確認 mc-mon-01.PNG

MackerelとEventBridgeの連携

Mackerelの公式の手順に沿って設定すれば問題ありません。一応、実施した内容を記載していきます。
Amazon EventBridgeにアラートを通知する

通知Channelの作成

MackerelのChannelメニューから、EventBridgeを選択して追加します。
イベント名は任意でOKです。(AWSコンソール側で表示される名前になります。)
mc-mon-02.PNG

監視対象の追加

続いて、Monitorsメニューから、ホスト死活監視を追加。
細かい設定は分からなかったので、全てデフォルトのままです。
mc-mon-03.PNG

AWSコンソールで連携設定をする

AWSコンソールのEventBridgeの画面を開くと、先ほど追加したイベントソースが表示されています。イベントバスと関連付けるを実施してください。
関連付けを行うと、ステータスがアクティブに変更されます。
mc-mon-04.PNG

アラート通知時に起動されるLambdaを作成

今回はテスト用なので、単純にログ出力するだけのLambda FunctionEventBridgeConsoleLogを定義しました。

lambda_function
import json

def lambda_handler(event, context):
    print('A alarm was notified  from Mackerel service.')
    print(event)
    return 'OK'

Event Bridgeにルールを作成

EventBridgeに新規でルールを作成し、上記で作成したLambda Functionをターゲットに設定します。詳細はキャプチャを参照してください。
ルール MackerelMonitoringRule を作成しましたと表示されれば完了です。
mc-mon-05.PNG
mc-mon-06.PNG
mc-mon-07.PNG

アラート通知→EventBridge→Lambda起動

では、実際にアラートを発生させてみます。
一番最初に構築したEC2インスタンスを、AWSコンソールからStopさせます。

しばらく放置すると、Mackerel側でアラートが発生しました。
mc-mon-08.PNG

CloudWatchで作成したルールMackerelMonitoringRuleが呼ばれているか確認します。
mc-mon-09.PNG

最後に、CloudWatch LogsでLambdaのログを確認します。
print(event)で出力したイベント情報が確認できればOKです。
この情報を元に、EC2の再起動や入れ替えなどを自動化できそうですね。

{
    "version": "0",
    "id": "ee6c34a9-ed85-e47d-e510-a355e2d9160f",
    "detail-type": "alert",
    "source": "aws.partner/mackerel.io/ys-dev-web/MackerelMonitoring",
    "account": "xxxxxxxx",
    "time": "2020-02-10T13:05:04Z",
    "region": "us-west-2",
    "resources": [],
    "detail": {
        "orgName": "ys-dev-web",
        "alert": {
            "createdAt": 1581339903296,
            "isOpen": "True",
            "monitorName": "connectivity",
            "trigger": "monitor",
            "closedAt": "None",
            "url": "https://mackerel.io/orgs/ys-dev-web/alerts/xxxxxxx",
            "openedAt": 1581339903,
            "status": "critical"
        },
        "host": {
            "name": "ip-10-0-0-102.us-west-2.compute.internal",
            "memo": "",
            "isRetired": "False",
            "id": "xxxxxx",
            "url": "https://mackerel.io/orgs/ys-dev-web/hosts/xxxxxxx",
            "status": "working",
            "roles": []
        },
        "event": "alert",
        "user": "None"
    }
}

最後に

Mackerel自体が良く分かっていないので、手順飛んでいたらすみません。。
ただ、慣れてきたらSaas監視ツールとの連携が便利になるのは間違いなさそうです。

次回は、自作のアプリケーションからカスタムイベントを登録してみたいと思います!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【小ネタ】AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた知識の整理②

概要

AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた小ネタ集②。

参考

アソシエイト資格の勉強法は以下を参照

AWS初心者がAWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法

その他の小ネタは以下を参照

整理①

IDプロバイダーとフェデレーション

  • ユーザーIDをAWSの外で管理している場合、AWSアカウントにIAMユーザーを作成する代わりに、IDプロバイダーとフェデレーションを使う
  • ウェブIDフェデレーションとSAML2.0ベースのフェデレーションの2パターンがある

ウェブIDフェデレーション

  • ウェブIDフェデレーション:モバイルデバイスでAWSの外の認証情報を使って認証しAWSサービスを使うタイプ image.png ※Amazon Cognitoの使用も推奨されている

SAML2.0ベースのフェデレーション

DDoS対策

DDoS対策(英語)
image.png

  • 基本的にはAWS Shield Standard/AWS Shied Advanced/AWS WAFの3対策
    • AWS Shield Standard:Route 53またはCloudFrontで使用する。無料。L3/L4の防御。
    • AWS Shield Advanced:Route 53、CloudFront、ELB、EC2、AWS Global Acceleratorで使用する。有料。L7、ネットワークACLを使った防御。
    • AWS WAF:CloudFront、ALB、APIGatewayで使用。有料。IPアドレス、HTTP、クエリ文字列でのアクセス制限に加え、SQLインジェクション、クロスサイトスクリプティングにも有効。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでECRにログインする時はget-loginではなくget-login-passwordを使おう

aws ecr get-login は非推奨に

コマンドリファレンスに記載されています。

Note: This command is deprecated. Use get-login-password instead.

AWS CLI Command Reference - get-login
https://docs.aws.amazon.com/cli/latest/reference/ecr/get-login.html

aws ecr get-login コマンドの出力結果は以下のようになります。

$ aws ecr get-login --no-include-email
docker login -u AWS -p <password> https://<aws_account_id>.dkr.ecr.<region>.amazonaws.com

docker login コマンド全体が標準出力されるため便利ではあるのですが
そのまま実行してしまうと、パスワードがシェルのhistoryやログファイルに
残ってしまうというリスクがあります。

aws ecr get-login-password を使う

AWS CLI Command Reference - get-login-password
https://docs.aws.amazon.com/cli/latest/reference/ecr/get-login-password.html

aws ecr get-login-password コマンドはログイン用のパスワードのみが標準出力されます。

$ aws ecr get-login-password
<password>

docker login コマンドは --password-stdin というオプションが利用可能で
パスワードを標準入力から読み込ませることができます。
以下のように aws ecr get-login-password の結果を渡すことで、
履歴やログにパスワードを残さず済みます。

$ aws ecr get-login-password | docker login --username AWS --password-stdin https://<aws_account_id>.dkr.ecr.<region>.amazonaws.com
Login Succeeded

Provide a password using STDIN
https://docs.docker.com/engine/reference/commandline/login/#provide-a-password-using-stdin

利用可能なAWS CLIのバージョン

get-login-password コマンドは AWS CLI Version 1.17.10 以降、
または2020/2/10にGAとなった Version 2で利用することができます。

注意点としては AWS CLI Version 2では get-loginコマンドは削除されているため利用できません。
Version 1.17.10 以降では 下位互換性のため、引き続き利用可能です。

The older aws ecr get-login command is still available in the AWS CLI version 1 for backward compatibility.

Breaking Changes – Migrating from AWS CLI version 1 to version 2
AWS CLI version 2 replaces ecr get-login with ecr get-login-password
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html#cliv2-migration-ecr-get-login

以上です。
参考になれば幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

そろそろaws初めてみよか#5~Cloud9環境での実行~

はじめに

awsと戯れる会も第5回目(^^♪
Cloud9環境でちゃんと開発できるようCloud9のインスタンスにもlaravel環境をセットアップしましたが
肝心のlaravel実行まではできませんでした。
今回はこの肝心の部分の記事になります♪

以前の記事はこちらから
- そろそろaws初めてみよか~まずは触れてみた~
- そろそろaws初めてみよか#2~CodeStarによるコード修正からDeployまで~
- そろそろaws初めてみよか#3~RDSとの接続~
- そろそろaws初めてみよか#4~Cloud9環境の整備~

Cloud9のビルトインサーバでの起動

Run>Run with>PHP (build-in web server)を選択します。

01.png

下ペインに現れる[New]タブの[CWD]をクリックし、ドキュメントルートphp-laravel/publicを選択します。
02.png

上のメニューからPreviewをクリックしブラウザを表示させます。
Oopsとか表示されますが、ポート番号があっていないためなので気にしない気にしない。
03.png

PHP (build-in web server)は下ペインのメッセージにある通り
Listening on http://0.0.0.0:8080
となっていますので、プレビューのURL欄をクリックし「:8080」を追加します。

04.png
04.5.png

それっぽい画面が出てきましたが…スクリプトも画像も読み込まれていません。
Chromeの別タブで同URLを表示させ、ソース表示すると判りますが
ページのURLはhttpsなのに対し、リソースのパスがすべてhttpとなっていることが原因でした。

04.6.png
04.7.png

laravelでassetとかのパスをhttpsで出力する

assetとかで指定したアドレスがことごとくhttpになっているのでhttpsになるようlaravel側で対応します。

具体的には此方の記事を参考にさせて頂きました。
Laravel5.3でSSL通信を強制する

修正したのはAppServiceProviderのboot()の定義となります。
なお本番環境にデプロイした際はhttpだったのでここではapp.envがlocal,stagingの場合のみhttpsにするとしています。
本来の商用環境ではELBも入りhttpsになると思うのでその際は修正が必要となります。

app/Providers/AppServiceProvider.php
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }

    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

修正後

app/Providers/AppServiceProvider.php
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        //

        if (config('app.env') === 'local' || config('app.env') === 'staging') {
            \URL::forceSchema('https');
        }
    }

    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }
}

これで確認するとこんな感じで正常に表示されます。
どうやらIDE内のブラウザではsvgが動かないっぽいので、動確するなら別タブで開いた方がよさそうですね!

05.png

06.png

07.png

これで本当の意味で開発環境を作ることができました!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

もしも ELB-HealthChecker で(あ|なか)ったら

もしも ELB-HealthChecker であったら

Basic 認証の対象外にする

.htaccess
AuthUserFile /path/to/.htpasswd
AuthGroupFile /dev/null
AuthName "Input ID and Password."
AuthType Basic
require valid-user

Satisfy Any
Order Deny,Allow

SetEnvIf User-Agent "^ELB-HealthChecker.*$" hc
Allow from env=hc
Deny from all

もしも ELB-HealthChecker でなかったら

https://example.com にリダイレクトさせる

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^ELB-HealthChecker.*$                                                                                                                       
RewriteRule ^.*$ https://example.com [R=301,L]
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでWordPress環境を構築する~part3~

概要

AWS学習目的で、下記記事のレシピを参考にAWS CLIでの環境構築を行う。
【Amazon3時間クッキング】材料費500円でAWSにWordPress環境を構築するレシピ ~part3~

この記事では以下の作業を行う。

  • サブネットの作成(プライベートセグメント)
  • キーペアの作成
  • セキュリティグループの作成(DBサーバー用)
    • ルールの追加
  • EC2インスタンスの作成(DBサーバー用)
  • NATゲートウェイの作成
    • メインのルートテーブルにNATゲートウェイのルートを追加
  • MySQLのインストール
    • 初期設定
    • データベース作成
    • ユーザー作成と権限の設定
  • WordPressのインストール
    • PHPのインストール
    • MySQL Clientのインストール
    • WordPressのデプロイ

環境

  • macOS Catalina

前提条件

構築

サブネットの作成(プライベートセグメント)

項目
CIDRブロック 10.0.2.0/24
名前 test-PrivateSegment
# パブリックセグメントのアベイラビリティゾーンの取得
$ aws ec2 describe-subnets --subnet-ids subnet-02558655ff2936296
{
    "Subnets": [
        {
            "AvailabilityZone": "ap-northeast-1c",
            "AvailabilityZoneId": "apne1-az1",
            "AvailableIpAddressCount": 250,
            "CidrBlock": "10.0.1.0/24",
            "DefaultForAz": false,
            "MapPublicIpOnLaunch": false,
            "State": "available",
            "SubnetId": "subnet-02558655ff2936296",
            "VpcId": "vpc-07154996e6c851750",
            "OwnerId": "403733593576",
            "AssignIpv6AddressOnCreation": false,
            "Ipv6CidrBlockAssociationSet": [],
            "Tags": [
                {
                    "Key": "Name",
                    "Value": "test-PublicSegment"
                }
            ],
            "SubnetArn": "arn:aws:ec2:ap-northeast-1:403733593576:subnet/subnet-02558655ff2936296"
        }
    ]
}

# サブネットの作成
$ aws ec2 create-subnet --vpc-id vpc-07154996e6c851750 --cidr-block 10.0.2.0/24 --availability-zone ap-northeast-1c
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-1c",
        "AvailabilityZoneId": "apne1-az1",
        "AvailableIpAddressCount": 251,
        "CidrBlock": "10.0.2.0/24",
        "DefaultForAz": false,
        "MapPublicIpOnLaunch": false,
        "State": "pending",
        "SubnetId": "subnet-069512764e560f68e",
        "VpcId": "vpc-07154996e6c851750",
        "OwnerId": "403733593576",
        "AssignIpv6AddressOnCreation": false,
        "Ipv6CidrBlockAssociationSet": [],
        "SubnetArn": "arn:aws:ec2:ap-northeast-1:403733593576:subnet/subnet-069512764e560f68e"
    }
}

# 名前の設定
$ aws ec2 create-tags --resources subnet-069512764e560f68e --tags Key=Name,Value=test-PrivateSegment

キーペアの作成

項目
名前 test-db-key
秘密鍵のファイル名 test-db-key.pem
# ディレクトリの移動
cd ~/.ssh

# キーペアの作成
$ aws ec2 create-key-pair --key-name test-db-key --query 'KeyMaterial' --output text > test-db-key.pem

# 権限の変更
$ chmod 600 test-db-key.pem

# Webサーバーに転送
$ scp -i ~/.ssh/test-key.pem ~/.ssh/test-db-key.pem ec2-user@54.249.79.116:~/.ssh/

セキュリティグループの作成

項目
グループ名 DB-Segment
説明 DB Server security group
# セキュリティグループの作成
$ aws ec2 create-security-group --group-name DB-Segment --description "DB Server security group" --vpc-id vpc-07154996e6c851750
{
    "GroupId": "sg-0e8a4425f79c7e9ce"
}

 ルールの追加

タイプ プロトコル ポート範囲 ソース
SSH TCP 22 0.0.0.0/0
MYSQL/Aurora TCP 3306 0.0.0.0/0
# SSHの有効化
$ aws ec2 authorize-security-group-ingress --group-id sg-0e8a4425f79c7e9ce --protocol tcp --port 22 --cidr 0.0.0.0/0

# MYSQL/Auroraの有効化
$ aws ec2 authorize-security-group-ingress --group-id sg-0e8a4425f79c7e9ce --protocol tcp --port 3306 --cidr 0.0.0.0/0

EC2インスタンスの作成

DBサーバー用のEC2インスタンスを作成する。

項目
AMI Amazon Linux 2 AMI (HVM), SSD Volume Type
インスタンスタイプ t2.micro
自動割り当てパブリックIP 無効化
プライベートIP 10.0.2.10
名前 DB-Server

AMIのイメージIDはここで確認をする。

項目 既定値
ストレージタイプ gp2
ストレージサイズ 8G

ストレージタイプやサイズなどは既定値で作成をする。

# EC2インスタンスの作成
$ aws ec2 run-instances --image-id ami-011facbea5ec0363b --count 1 --instance-type t2.micro --key-name test-db-key --security-group-ids sg-0e8a4425f79c7e9ce --subnet-id subnet-069512764e560f68e --private-ip-address 10.0.2.10
{
    "Groups": [],
    "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-011facbea5ec0363b",
            "InstanceId": "i-08f568e483f5aa14f",
            "InstanceType": "t2.micro",
            "KeyName": "test-db-key",
            "LaunchTime": "2020-02-11T05:43:28.000Z",
            "Monitoring": {
                "State": "disabled"
            },
            "Placement": {
                "AvailabilityZone": "ap-northeast-1c",
                "GroupName": "",
                "Tenancy": "default"
            },
            "PrivateDnsName": "ip-10-0-2-10.ap-northeast-1.compute.internal",
            "PrivateIpAddress": "10.0.2.10",
            "ProductCodes": [],
            "PublicDnsName": "",
            "State": {
                "Code": 0,
                "Name": "pending"
            },
            "StateTransitionReason": "",
            "SubnetId": "subnet-069512764e560f68e",
            "VpcId": "vpc-07154996e6c851750",
            "Architecture": "x86_64",
            "BlockDeviceMappings": [],
            "ClientToken": "",
            "EbsOptimized": false,
            "Hypervisor": "xen",
            "NetworkInterfaces": [
                {
                    "Attachment": {
                        "AttachTime": "2020-02-11T05:43:28.000Z",
                        "AttachmentId": "eni-attach-015e62e441a1e9e2f",
                        "DeleteOnTermination": true,
                        "DeviceIndex": 0,
                        "Status": "attaching"
                    },
                    "Description": "",
                    "Groups": [
                        {
                            "GroupName": "DB-Segment",
                            "GroupId": "sg-0e8a4425f79c7e9ce"
                        }
                    ],
                    "Ipv6Addresses": [],
                    "MacAddress": "0a:12:3f:55:49:96",
                    "NetworkInterfaceId": "eni-028a866898abcebea",
                    "OwnerId": "403733593576",
                    "PrivateIpAddress": "10.0.2.10",
                    "PrivateIpAddresses": [
                        {
                            "Primary": true,
                            "PrivateIpAddress": "10.0.2.10"
                        }
                    ],
                    "SourceDestCheck": true,
                    "Status": "in-use",
                    "SubnetId": "subnet-069512764e560f68e",
                    "VpcId": "vpc-07154996e6c851750",
                    "InterfaceType": "interface"
                }
            ],
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SecurityGroups": [
                {
                    "GroupName": "DB-Segment",
                    "GroupId": "sg-0e8a4425f79c7e9ce"
                }
            ],
            "SourceDestCheck": true,
            "StateReason": {
                "Code": "pending",
                "Message": "pending"
            },
            "VirtualizationType": "hvm",
            "CpuOptions": {
                "CoreCount": 1,
                "ThreadsPerCore": 1
            },
            "CapacityReservationSpecification": {
                "CapacityReservationPreference": "open"
            },
            "MetadataOptions": {
                "State": "pending",
                "HttpTokens": "optional",
                "HttpPutResponseHopLimit": 1,
                "HttpEndpoint": "enabled"
            }
        }
    ],
    "OwnerId": "403733593576",
    "ReservationId": "r-0260cad0308d0bbee"
}

# 名前の設定
$ aws ec2 create-tags --resources i-08f568e483f5aa14f --tags Key=Name,Value=DB-Server

NATゲートウェイの作成

# ElasticIPの作成
$ aws ec2 allocate-address --domain vpc
{
    "PublicIp": "18.177.56.100",
    "AllocationId": "eipalloc-04495c62f9ec8db78",
    "PublicIpv4Pool": "amazon",
    "NetworkBorderGroup": "ap-northeast-1",
    "Domain": "vpc"
}

# NATゲートウェイの作成
$ aws ec2 create-nat-gateway --subnet-id subnet-02558655ff2936296 --allocation-id eipalloc-04495c62f9ec8db78
{
    "NatGateway": {
        "CreateTime": "2020-02-11T05:55:55.000Z",
        "NatGatewayAddresses": [
            {
                "AllocationId": "eipalloc-04495c62f9ec8db78"
            }
        ],
        "NatGatewayId": "nat-08e449a89a50dd47b",
        "State": "pending",
        "SubnetId": "subnet-02558655ff2936296",
        "VpcId": "vpc-07154996e6c851750"
    }
}

メインのルートテーブルにNATゲートウェイのルートを追加

項目
送信先 0.0.0.0/0
ターゲット NATゲートウェイ
# メインのルートテーブルを出力
$ aws ec2 describe-route-tables --filter Name="association.main",Values="true"
{
    "RouteTables": [
        {
            "Associations": [
                {
                    "Main": true,
                    "RouteTableAssociationId": "rtbassoc-0b25cde6f32c2e053",
                    "RouteTableId": "rtb-03a6ba4c68af0a710",
                    "AssociationState": {
                        "State": "associated"
                    }
                }
            ],
            "PropagatingVgws": [],
            "RouteTableId": "rtb-03a6ba4c68af0a710",
            "Routes": [
                {
                    "DestinationCidrBlock": "10.0.0.0/16",
                    "GatewayId": "local",
                    "Origin": "CreateRouteTable",
                    "State": "active"
                }
            ],
            "Tags": [],
            "VpcId": "vpc-07154996e6c851750",
            "OwnerId": "403733593576"
        }
    ]
}

# ルートの追加
$ aws ec2 create-route --destination-cidr-block 0.0.0.0/0 --route-table-id rtb-03a6ba4c68af0a710 --nat-gateway-id nat-08e449a89a50dd47b
{
    "Return": true
}

ssh接続

# Webサーバーに接続
$ ssh -i ~/.ssh/test-key.pem ec2-user@54.249.79.116

# DBサーバに接続
$ ssh -i ~/.ssh/test-db-key.pem ec2-user@10.0.2.10

MySQLのインストール

10.0.2.10
# RPMファイルのインストール
$ sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm -y

# MySQLのインストール
$ sudo yum install mysql-community-server -y

# MySQLサービスの起動
$ sudo systemctl start mysqld.service

# MySQLサービスのステータス確認
$ systemctl status mysqld.service
● mysqld.service - MySQL Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled)
   Active: active (running) since 火 2020-02-11 06:38:54 UTC; 29s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
  Process: 32524 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS)
 Main PID: 32600 (mysqld)
   Status: "Server is operational"
   CGroup: /system.slice/mysqld.service
           └─32600 /usr/sbin/mysqld

 2月 11 06:38:47 ip-10-0-2-10.ap-northeast-1.compute.internal systemd[1]: St...
 2月 11 06:38:54 ip-10-0-2-10.ap-northeast-1.compute.internal systemd[1]: St...
Hint: Some lines were ellipsized, use -l to show in full.

MySQLの初期設定

10.0.2.10
# 初期パスワードの出力
$ cat /var/log/mysqld.log | grep password

# 初期設定を行う 
$ mysql_secure_installation

WordPress用のデータベースの作成

10.0.2.10
# MySQLに接続
$ mysql -u root -p

# データベースの作成
$ CREATE DATABASE wpdb DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

# ユーザーの作成
$ create user 'wpadmin'@'localhost' identified by '■■■■■■■■■';
$ create user 'wpadmin'@'10.0.1.10' identified by '■■■■■■■■■';

# デーベースの操作権限を与える
$ grant all privileges on wpdb.* to 'wpadmin'@'localhost';
$ grant all privileges on wpdb.* to 'wpadmin'@'10.0.1.10';

# ユーザーの確認
$ select user,host from mysql.user;
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| wpadmin          | 10.0.1.10 |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
| wpadmin          | localhost |
+------------------+-----------+
6 rows in set (0.00 sec)

WordPressのインストール

PHPのインストール

10.0.1.10
# PHPのインストール
$ sudo amazon-linux-extras install php7.3 -y

# 拡張モジュールの出力
$ yum list php* | grep amzn2extra-php7.3

# 関連モジュールのインストール
$ sudo yum -y install php-mysqlnd php-mbstring

MySQL Clientのインストール

10.0.1.10
# RPMファイルのインストール
$ sudo yum localinstall https://dev.mysql.com/get/mysql80-community-release-el7-1.noarch.rpm -y

# MySQLクライアントのインストール
$ sudo yum -y install mysql-community-client

# WebサーバーからMySQLの接続確認
$ mysql -h 10.0.2.10 -u wpadmin -p

WordPressのデプロイ

10.0.1.10
# 作業用ディレクトリの作成
$ mkdir ~/work

# 作業用ディレクトリに移動
$ cd ~/work

# WordPressのダウンロード
$ wget https://ja.wordpress.org/latest-ja.tar.gz

# 展開
$ tar xzvf latest-ja.tar.gz

# 展開したwordpressディレクトリに移動
$ cd wordpress/

# ファイルをapacheのDocumentRootディレクトリ配下にコピー
$ sudo cp -r * /var/www/html/

# 権限の変更
$ sudo chown apache:apache /var/www/html -R

# Apacheの再起動
$ sudo systemctl restart httpd

実際にアクセスして確認をする
http://54.249.79.116

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSクラウドプラクティショナーを受験しました。

目次

 1.試験勉強
 2.模擬試験
 3.本番試験
 4.感想・結果

1.試験勉強

 1.AWS認定クラウドプラクティショナー(トレノケート株式会社)を読む
 2.公式の模擬試験の実施
 3.AWS認定ソリューションアーキテクト(リックテレコム株式会社)を読む
 4.AWSの動画コンテンツとホワイトペーパーを読む
 合計 約20時間

2.模擬試験

 まず一通り、クラウドプラクティショナー対策本を読み覚えたので模擬試験を受けてみました。
 ほかの方の記事を読むとそこまで難しい試験ではなさそうだし大丈夫だろうと思ったら正解率50%でダメした。
 慢心ダメゼッタイ
 
 これはあかんなと思い本試験の日程を変更(2回までは日程を変更できる様です)
 1冊では試験範囲をカバーできないため、
ほかの方の記事を参考にソリューションアーキテクトの本を読みました。
 模擬試験で問われた内容がこの本に載っており、
 ソリューションアーキテクトの分野にも目を通しておいたほうが最低限読むことで
 クラウドプラクティショナーに必要な知識を学習できると感じました。

 また、AWSのホワイトペーパーも読みました。
 AWSについてのホワイトペーパーは試験のシラバスに近いので
 一通り見て内容を理解できていないと合格は難しいんじゃないかなぁと思います。
 
 なんとかクラウドプラクティショナーの範囲を網羅したと思った段階で試験に臨みました。

3 本番試験

 (私の場合)会場に入って受付をしたらロッカーに荷物を預けて免許証とクレジットカードを持って試験を受けました。
 時間は90分でしたが、たくさん時間が余ったので3回見直しをしてから試験を終了しました。
 
 

4.感想・結果

 1.結果
  815点で合格でした。2週間足らずの勉強で合格できたのはよかったです。
 2.感想
  基本的にシステムインフラを構築できる人間であれば、難しくない内容でした。
  しかしAWS特有のサービス名や、サービスの役割を0から覚えるのは、それなりに大変だと思います。
  
  (インフラSE向け)
  物理基盤の名称をAWS特有のサービス名に置き換えて考えるだけなので、
  インフラの役割を特有のサービス名に当てはめていけば、問題そのものは簡単だと思います。
  他の方の記事も参考に、参考書や模擬試験を受けて挑めば2週間もあれば合格できると思います。
  ただし慢心ダメゼッタイ
  模擬試験で問題の雰囲気とレベル感がわかるので、それを踏まえて勉強すれば大丈夫です。

  (非エンジニア向け)
  逆にシステムインフラを理解していなければ0ベースで勉強することになるので大変だと思います。
  

  広く浅く問われるので、クラウドインフラの基礎を抑えるにはとても良い試験です。
  しっかりと参考書やホワイトペーパーを理解していれば合格できる内容なので頑張ってください。
  
  今回の勉強でソリューションアーキテクトの本も読んだので忘れないうちにソリューションアーキテクトも受講していこうと思います。
 

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでWordPress環境を構築する~part2~

概要

AWS学習目的で、下記記事のレシピを参考にAWS CLIでの環境構築を行う。
【Amazon3時間クッキング】材料費500円でAWSにWordPress環境を構築するレシピ ~part2~

この記事では以下の作業を行う。

  • キーペアの作成
  • セキュリティグループの作成(Webサーバー用)
    • ルールの追加
  • EC2インスタンスの作成(Webサーバー用)
  • Apacheのインストール

環境

  • macOS Catalina

前提条件

構築

キーペアの作成

項目
名前 test-key
秘密鍵のファイル名 test-key.pem
# ~/.sshディレクトリが存在しない場合は作成
mkdir ~/.ssh

# 権限変更
chmod 700 ~/.ssh

# フォルダの移動
$ cd ~/.ssh

# キーペアの作成
$ aws ec2 create-key-pair --key-name test-key --query 'KeyMaterial' --output text > test-key.pem

# 権限の変更
$ chmod 600 test-key.pem

セキュリティグループの作成

項目
グループ名 Web-Segment
説明 Web Server security group
# セキュリティグループの作成
$ aws ec2 create-security-group --group-name Web-Segment --description "Web Server security group" --vpc-id vpc-07154996e6c851750
{
    "GroupId": "sg-04520c52a1d8cc27f"
}

# 名前の設定
$ aws ec2 create-tags --resources vpc-07154996e6c851750 --tags Key=Name,Value=Web-Segment

 ルールの追加

タイプ プロトコル ポート範囲 ソース
SSH TCP 22 0.0.0.0/0
HTTP TCP 80 0.0.0.0/0
# SSHの有効化
$ aws ec2 authorize-security-group-ingress --group-id sg-04520c52a1d8cc27f --protocol tcp --port 22 --cidr 0.0.0.0/0

# HTTPの有効化
$ aws ec2 authorize-security-group-ingress --group-id sg-04520c52a1d8cc27f --protocol tcp --port 80 --cidr 0.0.0.0/0

EC2インスタンスの作成

Webサーバー用のEC2インスタンスを作成する。

項目
AMI Amazon Linux 2 AMI (HVM), SSD Volume Type
インスタンスタイプ t2.micro
自動割り当てパブリックIP 有効化
プライベートIP 10.0.1.10
名前 Web-Server

AMIのイメージIDはここで確認をする。

項目 既定値
ストレージタイプ gp2
ストレージサイズ 8G

ストレージタイプやサイズなどは既定値で作成をする。

# EC2インスタンスの作成
$ aws ec2 run-instances --image-id ami-011facbea5ec0363b --count 1 --instance-type t2.micro --key-name test-key --security-group-ids sg-04520c52a1d8cc27f --subnet-id subnet-02558655ff2936296 --private-ip-address 10.0.1.10 --network-interfaces='[ { "DeviceIndex": 0, "AssociatePublicIpAddress": true } ]'
{
    "Groups": [],
    "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-011facbea5ec0363b",
            "InstanceId": "i-006e5f99c93e59b6a",
            "InstanceType": "t2.micro",
            "KeyName": "test-key",
            "LaunchTime": "2020-02-11T04:06:17.000Z",
            "Monitoring": {
                "State": "disabled"
            },
            "Placement": {
                "AvailabilityZone": "ap-northeast-1c",
                "GroupName": "",
                "Tenancy": "default"
            },
            "PrivateDnsName": "ip-10-0-1-10.ap-northeast-1.compute.internal",
            "PrivateIpAddress": "10.0.1.10",
            "ProductCodes": [],
            "PublicDnsName": "",
            "State": {
                "Code": 0,
                "Name": "pending"
            },
            "StateTransitionReason": "",
            "SubnetId": "subnet-02558655ff2936296",
            "VpcId": "vpc-07154996e6c851750",
            "Architecture": "x86_64",
            "BlockDeviceMappings": [],
            "ClientToken": "",
            "EbsOptimized": false,
            "Hypervisor": "xen",
            "NetworkInterfaces": [
                {
                    "Attachment": {
                        "AttachTime": "2020-02-11T04:06:17.000Z",
                        "AttachmentId": "eni-attach-0b6cc084839510e3b",
                        "DeleteOnTermination": true,
                        "DeviceIndex": 0,
                        "Status": "attaching"
                    },
                    "Description": "",
                    "Groups": [
                        {
                            "GroupName": "Web-Segment",
                            "GroupId": "sg-04520c52a1d8cc27f"
                        }
                    ],
                    "Ipv6Addresses": [],
                    "MacAddress": "0a:d9:42:fc:f4:e4",
                    "NetworkInterfaceId": "eni-0ae3beb1595c7e0f1",
                    "OwnerId": "403733593576",
                    "PrivateIpAddress": "10.0.1.10",
                    "PrivateIpAddresses": [
                        {
                            "Primary": true,
                            "PrivateIpAddress": "10.0.1.10"
                        }
                    ],
                    "SourceDestCheck": true,
                    "Status": "in-use",
                    "SubnetId": "subnet-02558655ff2936296",
                    "VpcId": "vpc-07154996e6c851750",
                    "InterfaceType": "interface"
                }
            ],
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SecurityGroups": [
                {
                    "GroupName": "Web-Segment",
                    "GroupId": "sg-04520c52a1d8cc27f"
                }
            ],
            "SourceDestCheck": true,
            "StateReason": {
                "Code": "pending",
                "Message": "pending"
            },
            "VirtualizationType": "hvm",
            "CpuOptions": {
                "CoreCount": 1,
                "ThreadsPerCore": 1
            },
            "CapacityReservationSpecification": {
                "CapacityReservationPreference": "open"
            },
            "MetadataOptions": {
                "State": "pending",
                "HttpTokens": "optional",
                "HttpPutResponseHopLimit": 1,
                "HttpEndpoint": "enabled"
            }
        }
    ],
    "OwnerId": "403733593576",
    "ReservationId": "r-043b930eee6f8945b"
}

# 名前の設定
$ aws ec2 create-tags --resources i-006e5f99c93e59b6a --tags Key=Name,Value=Web-Server

# パブリックIPを出力
$ aws ec2 describe-instances --instance-id i-006e5f99c93e59b6a --query "Reservations[].Instances[][PublicIpAddress]"
[
    [
        "54.249.79.116"
    ]
]

ssh接続する

$ ssh -i ~/.ssh/test-key.pem ec2-user@54.249.79.116

Apacheのインストール

10.0.1.10
# Apacheのインストール
$ sudo yum -y install httpd

# Apacheサービスの起動
$ sudo systemctl start httpd

# Apacheサービスのステータス確認
$ systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since 火 2020-02-11 04:08:49 UTC; 7s ago
     Docs: man:httpd.service(8)
 Main PID: 3616 (httpd)
   Status: "Processing requests..."
   CGroup: /system.slice/httpd.service
           ├─3616 /usr/sbin/httpd -DFOREGROUND
           ├─3617 /usr/sbin/httpd -DFOREGROUND
           ├─3618 /usr/sbin/httpd -DFOREGROUND
           ├─3619 /usr/sbin/httpd -DFOREGROUND
           ├─3620 /usr/sbin/httpd -DFOREGROUND
           └─3621 /usr/sbin/httpd -DFOREGROUND

 2月 11 04:08:49 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: St...
 2月 11 04:08:49 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: St...
Hint: Some lines were ellipsized, use -l to show in full.

実際にアクセスして確認をする
http://54.249.79.116

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでWordPress環境を構築する~part1~

概要

AWS学習目的で、下記記事のレシピを参考にAWS CLIでの環境構築を行う。
【Amazon3時間クッキング】材料費500円でAWSにWordPress環境を構築するレシピ

この記事では以下の作業を行う。

  • VPCの作成
  • サブネットの作成(パブリックセグメント)
  • インターネットゲートウェイの作成
  • ルートテーブルの作成

環境

  • macOS Catalina

前提条件

  • AWSアカウント
  • AWS CLI
    • aws configureで設定済み

構築

VPCの作成

項目
リージョン アジアパシフィック(東京)
CIDRブロック 10.0.0.0/16
名前 test-VPC
# VPCの作成
$ aws ec2 create-vpc --region ap-northeast-1 --cidr-block 10.0.0.0/16
{
    "Vpc": {
        "CidrBlock": "10.0.0.0/16",
        "DhcpOptionsId": "dopt-81eaa2e6",
        "State": "pending",
        "VpcId": "vpc-07154996e6c851750",
        "OwnerId": "403733593576",
        "InstanceTenancy": "default",
        "Ipv6CidrBlockAssociationSet": [],
        "CidrBlockAssociationSet": [
            {
                "AssociationId": "vpc-cidr-assoc-0a6334afa0f843a96",
                "CidrBlock": "10.0.0.0/16",
                "CidrBlockState": {
                    "State": "associated"
                }
            }
        ],
        "IsDefault": false,
        "Tags": []
    }
}

# 名前の設定
$ aws ec2 create-tags --resources vpc-07154996e6c851750 --tags Key=Name,Value=test-VPC

サブネットの作成(パブリックセグメント)

項目
CIDRブロック 10.0.1.0/24
名前 test-PublicSegment
# サブネットの作成
$ aws ec2 create-subnet --vpc-id vpc-07154996e6c851750 --cidr-block 10.0.1.0/24
{
    "Subnet": {
        "AvailabilityZone": "ap-northeast-1c",
        "AvailabilityZoneId": "apne1-az1",
        "AvailableIpAddressCount": 251,
        "CidrBlock": "10.0.1.0/24",
        "DefaultForAz": false,
        "MapPublicIpOnLaunch": false,
        "State": "pending",
        "SubnetId": "subnet-02558655ff2936296",
        "VpcId": "vpc-07154996e6c851750",
        "OwnerId": "403733593576",
        "AssignIpv6AddressOnCreation": false,
        "Ipv6CidrBlockAssociationSet": [],
        "SubnetArn": "arn:aws:ec2:ap-northeast-1:403733593576:subnet/subnet-02558655ff2936296"
    }
}

# 名前の設定
$ aws ec2 create-tags --resources subnet-02558655ff2936296 --tags Key=Name,Value=test-PublicSegment

インターネットゲートウェイの作成

項目
名前 test-IGW
# ゲートウェイの作成
$ aws ec2 create-internet-gateway
{
    "InternetGateway": {
        "Attachments": [],
        "InternetGatewayId": "igw-069600493ea4658d1",
        "Tags": []
    }
}

# 名前の設定
$ aws ec2 create-tags --resources igw-069600493ea4658d1 --tags Key=Name,Value=test-IGW

# VPCにインターネットゲートウェイをアタッチ
$ aws ec2 attach-internet-gateway --vpc-id vpc-07154996e6c851750 --internet-gateway-id igw-069600493ea4658d1

カスタムルートテーブルの作成

項目
名前 test-PublicRouteTable
送信先 0.0.0.0/0
# カスタムルートテーブルの作成
$ aws ec2 create-route-table --vpc-id vpc-07154996e6c851750
{
    "RouteTable": {
        "Associations": [],
        "PropagatingVgws": [],
        "RouteTableId": "rtb-0e03cccb92108b0d1",
        "Routes": [
            {
                "DestinationCidrBlock": "10.0.0.0/16",
                "GatewayId": "local",
                "Origin": "CreateRouteTable",
                "State": "active"
            }
        ],
        "Tags": [],
        "VpcId": "vpc-07154996e6c851750",
        "OwnerId": "403733593576"
    }
}

# 名前の設定
$ aws ec2 create-tags --resources rtb-0e03cccb92108b0d1 --tags Key=Name,Value=test-PublicRouteTable

# インターネットゲートウェイへのすべてのトラフィック (0.0.0.0/0) をポイントするルートテーブルでルートを作成
$ aws ec2 create-route --route-table-id rtb-0e03cccb92108b0d1 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-069600493ea4658d1
{
    "Return": true
}

ルートテーブル サブネットの関連付け

$ aws ec2 associate-route-table  --subnet-id subnet-02558655ff2936296 --route-table-id rtb-0e03cccb92108b0d1
{
    "AssociationId": "rtbassoc-04f4894cba1ed2dab",
    "AssociationState": {
        "State": "associated"
    }
}

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]DBレイヤを冗長化する方法

2020年2月11日現在の内容です。

構成イメージ
スクリーンショット 2020-02-11 16.26.41.png

マスタースレーブ構成の作成

RDSではマルチAZ機能でマスタースレーブ構成を構築できる

AWSコンソールからRDSを検索し、クリック
スクリーンショット 2020-02-11 16.32.01.png

サイドバーから「データベース」をクリック
スクリーンショット 2020-02-11 16.34.10.png

対象のデータベースをクリック
スクリーンショット 2020-02-11 16.35.27.png

「変更」をクリック
スクリーンショット 2020-02-11 16.37.21.png

マルチAZ配置を「はい」に変更し、「次へ」をクリック
スクリーンショット 2020-02-11 16.39.38.png
スクリーンショット 2020-02-11 16.41.41.png

すぐに適用にチェックし、「DBインスタンスの変更」をクリック
スクリーンショット 2020-02-11 16.43.03.png

マルチAZが「あり」になっていることを確認
スクリーンショット 2020-02-11 16.54.23.png

注:マルチAZ配置にするとRDSが複数起動している状態となるので、料金が高額になる可能性がある

参考

AWS:ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Cron式で「第○○曜日」を設定する方法

AWSでCloudWatch Eventsを使おうとして、
クーロン式で「第2日曜日」、「第3土曜日」みたく月次で曜日を指定して動かしたくなったので、調べてみた。

設定方法

少し調べた結果、SUN#4等でいけるっぽいです。
公式見たら普通に書いてありました。

使用例:毎月第4日曜日の午前9時

00 09 ? * SUN#4 *

曜日は1~7、もしくはSUN~SATで設定できますが、SUNとかの方がわかりやすいかも?

参考記事

公式を確認(結果的にこれで十分でした)
 リファレンス: Systems Manager の Cron および Rate 式
基本的な所はこ記事が参考になりました。
 AWS_Cron式のワイルドカード
 cronで第何何曜日にスクリプトを実行するか指定する

あと、CloudWatch Events設定するときは時差(UTCとJST)を考慮すべしです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSCDKでLambda(Nodejs)をTypeScriptのままデプロイする

はじめに

AWSCDKでNodejsのLambdaをTypeScriptで書いているときに、デプロイする前にJavaScriptにビルドする必要がなくなったので、その方法を紹介します。

使うパッケージ

AWSCDK v1.23.0 から @aws-cdk/aws-lambda-nodejs というパッケージがリリースされました。
このパッケージを使えばTSをビルドすることなくデプロイすることができます。

実際に何をやっているかというと、デプロイする前に内部でParcelを使ってビルドをしてくれます。
詳しくはこちらを確認してください。

サンプル

stack.ts
import cdk = require("@aws-cdk/core")
import { NodejsFunction } from "@aws-cdk/aws-lambda-nodejs"

export class NodejsFunctionStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props)

    new NodejsFunction(this, "NodejsFunction", {
      entry: "lambdaSources/demo_function/index.ts",
      handler: "handler",
      minify: true
    })
  }
}

NodejsFunctionentry に対してTSファイルを指定しています。
これでデプロイをすると .build というディレクトリが生成され、そこにビルド後のソースが置かれています。

さいごに

これで今までLambdaのソースをTypeScriptで書いているときに、デプロイをする前にビルドする必要があったところが不要になったので、地味に嬉しいアップデートでした。
ではまた!!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのインスタンス、作ったenvironmentがなくなった(初歩)

AWS、Cloud9で作った仮想環境が見つからなかった

左のメニューバー、”your environments”をクリックしても、画面遷移しない。create environmentsで作った環境が見つからない。
スクリーンショット 2020-02-11 14.50.30.png

リージョンが原因だった

ページ右上のリージョンがオハイオになっていた。
スクリーンショット 2020-02-11 14.53.33.png

東京を選択して、”your environments”をクリック。
スクリーンショット 2020-02-11 14.54.53.png

作った"my-demo-環境"が見つかった。
スクリーンショット 2020-02-11 14.50.08.png

所感

初歩的なことかもしれませんが、AWSでトラブったら、リージョンを確認してみましょう。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS試験対策(①基礎知識)

 はじめに

ここは、AWSの知識を自分なりにアウトプットする場です。
自分用メモなので人に見られるのは恥ずかしいですが、インプットばかりではいけないと思いたち、作成した次第。
主に試験対策であります。2月中にSAA取得が目標。先輩に負けん。
3月からは試験対策というよりは、Dockerとか触って、自分の備忘録として積み立てていく予定。
予定なのでまだ確定ではないですが。qiitaで色々見て、楽しそうとか流行ってるとかそういう技術を見つけたらそっちを触るかも。初心者おすすめなものを教えて下さい。
「ここ違うよ!」とか「ここはこう覚えると試験楽だよ!」とか「これはこれの構築を目標に一回手を動かして試してみたほうがいいよ!」とか、あれば教えてくれると励みになります。

また、qiita初心者のため、最初の方は見出しとか色々見にくいと思います。。。
次第に編集技術も見についていくと思うので暖かい目で見守ってください。(スマホから更新しにくい…)
そもそも誰も見てない説もありますが自分用メモなのでそれでも全然いいや。体裁汚くて載せれない〜〜ってうだうだやるより、汚くてもいいからとにかくアウトプットして覚えたほうがいいという考え。

ほぼ参考書書き写しかもしれないけど自分なりの言葉で説明できるところ、できないところが分かって自分の理解度が把握に繋がると思いやってます。すでにもっと読みやすい記事があるからと言ってやめてたらいつまでもアウトプットできないことに気づいた。

本題に入ります。
①なのでまずは基礎の基礎から。

 アベイラビリティゾーン

AZと略される。(かっこいい)データセンターそのものや、近隣DCの集まり。
特徴:他のAZに火災や地震など、物理的な障害が発生しても、影響ない場所に各AZが存在してる。

 リージョン

アベイラビリティゾーンを地域ごとにまとめたもの。国内では東京リージョンがある。大阪もあるけど成約ありなのでメインは東京。

 エッジロケーション

コンテンツキャッシュとかDNSサービスとかセキュリティの機能を提供するDC?
100箇所以上あるらしい
イメージとしては、AmazonがDCにDNSサーバたてて、それをサービスとして貸し出してるみたいな感じ(憶測で言ってるので違ったらアレ)

可用性を英語でアベイラビリティっていうらしい
直訳で可用性ゾーンってその名の通り、可用性欲しかったら2つのAZにまたがって冗長化するべき
これがマルチAZ配置
AZ1とAZ2にそれぞれインスタンスたてて、Amazonのロードバランサーで負荷分散させたらそれたけで可用性高め。なんと簡単な。

 AWSマネジメントコンソール

AWSにログインして、実際にいじるところ
インスタンス立てたければEC2クリックして新しいインスタンス選んでOS選べば建てれる。構築したことない初心者にもやさしいね!

これのコマンドライン版もある。AWS CLI(そのままやん)
やることは一緒だからCUIがいいかGUIがいいかくらいの違いしかないと思う。なれてる方でいいんじゃね(適当)

 AWS SDK

ソフトウェア開発キット。プログラミングするときに使うらしいけど使ったことないしよくわかんない、確認してみねば

 AWSサポート

4つのプランがある。
ベーシック、開発者、ビジネス、エンタープライズ。後のほうが高いけどサポート充実してる。

ベーシックは無料なのでできることは限られてる。しかし、ベーシックでも掲示板、請求の相談、製品FAQ、サービスダッシュボード(?)、AWSサービスの上限緩和申請ができる
この上限緩和、めちゃくちゃ大事。
VPCの数とか、IAMユーザーの数とか、制限があるらしいんだけど、それを超えることができる。

開発者から上は技術の問い合わせができる。
開発者はメールで営業日のみ対応だが、ビジネスとエンプラは24365対応してくれるらしい。しかも電話やチャットもある。格差社会。
返信スピードも違うらしい。開発者は最短12時間。ビジネスなら1時間。エンプラは15分。格差社会。

ビジネスより上はtrusted advisorってのが使える。
要するに、今の環境を分析して、もっとこうしたほうがいいよ!って言ってくれる。アドバイザー。
ベストプラクティスは5つあって、コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービスの制限に分かれてる。

エンプラのみ、TAMってのがつく。運用のサポートをしてくれる、いわばコンシェルジュ的な?
他のプランより月額が高いので大企業メインらしい。

 well-architected framework

W-Aって言うらしい。要するに今設計してるシステムや、これから設計するシステムがイケてるかイケてないか、5つの柱から考えてくれるらしい。
trusted advisorに似てね??あっちはリアルタイムだし観点がちがうってこと?
こっちは運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化…ってほぼ同じやんけ!
違う点あったら教えて下さい…まあどっちも試験の重要度は低そうだし関係ないな!(フラグ)

第一章はここまで!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CI/CD on AWS ハンズオン勉強会に参加してきた

MarkingCloudさん主催の勉強会 明日から職場で業務改善!CI/CD on AWS ハンズオン の参加レポートです。

1時間のハンズオンでCI/CDってすごい! 便利! と実感できる内容でした:smile:

勉強会の概要

全体の流れはこんな感じです。

  • コミュニティの説明
  • 参加者同士の自己紹介
  • ハンズオン(1時間)
  • 懇親会

MarkingCloudとは?

MarkingCloud - connpass

クラウド関連の勉強会を開催されている団体です。
初心者向けのハンズオンを色々なテーマで企画してくださっています。

どんな人が参加しているの?

筆者が交流させていただいた範囲だけでも、

  • 初心者から仕事でAWSの他のサービスを使っている人、独学で勉強中の人まで
  • Web系エンジニアからクラウドNGなお堅い業界の方まで

いろいろな方が参加されていました。
普段の業務とは違う分野の方のお話を聞けるのも面白いです。

勉強会のゴール

AWSでCI/CDを実現することじゃないの? と思いますが、さらに一歩踏み込んで

主催者様「明日、職場で上司にCI/CDの必要性を訴えましょう!!

とのことでした。
実際に上司を説得した方はいたのでしょうか? :eyes:

ハンズオン

ブログ用にメモをとりたかったのですが、ついていくのに必死で無理でした…

当日の資料 を眺めつつ、復習がてら書いていきます。

作るシステムの概要

AWS 2020-02-11 144027.png

当日の資料 から画像を拝借しました。

CodeCommitにソースコードをコミットすると、CodeBuildで自動ビルドされ、Lamdaにデプロイされる…という仕組みを作ります。

IAMユーザーを作成する

IAM = AWS Identity and Access Management

AWSの各サービスを使うために、ルートユーザーとしてサインインする以外にIAMユーザーとして認証する方法があるようです。
各IAMユーザーごとに、必要なサービスのみのアクセス権限を付与できるようです。

ここでは、後でCodeCommitにプッシュする用のユーザー&認証情報を作成します。

CI/CDの各パーツを作成する

時間の関係上、ここではAWSのCloudFormationを使って自動で作成してしまいます。
主催者様側で用意してくださっているテンプレートファイルを使います。

何が起きているのか分からないうちに、あっという間にできてしまいます。

コードをコミット~自動ビルド・自動デプロイ

上記で作成済みのCodeCommitのリポジトリをクローンしてきて、用意してくださっているコードをコミット&プッシュします。
最初に作成したIAMユーザーの認証情報を使います。
(クローンで詰まる人が多発していました…。一度パスワードを間違えると、間違った認証情報が記憶されてしまってうまくいかないようです。)

無事プッシュできると、自動でビルド&デプロイされていきます…! これは便利!
しかし時間は割とかかります。

出来上がったLambdaの関数を実行してみる

コードをコミットしただけでよく分からないけど関数が出来上がっていました!

コードを適当に変更して再度コミットしてみると、勝手に反映されてくれます。
(ここでも時間はかかりますが…)

ある程度遊んだら、今作ったものたちは削除しておきます。
せっかく作ったばかりなのに勿体ないですが、余計な料金が発生してしまうので…。

感想

  • EC2しか触ったことなかったけど、こんなこともできるんだ!
  • ハンズオンはかなりさくさく進むので、初心者は要復習
  • 懇親会で普段聞けない話を聞けるのが楽しい

これからも予定が合って枠が余っている時は参加していきたいです:smile:

次回イベントの予定も公開されていました↓
新しい技術に触れてみる!Firebaseで「お問い合わせフォーム」作成ハンズオン

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]Webレイヤを冗長化する方法

2020年2月11日現在の内容です。

構成イメージ
スクリーンショット 2020-02-08 16.03.54.png

用語説明

単一障害点(Single Point Of Failure)

その箇所で障害が発生すると全体が停止する箇所

冗長化

システムの構成要素を多重化すること
    ↓
ある構成要素で障害が発生しても処理を引き継げるようにすることで稼働率を高めることができる
(単一障害点をなくす)

プロビジョニング

アクセス数などを予測し適切にリソースを準備すること

ロードバランサー

各サーバーにアクセスを振り分け、負荷を分散させる装置

ELB(Elastic Load Balancing)

AWSクラウド上のロードバランサー

概要

  • 複数のEC2インスタンスに負荷分散する
  • 複数のアベイラビリティゾーンにある複数のEC2インスタンスの中から正常なターゲットにのみ振り分ける(ヘルスチェック)

特徴

  • スケーラブル:ELB自体も負荷に応じて自動でスケールアウト・スケールインする
  • アベイラビリティゾーンをまたがる構成:ELBを利用する場合、1つのリージョンを選び、そのリージョン内のアベイラビリティゾーン全てを対象にする
  • 名前解決:ELBにはDNS名が割り当てられる。ELBへの接続へのアクセスにはDNSを使用する
  • 安価な従量課金:従量課金で利用可能
  • マネージドサービス:運用が楽

稼働率を上げる

稼働率を高くするための考え方

  • 障害発生間隔を長くする
  • 平均復旧時間を短くする

稼働率を上げる具体的な方法

  • 要素単体の稼働率を高くする (AWSでは難しい)
  • 要素を組み合わせて、全体の稼働率を高くする
  • 負荷を適切なプロビジョニングで回避する

要素を組み合わせることで、サービスの構成を冗長化する
冗長化構成

  • Active-Active:冗長化した両方が利用可能
  • Active-Standby:冗長化した片方は利用不可能
    • Hot Standby:スタンバイ側は普段起動しすぐに利用可能
    • Warm Standby:スタンバイ側は普段起動しているが、利用するのに準備が必要
    • Cold Standby:スタンバイ側は普段停止している

負荷を適切なプロビジョニングで回避する

スケールアップ

  • 個々の要素の性能を向上させる
  • ある程度の規模まではスケールアップはコストパフォーマンスが良いが、一定範囲を超えると悪くなる

スケールアウト

  • 個々の要素の数を増やす
  • ある程度の規模を超える場合、スケールアウトで対応する
  • 最低限N+1構成を用意、N+2構成であれば安心 (N=サービス提供に必要な台数)

サーバー構成のベストプラクティス

基本的な構成
1台のサーバーでWebとDBを運用する
スクリーンショット 2020-02-08 22.03.44.png

パターン:Webサーバー×1、DBサーバー×1 構成
1台のサーバースペックが足りなくなった時に、DBを別のサーバーに切り出す
スクリーンショット 2020-02-08 22.09.14.png

パターン:Webサーバー×2、DBサーバー×1 構成
Web側の性能が足りない時に、Webサーバーを複数台使うことで、Web側の冗長化と負荷分散を行う
スクリーンショット 2020-02-08 22.12.03.png

パターン:Webサーバー×2、DBサーバー×2 構成
DBをマスタースレーブ方式にすることで、DBの冗長化を行う
(Webの冗長化と負荷分散、DBの冗長化ができる)
スクリーンショット 2020-02-08 22.25.48.png

AMIからEC2を起動

負荷分散用Webサーバーを構築する

パブリックサブネットを作成
スクリーンショット 2020-02-09 9.11.40.png
スクリーンショット 2020-02-09 9.13.04.png
スクリーンショット 2020-02-09 9.20.19.png

ルートテーブルを関連付ける
スクリーンショット 2020-02-09 9.14.41.png
スクリーンショット 2020-02-09 9.18.07.png
スクリーンショット 2020-02-09 9.21.52.png

EC2 → インスタンスから負荷分散元のEC2インスタンスを選択
アクション → イメージ → イメージの作成をクリック
スクリーンショット 2020-02-09 9.24.54.png

イメージ名、イメージの説明に任意の名前を入力し、「イメージの作成」をクリック
スクリーンショット 2020-02-09 9.28.09.png

イメージの作成を確認
スクリーンショット 2020-02-09 10.04.05.png

サイドバーから「AMI」をクリック
スクリーンショット 2020-02-09 10.06.55.png

作成したAMIを選択し、「起動」をクリック
スクリーンショット 2020-02-09 10.09.07.png

タイプは「t2.micro」を選択し、「次のステップ」をクリック
スクリーンショット 2020-02-09 10.11.35.png

以下の通り設定し、「次のステップ」をクリック
ネットワーク:作成したVPC
サブネット:作成したサブネット
自動割り当てパブリックIP:有効
キャパシティーの予約:なし
プライマリIP:10.0.11.10
スクリーンショット 2020-02-09 10.13.52.png
スクリーンショット 2020-02-09 10.19.29.png

ストレージは変更せずに、「次のステップ」をクリック
スクリーンショット 2020-02-09 10.21.13.png

タグを任意追加し、「次のステップ」をクリック
スクリーンショット 2020-02-09 10.22.39.png

既存のセキュリティグループ → 負荷分散元のEC2インスタンスと同じセキュリティグループを選択し、「確認と作成」をクリック
スクリーンショット 2020-02-09 10.25.54.png

設定内容に問題がないことを確認し、「起動」をクリック
スクリーンショット 2020-02-09 10.28.19.png

既存のキーペアを選択し、「インスタンスの作成」をクリック
スクリーンショット 2020-02-09 10.30.03.png

EC2インスタンスが作成されていることを確認
スクリーンショット 2020-02-09 10.36.00.png

ELBの作成

サイドバーから「ロードバランサー」をクリック
スクリーンショット 2020-02-11 10.05.25.png

「ロードバランサーの作成」をクリック
スクリーンショット 2020-02-11 10.06.19.png

Application Load Balancerの「作成」をクリック
スクリーンショット 2020-02-11 10.09.27.png

以下の通り設定し、「次の手順」をクリック
名前:任意名
VPC:EC2インスタンスを配置しているVPC
サブネット:EC2インスタンスを関連付けているパブリックサブネット
スクリーンショット 2020-02-11 10.12.06.png

「次の手順」をクリック
スクリーンショット 2020-02-11 10.30.56.png

新しいセキュリティグループを作成するを選択し、「次の手順」をクリック
セキュリティグループ名,説明:任意名
スクリーンショット 2020-02-11 10.33.02.png

以下の通り設定し、「次の手順」をクリック
名前:任意名
詳細設定:適宜設定
スクリーンショット 2020-02-11 10.44.41.png

ELBの対象とするインスタンスを選択し、「登録済みに追加」をクリック
スクリーンショット 2020-02-11 10.48.22.png

登録済みターゲットにインスタンスが追加されていることを確認し、「次の手順」をクリック
スクリーンショット 2020-02-11 10.51.25.png

設定内容に問題がないことを確認し、「作成」をクリック
スクリーンショット 2020-02-11 10.55.10.png

ロードバランサーが作成されていることを確認
スクリーンショット 2020-02-11 11.03.33.png

DNS名をブラウザでアクセスし、ELBにアクセスできることを確認
スクリーンショット 2020-02-11 11.05.28.png
スクリーンショット 2020-02-11 11.08.27.png

独自ドメインからELBにアクセス

AWSコンソールからRoute 53を検索し、クリック
サイドバーから「ホストゾーン」をクリック
対象のドメイン名をクリック
スクリーンショット 2020-02-11 11.21.28.png
スクリーンショット 2020-02-11 11.14.49.png
スクリーンショット 2020-02-11 11.16.32.png

Aレコードを選択
スクリーンショット 2020-02-11 11.24.24.png

以下の通り設定し、「レコードセットの保存」をクリック
エイリアス:「はい」
エイリアス先:作成したELB
スクリーンショット 2020-02-11 11.26.40.png

レコードセットが保存されていることを確認
スクリーンショット 2020-02-11 11.30.38.png

ヘルスチェックの確認

アベイラビリティゾーン「1a」のApacheを停止させる
スクリーンショット 2020-02-11 11.38.24.png
ssh -i test-ssh-key.pem ec2-user@18.179.167.73
sudo systemctl stop httpd.service

サイドバーから「ターゲットグループ」をクリック
スクリーンショット 2020-02-11 11.44.50.png

「ターゲット」をクリック
スクリーンショット 2020-02-11 11.46.48.png

アベイラビリティゾーン「1a」のステータスが「unhealthy」になっていることを確認
スクリーンショット 2020-02-11 11.48.25.png

ELBを運用する際のポイント

  1. サーバーはアベイラビリティゾーンを分けて配置する
  2. Webサーバーはステートレスに構築する

おまけ(ELBからEC2インスタンスを削除)

EC2 → ターゲットグループ → ターゲット → 編集をクリック
スクリーンショット 2020-02-11 12.11.16.png

削除対象のEC2インスタンスを選択し、「削除」をクリック
スクリーンショット 2020-02-11 12.12.11.png

EC2インスタンスが削除されたことを確認し、「保存」をクリック
スクリーンショット 2020-02-11 12.14.27.png

参考

AWS:ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DDoS攻撃に対処する WAF サンドイッチ構成とは

はじめに

  • Solution Architect の勉強で出てきた問題に WAF サンドイッチのアーキテクチャができてたのでその理解のため
  • 参考にした資料 (AWS初心者向けWebinar AWS上でのDDoS対策) が 2015 年のものなので、現在ではベストプラクティスではないかもしれないので注意
    • ELB を利用している点や、AWS WAF が ALB に適用できるようになっている点などから

DDoS とは

  • Distributed Denial of Service Attack のこと
  • ウェブサイトやアプリケーションをエンドユーザーが利用できないようにすることを目的とした攻撃
    • 攻撃者は、これを行うために、ネットワークやその他のリソースを消費するさまざまな手法を用いて、正規のエンドユーザーのアクセスを中断させる
    • DoS とは異なり、攻撃者は複数のシステムを使用して標的に対する攻撃を指揮する

WAF (ウェブアプリケーションファイアウォール) とは

  • ウェブトラフィックにルールセットを適用するフィルター
    • 通常、これらのルールはクロスサイトスクリプト (XSS) や SQL インジェクション(SQLi) といった弱点に対応
    • HTTP GET または POST フラッドを軽減して、DDoS に対する弾力性を構築するためにも役立つ
      • HTTP レート制限で、特定の期間にわたりエンドユーザーごとにサポートされる HTTP リクエストのしきい値を決めることが可能
        • そのしきい値を超えると、WAF は新しいリクエストをブロックまたはバッファリングし、他のエンドユーザーがアプリケーションにアクセスできるようにできる
      • HTTP リクエストを検査し、通常のパターンに準拠しないものを識別
        • 文字制限を超えているログインを防止したり、全件検索を防止するなど
  • AWS WAF は、CloudFront、Application Load Balancer (ALB)、API Gateway にデプロイできる
  • AWS WAF とは別に AWS Market Place にて EC2 にデプロイするための WAF アプリケーションが販売されている

WAF サンドイッチを利用する目的

  • アプリケーションレイヤーで発生する DDoS 攻撃を防ぐため
    • インフラストラクチャ攻撃と比較して、トラフィックのボリュームが低いウェブアプリケーションがよく標的になる
    • 攻撃を軽減するには、インフラストラクチャの一部に WAF を含める
  • ここで利用する WAF は AWS WAF ではなく、EC2 にデプロイした WAF アプリケーション

WAF サンドイッチのアーキテクチャ

image.png

  • 2つの ELB の間に WAF アプリケーションを乗せた EC2 インスタンスを Auto Scaling グループで実行
    • すべての HTTP リクエストを検査するため、トラフィックスパイクに対応する必要があり、Auto Scaling グループが必要
  • トラフィックが検査およびフィルタリングされると、WAF EC2 インスタンスは内部のバックエンドロードバランサーにトラフィックを転送し、このロードバランサーがトラフィックをアプリケーションの EC2 インスタンス間に分散

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS] TerraformでデフォルトEBS最適化のEC2インスタンスを作成するときの注意点

TL;DR

デフォルトでEBS最適化となるインスタンスタイプでは、AWSコンソール上はEBS最適: FalseでもEBS最適化は有効となっている(らしい)。
TerraformでEC2インスタンスを作成するときは、ebs_optimizedの指定を気にしなくてもよさそう。

検証環境

  • macOS Catalina
  • Terraform v0.12.20

EBS最適化とは

EC2インスタンスの記憶領域にはEBSを割り当てることができ、インスタンスとEBSはネットワークで接続しています。
EBS最適化とは、このネットワークに専用帯域を割り当てることです。

EC2のインスタンスタイプによって、EBS最適化を利用できるかどうかが決まっており、利用できるタイプの中でも最適化の設定がデフォルトで有効になっているものとインスタンス作成時に明示的に設定する必要があるものが存在します。

Amazon EBS – 最適化インスタンス

開発環境や検証でよく利用するt系のインスタンスでは、t3シリーズからEBS最適化がデフォルトで有効となっています。
下図は、AWSコンソールからt3-microのEC2インスタンスを起動した際の、インスタンスの情報です。

ebs_true.png

起動時にEBSの設定には特に触っていませんが、EBS最適化はTrueとなっています。

TerraformでデフォルトEBS最適化のインスタンスを作成してみる

今回問題となったのは TerraformからEC2インスタンスを作成した場合です。

検証として、以下のtfファイルを作成します。

VPCやサブネット等のネットワーク周りのリソースを用意し、その上でEC2インスタンスを一台起動するシンプルな内容です。

main.tf
provider "aws" {
  version = "~> 2.0"
  profile = "default"
  region  = "ap-northeast-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "sample_vpc"
  }
}

resource "aws_subnet" "public" {
  vpc_id            = "${aws_vpc.main.id}"
  cidr_block        = "10.0.0.0/24"
  availability_zone = "ap-northeast-1a"

  tags = {
    Name = "sample_public_subnet"
  }
}

resource "aws_internet_gateway" "main" {
  vpc_id = "${aws_vpc.main.id}"

  tags = {
    Name = "sample_internet_gateway"
  }
}

resource "aws_route_table" "main" {
  vpc_id = "${aws_vpc.main.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.main.id}"
  }

  tags = {
    Name = "sample_route_table"
  }
}

resource "aws_route_table_association" "public" {
  subnet_id      = "${aws_subnet.public.id}"
  route_table_id = "${aws_route_table.main.id}"
}

resource "aws_security_group" "ec2" {
  name        = "sample-ec2-sg"
  description = "This is sample"
  vpc_id      = "${aws_vpc.main.id}"

  ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
      from_port   = 0
      to_port     = 0
      protocol    = "-1"
      cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "sample_ec2_security_group"
  }
}

data "aws_ssm_parameter" "latest_amzn2_ami" {
  name = "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2"
}

resource "aws_instance" "sample" {
  ami                    = "${data.aws_ssm_parameter.latest_amzn2_ami.value}"
  instance_type          = "t3.micro"
  vpc_security_group_ids = ["${aws_security_group.ec2.id}"]
  subnet_id              = "${aws_subnet.public.id}"
  # 各々のキーペアに置き換え
  key_name               = "your-key-pair"

  tags = {
    Name = "sample_ec2_instance"
  }
}

terraform applyコマンドでAWSリソースを作成します。

terraform apply

作成されたEC2インスタンスの情報をコンソールから確認すると、

ebs_false.png

EBS最適化の項目がFalseになってしまっています。

EBS最適化をTrueにするには

ebs_optimized = trueオプションを追加しましょう。

resource "aws_instance" "sample" {
  ami                    = "${data.aws_ssm_parameter.latest_amzn2_ami.value}"
  instance_type          = "t3.micro"
  vpc_security_group_ids = ["${aws_security_group.ec2.id}"]
  subnet_id              = "${aws_subnet.public.id}"
  # 各々のキーペアに置き換え
  key_name               = "your-key-pair"
  ebs_optimized          = true  # 追加

  tags = {
    Name = "sample_ec2_instance"
  }
}

この設定でapplyすれば、AWSコンソール上でもEBS最適化の項目がTrueになります。

EBS最適化がFalseでもEBS最適化は無効にはなっていない?

EBS 最適化 (デフォルト)
次の表は、EBS 最適化をサポートするインスタンスタイプを示します。EBS 最適化はデフォルトで有効になっています。EBS 最適化を有効にする必要はなく、EBS 最適化を無効にすると効果はなくなりません。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-optimized.html

こちらのAWSのドキュメントによると、デフォルトEBS最適化のインスタンスはEBS最適化を無効にしようとしても無効にはならないようです。

(実際にパフォーマンスを比較したりはしていないので、100%は言い切れません...)

Terraformのドキュメントにも下記のように記載がありますね。

Note that if this is not set on an instance type that is optimized by default then this will show as disabled but if the instance type is optimized by default then there is no need to set this and there is no effect to disabling it.

https://www.terraform.io/docs/providers/aws/r/instance.html#ebs_optimized

また、インスタンスタイプを変更する場合に次のような注意点があることから、ebs_optimizedは指定しないほうが無難かもしれません。

【小ネタ】EBS最適化インスタンスをCLIツールでスペックダウンするときの注意点

その他参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[-bash: rbenv: コマンドが見つかりません�]aws(ec2)上のrbenvの初期設定エラーの解決方法

1.エラーの内容

Neverland:.ssh kontatomoya$ ssh -i freemarket_sample_62d.pem ec2-user@3.115.38.38

Last login: Mon Feb 10 20:51:18 2020 from xx000000000000.au-net.ne.jp

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2018.03-release-notes/
-bash: rbenv: コマンドが見つかりません
#↑ec2に接続した時に出るこのエラーが本題です
[ec2-user@ip-000-00-00-00 ~]$ 

2.考えられる原因

1.そもそもrubyに関する環境構築をしていない

2.環境構築の際コマンドの順番を誤り.bash__profileでサーバーサイドが想定した記載になっていない。(自分が確認した限りではデプロイしたアプリへの影響はありませんでしたが、どこでバグの原因となるかわからないため解消することを推奨します)

3.解決方法

1.そもそもrubyに関する環境構築をしていない

この場合は下記の手順に従ってコマンドを打ち込むことで解消します
中途半端に設定した方はひとまず指示に従って全て打ち込んでください(ダブってしまう不要な箇所を4.で確認および削除し解決します。一度アプリケーションをデプロイして、再度違うアプリケーションをデプロイし直す方も同様にしてください)

[ec2-user@ip-000-00-00-00 ~]$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv 
#rbenvをEC2にインストール
[ec2-user@ip-000-00-00-00 ~]$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile 
#パスを通すための記述を.bash_profileに追記
[ec2-user@ip-000-00-00-00 ~]$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
#rbenvを呼び出すための記述を.bash_profileに追記
[ec2-user@ip-000-00-00-00 ~]$ source .bash_profile
#.bash_profileをEC2に読み込み
[ec2-user@ip-000-00-00-00 ~]$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
#ruby-buildのインストール
[ec2-user@ip-000-00-00-00 ~]$ rbenv rehash  
#rehashを行う
[ec2-user@ip-000-00-00-00 ~]$ rbenv install 2.0.0
#rubyのインストールを行う(2.0.0は自分のアプリのrubyバージョンに合わせる)
[ec2-user@ip-000-00-00-00 ~]$ rbenv global 2.0.0
#rubyをEC2上共通のバージョンとする
[ec2-user@ip-000-00-00-00 ~]$ rbenv rehash 
#rehashを行う
[ec2-user@ip-000-00-00-00 ~]$ ruby -v 
#バージョンを確認→"ruby 2.0.0p648 (2015-12-16) [x86_64-linux]"が出ればok

#設定の内容を見たい場合は下記コマンド
[ec2-user@ip-000-00-00-00 ~]$ vim ~/.bash_profile
#.bash_profile(初期設定の隠しファイル)をviエディターで確認する
2.環境構築の際コマンドの順番を誤り.bash__profileでサーバーサイドが想定した記載になっていない。

エラーを起こしている.bash__profileファイルは下記のようになっています

[ec2-user@ip-000-00-00-00 ~]$ vim ~/.bash_profile
#.bash_profile(初期設定の隠しファイル)をviエディターで確認する
.bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH
eval "$(rbenv init -)"
export PATH="$HOME/.rbenv/bin:$PATH"
#↑環境構築のコマンドにより最下の行を追記しました。正しいコマンド通りだとした2行が逆転していなければなりません

コメントに従って下記の行を入れ替えることで正しい環境構築となります。エラーの理由はパスを通す前にrbenvを呼び出す記述となっているからでした。

4.中途半端に設定したあとにコマンドをした方の重複箇所のと確認と削除について

rbenv の環境構築で重複する箇所は.bash_profileだけなのでそちらを下記コマンドで確認し、一番最後に記載した.bash_profileのテンプレートと異なる部分の削除を行なっていただくことで正しく設定できます。

※また、注意点として、ローカルの.bash_profileとEC2(サーバー側)の.bash_profileは記載内容が異なり、今回は全てEC2(サーバー側)で作業を行なうようにしてください。

[ec2-user@ip-000-00-00-00 ~]$ vim ~/.bash_profile
#.bash_profile(初期設定の隠しファイル)をviエディターで確認する

※1.でなぜもう一度全て打ち直していただいたかというと.bash_profileにrubyやruby-buildが入っているか表示されないため、インストールされず進んでしまうおそれがあるからです。また、rubyやruby-buildは何度インストールしても自動でダブらないようにしてくれるため重複は気にしなくて大丈夫である(alreadyの文が出ます)ため、記載漏れしないように再度全て記述していただきました。(慣れている方はruby -vで環境の有無の確認の後.bash_profileに手打ちでもいいのですが、初期設定のファイルの存在自体がわかりにくく、これを見られているのは初学者の方が多いと思うのでコマンドから打って、最後に不要部分を削ることをお勧めします。)

<.bash_profileのテンプレート>

.bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

以上の方法でエラー文は解消されます

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【DevOps試験対策#1】マルチクラウドプラットフォームの是非を問う

概要

標題については私自身も結論を明確に出せていない。
近い将来、それぞれのパブリッククラウドが明確な棲み分けが出来るようになる、もしくはインフラという概念が希薄になってきている昨今、俗に言うフルスタックエンジニアがもう1歩、2歩先に見える将来像に到達した時には、間違いなくマルチクラウドプラットフォームは是である。と言えるかもしれないが、現状では必要要素が多く、全てのパターンにおいて必ずしも是であるとは言い難い部分も内包されている。

それらを踏まえた上で本稿では「あえて是であるという論調」で進めて行きたいと思う。

さて、Kubernetesについては実際の業務でかなり触れていたが、そろそろ資格でもとってみるかということで
受験勉強をしてみようと思う。
業務で触れていたのは、AWS, GCP, Azureと著名なパブリッククラウドでマルチクラウド環境を作り、利用する側のUIを統一するためにKubernetesで抽象化を行いました。

なので試験対策そのものはGCPからスタートではありますが、AWSやAzureについても受験をする予定です。

今回、Qitaを使ってマルチクラウドプラットフォーム化で感じたことと試験対策の内容を書き綴っていこうと思う。
いくつまで更新するかは現時点では未定であるが、結構な長編になるのではないかと思っている。

マルチクラウドプラットフォームにおける課題

作成するアプリケーションの特性やサービス提供ユーザーに併せて最適な環境を選択出来るという点では、
マルチクラウド環境は素晴らしい成果を上げますが、SREとしての立場としては様々な仕様を把握したり、仕組みが複雑化するという問題点もある。

例えば、とあるパブリッククラウドAのサービスで素晴らしいものがリリースされた。
今回計画しているアプリには、このサービスを利用するのが最適である。
だがしかし、現状プラットフォームとして利用しているのはパブリッククラウドBである。

新規でプラットフォームを作り上げるには、様々なハードルを乗り越える必要がある。
ハードルの種別は各社様々だと思うが、まずはコスト、運用手順の煩雑さ、この2つが乗り越える必要がある大きな壁だろう。

まずコストだが、上記のような状況でアプリ単体での収支を見ると新たにクラウドプラットフォームを導入するにはコスト感が合わない場合が多い。

ホームページ程度であるなら別だが、アプリを継続的にリリースしている会社であればあるほど
既存システムとの連携や業務システムとの連携、セキュリティ対策などアプリケーションを支える様々な仕組みを新たに構築する必要が出てくる。

これらのリソースを単なるコストとしないために複数のアプリケーションを新プラットフォームへデプロイしていく計画を立ててキーマンの承認を得る。というのが現状だと思う。

だがしかし、この手法で行くと最初の頃はそこまで煩雑化しないが、数年立つとプラットフォームA担当、B担当など担当の細分化が必要になったり、Aしか担当しないから見えない効率化方法、Bしか担当しないから見えない運用手順の煩雑化、AとBでそれぞれ別のオペレーションになったり、別ツールを使うなど多くの闇を抱えることに結果としてなりがちである。

次に運用手順の煩雑さだが、運用しているアプリの数、使っているツールの数、利用しているパブリッククラウドの種類が多くなるほど手順は複雑化しがちである。
定期的に手順やフローなどの標準化チェックを行い、各人が共通認識を持ち、特殊なフローを作らず、より簡素化へより標準化へと邁進し、しっかりとしたフローの中で進めて行くこと。

これらの前時代的感覚の弊害としては、一言でいうなら柔軟性にかけるということである。
DevOps関連のツールやミドルウェアは日々進化しており、それらを柔軟に取り入れるためには、まず使ってみようというチャレンジが必要となってくる。
ITの進歩は目まぐるしいので、世により良いものを提供していくためには柔軟性は必要不可欠といえる。
「新しいものを導入するにあたって、どれほど苦労するかわかってる?」などといった批判が聞こえてきそうだが、
アプリ自体は定期的に改修されるし、インフラは5年もたてば刷新しなければならない、クラウドであるならばもっと短いタームでの刷新が必要になる場合もあるだろう。
それに併せて運用部門についてもどんどん変革をしていかなければならない中で苦労を大上段に構えて変革を拒絶するのはナンセンスではなかろうか。

ただし、言わんとすることもわからなくもない。
ありがちなパターンでいうと開発部門やインフラ部門の「まず使ってみよう」という音頭で初めて使いっぱなしで終わるパターンがある。
結果として運用部門の人が苦労をして運用手順を立てつけたという話はよく耳にする。

新しいツールやミドルウェアを取り入れるにあたって、どの部門の方が「まず使ってみよう」と言い出すかは様々であるが、
最終的に運用部門に落とし込んで行く必要があるが、そこを忘れがちな人が多いのも事実である。

最終的に出てくる話としては、1つのパブリッククラウドですらしっかりとしたフローを回して共通認識を持てないのにマルチクラウドプラットフォームなんてとんでもない。といった結論に陥りがちである。

もちろん開発部門やインフラ部門の方も新しいツールやミドルウェアを利用することに難色を示す人もいるだろう。
理由は様々であるが、今は時間がない、メンバーの入れ替えが生じたのでまずは既存の業務を覚えることが優先、大型のPJが動いているので対応する人員がいない。といったところだろうか。

簡単に言うとプライオリティの問題とワークロードの問題である。
その他にも推察出来る要素は複数あるが、多くの方が挙げられる問題点は上記になるであろう。
この手の問題はマネージメント層の手腕で解決する以外に方法がない。

仕事には(仕事以外でもだが。)下記の4つがあると思う。

1. やらなければならないこと
2. やったほうが良いこと
3. やらないほうが良いこと
4. やってはならないこと

1をやるのは当然ではあるが、2については放置をすること自体は4に該当する場合が多い。
結論として1を間断なくやりながら2についてもしっかりと進める。
そのために業務負荷が上がるのであれば人の手当をするなど解決策はいくらでもある。
この時に人の手当が出来ないのであれば、それはマネージメントの問題となるであろう。
そのための人の確保であれば昨今ではSREという概念も定着しつつあり、SREの採用に積極的な会社も多数ある。

課題の整理

さて、ここで課題を整理したいと思う。

  1. コスト
  2. 煩雑化(闇を抱えかねない。)
  3. 柔軟性は必要不可欠
  4. 運用まで考慮に入れた変革が必要
  5. 優先度
  6. 業務負荷

如何でしたでしょうか。
この投稿で少しでも各社様のIT部門がより良い変革がもたらされることを祈っています。

それでは次回をお楽しみにお待ちください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

そろそろaws初めてみよか#4~Cloud9環境の整備~

はじめに

awsと戯れる会も第4回目(^^♪
Cloud9環境でちゃんと開発できるようCloud9のインスタンスにもlaravel環境をセットアップします。

以前の記事はこちらから
- そろそろaws初めてみよか~まずは触れてみた~
- そろそろaws初めてみよか#2~CodeStarによるコード修正からDeployまで~
- そろそろaws初めてみよか#3~RDSとの接続~

phpのバージョンアップ(5.6->7.3)

Cloud9上のphpは5.6.40
ところが実行環境であるインスタンスのphpは7.3.13
って事でphpのインストールと切り替えを行います。

php73のインストール

ec2-user:~ $ sudo yum install php73 php73-gd php73-json php73-mbstring php73-mysqlnd php73-pdo php73-soap php73-xml
 :

phpの切り替え(5.6->7.3)

ec2-user:~ $ php -v
PHP 5.6.40 (cli) (built: Oct 31 2019 20:35:16) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick Rethans
ec2-user:~ $ sudo alternatives --config php

There are 2 programs which provide 'php'.

  Selection    Command
-----------------------------------------------
*+ 1           /usr/bin/php-5.6
   2           /usr/bin/php-7.3

Enter to keep the current selection[+], or type selection number: 2
ec2-user:~ $ php -v
PHP 7.3.13 (cli) (built: Jan 21 2020 19:15:52) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.13, Copyright (c) 1998-2018 Zend Technologies
ec2-user:~ $ 

composerのインストール

次に必要となってくるcomposerのインストールを行います。
公式の手順(https://getcomposer.org/download/)に則って

ec2-user:~ $ php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ec2-user:~ $ php -r "if (hash_file('sha384', 'composer-setup.php') === 'c5b9b6d368201a9db6f74e2611495f369991b72d9c8cbd3ffbc63edff210eb73d46ffbfce88669ad33695ef77dc76976') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
Installer verified
ec2-user:~ $ php composer-setup.php
All settings correct for using Composer
Downloading...

Composer (version 1.9.3) successfully installed to: /home/ec2-user/composer.phar
Use it: php composer.phar

ec2-user:~ $ php -r "unlink('composer-setup.php');"
ec2-user:~ $ ls
composer.phar  environment  node_modules  package-lock.json

laravelなどのインストール

プロジェクトフォルダにはcomposer.jsonがありますので、以下のコマンドで必要なモジュールをインストールします。
ちなみにGitからCloneされたソースは~\environmentにあります。

ec2-user:~ $ 
ec2-user:~ $ cd environment/
ec2-user:~/environment $ cd php-laravel
ec2-user:~/environment/php-laravel (master) $ ls
app          artisan    buildspec.yml  composer.lock  database     index.php     phpunit.xml  README.md  routes   server.php  template-configuration.json  tests
appspec.yml  bootstrap  composer.json  config         gulpfile.js  package.json  public       resources  scripts  storage     template.yml

ec2-user:~/environment/php-laravel (master) $ ~/composer.phar install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Package operations: 63 installs, 0 updates, 0 removals
  - Installing kylekatarnls/update-helper (1.2.0): Downloading (100%)         
  - Installing jakub-onderka/php-console-color (v0.2): Downloading (100%)         
  - Installing symfony/polyfill-ctype (v1.12.0): Downloading (100%)         
  - Installing vlucas/phpdotenv (v2.6.1): Downloading (100%)         
  - Installing symfony/polyfill-mbstring (v1.12.0): Downloading (100%)         
  - Installing symfony/var-dumper (v3.1.10): Downloading (100%)         
  - Installing symfony/translation (v3.1.10): Downloading (100%)         
  - Installing symfony/routing (v3.1.10): Downloading (100%)         
  - Installing symfony/process (v3.1.10): Downloading (100%)         
  - Installing symfony/http-foundation (v3.1.10): Downloading (100%)         
  - Installing symfony/event-dispatcher (v3.4.30): Downloading (100%)         
  - Installing psr/log (1.1.0): Downloading (100%)         
  - Installing symfony/debug (v3.1.10): Downloading (100%)         
  - Installing symfony/http-kernel (v3.1.10): Downloading (100%)         
  - Installing symfony/finder (v3.1.10): Downloading (100%)         
  - Installing symfony/console (v3.1.10): Downloading (100%)         
  - Installing swiftmailer/swiftmailer (v5.4.12): Downloading (100%)         
  - Installing paragonie/random_compat (v2.0.18): Downloading (100%)         
  - Installing ramsey/uuid (3.8.0): Downloading (100%)         
  - Installing nikic/php-parser (v3.1.5): Downloading (100%)         
  - Installing jakub-onderka/php-console-highlighter (v0.3.2): Downloading (100%)         
  - Installing dnoegel/php-xdg-base-dir (0.1): Downloading (100%)         
  - Installing psy/psysh (v0.8.18): Downloading (100%)         
  - Installing nesbot/carbon (1.39.0): Downloading (100%)         
  - Installing mtdowling/cron-expression (v1.2.1): Downloading (100%)         
  - Installing monolog/monolog (1.24.0): Downloading (100%)         
  - Installing league/flysystem (1.0.53): Downloading (100%)         
  - Installing symfony/polyfill-util (v1.12.0): Downloading (100%)         
  - Installing symfony/polyfill-php56 (v1.12.0): Downloading (100%)         
  - Installing jeremeamia/superclosure (2.4.0): Downloading (100%)         
  - Installing doctrine/inflector (v1.3.0): Downloading (100%)         
  - Installing classpreloader/classpreloader (3.2.0): Downloading (100%)         
  - Installing laravel/framework (v5.3.31): Downloading (100%)         
  - Installing fzaninotto/faker (v1.8.0): Downloading (100%)         
  - Installing hamcrest/hamcrest-php (v1.2.2): Downloading (100%)         
  - Installing mockery/mockery (0.9.11): Downloading (100%)         
  - Installing webmozart/assert (1.4.0): Downloading (100%)         
  - Installing phpdocumentor/reflection-common (1.0.1): Downloading (100%)         
  - Installing phpdocumentor/type-resolver (0.4.0): Downloading (100%)         
  - Installing phpdocumentor/reflection-docblock (4.3.1): Downloading (100%)         
  - Installing phpunit/php-token-stream (2.0.2): Downloading (100%)         
  - Installing symfony/yaml (v3.3.18): Downloading (100%)         
  - Installing sebastian/version (2.0.1): Downloading (100%)         
  - Installing sebastian/resource-operations (1.0.0): Downloading (100%)         
  - Installing sebastian/recursion-context (2.0.0): Downloading (100%)         
  - Installing sebastian/object-enumerator (2.0.1): Downloading (100%)         
  - Installing sebastian/global-state (1.1.1): Downloading (100%)         
  - Installing sebastian/exporter (2.0.0): Downloading (100%)         
  - Installing sebastian/environment (2.0.0): Downloading (100%)         
  - Installing sebastian/diff (1.4.3): Downloading (100%)         
  - Installing sebastian/comparator (1.2.4): Downloading (100%)         
  - Installing phpunit/php-text-template (1.2.1): Downloading (100%)         
  - Installing doctrine/instantiator (1.2.0): Downloading (100%)         
  - Installing phpunit/phpunit-mock-objects (3.4.4): Downloading (100%)         
  - Installing phpunit/php-timer (1.0.9): Downloading (100%)         
  - Installing phpunit/php-file-iterator (1.4.5): Downloading (100%)         
  - Installing sebastian/code-unit-reverse-lookup (1.0.1): Downloading (100%)         
  - Installing phpunit/php-code-coverage (4.0.8): Downloading (100%)         
  - Installing phpspec/prophecy (1.8.1): Downloading (100%)         
  - Installing myclabs/deep-copy (1.9.3): Downloading (100%)         
  - Installing phpunit/phpunit (5.7.27): Downloading (100%)         
  - Installing symfony/css-selector (v3.1.10): Downloading (100%)         
  - Installing symfony/dom-crawler (v3.1.10): Downloading (100%)         
symfony/var-dumper suggests installing ext-symfony_debug
symfony/translation suggests installing symfony/config
symfony/routing suggests installing doctrine/annotations (For using the annotation loader)
symfony/routing suggests installing symfony/config (For using the all-in-one router or any loader)
symfony/routing suggests installing symfony/dependency-injection (For loading routes from a service)
symfony/routing suggests installing symfony/expression-language (For using expression matching)
symfony/event-dispatcher suggests installing symfony/dependency-injection
symfony/http-kernel suggests installing symfony/browser-kit
symfony/http-kernel suggests installing symfony/class-loader
symfony/http-kernel suggests installing symfony/config
symfony/http-kernel suggests installing symfony/dependency-injection
paragonie/random_compat suggests installing ext-libsodium (Provides a modern crypto API that can be used to generate random bytes.)
ramsey/uuid suggests installing ext-libsodium (Provides the PECL libsodium extension for use with the SodiumRandomGenerator)
ramsey/uuid suggests installing ext-uuid (Provides the PECL UUID extension for use with the PeclUuidTimeGenerator and PeclUuidRandomGenerator)
ramsey/uuid suggests installing ircmaxell/random-lib (Provides RandomLib for use with the RandomLibAdapter)
ramsey/uuid suggests installing moontoast/math (Provides support for converting UUID to 128-bit integer (in string form).)
ramsey/uuid suggests installing ramsey/uuid-console (A console application for generating UUIDs with ramsey/uuid)
ramsey/uuid suggests installing ramsey/uuid-doctrine (Allows the use of Ramsey\Uuid\Uuid as Doctrine field type.)
psy/psysh suggests installing ext-pdo-sqlite (The doc command requires SQLite to work.)
psy/psysh suggests installing hoa/console (A pure PHP readline implementation. You'll want this if your PHP install doesn't already support readline or libedit.)
monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB)
monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server)
monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required))
monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server)
monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server)
monolog/monolog suggests installing mongodb/mongodb (Allow sending log messages to a MongoDB server via PHP Driver)
monolog/monolog suggests installing php-amqplib/php-amqplib (Allow sending log messages to an AMQP server using php-amqplib)
monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome)
monolog/monolog suggests installing rollbar/rollbar (Allow sending log messages to Rollbar)
monolog/monolog suggests installing ruflin/elastica (Allow sending log messages to an Elastic Search server)
monolog/monolog suggests installing sentry/sentry (Allow sending log messages to a Sentry server)
league/flysystem suggests installing league/flysystem-aws-s3-v2 (Allows you to use S3 storage with AWS SDK v2)
league/flysystem suggests installing league/flysystem-aws-s3-v3 (Allows you to use S3 storage with AWS SDK v3)
league/flysystem suggests installing league/flysystem-azure (Allows you to use Windows Azure Blob storage)
league/flysystem suggests installing league/flysystem-cached-adapter (Flysystem adapter decorator for metadata caching)
league/flysystem suggests installing league/flysystem-eventable-filesystem (Allows you to use EventableFilesystem)
league/flysystem suggests installing league/flysystem-rackspace (Allows you to use Rackspace Cloud Files)
league/flysystem suggests installing league/flysystem-sftp (Allows you to use SFTP server storage via phpseclib)
league/flysystem suggests installing league/flysystem-webdav (Allows you to use WebDAV storage)
league/flysystem suggests installing league/flysystem-ziparchive (Allows you to use ZipArchive adapter)
league/flysystem suggests installing spatie/flysystem-dropbox (Allows you to use Dropbox storage)
league/flysystem suggests installing srmklive/flysystem-dropbox-v2 (Allows you to use Dropbox storage for PHP 5 applications)
laravel/framework suggests installing aws/aws-sdk-php (Required to use the SQS queue driver and SES mail driver (~3.0).)
laravel/framework suggests installing doctrine/dbal (Required to rename columns and drop SQLite columns (~2.4).)
laravel/framework suggests installing guzzlehttp/guzzle (Required to use the Mailgun and Mandrill mail drivers and the ping methods on schedules (~5.3|~6.0).)
laravel/framework suggests installing league/flysystem-aws-s3-v3 (Required to use the Flysystem S3 driver (~1.0).)
laravel/framework suggests installing league/flysystem-rackspace (Required to use the Flysystem Rackspace driver (~1.0).)
laravel/framework suggests installing pda/pheanstalk (Required to use the beanstalk queue driver (~3.0).)
laravel/framework suggests installing predis/predis (Required to use the redis cache and queue drivers (~1.0).)
laravel/framework suggests installing pusher/pusher-php-server (Required to use the Pusher broadcast driver (~2.0).)
laravel/framework suggests installing symfony/psr-http-message-bridge (Required to use psr7 bridging features (0.2.*).)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/php-code-coverage suggests installing ext-xdebug (^2.5.1)
phpunit/phpunit suggests installing ext-xdebug (*)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
Package phpunit/phpunit-mock-objects is abandoned, you should avoid using it. No replacement was suggested.
Generating autoload files
Carbon 1 is deprecated, see how to migrate to Carbon 2.
https://carbon.nesbot.com/docs/#api-carbon-2
    You can run './vendor/bin/upgrade-carbon' to get help in updating carbon and other frameworks and libraries that depend on it.
> Illuminate\Foundation\ComposerScripts::postInstall
> php artisan optimize
Generating optimized class loader
Compiling common classes
ec2-user:~/environment/php-laravel (master) $ 

.envの準備

開発用に.envを作成します。
コマンドでも良いのですがせっかくのIDEですので.env.exampleをコピー&ペーストして.envを作成
以下の部分を書き換えました。

DB_CONNECTION=mysql
DB_HOST=laravel-db.culgyynq9ap1.us-east-2.rds.amazonaws.com
DB_PORT=3306
DB_DATABASE=laravel_dev
DB_USERNAME=admin
DB_PASSWORD=***********

DBはインスタンスは本番と同様でデータベースを分ける想定です。
インスタンスから分けたい場合は、RDSで新たにDBを作成しセキュリティグループの設定を行ってください。
参考)そろそろaws初めてみよか#3~RDSとの接続~

開発用データベースの作成

例によってインスタンスにはmysqlがインストールされていませんのでまずはインストールします。

ec2-user:~/environment/php-laravel (master) $ sudo yum install -y mysql
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main                                                                                                                                                                                                                     | 2.1 kB  00:00:00     
amzn-updates                                                                                                                                                                                                                  | 2.5 kB  00:00:00     
1073 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package mysql.noarch 0:5.5-1.6.amzn1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================================================================================================================================================
 Package                                                 Arch                                                     Version                                                          Repository                                                   Size
=====================================================================================================================================================================================================================================================
Installing:
 mysql                                                   noarch                                                   5.5-1.6.amzn1                                                    amzn-main                                                   2.7 k

Transaction Summary
=====================================================================================================================================================================================================================================================
Install  1 Package

Total download size: 2.7 k
Installed size: 0  
Downloading packages:
mysql-5.5-1.6.amzn1.noarch.rpm                                                                                                                                                                                                | 2.7 kB  00:00:00     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : mysql-5.5-1.6.amzn1.noarch                                                                                                                                                                                                        1/1 
  Verifying  : mysql-5.5-1.6.amzn1.noarch                                                                                                                                                                                                        1/1 

Installed:
  mysql.noarch 0:5.5-1.6.amzn1                                                                                                                                                                                                                       

Complete!

次にデータベースに接続し、データベースを作成します。
※セキュリティグループにCloud9インスタンスからMariaDBへの接続を許可する設定を入れておいてください。
参考)そろそろaws初めてみよか#3~RDSとの接続~

ec2-user:~/environment/php-laravel (master) $ mysql -u admin -p -h laravel-db.culgyynq9ap1.us-east-2.rds.amazonaws.com
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 5.5.5-10.2.21-MariaDB-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE laravel_dev DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;                                                                                                                                                               
Query OK, 1 row affected (0.01 sec)

mysql> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| innodb             |
| laravel            |
| laravel_dev        |
| mysql              |
| performance_schema |
+--------------------+
6 rows in set (0.00 sec)

mysql> \q
Bye

php artisan migrateをしてみる

ec2-user:~/environment/php-laravel (master) $ php artisan migrate
Migration table created successfully.
Migrated: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_100000_create_password_resets_table

これで開発できますね^^

と思ったのですが…

php artisan serveができない...。
一難去ってまた一難。

一体どうやってaws上でlaravelプロジェクトを開発していくんでしょうか…。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む