2020年5月19日火曜日

Cloudfront for laravel(設定メモ)

■API gateway

ANYのメソッドを作成する。

VPCリンク：beanstalk(laravel)のNLBを指定している
エンドポイント：Beanstalk(laravel)


Cloufront：
Get Stratedを選択する。

Api gatewayのステージ：

上記のApi gateawayのステージのURLを以下の値に入力する

Origin Path /aaa
Minimum Origin SSL Protocol ：　SSLv1.2を選択
Origin Protocol Policy 　　　　：Match Viewer

以下の項目については特に変更してない

Create Distributionを選択


生成中の様子。
完成後、以下のアドレスにアクセスする。












時刻: 0 件のコメント:
ラベル: , ,

RDSスナップショット共有手順

参照先：

メソッドさんの検証レポート：


■作業イメージ
AWSアカウント(A)  ->AWSアカウント(B)にスナップショット複製する作業になる


スナップショットのコピー：
1)AWSアカウント(A)にログインすること
2)スナップショット > システム > 対象のDBを選択する。

3)アクションメニュー > スナップショットをコピーを選択する
ポイント：検索窓を使うことをお勧め！

4)新しいDBスナップショット識別子：識別し易い名前にする。
5)スナップショットをコピーするを押す。


スナップショットの共有手順：
1)スナップショット > 手動 > 該当のスナップショットを選択する


2)アクションメニュー > スナップショットの共有を選択


3)DBスナップショットの可視性：プライベート
4)共有先の[(AWSアカウント(B)]のアカウントIDを入力する
5)追加を押す



6)保存ボタンを押す。
これによりスナップショットの共有が開始される(数分で完了する)



スナップショット復元手順(共有先のアカウントで実施)：
1)AWSアカウント(B)のアカウントにログインして、スナップショットが共有されているか確認


2)対象のDBを選択 > アクションメニュー > スナップショットの復元を選択する。


3)復元するパラメータについては、現行環境のRDSの設計書を参考に記載する事
(設定内容については、割愛する)


時刻: 0 件のコメント:
ラベル: , ,

文字置換

UPDATE `clients` SET dbhost = REPLACE(dbhost, "xxxx.xxxxx.ap-northeast-1.rds.amazonaws.com", "test-xxxx.xxxxxxx.ap-northeast-1.rds.amazonaws.com");
時刻: 0 件のコメント:
ラベル: , ,

ELBに関するHTTPコードについて



HTTPCode_Backend_2XX：
(3)及び(4)のレスポンスで200系のHTTPレスポンスを行い、(1)〜(4)までのステップを全て正常に完了した場合、HTTPCode_Backend_2XXとしてカウントされます。
一般的に最も健全な動作と言えるでしょう。

HTTPCode_Backend_4XX：
(1)〜(4)までのステップを全て正常に完了したのだが、3のレスポンスが400系レスポンスであり、その結果(4)のレスポンスが400系として完了した場合、これはHTTPCode_Backend_4XXとしてカウントされます。存在しないリソースにアクセスして404がとなった場合や、Web APIに於いて必須のパラメータが足りなかった場合の400レスポンス等、クライアント側の「リクエストの仕方」に問題がある場合、400系のレスポンスを返すのが一般的ですね。

HTTPCode_Backend_5XX：
(1)〜(4)までのステップを全て正常に完了したのだが、(3)のレスポンスが500系レスポンスであり、その結果(4)のレスポンスが500系として完了した場合、これはHTTPCode_Backend_5XXとしてカウントされます。アプリケーション層でのエラーにより正常なレスポンスが返せなかった場合の500、メンテナンス中の503等、
エラーの原因がサーバ側にある場合、500系のレスポンスを返すのが一般的です。
ELBが独自の判断によりステータスコードを返す場合（HTTPCode_ELB_*）
以上の通り、普通は「バックエンドから受け取ったレスポンス(3)をそのままクライアントに返す(4)」のが
ELBの動きです。
しかし、特定の状況下ではELBは独自の判断で(4)のレスポンスを行います。

HTTPCode_ELB_4XX：
①HTTP 400: BAD_REQUEST
そもそも(1)のリクエストが日本語でおｋHTTPリクエストとして解釈不能な場合、ELBは(2)のリクエスト転送を行わず（行えず？）、400を返します。

②HTTP 405: METHOD_NOT_ALLOWED
(1)のリクエストにおけるHTTPメソッド名（GETやPOST等）が127文字を超えていた場合、ELBは(2)のリクエスト転送を行わず、405を返します。
HTTPメソッドは、よく知られたGET, POST, OPTIONS等の他に、独自の拡張が可能です。（RFC 2616 Section 5.1.1参照）
このような拡張を利用していた時、無駄に長いHTTPメソッド名が使われる可能性もゼロではありません。
HTTPの仕様上、この長さには制限は無いようですが、ELBとしては127文字を上限としているようです。

③HTTP 408: Request Timeout
(1)のリクエストでタイムアウトが発生した場合、ELBは(2)のリクエスト転送を行わず（行えず？）、408を返します。
例えば、ネットワーク切断が発生した場合や、Content-Lengthの値よりも実際のサイズが小さくてELBが続きを待ってしまう場合など、ELBが(1)の完了を認識できずにタイムアウトした場合があてはまります。

