Cloud9でLaravel開発環境を構築する際にいろいろハマったのでメモしておきます。

・やりたかった事
すでにgithubに上がっているlaravelプロジェクトをcloud9で動作させたい

・躓いたこと
git clone https:\hogehogeしても、動かない

↓↓↓　以下、laravelトップページが表示されるまでの足跡　↓↓↓

cloud9の初期設定はバージョンが古いです。
アップデートしましょう。

参考：https://qiita.com/kidatti/items/2d6a4a24f89dc71eb66e

ちなみにこの記事では7.2をインストールしていますが、現在の最新verは7.3ですね。
まとめると以下のような形でしょうか。

sudo yum -y update
sudo yum -y install php73 php73-mbstring php73-pdo
sudo unlink /usr/bin/php
sudo ln -s /etc/alternatives/php7 /usr/bin/php

phpのバージョンアップが済んだらcomposer installかcomposer updateを走らせると思います。
僕の場合はここでphpのバージョンが古いと以下のように怒られました。

(C9 ﾟДﾟ) ふざけんじゃねぇバカヤロウ!!
This package requires php ^7.2 but your PHP version (7.1; Package overridden via config.platform (actual: 7.1.33)) does not satisfy that requirement

さっき最新のバージョン入れたのに、php-vしても7.1しか返ってきません。
同じような症状にあった場合は以下を実行してみてください。

sudo yum remove php71*

そうすると7.3なり、7.2なりが顔を出してくると思います。

ちなみにcomposer.jsonの設定が古い可能性もあるので、念のため以下のように変更しておきました。

composer config platform.php 7.1.13

その後、満を期してcomposer updateを実行。
Laravelプロジェクトをgithubにプルした際、Vendorファイルが無くなる現象があります（僕だけ？）
Venderファイル上がってるよって人はこのcomposer updateは不要かも。

あとenvファイルもなかったので、それも復活させます。
参考：https://www.kabanoki.net/2524/

cp .env.example .env
php artisan key:generate
php artisan config:clear

これで初期設定完了。
なお執筆者はド素人なので皆さんの力を借りつつ何とか設定することが出来ました。
ありがとうございました。

はじめに

ECSで色々と作成しているとサービスが乱立してしまいがちで、それによってエラーが発生したりもします。
本記事はそれらを削除する方法をメモしておくものです。

要らないサービス名称を消す

AWS Cloud Mapからサービス名称を一覧表示することができます。

ここで不要なもののラジオボタンを押し、削除ボタンを押してあげれば削除完了となります。

なお、サービスインスタンスが存在する場合は、そちらを先に解除しないと削除できません。

※Route53の.localホストゾーンの当該レコードも一緒に削除されます。

まとめ

筆者はECS設定中に以下のエラーに遭遇しました。
creation failed: Service already exists. (Service: AWSServiceDiscovery; Status Code: 400; Error Code: ServiceAlreadyExists; Request ID: xxx)

Serviceが既に存在している為に作成できないとか。

こちらの記事によれば、以下で対処可能とのことです。

対処1：別のサービス名で作成する。
対処2：「サービスの検出サービスの設定」を「既存のサービスの検出サービスの選択」で進める。

が、そもそもサービスが乱立していて整理されていないのが根本原因だと思い、
不要なものを削除する方法を調べるに至りました。

参考

Amazon ECS サービス作成に失敗する

Amazon ECS 開発者ガイド
※CLIで削除したい場合

接続がVPC内部に限定されたリソース ( RDS, ElastiCache, 他... ) に、Docker Compose 内のコンテナからのアクセス

(ちょっといじればWindowsとかでも利用できるとおもいますが、主にMacなりLinux向けです)

私が担当しているサービスのWebアプリケーションは、docker-compose を利用して開発し、運用環境はECRで稼働させています。
開発時、サンプルデータを作成するのが面倒なので、RDSは開発環境と検証環境は、同一のデータベースを利用しています。
つい最近まで、パブリックアクセシビリティをONにしていたのですが、セキュリティ的によろしくないので、非許容(OFF)にする事にしました。
RDSは、パブリックアクセシビリティをOFFにすると、VPC外からの接続ができなくなります。
会社などのネットワークから接続できなくなるわけですから、開発時にはRDSに直接接続できなくなりますが、SSH Tunnelingで接続できます。
つまり、RDSと同じVPC内にEC2インスタンスを立てておき、このEC2インスタンスを踏み台にしてアクセスするということです。

開発端末からRDSに、開発端末のmysqlクライアントで接続したい場合、多くの情報が見つかります。
以下がその例になります。

RDSにSSHポートフォワーディングを利用して接続してみた

しかし今回の場合、開発にはDocker Composeを利用しているので、ローカルでトンネルを開通しても、ブリッジなど噛ますなどしなければ、
Docker Composeのネットワークから、ローカルに貼られたトンネルを利用できません。
そこらへんの手順は結構ややこしいので、なるべく少ない手順でSSH Tunnel を開通し、接続できないかと考えました。

