PHP/Laravel で作成したプロジェクトをAWSにデプロイ

前提

・ローカルで開発したプロジェクトをすでにgithubにプッシュ済み
・EC2にSSH接続できている事

PHP7.2のインストール

““`
$sudo yum install -y \
php72 php72-devel php72-fpm php72-gd php72-mbstring \
php72-mysqlnd php72-pdo \
php72-xml php72-json

インストール済みを確認
$sudo yum list installed | grep php72
““

Mysqlのインストールと動作の確認

“`
インストール
$sudo yum -y install mysql56-server mysql56-devel mysql56

スタート
$sudo service mysqld start

動いているか確認（runnning)になっていればOKです。
$sudo service mysqld status
mysqld (pid ) is running…
`

AWSでYOLOv3を動かすv2

#目的
AWS上でYOLOを動かす。

#使用したもの
[YOLO] https://github.com/ptxyasu/keras-yolo3
[AWS] EC2　https://aws.amazon.com/jp/ec2/

#流れ
1.AWSに環境構築
2.AWSに必要なデータ設置
3.yolo実行

##AWS EC2について
今回は無料枠であったAmazon Linux2を使用した。

##解決策
まず、普段開発を行っている環境でYOLO実行。
ここで、CPUのみで動かすように変更した。
freeコマンドを使用して、実行中のCPUの使用率を確認。
すると、2G程度あればいけそうだった。
→ インスタンスタイプは余裕を持って、t2.mediumに決定。

**その後、tensorflow, keras等を入れて検出プログラムを実行すると
無事に検出が行えた！**

##今後の予定
PHPを通じて検出プログラムを実行し、結果をスマートフォン等から確認できるようにする。

CloudformationでEC2を作った話

# はじめに
CloudformationでEC2の構築＋ユーザデータでM/W導入を自動化しようと思いました。
結論から言うとユーザデータ関連のテンプレートフォーマットエラーが解消できず、ただ単にCloudformationでEC2を作るだけの平凡な結果に終わってしまいました。

それでもCLoudformationについて多少勉強になったのでまとめます。
（今後解決策が見つかったら更新します）

# やろうとしたこと
– EC2インスタンスを作成
– テンプレートを修正せずに最新バージョンのAmazon Linux 2のAMIで起動させる
– ユーザデータでterraformをインストール【失敗】

# terraform導入
まずはユーザデータ作成のためEC2上で普通に導入しました。
特に理由はありませんが、何となくrootのプロファイルにPATHを追加する手順も入れました。

$ sudo yum install wget unzip
$ wget https://releases.hashicorp.com/terraform/0.12.20/terraform

【AWS】実質1ヶ月でデベロッパーアソシエイト試験に合格できたので忘れないうちに備忘録

実質1ヶ月勉強して、AWSデベロッパーアソシエイト試験（以下、DVA）を受験し、なんとか合格できました。
備忘録を兼ねて、やったことや振り返りなどを以下にまとめます。

## 受験の動機
クラウドに興味があり、まずはAWSから、と思ったのと、AWSを用いた開発に必要な機能概要を一通り押さえておきたいと思ったため。
あとは、会社の勉強会の最終ゴールだったということもあり。
## 業務経験と勉強期間
– AWS業務経験：なし
– 勉強期間：実質約1ヶ月

レガシーな案件への参画ばかりでAWSの業務経験はゼロ。
昨年、会社の月1勉強会に参加し、なんとなく主要な製品や特長を把握できたかな、というレベル。
受験直前1ヶ月は平日2～3時間、休日4,5時間勉強にあてました。

## やったこと
### 1. 情報収集（1日）
まずはAWS公式サイトで試験範囲の確認を行い（試験範囲は[コチラ](https://d1.awsstatic.com/training-and-certification/docs-dev-associate/AWS%20Certified%20Developer%20-%20

AWS Dynamodb 調べてみた

キーワードをメモしてみました。

## Dynamodbとは
Nosqlのデータベース。AWSのフルマネージドサービス
Nosqlの範囲は、キーバリュー型・ドキュメント型・カラム型

## テーブル構造>アイテム
パーティションキー
ソートキー（オプション）
アトリビュート
※パーティションキー、またはパーティションキー＋ソートキーで一意となる。
※パーティションキーによって、データどこのパーティションに登録されるかが決まる。

##レプリケーションは３つ。クロスリージョン

##DynamoDB Transactions
BachGetItemなどで、複数itemの操作をした時の動きを決めることができる。
一つでもエラーであれば、ロールバックするのかどうか。

##ローカルセカンダリインデックス
パーティションキーは変更できないが、
ソートキーの代わり、第二のソートキーとして検索に使用できる。
※テーブルをもう1つ作るようなイメージ（非同期なのでレイテンシーに影響なし）

##グローバルセカンダリインデックス
これは上記と異なり、パーティションキーの代わり
※テーブルをもう1つ作るよ

AmplifyのStorageと認証まわり

# AmplifyのStorageと認証まわり

## はじめに
サーバーレスWebアプリ開発を進めてくなかで、AmplifyのStorageと認証まわりの理解が進んできて、完全に理解したなと思ってJAWS-UG浜松で発表しようとしたら全然できませんでした。
できなかったというか、話し始めようとしたら話せるほど自分のなかで整理できてないことに気付いてギブアップしました。発表内容はこれだけじゃなかったとはいえ、まぁ失礼な話ですよね。本当すみません。
リベンジすべく、整理するために記事を書きます。

## Guest許可と認証ユーザーのみ
AmplifyのStorageをセットアップする際の質問のなかに以下のような質問があって、選択できます。

“`
? Who should have access: (Use arrow keys)
Auth users only
Auth and guest users
“`

* Auth user only
Storageへアクセスするためにユーザー認証(ログイン)が必要。
* Auth and guest users

【体験記】AWS認定クラウドプラクティショナーを受験した

AWS認定クラウドプラクティショナーに合格したので、勉強方法や感想をかんたんにまとめます。

###受験結果
***合格（755/1000）***

###事前知識
およそ1ヵ月前にMicrosoftのAzure Fundamentals試験(AZ-900)に合格していました。

###使用した教材
①[AWS認定資格試験テキスト AWS認定 クラウドプラクティショナー](https://www.amazon.co.jp/AWS%E8%AA%8D%E5%AE%9A%E8%B3%87%E6%A0%BC%E8%A9%A6%E9%A8%93%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88-AWS%E8%AA%8D%E5%AE%9A-%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B7%E3%83%A7%E3%83%8A%E3%83%BC-%E5%B1%B1%E4%B8%8B-%E5%85%89%E6%B4%8B/dp/4797397403/

Auto ScalingとOpsWorksの統合

## 参考
https://aws.amazon.com/jp/blogs/devops/auto-scaling-aws-opsworks-instances/

### AWS OpsWorksインスタンスの自動スケーリング

– AWS OpsWorksは、アプリケーションの構成と管理に役立ちます。 EC2インスタンスのグループ（スタックおよびレイヤーと呼ばれる）を作成し、マウントするボリュームや、ライフサイクルイベント（起動/シャットダウンなど）に応じて実行するChefレシピなどの構成に関連付けます。このサービスは、インスタンスのプロビジョニングと管理プロセスを合理化し、ChefとEC2を使用してユニフォームフリートを簡単に起動できるようにします。

#### Auto ScalingとOpsWorksの統合

– Auto Scalingグループ
：このグループは、EC2インスタンスのプロビジョニングとリリースを担当します。

– 起動設定
：Auto Scalingグループがインスタンスを起動するために使用する設定テンプレート。

– OpsWorksスタック
：Auto

AWS cliのコマンドメモ

# 記事の趣旨

AWS CLIのコマンドをメモしていく．必要が生じたときに調べて埋めていくので内容は偏ります．

## 1. AWS CLIとは

コマンドライン上でAWS操作を可能とするツール．インストールとかの話は[以前の記事](https://qiita.com/nk5jp/items/5dd72097e31c0340878c)のAWS CLIの項目を参照．以下に書き並べるリファレンスは[こちら](https://docs.aws.amazon.com/cli/latest/reference/)を参照してコピペしている．

## 2. 基本操作

### 認証情報などの設定

`aws configure`

この設定情報はwindowsの場合`C:\Users\USERNAME\.aws\config`というファイルに保存される．アクセスキーはIAMサービスからIAMユーザを選択，「認証情報」タグ内の「アクセスキーの作成」ボタンから作成可能．

“`console
$ aws configure –profile myprofile //myprofileというプロファ