HTTPCode_ELB_5XX：
①HTTP 502: Bad Gateway
(3)のレスポンスが日本語でHTTPレスポンスとして解釈不能な場合、ELBは502を返します。

②HTTP 503: Service Unavailable(ELBの高負荷系)
Case 1:
突発的なアクセスによりELB自体がキャパシティを超えてしまった場合です。
ELBは、負荷に応じて自動スケールします。
 ->ELBを突発的な負荷が襲った場合、スケーリングが間に合わないことがあります。
また、負荷により「スケールアップ」が行われた場合、ELBのDNS名から正引きされるIPアドレスが変わります。
つまり、古い（小さな）インスタンスと、新しい（大きな）インスタンスにバトンタッチが起こります。
しかし、クライアントがDNSキャッシュを持っていた場合、スケールアップ前の古いインスタンスに対してリクエストを送り続けてしまうことがあります。
こういった場合にも、キャパ超えのレスポンスとして503が返されるでしょう。
このようなケースに対しては、ベンチマークツール等を利用して本番想定の負荷をあらかじめ掛けておき
ELBの自動的なスケーリングによる調整を期待した上で、本番運用を開始するといった対応が必要です。
このような対応が行えない場合、AWSサポートのビジネスまたはエンタープライズに加入しているのであれば
暖気申請を行うことも可能です。

AWSサポートに対して、いつ頃どの程度のリクエストが来るのか、事前に通知を行うことにより、リクエストを充分受け付けられる規模にあらかじめスケールをしてもらえます。


Case 2: 
(3)を行った後(4)が返ってくるのに時間が掛かり、(3)のリクエストがタイムアウトした場合です。
このタイムアウト時間は通常60秒です。
このケースに対応する場合、アプリケーションが60秒以内にレスポンスを返すように何らかの対応を行うのが
第一選択ですが、サポートに依頼することによりタイムアウト時間を最大17分まで延長することができるようです。

時刻: 0 件のコメント:
ラベル: , , ,

Fargate for CLIでデプロイ

参照先：

 ecsコマンドのオプション関連：

ECS IAMロール：

オプション：



1)ecsコマンドを投入してクラスタ名、ランチタイプ(EC2 or Fargate)、コンフィグ名、リージョン(東京リージョン)を
指定する。
ecs-cli configure --cluster tutorial --default-launch-type FARGATE --config-name tutorial --region ap-northeast-1


2)ecsコマンドを投入して、名前付き Amazon ECS プロファイルで、~/.ecs/credentials ファイルに保存されている AWS 認証情報を設定します。
ecs-cli configure profile --access-key [アクセスキー] --secret-key [シークレットキー] --profile-name tutorial-profile


3)IAMロールをアタッチする。
aws iam --region ap-northeast-1 attach-role-policy --role-name ecsTaskExecutionRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy


4)ecsコマンドで、クラスター設定名とecsプロファイル設定名を指定する。
ecs-cli up --cluster-config tutorial --ecs-profile tutorial-profile


5)ec2コマンドを投入して、VPCの指定を行う。
aws ec2 describe-security-groups --filters Name=vpc-id,Values=vpc-xxxxxxxxxxx --region ap-northeast-1

参照先：


6)ec2コマンドを投入して、セキュリティグループの追加を行う。
aws ec2 authorize-security-group-ingress --group-id sg-xxxxxxxxxxxxx --protocol tcp --port 80 --cidr 0.0.0.0/0 --region ap-northeast-1

参照先：


7)docker-composeファイルとECSの環境設定用のファイルを作成する

 vi docker-compose.yml 


 vi ecs-params.yml(ECSの定義ファイル)

8)docker-composeファイルからデプロイする
 ecs-cli compose --project-name tutorial service up --create-log-groups --cluster-config tutorial --ecs-profile tutorial-profile

9)コンテナの状態を確認する。
 ecs-cli compose --project-name tutorial service ps --cluster-config tutorial --ecs-profile tutorial-profile


スケールアップさせる場合：
例：2台にスケーリングアップする。 
ecs-cli compose --project-name tutorial service scale 2 --cluster-config tutorial --ecs-profile tutorial-profile

コンテナ状態を確認する。
ecs-cli compose --project-name tutorial service ps --cluster-config tutorial --ecs-profile tutorial-profile


削除を行う場合：
ecs-cli compose --project-name tutorial service down --cluster-config tutorial --ecs-profile tutorial-profile
ecs-cli down --force --cluster-config tutorial --ecs-profile tutorial-profile







時刻: 0 件のコメント:
ラベル: , ,

ECS(CLI)

参照先(ECS-CLI)：

参照先(ECS チュートリアル)：

参照先(docker-composeファイル構文について)：

<<タスク定義：環境に関する設定値を作成する>>
参照先：

参照先(タスク定義パラメータ解説ページ)：

タスク定義(esc-deployについてなど)：