理想は、普段どおり docker-compose up だけでアプリケーションがRDSに接続できるようになることです。
新規に開発メンバーがジョインしたときなどに、なるべく開発開始までに時間がかからないようにしたいからです。
また、アプリケーションそのものに影響を与えないような設計が望ましいと考えました。

デザイン

今回はPublic AccessibilityのないRDSへのアクセスを例に採ります。

以下の記事を大変参考にさせていただきました。

コンテナからSSHトンネルパターン (1)
コンテナからSSHトンネルパターン (2)

開発端末、（Dockerを起動するホスト）側でSSHトンネルを開通して通信するのではなく、
Docker ComposeでSSHトンネリング専用のコンテナ(アンバサダーコンテナ)を立ち上げて、アプリケーションからのMySQLの向き先をアンバサダーコンテナに向ける方法です。

このやり方なら、SSHトンネリング開通コマンドをアンバサダーコンテナのエントリーポイントに指定しておけば、docer-compose実行時に自動でトンネリングが開始されますし、同じDockerComposeネットワーク内の通信なので、ブリッジ等かませる必用はありません。

なお、証明書をボリュームマウントで利用しているのは、言わずもがなそちらのほうがセキュアだからです。
セキュリティ向上のためにVPC外のアクセスを断っているわけですから、DockerfileのADDなどでコンテナ内部に複製してしまうのは望ましくないと考えました。

手順

セキュリティグループとかの設定は、省略します。
各自で開発端末からEC2インスタンスにSSHで接続して、
EC2インスタンスにmysqlクライアントをインストールしてRDSに接続できる所くらいまでは確認しておいてください。

ディレクトリ構成

以下の様なディレクトリ構成を例に採り、説明します

web-app/
    .env # 環境変数ファイル(きっとバージョン管理外, ECRでもタスク定義とかで設定するマスタ)
    .env.local # 環境変数ファイルその2 開発端末以外は利用しない環境変数はこちらに分けておく事にする
    docker-compose.yml
    dockerfiles/
        app/ # アプリケーションコンテナ関連 (今回はさわらない)
            Dockerfile
            ... # アプリケーションコンテナ起動時に利用するファイルなど
        vpc-ssh-tunnel/ # 今回作成するアンバサダーコンテナ関連
            Dockerfile
            run-ssh.sh # コンテナでCMDとして渡されるファイル

  ....他、アプリケーションのソースコードなど

docker-compose.yml

docker-compose.yml

version: '3'

services:
  webapp: # アプリケーション
    build:
      context: ./
      dockerfile: dockerfiles/app/Dockerfile # まあ、各自そのままでおｋ
    env_file:
      - .env
    # ~~~~~~~~~~~
    # 略
    # ~~~~~~~~~~~
    depends_on:
      - vpc-ssh-tunnel # runするときなども、vpc-ssh-tunnelコンテナを先に起動させる
  vpc-ssh-tunnel: # アンバサダーコンテナ
    build:
      context: ./
      dockerfile: dockerfiles/vpc-ssh-tunnel/Dockerfile
    env_file:
      - .env # アプリケーションで利用している環境変数
      - .env.local # SSH Tunnelingで利用する環境変数
    volumes:
      - ~/.ssh:/cred:ro # Read Onlyで、Macの秘密鍵ディレクトリをマウント

Dockerfile

OpenSSHクライアントのインストール、起動時に実行するスクリプトをコピーして、エントリーポイントに指定

vpc-ssh-tunnel/Dockerfile

FROM alpine:latest

RUN apk add --no-cache openssh-client

WORKDIR /app
ADD dockerfiles/vpc-ssh-tunnel/run-ssh.sh /app

ENTRYPOINT ["/bin/sh", "/app/run-ssh.sh"]

環境変数

.env

この環境変数は、アプリケーションが利用する環境変数を想定しています。
現在、何らかのアプリケーションを動かしている場合、すでにDB接続先を環境変数などで指定していると思います。
それに合わせる感じでいいのですが、とにかくDockerComposeを実行する際の、接続先ホストとポートを変更します

.env

.
.
.
MYSQL_HOST=vpc-ssh-tunnel
MYSQL_PORT=33062 # 影響ないポートを任意で指定
.
.
.
略

.env.local

トンネリング用の環境変数です。
AWS上で稼働する運用環境では利用しないので、一応ファイルを分けました。
(現状、 .env は、ECRに環境変数を登録する際のマスタ的にも利用しているのです。。。)

.env.local

SSH_USER={EC2インスタンスのSSH接続ユーザ名}
SSH_HOST={EC2のGlobal IPアドレス}
SSH_KEY_NAME={秘密鍵のファイル名}
MYSQL_OUTBOUND_HOST={RDSのエンドポイント}
MYSQL_OUTBOUND_PORT=3306　# RDS接続ポート。基本3306だと思うけど変えてるならここも変更

エントリーポイント

ENTRYPOINTで指定しているシェルスクリプトです。
上述の2つの環境変数を利用して、SSHのトンネルを開通します

