- 投稿日:2020-02-11T23:18:33+09:00
WordPressで作成した記事をS3に連携しエンドポイントでホスティングする
はじめに
構築作業の覚書としてQiita記事を作成しておきます。
また、この記事ではWordPressからS3に連携し、S3のエンドポイントでホスティングするまでを記載しています。
その先のCDN、DNS部分はまた別の記事で。本アーキテクチャのメリット
- ColoudFrontを使用するので負荷に強い
- サーバー容量も気にしなくて良い(訳ではないが、EC2に直接配置するよりはまし)
- Route53は可用性100%
構築難易度とかは一旦無視していますが、メリットが非常に大きいです。
ただし、その分コストはかかりますので「ランニングコストは1円もかけたくない!」という特殊な事情があれば話は別です。WordPressからS3に連携しHelloWorldページを閲覧できるようにする
EC2インスタンスの作成
WordPress本体を稼働させれるためのEC2を構築していきます。
今回はbitnamiのAMIを使用します。
https://bitnami.com/1. AMIの選択
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のみアタッチします。
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]と選択し、以下のような設定を行う。
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/pluginshttps://docs.bitnami.com/virtual-machine/how-to/troubleshoot-wordpress-issues/
インストール後
再実行
を行うとS3に記事が連携され、S3のエンドポイントでアクセスするとHelloWorldを確認できます。
参考文献
参考にさせていただきました。ありがとうございました。
WordPress + StaticPress S3で静的WebサイトをS3でホストする
- 投稿日:2020-02-11T22:15:49+09:00
設計、資料作成に活躍、クラウドサービスアイコン集
AWS
GCP
Azure
Microsoft Azure Cloud and AI Symbol / Icon Set - SVG
Oracle Cloud
NIFTY Cloud
さくらのクラウド
クラウド用ではありませんが。
さくらのアイコンセット
- 投稿日:2020-02-11T22:15:41+09:00
【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
- 投稿日:2020-02-11T20:46:45+09:00
PythonでCloudWatchのデータを取得してみた
きっかけ
CloudWatchのダッシュボードでサーバーの状態を確認する日々。
出社したらまずダッシュボードを順番に確認してー・・・って、めんどくさい!
ダッシュボードの情報を一気に取得したい!
よし、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のグラフ化したメトリクス
タブの詳細情報にマウスカーソルを合わせると表示される情報の一番上に書かれたものです。
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時間 → 86400Statistics
統計を書きます。
レスポンス
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ページ からお気軽にご連絡ください!参考記事
- 投稿日:2020-02-11T20:45:02+09:00
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! ************************************* ※上記が表示されたらOKMackerelとEventBridgeの連携
Mackerelの公式の手順に沿って設定すれば問題ありません。一応、実施した内容を記載していきます。
Amazon EventBridgeにアラートを通知する通知Channelの作成
MackerelのChannelメニューから、EventBridgeを選択して追加します。
イベント名は任意でOKです。(AWSコンソール側で表示される名前になります。)
監視対象の追加
続いて、Monitorsメニューから、
ホスト死活監視
を追加。
細かい設定は分からなかったので、全てデフォルトのままです。
AWSコンソールで連携設定をする
AWSコンソールのEventBridgeの画面を開くと、先ほど追加したイベントソースが表示されています。
イベントバスと関連付ける
を実施してください。
関連付けを行うと、ステータスがアクティブ
に変更されます。
アラート通知時に起動されるLambdaを作成
今回はテスト用なので、単純にログ出力するだけのLambda Function
EventBridgeConsoleLog
を定義しました。lambda_functionimport json def lambda_handler(event, context): print('A alarm was notified from Mackerel service.') print(event) return 'OK'Event Bridgeにルールを作成
EventBridgeに新規でルールを作成し、上記で作成したLambda Functionをターゲットに設定します。詳細はキャプチャを参照してください。
ルール MackerelMonitoringRule を作成しました
と表示されれば完了です。
アラート通知→EventBridge→Lambda起動
では、実際にアラートを発生させてみます。
一番最初に構築したEC2インスタンスを、AWSコンソールからStopさせます。しばらく放置すると、Mackerel側でアラートが発生しました。
CloudWatchで作成したルール
MackerelMonitoringRule
が呼ばれているか確認します。
最後に、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監視ツールとの連携が便利になるのは間違いなさそうです。次回は、自作のアプリケーションからカスタムイベントを登録してみたいと思います!
- 投稿日:2020-02-11T19:21:26+09:00
【小ネタ】AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた知識の整理②
概要
AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた小ネタ集②。
参考
アソシエイト資格の勉強法は以下を参照
AWS初心者がAWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法
その他の小ネタは以下を参照
IDプロバイダーとフェデレーション
- ユーザーIDをAWSの外で管理している場合、AWSアカウントにIAMユーザーを作成する代わりに、IDプロバイダーとフェデレーションを使う
- ウェブIDフェデレーションとSAML2.0ベースのフェデレーションの2パターンがある
ウェブIDフェデレーション
- ウェブIDフェデレーション:モバイルデバイスでAWSの外の認証情報を使って認証しAWSサービスを使うタイプ ※Amazon Cognitoの使用も推奨されている
SAML2.0ベースのフェデレーション
- SAML2.0ベースのフェデレーション:AWSコンソールにシングルサインオンするタイプ
DDoS対策
- 基本的には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インジェクション、クロスサイトスクリプティングにも有効。
- 投稿日:2020-02-11T18:38:04+09:00
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.comdocker 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 SucceededProvide 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以上です。
参考になれば幸いです。
- 投稿日:2020-02-11T17:44:33+09:00
そろそろ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)を選択します。
下ペインに現れる[New]タブの[CWD]をクリックし、ドキュメントルート
php-laravel/public
を選択します。
上のメニューからPreviewをクリックしブラウザを表示させます。
Oopsとか表示されますが、ポート番号があっていないためなので気にしない気にしない。
PHP (build-in web server)は下ペインのメッセージにある通り
Listening on http://0.0.0.0:8080
となっていますので、プレビューのURL欄をクリックし「:8080」を追加します。それっぽい画面が出てきましたが…スクリプトも画像も読み込まれていません。
Chromeの別タブで同URLを表示させ、ソース表示すると判りますが
ページのURLはhttpsなのに対し、リソースのパスがすべてhttpとなっていることが原因でした。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が動かないっぽいので、動確するなら別タブで開いた方がよさそうですね!これで本当の意味で開発環境を作ることができました!
- 投稿日:2020-02-11T17:29:08+09:00
もしも ELB-HealthChecker で(あ|なか)ったら
もしも ELB-HealthChecker であったら
Basic 認証の対象外にする
.htaccessAuthUserFile /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]
- 投稿日:2020-02-11T17:18:14+09:00
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
前提条件
- AWSアカウント
- AWS CLI
- aws configureで設定済み
- AWS CLIでWordPress環境を作成する~part1~の作業を実施
- AWS CLIでWordPress環境を作成する~part2~の作業を実施
構築
サブネットの作成(プライベートセグメント)
項目 値 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/0EC2インスタンスの作成
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-ServerNATゲートウェイの作成
# 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.10MySQLのインストール
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_installationWordPress用のデータベースの作成
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-mbstringMySQL 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 -pWordPressのデプロイ
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参考
- 投稿日:2020-02-11T17:18:11+09:00
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ベースで勉強することになるので大変だと思います。
広く浅く問われるので、クラウドインフラの基礎を抑えるにはとても良い試験です。
しっかりと参考書やホワイトペーパーを理解していれば合格できる内容なので頑張ってください。
今回の勉強でソリューションアーキテクトの本も読んだので忘れないうちにソリューションアーキテクトも受講していこうと思います。
- 投稿日:2020-02-11T17:12:04+09:00
AWS CLIでWordPress環境を構築する~part2~
概要
AWS学習目的で、下記記事のレシピを参考にAWS CLIでの環境構築を行う。
【Amazon3時間クッキング】材料費500円でAWSにWordPress環境を構築するレシピ ~part2~この記事では以下の作業を行う。
- キーペアの作成
- セキュリティグループの作成(Webサーバー用)
- ルールの追加
- EC2インスタンスの作成(Webサーバー用)
- Apacheのインストール
環境
- macOS Catalina
前提条件
- AWSアカウント
- AWS CLI
- aws configureで設定済み
- AWS CLIでWordPress環境を作成する~part1~の作業を実施済み
構築
キーペアの作成
項目 値 名前 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/0EC2インスタンスの作成
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.116Apacheのインストール
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参考
- 投稿日:2020-02-11T17:10:07+09:00
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" } }参考
- 投稿日:2020-02-11T16:58:43+09:00
[AWS]DBレイヤを冗長化する方法
- 投稿日:2020-02-11T16:17:41+09:00
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)を考慮すべしです。
- 投稿日:2020-02-11T15:48:42+09:00
AWSCDKでLambda(Nodejs)をTypeScriptのままデプロイする
はじめに
AWSCDKでNodejsのLambdaをTypeScriptで書いているときに、デプロイする前にJavaScriptにビルドする必要がなくなったので、その方法を紹介します。
使うパッケージ
AWSCDK v1.23.0 から
@aws-cdk/aws-lambda-nodejs
というパッケージがリリースされました。
このパッケージを使えばTSをビルドすることなくデプロイすることができます。実際に何をやっているかというと、デプロイする前に内部でParcelを使ってビルドをしてくれます。
詳しくはこちらを確認してください。サンプル
stack.tsimport 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 }) } }
NodejsFunction
のentry
に対してTSファイルを指定しています。
これでデプロイをすると.build
というディレクトリが生成され、そこにビルド後のソースが置かれています。さいごに
これで今までLambdaのソースをTypeScriptで書いているときに、デプロイをする前にビルドする必要があったところが不要になったので、地味に嬉しいアップデートでした。
ではまた!!!
- 投稿日:2020-02-11T15:01:29+09:00
AWSのインスタンス、作ったenvironmentがなくなった(初歩)
- 投稿日:2020-02-11T14:55:05+09:00
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に似てね??あっちはリアルタイムだし観点がちがうってこと?
こっちは運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化…ってほぼ同じやんけ!
違う点あったら教えて下さい…まあどっちも試験の重要度は低そうだし関係ないな!(フラグ)第一章はここまで!
- 投稿日:2020-02-11T14:53:44+09:00
CI/CD on AWS ハンズオン勉強会に参加してきた
MarkingCloudさん主催の勉強会 明日から職場で業務改善!CI/CD on AWS ハンズオン の参加レポートです。
1時間のハンズオンでCI/CDってすごい! 便利! と実感できる内容でした
勉強会の概要
全体の流れはこんな感じです。
- コミュニティの説明
- 参加者同士の自己紹介
- ハンズオン(1時間)
- 懇親会
MarkingCloudとは?
クラウド関連の勉強会を開催されている団体です。
初心者向けのハンズオンを色々なテーマで企画してくださっています。どんな人が参加しているの?
筆者が交流させていただいた範囲だけでも、
- 初心者から仕事でAWSの他のサービスを使っている人、独学で勉強中の人まで
- Web系エンジニアからクラウドNGなお堅い業界の方まで
いろいろな方が参加されていました。
普段の業務とは違う分野の方のお話を聞けるのも面白いです。勉強会のゴール
AWSでCI/CDを実現することじゃないの? と思いますが、さらに一歩踏み込んで
主催者様「明日、職場で上司にCI/CDの必要性を訴えましょう!!」
とのことでした。
実際に上司を説得した方はいたのでしょうか?ハンズオン
ブログ用にメモをとりたかったのですが、ついていくのに必死で無理でした…
当日の資料 を眺めつつ、復習がてら書いていきます。
作るシステムの概要
当日の資料 から画像を拝借しました。
CodeCommitにソースコードをコミットすると、CodeBuildで自動ビルドされ、Lamdaにデプロイされる…という仕組みを作ります。
IAMユーザーを作成する
IAM = AWS Identity and Access Management
AWSの各サービスを使うために、ルートユーザーとしてサインインする以外にIAMユーザーとして認証する方法があるようです。
各IAMユーザーごとに、必要なサービスのみのアクセス権限を付与できるようです。ここでは、後でCodeCommitにプッシュする用のユーザー&認証情報を作成します。
CI/CDの各パーツを作成する
時間の関係上、ここではAWSのCloudFormationを使って自動で作成してしまいます。
主催者様側で用意してくださっているテンプレートファイルを使います。何が起きているのか分からないうちに、あっという間にできてしまいます。
コードをコミット~自動ビルド・自動デプロイ
上記で作成済みのCodeCommitのリポジトリをクローンしてきて、用意してくださっているコードをコミット&プッシュします。
最初に作成したIAMユーザーの認証情報を使います。
(クローンで詰まる人が多発していました…。一度パスワードを間違えると、間違った認証情報が記憶されてしまってうまくいかないようです。)無事プッシュできると、自動でビルド&デプロイされていきます…! これは便利!
しかし時間は割とかかります。出来上がったLambdaの関数を実行してみる
コードをコミットしただけでよく分からないけど関数が出来上がっていました!
コードを適当に変更して再度コミットしてみると、勝手に反映されてくれます。
(ここでも時間はかかりますが…)ある程度遊んだら、今作ったものたちは削除しておきます。
せっかく作ったばかりなのに勿体ないですが、余計な料金が発生してしまうので…。感想
- EC2しか触ったことなかったけど、こんなこともできるんだ!
- ハンズオンはかなりさくさく進むので、初心者は要復習
- 懇親会で普段聞けない話を聞けるのが楽しい
これからも予定が合って枠が余っている時は参加していきたいです
次回イベントの予定も公開されていました↓
新しい技術に触れてみる!Firebaseで「お問い合わせフォーム」作成ハンズオン
- 投稿日:2020-02-11T11:56:04+09:00
[AWS]Webレイヤを冗長化する方法
2020年2月11日現在の内容です。
用語説明
単一障害点(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=サービス提供に必要な台数)
サーバー構成のベストプラクティス
パターン:Webサーバー×1、DBサーバー×1 構成
1台のサーバースペックが足りなくなった時に、DBを別のサーバーに切り出す
パターン:Webサーバー×2、DBサーバー×1 構成
Web側の性能が足りない時に、Webサーバーを複数台使うことで、Web側の冗長化と負荷分散を行う
パターン:Webサーバー×2、DBサーバー×2 構成
DBをマスタースレーブ方式にすることで、DBの冗長化を行う
(Webの冗長化と負荷分散、DBの冗長化ができる)
AMIからEC2を起動
負荷分散用Webサーバーを構築する
EC2 → インスタンスから負荷分散元のEC2インスタンスを選択
アクション → イメージ → イメージの作成をクリック
イメージ名、イメージの説明に任意の名前を入力し、「イメージの作成」をクリック
タイプは「t2.micro」を選択し、「次のステップ」をクリック
以下の通り設定し、「次のステップ」をクリック
ネットワーク:作成したVPC
サブネット:作成したサブネット
自動割り当てパブリックIP:有効
キャパシティーの予約:なし
プライマリIP:10.0.11.10
既存のセキュリティグループ → 負荷分散元のEC2インスタンスと同じセキュリティグループを選択し、「確認と作成」をクリック
ELBの作成
Application Load Balancerの「作成」をクリック
以下の通り設定し、「次の手順」をクリック
名前:任意名
VPC:EC2インスタンスを配置しているVPC
サブネット:EC2インスタンスを関連付けているパブリックサブネット
新しいセキュリティグループを作成するを選択し、「次の手順」をクリック
セキュリティグループ名,説明:任意名
以下の通り設定し、「次の手順」をクリック
名前:任意名
詳細設定:適宜設定
ELBの対象とするインスタンスを選択し、「登録済みに追加」をクリック
登録済みターゲットにインスタンスが追加されていることを確認し、「次の手順」をクリック
DNS名をブラウザでアクセスし、ELBにアクセスできることを確認
独自ドメインからELBにアクセス
AWSコンソールからRoute 53を検索し、クリック
サイドバーから「ホストゾーン」をクリック
対象のドメイン名をクリック
以下の通り設定し、「レコードセットの保存」をクリック
エイリアス:「はい」
エイリアス先:作成したELB
ヘルスチェックの確認
アベイラビリティゾーン「1a」のApacheを停止させる
ssh -i test-ssh-key.pem ec2-user@18.179.167.73
sudo systemctl stop httpd.service
アベイラビリティゾーン「1a」のステータスが「unhealthy」になっていることを確認
ELBを運用する際のポイント
- サーバーはアベイラビリティゾーンを分けて配置する
- Webサーバーはステートレスに構築する
おまけ(ELBからEC2インスタンスを削除)
EC2 → ターゲットグループ → ターゲット → 編集をクリック
EC2インスタンスが削除されたことを確認し、「保存」をクリック
参考
- 投稿日:2020-02-11T10:20:46+09:00
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 サンドイッチのアーキテクチャ
- 2つの ELB の間に WAF アプリケーションを乗せた EC2 インスタンスを Auto Scaling グループで実行
- すべての HTTP リクエストを検査するため、トラフィックスパイクに対応する必要があり、Auto Scaling グループが必要
- トラフィックが検査およびフィルタリングされると、WAF EC2 インスタンスは内部のバックエンドロードバランサーにトラフィックを転送し、このロードバランサーがトラフィックをアプリケーションの EC2 インスタンス間に分散
参考
- 投稿日:2020-02-11T08:19:51+09:00
[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最適化を利用できるかどうかが決まっており、利用できるタイプの中でも最適化の設定がデフォルトで有効になっているものとインスタンス作成時に明示的に設定する必要があるものが存在します。
開発環境や検証でよく利用するt系のインスタンスでは、t3シリーズからEBS最適化がデフォルトで有効となっています。
下図は、AWSコンソールからt3-microのEC2インスタンスを起動した際の、インスタンスの情報です。起動時にEBSの設定には特に触っていませんが、EBS最適化はTrueとなっています。
TerraformでデフォルトEBS最適化のインスタンスを作成してみる
今回問題となったのは TerraformからEC2インスタンスを作成した場合です。
検証として、以下のtfファイルを作成します。
VPCやサブネット等のネットワーク周りのリソースを用意し、その上でEC2インスタンスを一台起動するシンプルな内容です。
main.tfprovider "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になってしまっています。
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ツールでスペックダウンするときの注意点
その他参考
- 投稿日:2020-02-11T07:16:28+09:00
[-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 -)"以上の方法でエラー文は解消されます
- 投稿日:2020-02-11T05:34:57+09:00
【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の採用に積極的な会社も多数ある。課題の整理
さて、ここで課題を整理したいと思う。
- コスト
- 煩雑化(闇を抱えかねない。)
- 柔軟性は必要不可欠
- 運用まで考慮に入れた変革が必要
- 優先度
- 業務負荷
如何でしたでしょうか。
この投稿で少しでも各社様のIT部門がより良い変革がもたらされることを祈っています。それでは次回をお楽しみにお待ちください。
- 投稿日:2020-02-11T00:55:08+09:00
そろそろ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.jsonlaravelなどのインストール
プロジェクトフォルダには
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 Byephp 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プロジェクトを開発していくんでしょうか…。