【AWS IoT】AWS IoT Python SDKを使ってAWS IoTにモノを登録する

# 目的

AWS IoTへのモノの登録を、AWS IoT Python SDKを用いて行います。
モノが大量になると、コンソールで毎回登録するのが大変なため。

# 補足
モノの登録と同時に下記のことを行います。

– 各種情報登録
– “属性”に情報を登録
– デバイスシャドウに情報を登録
– モノを”モノのグループ”に追加
– 証明書の発行、アタッチ
– デバイス証明書・キーを発行して保存
– ポリシーを証明書にアタッチ
– モノを証明書にアタッチ

# 実行

## 事前準備

– モノを所属させるグループを作成しておきます。（手順は割愛）

– 証明書にアタッチするポリシーを作成しておきます。（手順は割愛）
![policy.png](https://qiita-image-store.s

codester チームメンバーの管理,

https://docs.aws.amazon.com/ja_jp/codestar/latest/userguide/how-to-add-team-member.html
### AWS CodeStar ロールとチームメンバーシップの利点
– チームメンバーの IAM でアクセス許可を手動で設定する必要はありません。

– チームメンバーのプロジェクトへのアクセスレベルを簡単に変更できます。

– ユーザーは、チームメンバーである場合にのみ、AWS CodeStar コンソールでプロジェクトダッシュボードにアクセスできます。

– プロジェクトへのユーザーアクセスは、ロールによって定義されます。

### CodeStar と連携する Managedサービス

– コードはCodeCommit に。Git credentialsは IAM Userに。

Use Cases for DAX

## 参考
https://docs.amazonaws.cn/en_us/amazondynamodb/latest/developerguide/DAX.html#DAX.use-cases

### Use Cases for DAX
– DAXは、マイクロ秒のレイテンシで、DynamoDBテーブルから最終的に一貫したデータへのアクセスを提供します。 Multi-AZ DAXクラスターは、1秒あたり何百万ものリクエストに対応できます。

– DAXは、次の種類のアプリケーションに最適です。
– 読み取りに可能な限り速い応答時間を必要とするアプリケーション。一部の例には、リアルタイム入札、ソーシャルゲーム、取引アプリケーションが含まれます。
– 少数のアイテムを他のアイテムよりも頻繁に読み取るアプリケーション。たとえば、人気のある商品の1日販売があるeコマースシステム

– **読み取り集中型であるが、コストに敏感なアプリケーション。**
– DynamoDBでは、アプリケーションが必要とする1秒あたりの読み取り数をプロビジョニングします。読み取りアクティビティが増加

テンプレートの検証

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-validate-template.html

テンプレートファイルの構文エラーを確認するには、aws cloudformation validate-templateコマンドを使用できます。

– 使い時
– syntaxチェック
– rollback したときに同じ状態になっているか確かめる

【AWS認定試験対策】EC2のポイントまとめ

# はじめに

AWSの認定試験を受験するにあたって、各AWSのサービスを幅広く理解する必要があったためサービスごとに抑えるべきポイント等をまとめてみました。

ちなみにAWS認定試験での勉強方法についてはこちらの記事で紹介しています。

– [AWS 認定Developer Associateに合格するまで](https://qiita.com/yoshiyama_hana/items/8ea41e756036ca098c4b)

今回はEC2についてアソシエイトレベルでまとめたものになります。

※情報は2019年12月31日時点のものになります。ご了承ください。

# 概要

– AWS上で起動する仮想サーバー
– 購入時に起動するインスタンスタイプを選択できる
– インスタンスタイプによって仮想サーバーのスペックが変わる(CPUやメモリなど)
– sshなどでログインする際にはキーペア(pemキー)が必要

# 料金

選択されたインスタンスタイプ、購入方法によって異なる
基本はインスタンスを起動させている時間(秒単位)に応じて料金が発生する

# 購入方法

購入方法は以下に

開発用AWS RDSインスタンスを Instance Schedulerを使って自動起動・停止してコスト削減する

最近、AWS費用削減のため、Instance Schedulerを使ったRDSの自動起動・停止の仕組みを導入しました。
Instance Schedulerは、EC2とRDSインスタンスの起動および停止スケジュールを設定できるソリューションです。
今回は、RDSを自動起動・停止するために必要な一連の設定手順についてまとめていこうと思います。

なお、手順については、AWSナレッジセンターの下記記事を参考にさせていただきつつ、ところどころ必要に応じて変更しています。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/stop-start-instance-scheduler/

# 事前準備
Instance Schedulerを使うには、Instance Scheduler CLIのセットアップが必要になります。また、Instance Scheduler CLIの利用するにあたり、AWS CLIの認証情報が必要になりますので、AWS CLIの設定も合わせて行う必要があります。
※AWS CLIとInstance Sche

OpsWorks で作成した インスタンスの データベースサーバーへの接続

Opsworksで作成したLinuxインスタンスがデータベースに接続するには、適切なドライバーパッケージをインストールするよう、アプリケーションサーバーの [Recipes] タブを編集すること

## 参考
https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/workingapps-connectdb.html

### アプリケーションのデータベースサーバーへの接続
AWS OpsWorks スタックにより 2 つの方法でアプリケーションにDBサーバーへの情報が提供されます。

– Linux スタックでは、AWS OpsWorks スタックにより、各組み込みアプリケーションサーバーインスタンスに、アプリケーションがデータベースサーバーへの接続に使用できる接続データを含むファイルが作成されます。

– AWS OpsWorks スタックでは、各インスタンスにインストールされるスタック設定およびデプロイ属性に接続情報が含められます。
– カスタムレシピを実装してこれらの属性から接続情報を取得し、任意の形式でファイ

AWS 認定Developer Associate に合格するまで

# はじめに

この記事では、いかにして私が2週間ほどの勉強期間でデベロッパーアソシエイトの認定を合格したのかを紹介いたします。

# 動機

今までの業務ではAWSを主に分析やETL処理といった用途で扱ってきたが、新しい業務ではAWSの基本的なサービスを抑える必要がありました。

そこで、AWSの勉強の１つのマイルストーンとして認定試験の合格とし、勉強をはじめました。

# 経歴

私は業務でデータエンジニア、データサイエンティストといった職種の業務を担当することが多く、触ったことがある AWSサービスはかなり偏っておりました。
(もちろん他のAWS認定資格は持ち合わせておりません)

ちなみに勉強を始める以前に使ったことのあるサービスは以下になります。

– S3
– AWS Athena
– EMR
– EKS
– AWS QuickSight
– AWS CodeBuild
– AWS Glue
– AWS ECS

分かる人はわかるかもしれませんがこの中で認定試験で頻出するサービスはS3とCodeBulidくらいで、正直0からのスタートといっても過言ではありませんでした。

BeanStalk アプリケーションライフサイクル, アプリケーションバンドルについて

https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/applications-lifecycle.html

### アプリケーションバージョンライフサイクルの設定
– Elastic Beanstalk は、新しいアプリケーションバージョンを作成するたびにアプリケーションのライフサイクルポリシーを適用し、ライフサイクルポリシーが適用されるたびに、最大 100 個のバージョンを削除
– デフォルトでは、Elastic Beanstalk はデータの損失を防ぐため、アプリケーションバージョンのソースバンドルを Amazon S3 に残します。ソースバンドルを削除すると、領域を節約できます。

### アプリケーションバンドル
ソースバンドルの要件

– 単一の ZIP ファイルまたは WAR ファイルで構成される (WAR ファイル内に複数の ZIP ファイルを含めることが可能)

– 512 MB 以下

– 親フォルダまたは最上位ディレクトリを含まない（サブディレクトリを除く）

AWS Batchでインスタンスストレージを使う方法

# 欲しいのはEBSじゃなくてエフェメラルなディスク

AWS BatchでEBSを使う方法なら、どこにでも書いてある。でもインスタンスストレージは？　2020年1月25日調べでは、どうやらどこにも書いてない。
エフェメラルなディスクが欲しいときにEBSを使うと、アホな管理の手間が発生するし、おそらくはインスタンスストレージのほうが速い。

# 結論

### 1. BatchのCompute environmentで、Instance typesにc5dなどのインスタンスストレージつきのを選ぶ

### 2. ジョブが走るコンテナ内で`lsblk`する

c5d.4xlargeの場合、ログはこうなる：

“`bash
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
/dev/nvme2n1 259:0 0 372.5G 0 disk
/dev/nvme1n1 259:1 0 22G 0 disk
└─/dev/nvme1n1p1 259:5 0 22G 0 part
/dev/nvme0n1 259:2 0 8G 0 disk
├─/dev/nvme

CodeBuild に用意されている Docker イメージ

https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-env-ref-available.html
RHEL/CentOS はないがWindowsはある。