vpc-ssh-tunnel/run-ssh.sh

#!/bin/sh
ssh ${SSH_USER}@${SSH_HOST} -p 22 -i /cred/${SSH_KEY_NAME} -o "StrictHostKeyChecking no" -4 -fNL 0.0.0.0:${MYSQL_PORT}:${MYSQL_OUTBOUND_HOST}:${MYSQL_OUTBOUND_PORT}
while true; do sleep 30; done;

おしまい

あとは、 docker-compsoe up --buildなどで、アンバサダーコンテナをビルドしつつオーケストレーションしましょう。
あ、docker-compose.yml で、トンネル入口のポート番号(例だと33062)とかを空けておくなりすれば、開発端末のmysqlクライアントから接続もできるのではないかなと思います。

課題として、SSH接続が数十分で切れる問題が起きているので、それも解決できたら追記しようと思います。

IoT@Loft #8 スマートホームのセキュリティ脅威と対策を受講したよ!

セキュリティ対策にはOTA(DFU)が大事

今回は、コロナウィルスの影響で懇親会が中止となりました。
それもあってか、ちょっと軽めなセミナーでした。

LT1 - Zero Touch Provision for AWS IoT

マイクロチップ・テクノロジー・ジャパン株式会社
篠崎 雅和 氏

少量でもセキュリティチップを製作可能
https://www.microchip.com/promo/zero-touch-secure-provisioning-kit-forAWSIoT

LT2 - 非IoTスマートロックをIoT化する製品とそのバックエンド/セキュリティについて

株式会社ビットキー
山本 寛司 氏

スマートロックの脆弱性が見つかってもアップデートできないと大問題
ファームウェアの書き換え（DFU・OTA)出来ることが重要

