dynamodbを使ってみる

AWS DynamoDBのメモ - Qiita
https://qiita.com/YukiMiyatake/items/c3f13d32d90d15e5cfe0

Lambda(js)とDynamoDBを連携する - Qiita
https://qiita.com/kojiro_ueda/items/303f2466e11b55e5ec21

DocumentClientをつかうといいのね

メモ書き直感的に理解

amazon elasticsearch service

AWS LambdaからAmazon Elasticsearch serviceを利用する
https://wp-kyoto.net/using-aes-for-alexa-skills-datasource

lambdaからだと権限は設定できそうだけど、でも標準でなく自分でライブラリを入れる必要があるか。

Quick Start | elasticsearch.js | Elastic
https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/quick-start.html

jsライブラリ

lambdaとdocker

suddi/claudia-local-api： Command line utility to launch Express local API for claudia-api-builder. Test drive your lambda functions before deployment (https：//www.npmjs.com/package/claudia-local-api)
https://github.com/suddi/claudia-local-api

macだとうまくうごかせなかった
dockerで動かす

danlynn/claudia - Docker Hub
https://hub.docker.com/r/danlynn/claudia/

こちらはローカルで動かすというよりデプロイとリモートへのリクエストっぽいかな

初めてのAWS Lambda（どんな環境で動いているのかみてみた） - Qiita
https://qiita.com/ch7821/items/e3831e0dd67a30a13eca

amd64/node - Docker Hub
https://hub.docker.com/r/amd64/node/

node - Docker Hub
https://hub.docker.com/_/node/

trentm/node-bunyan： a simple and fast JSON logging module for node.js services
https://github.com/trentm/node-bunyan

出力を綺麗にできる

cognite

CognitoのWebサイトログインをES6で書く - Qiita
https://qiita.com/honmaaax/items/93945a5f98a2429d2dda

jsのライブラリがあるっぽい

aws amplify

AWS Amplify
https://aws.amazon.com/jp/amplify/

公式

AWS Amplify CLIの使い方〜インストールから初期セットアップまで〜 - Qiita
https://qiita.com/Junpei_Takagi/items/f2bc567761880471fd54

基本

Try #020 – CognitoとAmplifyでフロントエンドのみでログイン機能を構築してみた | dayjournal memo
https://day-journal.com/memo/try-020/

cogniteの認証ができるっぽい

AWS Amplify+Angular6+Cognitoでログインページを作ってみる ~バックエンド編~ ｜ DevelopersIO
https://dev.classmethod.jp/cloud/aws/aws-amplify-angular6-cognito-loginpage-backend/

AWS-Amplifyの中身、とくにAuth - たれぱんのびぼーろく
https://tarepan.hatenablog.com/entry/2018/05/23/135402

amazon-cognito-identity-jsがamplifyに統合されたのか
gatewayのオーソライザーで設定できるのね。。

忘れた頃にユーザー追加やMFAで登録していた端末を変更した時によく陥る現象。
原因も対策もなんてことはないけど、ググってもあんまりそれっぽいのが出てこないので備忘録として残します。

直面する問題

ユーザーにアクセス権限（ポリシー）を付与しているのにAWS マネジメントコンソールでアクセス権がないと言われ、インスタンスなど表示してもらえない。

↓↓↓どういう現象かというとこんな感じ↓↓↓

「you are not authorized to ~」　なので権限がないと言われているっぽい。
ユーザーを追加した時に、全ての権限を付与したはずなのに・・・？と思ったけど、よくよく考えて見たらポリシーにMFAデバイス認証つけてた。

ちなみに自分たちで追加したMFAデバイス認証はこんな感じ。（検索すると公式も出てくる）

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAllUsersToListAccounts",
            "Effect": "Allow",
            "Action": [
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:GetAccountSummary"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToSeeAndManageOnlyTheirOwnAccountInformation",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:CreateAccessKey",
                "iam:CreateLoginProfile",
                "iam:DeleteAccessKey",
                "iam:DeleteLoginProfile",
                "iam:GetAccountPasswordPolicy",
         　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ・・・中略・・・
        {
            "Sid": "BlockAnyAccessOtherThanAboveUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": "iam:*",
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

原因

アクセス権限（ポリシー）は付与していたけど、MFAデバイスの割り当てをまだ設定していなかったから、EC2インスタンス等の表示がブロックされていたみたい。

対策

ログイン後に「IAM→ユーザー→認証情報→ MFA デバイスの割り当て」でMFAのデバイスを登録する。
（こちらに詳しい設定方法が記載されてます → 「AWSでMFA(二段階認証)を有効にする方法を超丁寧に説明するよ」）

しかし、そのままEC2のダッシュボードに行ってもまだ権限がないと言われる。
一度サインアウトして、MFAデバイス認証を突破しないと見せませんよ、ってことらしいです。

もう忘れない。

参考

参考にさせていただきました。ありがとうございます。

[チュートリアル: ユーザーが自分の認証情報および MFA を設定できるようにする]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html

[MFA 条件を指定したサンプルポリシー]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_sample-policies.html

[AWSでMFA(二段階認証)を有効にする方法を超丁寧に説明するよ]
https://qiita.com/viptakechan/items/6d19aee635b2ab189e47

メールやslack通知を非同期実行するのに Delayed jobを導入。
.ebextensionsでworker起動しようと思ったが、killして起動し直すのも面倒だし、止まってないかの監視も必要なので、Rakeタスクで止まってたら起動する処理をスケジューラで実行することにした。
（Modules::LogNotice、Modules::SlackNotifierJobはログ書き出し、slack通知を行うJob。）

lib/tasks/delayed_jobs.rake

namespace :delayed_jobs do
  desc 'delayed_job のプロセスを起動'
  task start_up: :environment do
    Rails.logger.info "[BATCH]delayed_jobs.start_up is begun."
    ps = `ps aux | grep jobs`
    Rails.logger.info ps
    if !Rails.env.development? && !ps.match(/bin\/rake jobs:work *\n/)
      # バックグラウンドでjobを起動。
      if system('cd /var/app/current && nohup bundle exec rake jobs:work > /dev/null 2>&1 &')
        Modules::LogNotice.perform ['jobが起動していなかったので起動しました。']
      else
        message = 'jobの起動に失敗しました。確認してください。'
        Rails.logger.fatal message
        Modules::SlackNotifierJob.perform_now({ text: message }, 'danger')
      end
    end
    Rails.logger.info "[BATCH]delayed_jobs.start_up is finished."
  end
end

config/schedule.rb

...
every 10.minute do
  command "cd /var/app/current && bundle exec rake delayed_jobs:start_up"
end
...

標準出力、標準エラー出力を破棄しているが、ログに出すのも余裕があれば検討。

参考

• Railsでの非同期処理とDelayed Job – RE:ENGINES
• nohup - コマンド (プログラム) の説明 - Linux コマンド集 一覧表
• bash スクリプトの先頭によく書く記述のおさらい | Money Forward Engineers' Blog
• Railsのrakeタスクをバックグラウンド実行し、ログアウトしても終了させない方法 | Zoetin's diary
• いい加減覚えよう。 `command > /dev/null 2>&1`の意味 - Qiita

オレゴンでCloud9の環境作成しようとすると、そのAvailabilityZoneはサポートしていないぜって言われるんだけどなんだこれ。前まで作れたのに突然どうした。

エラーメッセージ

The AWS CloudFormation stack aws-cloud9-XXX failed with the error: Your requested instance type (t2.micro) is not supported in your requested Availability Zone (us-west-2d).Please retry your request by not specifying an Availability Zone or choosing us-west-2c, us-west-2a, us-west-2b. (Service: AmazonEC2; Status Code: 400; Error Code: Unsupported; Request ID: XXX).

直訳すると

AWS CloudFormation でエラーが起きたよ。
t2.microはあなたのAvailability Zone(us-west-2d）でサポートされていないよ。
us-west-2a〜cのどれかを選んでね。

原因

Cloud9を構築したVPCのサブネットに原因あり。
VPCを作成するときにサブネットのAZを「指定なし」にしていると、「d」にできあがる。

多分、2dは最近できあがったから期間限定のエラーなのだと思うけど、
ネットを調べても情報がなかったので残しておく。

対応にあたる経緯

以前の ELBをCLB(Classic Load Balancer)からNLB(Network Load Balancer)にオンラインで変更した時のメモ - Qiita の対応以後、SSL TerminationがEC2内で行われることから、その負荷に対応するためにインスタンスタイプを上げたり、EC2内でnginxへSSLの設定を加えたり、毎年なり２年おきなりにSSL証明書の更新作業が入って、運用コストがかかっていまして、、、
あー、、、ACMで自動更新できるようにならないかなー ってずっと思ってたんですが、先日、AWSから下記のアップデートが

Network Load Balancer が TLS ターミネーションのサポートを開始

お、これは ということで、軽く検証したところ、SSL証明書をACM化できちゃいました
ということで早速、ちょうどSSL証明書の期限切れアラートがきているシステムがあるので、実際に本番へ反映しちゃいます

対応手順の前に取り急ぎ検証した手順

※今の本番URL（www.XXXXXXX.jp）とは別で（nlb.XXXXXXX.jp）にてアクセスできるようにAWS管理コンソールを色々触りますので注意

1. まずは下記のデモの手順にそって新しいNLBを作成します。

• AWS Elastic Load Balancer Demos
• NLB作成時にElastic IPが１つ以上必要なので、作成しました。（ケチって１つだけにしてます ）
• NLBへセットするリスナーにて、新しいターゲットグループも作成しました。

2. 作成したNLBへ現在の本番のNLBに接続されているプロキシサーバをぶらさげます。

• せっかくNLBにて SSL Termination してくれるのであれば、それ以降のバックエンドではHTTPでいいだろってことでポートも 80 にします。
• ターゲットグループでステータスが healthy にならなくて少しハマりました。。。。
  • 原因は受け側にいるEC2 の SG（セキュリティグループ）にて、80ポートの解放を NLBを配置した subnetのCIDRからアクセスできるように設定する必要があった感じでした

3. また、EC2で動いている nginx でも 80 でアクセスして動作するような設定が必要ということで、取り急ぎ、 /etc/nginx/conf.d/XXXX-http.conf をコピーで作成して設定

/etc/nginx/conf.d/XXXXXXX-http.conf

server {
    listen       80;
    server_name  nlb.XXXXXXX.jp;

<後はコピー元と同じ>

4. んで、nginx再起動でできあがりです

$ sudo service nginx reload

本当にできてるのか？って思ったので、下記の資料の方法を使って、SSL通信でなくて、HTTPでアクセスされるのかをアクセスログを見て、チェックしました。
SSLじゃない場合は -[ハイフン] で出るんですね。勉強になります

• security - How can I let nginx log the used SSL/TLS protocol and ciphersuite? - Server Fault

ってことで次は本番反映にトライ！

検証はできたので、次はじゃあどうやってオンラインで変更するか ですよね
どうやってやろうかなーってことで、下記の前提条件がありながら、下記の手順を考えました

前提条件と必要条件

• 今のNLBのグローバルIPは変えたくない
  • 理由は外部からシステムへアクセスする方がVPNをはってアクセスしてくる際に、またルーティングの変更が必要になる。
• NLBのリスナーは複数作成できそうだったので、試したが同じポートだと作成できない。。。やろうとしたらエラーになっちゃいました・・・
  • 現在：TCP:443
  • 作成トライしたやつ：TLS:443
• せっかくNLBで Termination してくれるんだからバックエンドはもう http にしたい。
• バックエンドのnginxはHTTPS、HTTPの両方で動く状態にしておく。具体的には下記。

server {
    listen       80;
    listen       443 ssl;
    server_name  clb.XXXXXXX.jp  www.XXXXXXX.jp;

# ここはコメントアウトしてね
#    ssl                  on;
    ssl_certificate      /etc/pki/tls/certs/XXXXXXX.pem;
    ssl_certificate_key  /etc/pki/tls/certs/XXXXXXX.key;
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_protocols  SSLv2 TLSv1.2;

対応手順

1. まずは新しく、CLB（Classic Load Balancer）を作成。　※これを選んだのは単純に使い慣れてるのと、コンソール上でわかりやすいからでしたw
2. 作成できたら今のプロキシEC2をぶらさげて下記を対応
   • CLBへ今回反映しようとしているACMのSSL証明書を設定
   • SG（セキュリティグループ）は取り急ぎ社内LANからのHTTPSを解放
   • ぶらさげたEC2のSGへは社内LANからのHTTPSを解放したSGを送信元としたHTTPを解放するように設定
   • clb.XXXXXXX.jpで、このCLBのエンドポイントが名前解決されるようにRoute53へCNAMEレコード追加(Aレコードでもできた)
   • https://clb.XXXXXXX.jp でアクセスできるかチェック
3. 今、NLBにぶらさがってるプロキシEC2のSGをCLBへも設定
4. Route53でwww.XXXXXXX.jp の名前解決先をCLBへ変更
   • これで、アクセスの許可されたユーザが社外からの場合はVPNのルーティングが要変更だが、社内からのアクセスは可能となります
5. NLBへのアクセスがなくなった時点で、NLBの設定変更に着手
   • リスナーにて、TCP:443からTLS:443へ設定を変更し、新しく作成したACMを設定。
   • ぶら下がってるEC2のSGにて、一時的にHTTPを全解放するように設定
6. Route53でclb.XXXXXXX.jpにてNLBのエンドポイントに名前解決されるように設定し、アクセス確認
7. 問題なければ、Route53にて、www.XXXXXXX.jpの名前解決先をNLBへ変更して、アクセスできれば完了！
8. 一時的に解放したHTTPの全解放をクローズしてアクセス確認
9. 問題なければ、Route53でclb.XXXXXXX.jpの削除
10. 最初に作成したCLBの削除などでお片づけして終了

これでちゃんと、Amazon発行の証明書になります！
そして、SSL証明書の年間費用は不要となりましたとさ めでたし、めでたし

参考資料

• Network Load Balancer が TLS ターミネーションのサポートを開始
• AWS Elastic Load Balancer Demos
• - security - How can I let nginx log the used SSL/TLS protocol and ciphersuite? - Server Fault

AWS認定資格のバッジがいつの間にか変わってます。

資格	バッジ
ソリューションアーキテクト プロフェッショナル
ソリューションアーキテクト アソシエイト

枠の色が資格ごとに違うようです。
他の資格は持ってないのでわかりません。

はじめに

最近AWS Lambdaを使い始めるようになったのですが、公開できる（利益に関わらない）範囲内で特に楽しい使い方が思い浮かばなかったので334を自動で呟くbotでも手軽く作ろうかなと思った次第です。

Lambdaは簡単に言うとAmazonのレンタルサーバーでプログラムを実行する環境のことなのですが、これの大変素晴らしい点はサーバーの環境構築とか言う如何にも面倒臭そうでその道のプロじゃないと歯が立たなそうな作業をスルーして、コードを書いてちょっとした設定をするだけで実行できるとこです。すごい...

Lambdaに載せる段階でちょっと苦労したので初心者にも分かりやすい様に書く予定です。

前提条件

• AmazonWebServise(AWS)のアカウントがある
• Macにpython3およびpip3がインストールされている
• pythonに関する超基礎的な知識がある(progateレベル)
• twitterのapiを取得している

ディレクトリの準備

AWS Lambdaの仕様上、サードパーティのライブラリを使うときはコードがあるディレクトリに使うライブラリをインストールして丸ごとzipに圧縮してアップロードする必要があるので、それ用に新しいディレクトリを作る必要があります。

$ mkdir 334
$ cd 334
$ pip3 install twython -t ./
$ touch tweet334.py

ターミナルで上のコマンドを実行して334というディレクトリを作成、移動、ライブラリのインストール、pyファイルの作成までを済ませたらお好みのエディタでtweet334.pyを開いて以下のコードを書きます。

tweet334.py

from twython import Twython
import time

CONSUMER_KEY = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
CONSUMER_SECRET = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
ACCESS_KEY = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
ACCESS_SECRET = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
api = Twython(CONSUMER_KEY,CONSUMER_SECRET,ACCESS_KEY,ACCESS_SECRET)

def next334time(now):
    index=int((now-1551292440)/86400)
    return float(1551378840 + (index * 86400))-0.05

def lambda_handler(event,context):
    twiTime = next334time(time.time())
    while time.time() < twiTime:
        pass
    api.update_status(status='334')
    console.log('successfully tweeted!')

※XXXXXXのところは自分の情報に置き換えてください。

コードの説明

まずnext334time(now)という関数で次の3:34(JST)をUNIX TIMEで出力しています。1551292440は2019年2月28日の3:34であり1551378840は2019年3月1日の3:34です。そして86400は一日の秒数です。なのでindexは2019年2月28日から数えて何日目ですかって感じです。なおこのコードではtwitterサーバーとのラグを読んで50ミリ秒ほどフライングする計算になっています、後から微調整可能です。

lambda_handler(event,context)というのはLambda特有の表現ですが、要するにその中身をイベントが渡された際に実行しますよって感じです。while分は過激な内容で、指定した時間になるまで何もしないでtime.time()で一生現在時刻を測り直しています。pythonにはschedなどのライブラリもあるのでそれを使っても良いと思いますが、過激派なので使いません。

AWS Lambdaの設定

最初にLambdaのページにアクセスしてサインインしてください。
次に、以下の手順でLambda関数を作成します

1. 関数を作成をクリック
2. 一から作成を選んで名前好きな関数名(今回はtweet334とか)を入力
3. ランタイムはpython3.7(以降)を選択
4. ロールは「1つ以上のテンプレートから〜」を選択
5. ロール名という項目が出現しますがこれは好きな名前で良いです
6. ポリシーテンプレートは「テストハーネスのアクセス権限」を選択
7. おそらく右下にある関数を作成をクリックして完了

ここまで来たら関数をイジるページに変遷するので、少し下にスクロールして関数コードというテーブルを見つけます(普通にすぐ下にあります)。このテーブルの左上にコードエントリタイプという項目があり「コードをインラインで編集」がデフォルトでは選択されているはずなのでこれを「.zipファイルをアップロード」に変えてあげます。当然zipファイルを作らなければいけないので先ほどのディレクトリ内で以下のコマンドを実行してください。

$ zip -r tweet334.zip ./*

これは./(カレントディレクトリ)の*任意のファイルorディレクトリをzip形式で圧縮してtweet334.zipするという意味です。これを選択してアップロードしてあげましょう。サイトの方からGUIでお手軽アップロード可能です。

最後に、以下の設定をしてください
- 関数コード内のハンドラをtweet334.lambda_handlerに変更する
- 基本設定内のタイムアウトを1分10秒に変更する
- 上にあるテストイベントの設定からデフォルトで良いので適当にイベントに名前を付けて保存する

「ではテストを〜」と言いたいところですが、まだテストを押さないでください！

いや押しても良いのですが普通にタイムアウトになります、残念でした。
まだLambdaの外での設定が残っています

AWS CloudWatchでタイマーの設定をする

CloudWatchにアクセスして左の項目からルールを選択します。

ルールの作成 > イベントソース > スケジュール > cron方式

と選択し、33 18 * * ? *を入力します。これは毎日18:33分にプログラムを起動するという意味です。ちなみにAWSのリージョンを東京にしていてもこの時間はUTCが選択されるので時差9時間を足して3:33ということです。3:34の1分前にLambda関数を起動して「まだかまだか...」とpythonのコードないのwhile分で待機する感じですね。

そうしたら右のターゲットを追加で作ったLambda関数を選んで最後のポチポチは頑張ってください。人間ならできます。

いかがでしたか？！

すみません、突然アフィリエイトブログと化してしまいました...

実際のところ著者は万年金欠で困っているのでもし良かったら投げ銭して頂けると泣いて喜びます...ちなみにこれPaypal.meってサイトなんですがめっちゃ便利でご自分で金額を決めて送金できるんですよ！！！ちなみに配送先住所はセレクトボックスに住所は不要という選択肢があるので投げ銭等の場合はそちらを選べば相手に住所が伝わらないのでオススメです！！

注意：うろ覚えなんで手順抜けてる可能性あります。

背景

aws s3の静的ホスティングでサイトを公開している。最初はいちいちコンソールで上げてたが、流石にめんどくさすぎるので自動化したかった。サイト自体はgitで管理してたので、gitと連携して自動アップロードできないかなぁって調べたらCodeshipってサービスでできるらしいと知ったので使って自動化した。ついでにcloudfrontのキャッシュ削除も。

codeship

githubやbitbucketと連携してpushと連動してサーバのビルドとかができるらしいです。
aws s3とも連携できてBucket名を指定すればアップロードしてくれます。
月100回のビルドまで無料らしいです。

設定手順

codeshipアカウントの準備

https://codeship.com/
トップページのSign upを押すと上の欄にgitのホスティングサービスが出てくるので自分が使ってるやつを選びます。（自分はbitbucket）
多分認証画面みたいなのが出てくるのでOKを押して、あとは必要事項を入れてsign up

新しいProjectを作る

最初のログインのときにプロジェクト作成画面が出ます。
飛ばしてもあとから作れます。
下側の入力欄にbitBuketの自動アップロードしたいリポジトリの「クローンの作成」でコピーできるURLを貼ります。
この時自分はエラーが出ました。

bitbucket側でpipelinesを使うことを許可する設定を行わないとだめっぽいです。
bitbucketだとリポジトリの設定の一番下のPIPELINESのSettingのEnable Pipelinesのチェックをつけたら行けました。多分他のサービスでも似たような設定項目があると思います。

次にプロジェクトタイプを選びます。s3へのアップロードとcloudfrontのキャッシュ削除だけならbasicでいいです。というかproだとお金取られるのかな？(わからない)

Projectの設定

Projectの作成が完了したらこんな画面が出てくると思います。上の項目のDeployを選びます。

パイプライン（ビルドの手順のことをこう呼ぶらしい）でデプロイするブランチを設定します。この項目はよくわかってません。指定したブランチにプッシュされた時にトリガーするって設定かと思ったら初期設定だと他のブランチにプッシュしてもビルドが動いてました。ビルドするデータの場所……？とりあえずgit側でデプロイ用のブランチ作ってその名前と同じにしました。

s3へのアップロード

まずはs3の項目を選択。

s3の設定。AWS Access Key ID、AWS Secret Access Keyはs3の権限（AmasonS3FullAccess）を持ってるIAMユーザのものを使用します。新しく作るなら後でつかうのでcloudfrontの権限(CloudFrontFullAccess)も持たせておくといいです。AWS Secret Access Keyは後でも入力するのでちゃんと保存しておいてください。IAMの設定は割愛します。AWSのドキュメントを参照して下さい。
Regionはリージョン対応表を見て合うものを選択してください。東京ならap-northeast-1です。
local Pathはgit上のアップロードしたいファイルがあるフォルダを指定します。
S3 Bucketはアップロード先のBucket名を入れてください。
ACLはprivateでいいと思います。（よくわかってない）（権限関連だからよくわかってないのは危なそう）(資料読む限りprivateなら許可された人のみアクセスできるからこれでいいっぽい？)

設定ができたら下の画像のように表示されます。これでs3へのアップロードの設定は完了です。次はcloudfrontのキャッシュ消去です。

cloudfrontのキャッシュ消去

cloudfrontは連携できないのでaws cliを使って行います。codeshipに標準で入ってます。Custom Scriptを選びます。

deployment commandsには
aws cloudfront create-invalidation --distribution-id クラウドフロントのディストリビューションのアイディ --paths "/*"と書きます。ID（アイディ）は下の画像の赤丸の部分のことです。"/*"の部分は消去したいキャッシュの場所です。注意点として*(アスタリスク)を使う場合は""(ダブルクォーテーション)で囲む必要があります。

↓AWSコンソール画面↓

↓custom scriptの設定画面↓

次にaws cliで使うアクセスキーの設定をします。
上のメニューのEnvironmentを選びます。

Environment VariablesにIAMのアクセスキーを追加します。keyにAWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYと入力してValueにそれぞれの値を入力してください。内容はs3で設定したときと同じです。cloudfrontのアクセス権(CloudFrontFullAccess)を持ってるユーザじゃないとだめです。

↓流石に雑消しじゃ怖いのでキーは映してません。右側にvalueがあります。↓

build triggerの設定

初期設定だと、どのブランチにプッシュしてもビルドが走ってしまいます。
デプロイ用のブランチにプッシュしたときのみビルドを走らせたいので設定を変更します。
上のメニューのBuid Triggersを選びます。

この項目はお好みで（特定のブランチのみを指定するならRun builds for these branches onlyをえらんでEnter one branch per lineにそのブランチ名を書けばOKです）正規表現も使えるらしい。

実行

指定したブランチにプッシュするとビルドが始まるはずです。Projectトップを見るとビルド中の情報が見れます。成功したら以下のようにSUCCEEDEDと出ます。失敗したらFAILEDと出てどのステップで失敗したか、どういうエラーが出たかが見れます。設定を修正したら赤丸のRestart buildでもう一度実行できます。最初は一応s3とcloudfront、自分のサイトが更新されているかを確認しましょう。

終わり

これでデプロイ作業が楽になります。正直手動でアップロードとキャッシュ削除するのがめんどくさすぎてサイトの更新停滞してたのでこれでだいぶモチベ戻りました。やっぱり自動化は大事。

表記統一全然できてないな……。最初とかですます調ですらないし……。

参考

https://qiita.com/kashitaka1118/items/75954c92c0db9bf669e3
https://cwhite.me/continuous-delivery-for-your-static-site-with-codeship/

概要

ECS+EC2で動作しているアプリケーションをFargateに変更にします。
ECS+EC2での環境構築は、LaravelアプリケーションをAWS上のDockerで動かすを参考にしてください。

全てマネジメントコンソール上で行います。

前提条件

• LaravelアプリケーションをAWS上のDockerで動かすと同様のECS+EC2の環境が構築されていること

Farageteについて

メリット

• コンテナのためのEC2の管理が不要
  • コンテナのスケールに合わせてインスタンスタイプの変更、あるいはスケールアウトさせる必要がない
  • インスタンスタイプの選択が不要
• AutoScaleのタイミング設定が不要

デメリット

• コンテナホストにssh接続できない
  • Dockerコマンドが実行できないため、コンテナの状況を確認するといったことができない
• ログドライバがawslogsのみ

料金

EC2単位ではなく、コンテナ単位で料金が発生します。
下記の記事に最新の料金が記載されていましたので、参考にしてみてください。
2019年1月にAWS Fargateが大幅値下げしたのでEC2との価格比を確認してみた ｜ DevelopersIO

nginxの設定ファイルを修正

Fargateでは、コンテナ間通信の宛先は127.0.0.1になります。
nginxの設定ファイルの一部を下記の通り変更します。

default.conf

# 変更前
fastcgi_pass php-fpm:9000;
# 変更後
fastcgi_pass 127.0.0.1:9000;

IAMロールを作成

ECSタスク実行ロールを作成します。
手順は、下記のecsTaskExecutionRole IAM ロールを作成するにはに従って作成してください。
Amazon ECS タスク実行 IAM ロール - Amazon Elastic Container Service

なお、タスク定義のリビジョンの作成前にECSタスク実行ロールが作成されている必要があります。新しいリビジョンの作成の途中でロールを作成した場合、ECSタスク実行ロールを選択することができず、エラーとなります。

ALBのターゲットグループを作成

ALBのターゲットグループのターゲットの種類はipである必要があります。
既存のEC2のALBのターゲットグループがターゲットの種類がinstanceとなっている場合、新規で作成する必要があります。

タスクの定義のリビジョンを作成する

Amazon ECS > タスク定義 から作成済みのタスクを選択し、新しいリビジョンの作成を選択します。

以下の項目を変更します。

項目	値
ネットワークモード	awsvpc
互換性が必要	FARGATE

Fargateの場合、ネットワークモードはawsvpcを設定する必要があります。
nginxの設定ファイルを修正で、コンテナ間通信の宛先を127.0.0.1に変更した理由もここにあります。

タスクサイズ

項目	値
タスクメモリ (GB)	0.5GB
タスクメモリ (GB)	0.25vCPU

EC2の場合、設定はオプション項目となっていますが、FARGATEを選択した場合は必須となります。

コンテナの定義
コンテナのネットワーク設定でリンクを設定している場合、awsvpcではサポートされていないため変更する必要があります。今回は、EC2で動作している際に、nginxコンテナのネットワーク設定のリンクの設定を削除します。

また、ここではログの設定も行います。
コンテナでの運用の場合、コンテナを落とした際にログが消えてしまうため、ログを外部に出力する必要があります。
今回は、awslogsログドライバーを利用して、標準出力に出力されたログをCloudWatchに送信します。

ストレージとログのログ設定でログの出力先を設定します。
Auto-configure CloudWatch Logsにチェックを入れると、自動でロググループが作成されます。以上でログの設定は完了です。CloudWatchからログを確認することが可能となりました。

そのほかの設定の変更がなければ作成を押下して、新しいリビジョンの作成は完了です。

サービスを作成する

Amazon ECS > クラスター から作成済みのクラスタを選択し、サービスタブの作成を押下します。

項目	値
起動タイプ	FARGATE
タスク定義	上記で作成した新しいリビジョンを選択
プラットフォームのバージョン	LATEST
クラスタ	sample-api-cluster
サービス名	sample-fargate-api
サービスタイプ	REPLICA
タスクの数	1

Elastic Load Balancing（オプション）

項目	値
ELB タイプ	Application Load Balancer
サービス用の IAM ロールの選択	自動で生成されるAWSServiceRoleForECSサービスリンクロールが使用される
ELB 名	作成したALBを選択

負荷分散用のコンテナ

nginx:80:80を指定し、ELBへの追加を選択。
ターゲットグループ名に、作成したALBに紐づくターゲットグループを選択を選択。

以上で、ECSの環境構築は完了です。

動作確認

作成したALBのDNS名にアクセスし、動作確認を行います。

余談

Laravelのログを標準出力する際に、以下の余分なメッセージが出力される問題にぶつかりました。

WARNING: [pool www] child 10 said into stdout

原因と対応方法は、https://github.com/docker-library/php/issues/207 に記載されています。
また、PHP7.3ではこの問題が解消しており、 DockerイメージFROM php:7.3.2-fpm-alpineでは余分なメッセージが出力されていないことを確認できています。

参考記事

参考にさせていただきました。ありがとうございます。
AWS FargateでElixirのコンテンツ配信システムを動かしてみた (実装編) - エムスリーテックブログ
AWSにおける本番環境を想定したCI/CD実践 - y-ohgi's blog
AWS Fargate のすヽめ | 開発ブログ | Elastic Infra

手順

# rbenvをインストール
# 参考: https://github.com/rbenv/rbenv#basic-github-checkout
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
source ~/.bash_profile

# ruby-buildをインストール
# 参考: https://github.com/rbenv/ruby-build#readme
mkdir -p "$(rbenv root)"/plugins
git clone https://github.com/rbenv/ruby-build.git "$(rbenv root)"/plugins/ruby-build

1.はじめに

このドキュメントはSevTechAgesのmodを導入したマインクラフトサーバーを立ち上げるときに参考にしたサイトと手順をまとめたものです。
何かのお役に立てればと思います。

2.おことわり

• 個人的なメモです。
• 日本語でSevTechのマルチ鯖の立て方を説明しているページがほとんどなかったので書きました。
• よりよいサイトがあればそちらを紹介いただけると幸いです。
• Minecraftのライセンスを取得してあり、バニラ環境で自由に遊べる方向けです。
• EC2インスタンスは有料のプランを想定しています。クレカを準備してください。
• 1日4時間起動したとして月に2000円くらいの計算です。
• EC2インスタンスの状態を停止にしておけば課金は発生しない。。。はず。。。！

3.クライアント側

サーバをいじる前にクライアント側を解決します。

• 以下のサイトからTwitchデスクトップアプリを入手 https://www.twitch.tv/

1. アプリを立ち上げたらトップバーのModsを選択
2. Modsのタブ「すべてのModパックを参照する」を選択し「SevTech: Ages」で検索
3. SevTech: Agesをインストール
4. 起動オプションからJVMの引数で指定されているメモリ量を貴方のPCのスペックが許す限り引き上げましょう。

-Xmx6144m -Xms4096m -XX:Per...

※最低4GBは割り当てないとゲームになりません。

※より詳しくは以下の動画を参照
https://www.youtube.com/watch?v=WX2iLnYJEvY

4.サーバ側

AWSでEC2サーバを立てます。
以下のログインまでを参照
※インスタンスタイプの選択はt3.largeが良いかと思います。sev君とってもおもいので。。。
※セキュリティグループの設定ではpingが通るように設定してください

• AWSで爆速でMinecraft Plugin鯖を建てる方法！-https://qiita.com/ReyADayer/items/551755bf22698541e30c
• AWSのEC2インスタンスping送受信設定-https://blogenist.jp/2018/06/20/4805/

ログインできたら以下のコマンドを順に打ってインストールまでする。

mkdir sevtech
cd sevtech
sudo yum install java-1.8.0-openjdk
wget https://media.forgecdn.net/files/2570/735/SevTech_Ages_Server_3.0.8.zip
unzip SevTech_Ages_Server_3.0.8.zip
chmod 777 Install.sh
chmod 777 ServerStart.sh
./Install.sh

↑のコマンドが何をやっているかコメントで説明

mkdir sevtech #ディレクトリをきる
cd sevtech #ディレクトリに移動
sudo yum install java-1.8.0-openjdk #javaをインストール(javaバージョンは2019年現在のもの)
wget https://media.forgecdn.net/files/2570/735/SevTech_Ages_Server_3.0.8.zip #SevTech_Ages_Serverをダウンロード
unzip SevTech_Ages_Server_3.0.8.zip #解凍
chmod 777 Install.sh #実行権限付与(777だとすべての権限が付く)
chmod 777 ServerStart.sh #実行権限付与
./Install.sh #実行(時間がかかるので終わるまで待つ)

インストールが完了したらおなじみのeula.txtを作成

vi eula.txt

aを押して以下をコピペしESC,ZZの順で操作すると保存できる
※わからなかったら「viコマンド」で検索

eula.txt

eula=true

スタートする前にコンフィグをいじる

vi settings.sh

settings.sh

# Don't edit these values unless you know what you are doing.
export INSTALL_JAR="forge-1.12.2-14.23.4.2707-installer.jar"
export SERVER_JAR="forge-1.12.2-14.23.4.2707-universal.jar"

# You can edit these values if you wish.
export MIN_RAM="4096M"
export MAX_RAM="6144M"
export JAVA_PARAMETERS="-XX:+UseG1GC -Dsun.rmi.dgc.server.gcInterval=2147483646 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Dfml.readTimeout=3600"

sevtechサーバを起動する

./ServerStart.sh

Stuck on unloading dimension 20とかがコンソールに流れ始めたら大体起動できているので、twitchから起動したsevtechのクライアントを立ち上げて、自由に遊びましょう。

Have a nice game!

はじめに

2019/2/25に￥1,400で購入したUdemyの以下の講座で学んだことを記録する。
これだけでOK！ AWS認定ソリューションアーキテクト – アソシエイト試験突破講座（充実の20時間完全コース）

記録の目的は以下の通り

1. メモを取ることで学習のモチベーションを上げる
2. 学んだこと（忘れたこと）を思い出せるようにする
3. Qiitaを使って見る
4. Markdown表記になれる ※認定試験を受ける予定はない

記録しようと思うこと

• 受講した講座のタイトル
• ハンズオンで行った事
• 学んだこと
• 感想

さしあたり時系列で記録をとるが、後から見やすいように編集をするかも知れない。
まずは最後までやり遂げることを目指す。

2019/2/26

受講した講座のタイトル

・はじめに
01. はじめに
02. AWSのアカウント登録
03. AWSでサーバーを構築してみる①
05. SSHの基礎
06. Day1対応の実施①
07. Day1対応の実施②
08. Day1対応の実施③
09. Day1対応の実施④

ハンズオンで行った事

AWSアカウントの作成、Tera Termのインストール、お試しでのEC2インタンスの作成、AIMでのユーザー作成

学んだこと

用語
VPC：Amazon Virtual Private Cloud
EC2：Elastic Compute Cloud
RDS：Relational Database Service
S3：Simple Storage Service

感想

講師の挨拶ビデオが無かったので、どのような方が講師なのかが解らない。講義は不慣れなようでこなれた感じはない。モチベーションが上がらないが講義内容自体は興味があるので楽しめた。私の知識不足が原因だが、講師の言っていることや行っていることの意図が解らないことがあり、ただ指示された作業をこなしている状態になる事があった。理解が深まれば、そのような問題は解消されるものと願っている。先輩からのOJTというよりは、大衆向けeラーニングという感じ、テキストに沿って表面的な知識をなぞっている感じが否めない。

2019/2/27

受講した講座のタイトル

・AWSとアソシエイト試験の概要
10. AWSの仕組み
11. アソシエイト試験概要
12. AWSの全体像

ハンズオンで行った事

なし

学んだこと

なし

感想

試験にほとんど興味がなかったこと、電車内での受講だったこともあり、とても退屈で半分寝ながらの受講となってしまった。

2019/2/28

受講した講座のタイトル

・IAM
13. IAMの概要
14. IAM設計
15. IAMグループへのポリシー適用
16. IAMグループへのポリシー適用（ハンズオン）①
17. IAMグループへのポリシー適用（ハンズオン）②
18. IAMロールへのポリシー適用

ハンズオンで行った事

IAMを利用して、以下の3種類の役割を想定してポリシーの作成とポリシーのグループへの割り当てを行った。

想定した役割
1.管理者
2.運用担当
3.開発担当

作成したグループと割り当てたポリシー
1.Administrator
　　AdministratorAccess
2.Operation
　　Operation
　　Development
3.Development
　　Development

作成したポリシーと割り当てたサービス
1.Operation
　　cloudwatch,config,cloudtrail　　
2.Development
　　EC2,S3,RDS,ほか

続いて、EC2インスタンスへの、S3への接続を行うロール設定を行った。
まずはポリシーを作成し、そのポリシーを割り当てたロールを作成した。
そのうえで、EC2から、該当するインスタンスを選択して、ロールの割り当てを行った。

学んだこと

WindowsのADと同様に階層構造を持ったロール設定が行える。
あらかじめ準備されているポリシーとは別に、自分でポリシーの作成が可能。
その際には、サービスの指定と、対象とするリソースの範囲など、さらに細かな指定ができる。
ユーザーだけでなく、EC2インスタンスに対しても同様の仕組みでロールの割り当てができる。

感想

いかにもテキストに沿ったシナリオ通りの講義。考えることもほとんどなく、黙々と作業をこなす印象だった。また「本当はよくないけど、ここではとりあえず...」といった雑な説明で詳細をはしょる箇所が多い。試験対策としては応用の領域で対象ではないのかもしれないけど、実運用ではどの程度細かい設定で運用しているのかなど説明も欲しかった。また、説明をしているのか、ぶつぶつと独り言を言っているのかよくわからない。
それから、設計が重要だといっておきながら、まともな設計はせずに、ポリシーやロールを実際に作りながら、「とりあえずこんな感じで作っておきましょうか」と適当な名前や設定で進めていくのも、なんだかなぁと思った。
とはいえ、講義のみに比べればハンズオンは楽しい。

2019/2/xx

受講した講座のタイトル

ハンズオンで行った事

学んだこと

感想