参照先(バインドボリューム)：
ホストマシン上のファイルやディレクトリがコンテナにマウントさせたい場合に利用する方法

参照先(depends_on関連)：



ecs-params.ymの作成：

1)Docker Compose で定義できないパラメータは、別ファイル(デフォルトではecs-params.yml)で
パラメータを定義する必要があります。

2)ECS CLI をインストールするために、署名作業を行う。
(初回だけ行う)
①gpg --keyserver hkp://keys.gnupg.net --recv BCE9D9A42D51784F
②curl -o ecs-cli.asc https://amazon-ecs-cli.s3.amazonaws.com/ecs-cli-darwin-amd64-latest.asc
③gpg --verify ecs-cli.asc /usr/local/bin/ecs-cli
④sudo chmod +x /usr/local/bin/ecs-cli

参照先(ECS-CLI)：

注意：上記を行わないと、デプロイ作業が行えない(認証でNGになる)


ECS-Cluster作成：
1)クラスタ設定を作成する。
ecs-cli configure --cluster ec2-tutorial --default-launch-type EC2 --config-name ec2-tutorial --region ap-northeast-1

2)アクセスキーとシークレットキーを使用して、プロファイルを作成します。
ecs-cli configure profile --access-key [access keyの値] --secret-key [secret keyの値] --profile-name ec2-tutorial-profile

3)クラスターの作成を行います。クラスト：1台構成)
ecs-cli up --keypair [keypair名] --capability-iam --size 1 --instance-type t2.nano --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile



4)docker-composeとECSの環境ファイルの作成を行う。
vi docker-compose.yml

5)上記のdocker-composeファイルとECSの設定ファイルのデプロイを行う。
ecs-cli compose up --create-log-groups --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile

6)コンテナの状態を確認する。
ecs-cli ps --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile


7)ESCサービスの作成を行う
ecs-cli compose service up --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile




コンテナ停止方法：
ecs-cli compose down --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile


スケーリングアップの設定(2台)：
ecs-cli compose scale 2 --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile


クラスタの削除：
1)サービスの削除を行う
ecs-cli compose service rm --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile

2)クラスタの削除を行う。
ecs-cli down --force --cluster-config ec2-tutorial --ecs-profile ec2-tutorial-profile



タスク定義作成：
taskdefinition.json


時刻: 0 件のコメント:
ラベル: , , ,

ECS for deploy(その2)

参照先：

参照先(docker-composeファイル構文について)：


1)作成した、test-endo.pemがあるディレクトリに移動する。

2)クラスタの作成を行う。
ecs-cli up --keypair [keypair名] --capability-iam --size 2 --instance-type t2.nano --cluster-config ec2-tutorial --ecs-profile tutorial-profile

時刻: 0 件のコメント:
ラベル: , ,

ECS for Wordpress

参照先：

参照先(wordpress for RDS)：

参照先(docker-composeファイル構文について)：


1)クラスターの作成を行う
①ecs-cli configure --region ap-northeast-1 --cluster ecs-sample

②ecs-cli up --keypair [keypair名] --capability-iam --size 1 --instance-type t2.nano -ecs-profile tutorial-profile


2)docker-compose.ymlを作成する。

vi docker-compose.yml
====docker-compose===============
wordpress:
  image: wordpress:latest
  mem_limit: 156MB
  ports:
    - "80:80"
  links:
    - mysql
  environment:
    WORDPRESS_DB_HOST: mysql
    WORDPRESS_DB_USER: wordpressuser
    WORDPRESS_DB_PASSWORD: password
    WORDPRESS_DB_NAME: wordpress

mysql:
  image: mysql:5.7
  mem_limit: 156MB
  environment:
    MYSQL_DATABASE: wordpress
    MYSQL_USER: wordpressuser
    MYSQL_PASSWORD: password
    MYSQL_RANDOM_ROOT_PASSWORD: '1'
==================================

3)作成したdocker-compose.ymlを実行する。
ecs-cli compose -f docker-compose.yml up -ecs-profile tutorial-profile


4)コンテナの状態を確認する。
ecs-cli ps --ecs-profile ec2-tutorial-profile


5)アクセスを行う。


6)EC2にログインして確認してみる。



不要になったら、クラスタを削除する。
ecs-cli down --ecs-profile ec2-tutorial-profile

時刻: 0 件のコメント:
ラベル: , , ,

定義ファイル ->docker-copose変換

ECSの定義ファイルからdocker-composeのファイルに変更する便利な方法です。

参照先：


1)定義ファイルを作成する。
vi 12345.json

2)作成した定義ファイルをdocker-composeファイルに変換する。
ecs-cli local create --task-def-file 12345.json --output docker-compose.12345.yml
時刻: 0 件のコメント:
ラベル: , ,

git clone OTAトークン

参照先：


dockerfile上で、git cloneを記載するときに利用した手順


時刻: 0 件のコメント:
ラベル: , ,

docker エラー解析

参照先：


エラーコード確認；
docker ps -a

ログを確認する
docker logs [container_name]
時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)

ローカルLLMでコーディングさせるポイント

 簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい 途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして 参照して実施してくれるのがポイント