バックエンドがしっかりしていると、実装作業(ソフト製作）に注力できる。

スマートホームのセキュリティ脅威と対策

アマゾン ウェブ サービス ジャパン株式会社
飯田 起弘 氏

POCや少量(数個）ならば、ハイエンドデバイスを選ぶべき
逆に大量に作るときは、セキュリティを先に考えないと、セキュリティ対応できなくなるケースがある。

個人的に苦手意識のあるまったくわからないゾーン！やってくよーー！
とりあえずわかるまでやるしかないのじゃ。資格とるには。

Route 53

DNSサービス。可用性高く低レイテンシー。自分でDNSサーバを構築する必要がなくなる。

パブリックホストゾーンとプライベートホストゾーンがある。
パブリックは、インターネット上に公開するDNSドメインのレコードを管理するホストゾーン。
プライベートはVPC内でのDNSドメインのレコードを管理するホストゾーン。
つまり公開する情報か公開しない情報かの違い。ちなみに四つのトップレベルドメインの、異なるロケーションに配置されたDNSサーバで管理されている。

エイリアスレコード

仮想リソースレコード。よくわからんな。

• AWSサービスのエンドポイントをDNSに登録する場合 AWSサービスはエンドポイントのIPが変わり続けるため、Aレコードの設定ができない。Aレコードとは、ホスト名からIPを引き出すやつ。IP変わっちゃうなら登録しても無意味やなそりゃ。

なのでRoute53でエイリアスレコードを作成し、エンドポイントのIPに直接応答するときに使う。
よくあるのは、ロードバランサの名前はLB.comだけど、エンドユーザからは別名(site.com)でアクセスさせたいときなどに使う。
ELBは動的IPなのでAレコードは使えない。よってCNAMEを使うのが一般的だが、同じようにエイリアスレコードを使える。
どちらも別名を登録するという点では同じだが、エイリアスレコードの場合、内部で処理してから返してくれるので早い。そしてS3/CloudFront/ELBへのクエリは無料。
site.com→site.comはLB.comのことだったな…せや！LB.comのIPで応答したろ！みたいな感じ。気が利く。

• Zone Apex 管理しているDNSドメインの頂点となるノードのこと。 例えば、「www.exam.com」の「exam.com」の部分のこと。すでにNSレコードにZone Apexが登録されている場合、CNAMEでの登録はできないため、エイリアスレコードを使う。

基本的にエイリアスレコード使えばいいんじゃないかな(適当)
別名ってことだけ覚えておこう。

ポリシーベースのルーティング

ポリシー名	説明
シンプルルーティング	従来と同様、事前に設定された値に基づいて応答
加重ルーティング	優先度を先に決めておいて、それが高いほうから
レイテンシールーティング	遅延が少ないほうから
フェイルオーバールーティング	ヘルスチェックの結果、利用可能なところから。一個も正常なのがない場合、逆にすべて正常とみなす。
位置情報ルーティング	クライアントの位置情報に基づき応答

たとえば接続が不安定な場合、ダウンタイムを最小にしたいならレイテンシールーティングポリシーを設定すれば解決できる。

Direct Connect

オンプレとAWSを専用線でつなぐサービス。インターネットVPNはネット経由なのでそれぞれの特色がある。

項目	インターネットVPN	専用線
コスト	安価なベストエフォートの回線を選択して利用することも可能	高め
利用開始までの期間	短い期間で開始可能	数週間以上
帯域	暗号化などのオーバーヘッド(負担)による制限あり	占有型は1,10Gbps。共有型は～10Gbps
品質	インターネットを利用してるため経路で影響を受ける	キャリアによる高い品質保証
障害対応	インターネットを利用しているため自社の範囲外だと困難	どの経路を使用しているのかはっきりわかるので比較的容易

要するに、高くて準備に時間がかかるけど早くて品質よいのが専用線。すぐ使えて安いけど品質とか速度落ちるのがインターネットVPN。よくあるのはプライマリ接続は専用線、バックアップ回線はインターネットVPNにするなど。

Direct Connectの接続構成

• 物理接続
  AWS自体はDCの場所を公開していないため、AWSのパートナーの設備に用意された相互接続ポイントを使って接続する。ルータを持ち込めば占有型、持ち込まないでパートナーのを共有して使うなら共有型になる。
  ちなみにパートナーのことをAPNパートナーというらしい。

• 論理接続
  物理的な接続を論理的に分割し、複数のAWSアカウントで使用できる。要するに物理線一本引いて、その中で分割すれば部署や用途ごとに使える。

プライベート接続とパブリック接続

プライベート接続は、プライベートIPを利用し、VPCのサブネットへアクセスする接続。
パブリック接続は、パブリックIPを利用し、全リージョンのパブリックサービスへ接続。パブリックIPじゃないといけないのでオンプレ側にNAT機器が必要。

Direct Connect Gateway

プライベート接続でVPCに接続するとき、VGW(仮想プライベートゲートウェイ)に接続する。
ほかのリージョンのVPCへ接続する場合はVPC同士がピア接続していないといけないが、ここでDirect Connect Gatewayの出番。友達の友達は友達！！ってタイプのやつ。
しかし、注意としては、オンプレ同士は友達になれない。VPC同士もなれないってかピア接続っていう方式を使え。

課金体系

使用した時間とデータの転送量で課金される。

CloudFront

CDNサービスのこと。こいつがキャッシュを持ってればそこから配信してくれるし、もってなかったらこいつがオリジンサーバ(大本)からコンテンツを取得する。
要するに野球でいうショートやセカンドのカット(中継)みたいな感じ。外野から一本でバックホームすると負担がすごいからこいつらが受け取って代わりに投げてくれる(ちょっと違うか)
どの中継になるかはディストリビュージョンが決める。レフトだったらショートが、ライトだったらセカンドがカットに入るとかそういう決まりをディストリビュージョンっていう。(しつこい)
オリジンサーバの負荷軽減や、クライアントに対してレスポンス向上などのメリットがある。
DNSサーバへドメイン名の問い合わせ→CloudFrontへドメイン名を問い合わせ→最適なエッジサーバを応答→エッジサーバへアクセス→キャッシュから応答もしくはオリジンサーバから取得してきて応答
って流れ。

暗号化通信

言っちゃえばこいつは中継地点なので、クライアントとこいつの間で暗号化できるし、こいつとオリジンサーバ間でも暗号化できる。

• クライアント-エッジサーバ間の暗号化
  デフォルトのドメインである、cloudfront.netドメインのSSL証明書を標準で利用できる。これによってデフォルトのドメイン名で利用する場合はHTTPSでクライアントとエッジサーバとの間で通信できる。
  また、独自ドメイン名の場合はX.509PEM形式のSSL証明書を入れれば利用可能。

• エッジサーバ-オリジンサーバ間の暗号化
  オリジンサーバが何かによって、暗号化の種類が変わる。

S3バケット
デフォルトではクライアントからアクセスされたプロトコルで通信される。HTTPSを必須にするなら、CloudFrontにてViewer Protocol PolicyをRedirect HTTP to HTTPS、または、HTTPS Onlyにする必要がある。

S3静的ウェブホスティング
HTTPSを使用できない。S3静的ウェブホスティングのエンドポイントがHTTPS不可のため。
この場合、S3静的ウェブホスティングはカスタムオリジンとして暗号化しなければいけない。

カスタムオリジン
CloudFrontにてViewer Protocol PolicyをRedirect HTTP to HTTPS、または、HTTPS Onlyに設定し、かつ、カスタムオリジンサーバに自分で証明書を入れなければならない。

要するにS3バケットならCloudFrontの設定変えるだけでいいけど、それ以外は設定変えたうえで証明書入れてねってこと。

署名付きURL

コンテンツへのアクセスを期間限定にしたい場合、署名付きURLにてURLの有効期限を設定できる。
例えば期間限定で音楽配信したりとか。長い期間なら事業計画を投資家に配信したりとか。

オリジンサーバの保護

オリジンサーバのURLが外部にばれて直接アクセスされることはセキュリティ的に大きな問題となる。(CloudFrontとクライアント間で暗号化とかしてたら、ここすっ飛ばされて暗号化できないため)
これを避けるため、オリジンサーバを保護する機能がある。

S3バケットの場合
Origin Access Identity(OAI)(かっこいい)を使い、S3バケットへのアクセスをCloudFrontからのみに制限できる。

S3静的ウェブホスティング
無力。注意すべし。

カスタムオリジン
オリジンカスタムヘッダーを利用して、CloudFrontで指定された任意のヘッダーをオリジンサーバでチェックすることで、CloudFrontからのアクセスのみ受け付けにできる。
しかし、オリジンサーバへのアクセス自体はパブリックにしておかないといけないためURL流出は注意。

要するにS3バケットの場合制限できる。カスタムの場合は制限しててもパブリックなので危険。静的ウェブホスティングは危険ってこと。まず流出しないよう気を付けよう。

以上。次回DBへ。

amplifyのアプリでディレクトリ名変更や他の人のをコピーしてきてからamplify pushするとエラーが発生する。
私の場合はパス変更後、「amplify add storage」したあとにamplify pushしたらエラーになりました。

+0900 (GMT+09:00) Parameters: [bucketName, unauthRoleName, unauthPolicyName, authRoleName, triggerFunction, authPolicyName] must have values

「amplify/.config/local-env-info.json」のパスを正しく直せばうまくいくらしい。

• 参考：https://blog.mismith.me/entry/2019/10/13/212300

aws ssm describe-instance-information の出力項目に ComputerName というのがある。
これは、公式ドキュメントによると

https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-instance-information.html

The fully qualified host name of the managed instance.

とのことで、FQDNが表示されるとのこと。
ところが、自分の現場ではこれの表示がlocalhostだったりしてうまく表示できていなかった。

$ aws ssm describe-instance-information --output table --query "InstanceInformationList[].[InstanceId,ComputerName]" --filters "Key=InstanceIds,Values=i-01234567890123456"
----------------------------------------------
|  DescribeInstanceInformation               |
+----------------------+---------------------+
|  i-01234567890123456 |  localhost          |  
+----------------------+---------------------+

これを解決した方法。

hostname が適切でない場合

$ hostname 
ip-172-31-15-172

この様になっている場合は、ホスト名を変更する。
Ubuntu 18.04の場合は以下。

sudo hostnamectl set-hostname awesome-production

$ hostname 
awesome-production
$ hostname -f
awesome-production

となればOK。

$ aws ssm describe-instance-information --output table --query "InstanceInformationList[].[InstanceId,ComputerName]" --filters "Key=InstanceIds,Values=i-01234567890123456"
----------------------------------------------
|  DescribeInstanceInformation               |
+----------------------+---------------------+
|  i-01234567890123456 |  awesome-production |  
+----------------------+---------------------+

ただ、自分の環境ではこれでも解決しないケースがあった。
原因は /etc/hosts の設定だった。

/etc/hosts が適切でない場合

まず、ComputerName に表示される内容は、自分の環境の複数インスタンスで確認した限りでは
hostname -f の出力と一致していた。
（ほんとはソースコードまで追っかけて裏取りたかったが、時間無く断念）

ComputerName が localhost になっていたインスタンスの /etc/hosts をみると
以下のようになっていた。

127.0.0.1 localhost awesome-production

いろいろ試したところ、localhost が単独行でないと、ダメらしく、以下のように修正した。

127.0.0.1 localhost 
127.0.0.1 awesome-production

こう修正したうえで hostname -f をすると、hostname と一致した。
（なぜこうなるか、までの理由はわからなかった）

$ hostname 
awesome-production
$ hostname -f
awesome-production

$ aws ssm describe-instance-information --output table --query "InstanceInformationList[].[InstanceId,ComputerName]" --filters "Key=InstanceIds,Values=i-01234567890123456"
----------------------------------------------
|  DescribeInstanceInformation               |
+----------------------+---------------------+
|  i-01234567890123456 |  awesome-production |  
+----------------------+---------------------+

ちなみに、上記hostname等修正後、 aws ssm describe-instance-information の出力に修正が反映されるまでは、少しタイムラグがある。
体感で数分程度。
おそらく SSM Agentが情報を取りに行くタイミングがあるのだろう。

目次

0.AWS/EB CLIとは...
1.設定方法
・EB CLIのインストール
　a)Homebrew で EB CLI をインストール
　b)macOS で Python、pip、EB CLI をインストール
・EB CLIの設定
2.デプロイ方法

0.AWS/EB CLIとは...

AWS Elastic Beanstalk は、Java、.NET、PHP、Node.js、Python、Ruby、Go および Docker を使用して開発されたウェブアプリケーションやサービスを、Apache、Nginx、Passenger、IIS など使い慣れたサーバーでデプロイおよびスケーリングするための、使いやすいサービスです。
お客様はコードをアップロードするだけで、Elastic Beanstalk が、キャパシティのプロビジョニング、ロードバランシング、Auto Scaling からアプリケーションのヘルスモニタリングまで、デプロイを自動的に処理します。同時に、お客様のアプリケーションが稼動している AWS リソースの完全な制御を維持でき、いつでも基盤となるリソースにアクセスすることができます。
https://aws.amazon.com/jp/elasticbeanstalk/ より引用

1.設定方法

・EB CLIのインストール（以下 a), b)の２種類。）
a)Homebrew で EB CLI をインストールする。

#Homebrewが最新バージョンであるかを確認
$ brew update

#インストールを実行
$ brew install awsebcli

#EB CLIが正しくインストールできているか確認
$ eb --version
EB CLI 3.17.1 (Python 3.8.1)

b)macOS で Python、pip、EB CLI をインストールする。
https://www.Python.org からPythonをダウンロードして、インストールする。

#pipをインストールする。
$ curl -O https://bootstrap.pypa.io/get-pip.py
$ python3 get-pip.py --user

#pipを使用してEB CLIをインストールする。
$ pip3 install awsebcli --upgrade --user

#EB CLIが正しくインストールできているか確認
$ eb --version
EB CLI 3.17.1 (Python 3.8.1)

※最新バージョンにアップグレードするには、以下インストールコマンドを実行。

$ pip3 install awsebcli --upgrade --user

EB CLIインストール完了！

・EB CLIの設定
　EB CLI をインストールした後で、eb init を実行するとプロジェクトディレクトリと
EBCLIを設定する準備ができる。

EB CLI プロジェクトを初期化する
1.リージョンを指定する。

% eb init

Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-south-1 : Asia Pacific (Mumbai)
7) ap-southeast-1 : Asia Pacific (Singapore)
8) ap-southeast-2 : Asia Pacific (Sydney)
9) ap-northeast-1 : Asia Pacific (Tokyo)
10) ap-northeast-2 : Asia Pacific (Seoul)
11) sa-east-1 : South America (Sao Paulo)
12) cn-north-1 : China (Beijing)
13) cn-northwest-1 : China (Ningxia)
14) us-east-2 : US East (Ohio)
15) ca-central-1 : Canada (Central)
16) eu-west-2 : EU (London)
17) eu-west-3 : EU (Paris)
18) eu-north-1 : EU (Stockholm)
19) ap-east-1 : Asia Pacific (Hong Kong)
20) me-south-1 : Middle East (Bahrain)
(default is 3): 9

2.リソースを管理できるように、アクセスキーとシークレットキーを入力。

You have not yet set up your credentials or your credentials are incorrect
You must provide your credentials.
(aws-access-id): hoge（入力）
(aws-secret-key): hoge（入力）

3.アプリケーションを選択する。

Select an application to use
1) hoge_server
2) xxx_pj
3) aws_app
4) [ Create new Application ]
(default is 4): 1（今回は1）

4.CodeCommit

Do you wish to continue with CodeCommit? (y/N) (default is n): n（defaultのまま）

EB CLIの設定完了！

2.デプロイ方法

・実際にデプロイできているか確認。

    $ eb deploy
    Creating application version archive "app-0d27-200220_180123".
    Uploading: [##################################################] 100% Done...
    2020-02-20 09:01:50    INFO    Environment update is starting.
    2020-02-20 09:01:57    INFO    Deploying new version to instance(s).
    2020-02-20 09:03:13    INFO    New application version was deployed to running EC2 instances.
    2020-02-20 09:03:13    INFO    Environment update completed successfully.

デプロイ完了！

以上

Elastic Beanstalk で Railsアプリをデプロイする時にハマったとこ

まとめ

Elastic Beanstalk へデプロイした経験から、ハマりやすいポイントをまとめました。
詳細については、以下の1回目と２回目のところを参照してみてください。

• セキュリティグループ
• MySQL エンコード
• .ebextension 設定
• 各gemの対応

1回目

• 文字コード（日本語の場合、utf8 へ変更必要）
  • RDSに作成したMySqlのDatabaseに日本語が登録出来ない問題 - Qiita
• セキュリティグループ (Mysql2::Error: Can't connect to MySQL server on '**********.*****.ap-northeast-1.rds.amazonaws.com' (4))
  • EC2 と RDS を同じVPC/サブネット上に置く方法
  • RDS のセキュリティグループに EC2 からのアクセスを許可する。

• rails db:createをやってくれない？
  (Mysql2::Error: Unknown Databese'**********')

  • 下記コマンドにて、自分でMySQLに接続して、DB作成。
  • MySQL への接続（EC2上で（eb ssh））
    • mysql -h **************.***.ap-northeast-1.rds.amazonaws.com -P 3306 -u ** -p
  • DB作成
    • create database ***********;
  • utf8 へ変更されているかコマンドを実行して確認

• initializers/carrierwave.rb 用に beanstalk へS3設定を追記

2回目

• eb init
• eb create
• RDS 作成
• ebに環境変数を格納

• .ebextensionを記述

• eb deploy

• EC2 cd /var/app/ondeck/ 内で

  • bundle update --bundler
  • gem install bundler:2.0.2

• local上の Ruby のversionを上げることでglobal環境のversionと合わせる

# install可能なversionを表示
$ rbenv install -l

# versionを指定してinstall
$ rbenv install 2.6.5

# インストールしたversionを使用可能な状態にする⇒shimsへの反映
$ rbenv rehash
$ rbenv local 2.6.5
$ rbenv global 2.6.5

• bundler のバージョンがあっていない？

(参照：Gem::GemNotFoundExceptionと出てきたときの対処法 - Qiita)

$ gem install bundler -v '1.17.3'

$ bundle install

• MySQLのインストールでエラーが出る。 mysql2 gemインストール時のトラブルシュート - Qiita

$ gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/' -- --with-cppflags=-I/usr/local/opt/openssl/include --with-ldflags=-L/usr/local/opt/openssl/lib

• nodeのversionが古いとかいうエラーがでた、mini-racer っていうgemを追加すれば直るって記述があった
  （ruby on rails - ERROR: ServiceError - Failed to deploy application. on ElasticBeanstalk - Stack Overflow）

• mini-racer入れたら直った？？

  • .ebextension に rails db:create を追加

• RDS のセキュリティグループを変更

• Sequel Pro から MySQLに接続できるかどうかを確認。→ できなかった

• EC2 に入って、コマンドで接続できるか

$ mysql -h *****RDSインスタンス*****.ap-northeast-1.rds.amazonaws.com -P 3306 -u **DB名** -p

→ 接続できた。
つまり、他の問題？

• EC2内から直接、DB(-)を作成するコマンドを打ったところ、ハイフンは使えないということを言われる。
  → 環境設定の ***-*** を _** へ変更。

• 再度、eb deployしたところ、同じエラーが出る。
  → わからないので、MySQLの中から _** を作成してしまって、再度 eb deploy

• エラーコードが変わって、MySQLのエンコードが問題っぽい。
  [AWS][RDS][MySQL] 文字コードをutf8mb4にする - Qiita

【MySQL】Mysql2::Error: Incorrect string value 【エラー】 - Qiita

• 対象のRDSのパラメーターグループをさっき変更したものに指定する。

• 作ったDBを一旦削除して、作成し直す。

• これも意味がなく、過去のEBではまったところが確認し直したところ、以下の記事を見つける。
  RDSに作成したMySqlのDatabaseに日本語が登録出来ない問題 - Qiita

ALTER DATABASE データベース名 default character set utf8;

• 下記エラーコードが出たので、crontabのコードを削除して、再度デプロイしてみる。

container_command 06-crontab in .ebextensions/02_setup_app.config

ようやくデプロイ完了！！

概要

awscliv2をインストールして、EKS上の情報をkubectl get svcで取得できるようにする。

目的、背景

awscliv2でkubectlが使えない？ということがあったので、実際にやってみる。

環境

• mac os　： Mojave 10.14.16
• 現在のawscli バージョン：　aws-cli/1.16.292

aws cli v2 インストール手順

AWS公式手順にしたがって作業する。

まずは以下のコマンドでインストールし、awscliv2.zipファイルとして保存する。

curl "https://d1vvhvl2y92vvt.cloudfront.net/awscli-exe-macos.zip" -o "awscliv2.zip"

保存したzipファイルを解凍する。

unzip awscliv2.zip

上記でawsというディレクトリが作成されるので、インストールコマンドを実行する。

sudo ./aws/install

パスワードを入力し、You can now run: /usr/local/bin/aws2 --version　と返って来ればOK。
バージョンを確認してみる。

hoge:~ akane$ aws2 --version
aws-cli/2.0.0dev4 Python/3.7.4 Darwin/18.7.0 botocore/2.0.0dev3

保存されたパスも確認してみる。

hoge:~ akane$ which aws2
/usr/local/bin/aws2

これでkubectl get svcをすると普通に実行できる。

hoge:~ akane$ vim ~/.kube/config
hoge:~ akane$ kubectl get svc
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)        AGE
kubernetes        ClusterIP      xxx.xx.x.x      <none>                                                                         443/TCP        88d

awscli v1がまだインストールされてる状態だったことを思い出したので、
v1をアンインストールしてもう一回実行してみると

hoge:~ akane$ kubectl get svc
Unable to connect to the server: getting credentials: exec: exec: "aws": executable file not found in $PATH

取得できなかった。

kubectlを使えるようにする

kubeconfigを確認してみる。

hoge:~ akane$ kubectl config view
- name: arn:aws:eks:us-west-2:xxxxxxxxxx:cluster/hoge-eks-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws
      env:
      - name: AWS_PROFILE
        value: fuga

commandで使用するコマンドを指定しているが、awsと記述していた。
awscliv2はaws2なので、これをaws2に修正する。

hoge:~ akane$ kubectl config view
- name: arn:aws:eks:us-west-2:xxxxxxxxxx:cluster/hoge-eks-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws2
      env:
      - name: AWS_PROFILE
        value: fuga

kubectl get svcを実行してみると

hoge:~ akane$ vim ~/.kube/config
hoge:~ akane$ kubectl get svc
NAME              TYPE           CLUSTER-IP      EXTERNAL-IP                                                                    PORT(S)        AGE
kubernetes        ClusterIP      xxx.xx.x.x      <none>                                                                         443/TCP        88d

ちゃんと取得できるようになった。

番外編

homebrewでのインストール

• homebrewでのインストールも可能。brew install awscliで、awscliv2がインストールされる。

参考

Linux または macOS での AWS CLI バージョン 2 のインストール

重要な変更 – AWS CLI バージョン 1 からバージョン 2 移行

CloudWatch エージェントのインストール

$ cd /usr/local/src #自分でインストールしたライブラリはここに入れてる

$ sudo wget https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm

$ sudo rpm -U ./amazon-cloudwatch-agent.rpm

その後
IAMでアカウントを作成
シークレットコード、アクセスキーを取得する
アタッチするロールはよくわからないので
CloudWatch*
の名のついたものすべてにしてみた。

CloudWatch エージェント設定ファイルを作成

ウィザードで簡単に作成してみる

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

# 全部デフォルトで。
# 追加ログいる？って聞かれたところで2. noを選択

Do you want to specify any additional log files to monitor?
1. yes
2. no
default choice: [1]:
2
Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully.
Current config as follows:

# 設定ファイルの中身が表示される

Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:

What parameter store name do you want to use to store your config? (Use 'AmazonCloudWatch-' prefix if you use our managed AWS policy)
default choice: [AmazonCloudWatch-linux]

Trying to fetch the default region based on ec2 metadata...
Which region do you want to store the config in the parameter store?
default choice: [ap-northeast-1]

Please provide credentials to upload the json config file to parameter store.
AWS Access Key:
[AMIで取得したアクセスキー]
AWS Secret Key:
[AMIで取得したシークレットキーを入力]
Successfully put config to parameter store AmazonCloudWatch-linux.
Program exits now.

IAM 認証情報とAWS リージョンの指定

$ sudo aws configure
Traceback (most recent call last):
  File "/usr/bin/aws", line 19, in <module>
    import awscli.clidriver
ImportError: No module named awscli.clidriver

# ↑ awscli.clidriver がないといわれる
# 念のためアップデート

$ sudo /usr/local/bin/pip install --upgrade pip
$ sudo /usr/local/bin/pip uninstall awscli
$ sudo /usr/local/bin/pip install awscli

# 再度実行
$ sudo aws configure
Traceback (most recent call last):
  File "/usr/bin/aws", line 19, in <module>
    import awscli.clidriver
ImportError: No module named awscli.clidriver

# まだawscli.clidriverがないといわれる、パッケージがあるかチェック
$ locate clidriver
/usr/local/lib/python2.6/site-packages/awscli/clidriver.py
/usr/local/lib/python2.6/site-packages/awscli/clidriver.pyc
/usr/local/lib/python2.6/site-packages/awscli/clidriver.pyo

# ある、対話モードでパスを確認
$ python
>>import sys
>>print sys.path
['', '/usr/local/lib/python26.zip', '/usr/local/lib/python2.6', '/usr/local/lib/python2.6/plat-linux4', 
'/usr/local/lib/python2.6/lib-tk', '/usr/local/lib/python2.6/lib-old', '/usr/local/lib/python2.6/lib-dynload', 
'/usr/local/lib/python2.6/site-packages', '/usr/local/lib/python2.6/site-packages/pip-9.0.1-py2.6.egg', 
'/usr/local/lib/python2.6/site-packages/setuptools-33.1.1-py2.6.egg']

# 見づらいけど「/usr/local/lib/python2.6/site-packages/」はあるなー
# 対話モードを[ctr +D]で終了

# 再度実行するとなぜかできた、パス認識してなかったのかも
aws configureaws 
AWS Access Key ID [None]: [AMIで取得したアクセスキー]
AWS Secret Access Key [None]: [AMIで取得したシークレットキーを入力]
Default region name [None]: ap-northeast-1　#東京リージョンを入力
Default output format [None]: 

#できたか確認
$ aws ec2 describe-instances
#　所有しているインスタンス情報が確認できればOK

cloudwatchエージェントを実行

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

# エラー

E! Error parsing /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml, 
open /usr/share/collectd/types.db: no such file or directory

# types.dbがないといわれる
# これは、「collectd」をインストールすることで解決

$ sudo vi /etc/yum.repos.d/epel.repo 
[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch
failovermethod=priority
enabled=0　→　ここを1に変更
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6

#保存してインストール

$ sudo yum install collectd

# もう一度、cloudwatchエージェントを実行

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json -s

Successfully fetched the config and saved 
in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp

止めるのはこう

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop

OK！みたいな雰囲気だけどどうかな？

設定ファイル「config.json」を変更した場合のパラメータリストへの手動アップ方法

$ cd /opt/aws/amazon-cloudwatch-agent/bin/
$ aws ssm put-parameter --name "AmazonCloudWatch-linux" --type "String" --overwrite --value file://config.json