What's New Qiita

20200430のAWSに関する記事は22件です。

  • 投稿日：2020-04-30T23:51:36+09:00

AWS, LPICの資格取得計画

取得目的

入社後の研修期間中にクラウド・サーバーエンジニアに必要な知識を高めるため

取得予定資格

  • AWSソリューションアーキテクトアソシエイト
  • LPIC1

学習方法

AWS

  • Udemy これだけでOK!AWS認定ソリューションアーキテクト
  • 徹底攻略　AWS認定ソリューションアーキテクトーアソシエイト教科書: 株式会社インプレス 2019

LPIC1

  • Udemy Linuxコマンド、シェルスクリプト、データベース、ネットワーク 、セキュリティ、LPIC101・102を極める14時間
  • Linux標準教科書: https://linuc.org/textbooks/linux/
  • UNIXコマンドブック: ソフトバンククリエイティブ株式会社 2009
  • Linuxコマンドポケットリファレンス: 技術評論社 2009

学習計画

AWS

04/24 はじめに

04/24 Day1対応

04/24 試験の概要

04/27 IAM

04/27 EC2

04/27 VPC

04/28 S3

04/29 WAF

04/30 信頼性の設計

05/01 Route53

05/04 DB

05/04 サーバーレス

05/04 環境の自動化

05/05 キャッシュの活用

05/06 セキュリティと運用

05/07 模擬試験

LPIC1

4/24 Linux環境構築、コマンド

4/27-4/29 シェルスクリプトの実装

4/30 LPIC101

5/01 LPIC 102

5/04 UdemyカリキュラムS1復習

5/05 UdemyカリキュラムS2復習

5/06 UdemyカリキュラムS3復習

5/07 UdemyカリキュラムS4復習

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T23:44:20+09:00

LINEBotをみんなで作ろう〜LINEBot is 何？編〜【GWアドベントカレンダー2日目】

この記事は下記の #GWアドベントカレンダー の 2日目の記事になります。

楽しそうなのでやってみる　( @inoue2002 ） | GWアドベントカレンダー

はじめに

こちらの内容は超初心者向けです。
公式ドキュメントを読める方はこちらをお読みいただく方が正確です。

昨日の記事をご覧になってない方はぜひ。
こちらの記事はGWアドベントカレンダーを通してLINEBotをサーバレスで作れるようになろう！ということを目標に書いている記事です。

LINEBotって何なん？って思われる方にまずお読みいただきたいです。
できるだけ専門用語を使わず、噛み砕いて書いていきます。

LINEBotとは

「bot」という単語は robotの短縮形であり、みなさんが想像されるロボットの短縮形という認識で大丈夫です。

ロボット＝人間の代わりに仕事をしてくれる

つまり
LINEの中で、人間の代わりにメッセージのやりとりをしてくれるロボット　→　LINEBot　と呼ばれているわけです。

「人間の代わりにメッセージのやりとりをしてくれる」というのは具体的にどんなものでしょうか。
よくみなさんも目にするであろう企業のLINE公式アカウントを思い出してみてください。定期的にメッセージが送られてきたり、トーク内でメッセージを送ったりすると、即答でメッセージが返ってくる経験をした事があるはずです。
最近で有名な公式アカウントを例にあげると、

ローソン：　AIを搭載しており、ユーザーに合った商品をレコメンドしてくれる
ローソンのLINEBot
https://www.lawson.co.jp/lab/tsuushin/art/1372267_4659.html

クロネコヤマト：　再配送を依頼したり、荷物がいつ頃届くのか確認したりできる
人狼GM
http://www.kuronekoyamato.co.jp/ytc/campaign/renkei/LINE/

日々増え続けているのでぜひ「LINEBot　企業」などで検索をかけてみると面白いBotに出会えるかもしれません。

少しはLINEBotというものがどういうもので、どんな物に活用されているのかを掴んでもらう事ができましたでしょうか。

ここで、企業は色々と客に対して便利なサービスを提供できるけど、個人で開発したところで何の役にもたたんやろ。と思っておられる方もおられるのではないでしょうか。

実際に筆者が、過去２ヶ月で作ったLINEBotをみていただき、個人開発でどんな事ができるのか。可能性を広げていただければなと思います。こちらの動画では５種類の実際にリリースしたbotを紹介しています。↓登壇動画 2020/4/29
bot紹介動画

LINEBotが動く（Messaging API)の仕組み

Messaging APIを使い、リクエストは、JSON形式でHTTPSを使って送信されます。

1.ユーザーが、LINEBotにメッセージを送信します。
2.LINEプラットフォームからボットサーバーのWebhook URLに、Webhookイベントが送信されます。
3.Webhookイベントに応じて、ボットサーバーからユーザーにLINEプラットフォームを介して応答します。
API

LINEBotでできること

・応答メッセージを送る
・プッシュメッセージを送る
・さまざまなタイプのメッセージを送る
・ユーザーが送ったコンテンツを取得する
・ユーザープロフィールを取得する
・グループチャットに参加する
・リッチメニューを使う
・ビーコンを使う
・アカウント連携を使う
・送信メッセージ数を取得する

メインで使う機能としては、

・応答orプッシュメッセージを送る
・ユーザープロフィールを取得する
・リッチメニューを使う

辺りだと思います。言葉だけでも覚えておくと良いでしょう。

終わりに

明日からサンプルコードを利用しながら、実際にLINEBotを作っていきます！頑張っていきましょう！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T23:41:02+09:00

AmazonLinux2でFTPとFTPS兼用させる

！！！ 基本的に全てroot権限の作業になりますのでご注意ください ！！！

AmazonLinuxの場合

デフォルトの

/etc/vsftpd/vsftpd.conf

でなく

/etc/vsftpd/vsftpd-ftp.conf
/etc/vsftpd/vsftpd-ftps.conf

のようにFTPとFTPS両方に対応した2つの設定ファイル(*.confであること)を用意すれば自動的に兼用出来るようになっています。
(/etc/init.d/vsftpd の処理を見れば分かると思います。)

AmazonLinux2の場合

AmazonLinuxと同様の方法が使えないため別のやり方をする必要があります。
ちなみにCentOS7も同様かと思いますが試していません。

　まずFTP用の設定ファイルとFTPSの設定ファイルのそれぞれでvsftpdを起動するシェルを作ります。

/usr/sbin/myvsftpd.sh
#!/bin/bash
/usr/sbin/vsftpd /etc/vsftpd/vsftpd-ftp.conf
/usr/sbin/vsftpd /etc/vsftpd/vsftpd-ftps.conf

　次にvsftpdの起動コマンドを修正します。

/usr/lib/systemd/system/vsftpd.service
ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

↓

/usr/lib/systemd/system/vsftpd.service
ExecStart=/usr/sbin/myvsftpd.sh

vsftpdの再起動とリロードを行い完了です。

systemctl restart vsftpd.service
systemctl daemon-reload

確認

ポート21と990の両方でListenしていたらOKです。

[root@ip-XX-XX-XX-XX hogehoge]# lsof -i:21
COMMAND  PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
vsftpd  7516 root    4u  IPv4 8366586      0t0  TCP *:ftp (LISTEN)
[root@ip-XX-XX-XX-XX hogehoge]# lsof -i:990
COMMAND  PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
vsftpd  7518 root    4u  IPv4 8366588      0t0  TCP *:ftps (LISTEN)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T23:30:56+09:00

CloudFormationに日本語コメントを含めるとエラーになる場合の解決方法

前提条件

  • Windowsで*.ymlに日本語コメントを含めてAWS CLIを叩いた場合のみ起こる
    • マネコンから*.ymlをアップロードした場合は不明
  • AWS CLIをインストーラからインストールしている場合のみ起こる
    • 結論から言うと、インストーラからインストールしているAWS CLIをアンインストールしてpipでgithubからインストールすればいい

テンプレートに日本語コメントを含めるとエラーになる

# これは日本語だ
AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  Parameter:
    Type: Number

Resources:
  # 日本語だ、これは
  Lambda:
    Type: 'AWS::Lambda::Function'

こういうテンプレートファイルをaws cloudformation create-stack --template-body file://hoge.yml --stack-name fooと実行すると

Error parsing parameter '--template-body': Unable to load paramfile (hoge.yml), text contents could not be decoded.  If this is a binary file, please use the fileb:// prefix instead of the file:// prefix.

いったエラーが出ることがある。fileb://とあるが、もちろんテンプレートはバイナリではない。AWS CLI実行時に--debugをつけるとこのようなエラーが見える。

UnicodeDecodeError: 'cp932' codec can't decode byte 0xef in position 89: illegal multibyte sequence

文字コード関連のエラーらしい

VS Codeで記述したので、テンプレートファイルはUTF8である。根本的解決にならないが、テンプレートファイルをShift_JISに変換してAWS CLIを実行すれば問題ない。ただ、JISのままだと、GithubにPushすると文字化けする等、いろいろと面倒。というかつい先日にMicrosoftからUnicodeを使ってくれとお触れが出たばっかりである。

AWS CLIが食っている文字コードをUTF8にする

調べたところ、AWS CLIは後ろでboto(Python)が動いているらしい。

C:\> aws --version
aws-cli/2.0.3 Python/3.7.5 Windows/10 botocore/2.0.0dev7

管理者権限を持つCMDなりPowershellで環境変数を付加してやる。参考にしたのはこの記事。

setx /m PYTHONUTF8 1

何も変わらん

'cp932' codec can't decode byte 0xef in position 89: illegal multibyte sequence

CLIが使っているPythonは環境変数を読んでないらしい

インストーラから入れたAWS CLIをアンインストールする。
参考にした記事はこの記事、要するにPythonが環境変数を読んでないなら、環境変数を読ませたいPythonのパッケージマネージャであるpipから、botoとAWS CLIをインストールしてやればいい。

pip install https://github.com/boto/botocore/archive/v2.tar.gz
pip install https://github.com/aws/aws-cli/archive/v2.tar.gz

解決した

aws cloudformation create-stack --template-body file://lambda.yml --stack-name foo 

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:111111111111:stack/foo/00000000-1111-1111-1111-111111111111"
}

環境構築でハマるのもストレスマッハだけど、文字コード関連もそれに準ずるくらいイラつく。

参考記事

WindowsでCP932(Shift-JIS)エンコード以外のファイルを開くのに苦労した話
https://qiita.com/Yuu94/items/9ffdfcb2c26d6b33792e
Windows 上の Python で UTF-8 をデフォルトにする
https://qiita.com/methane/items/9a19ddf615089b071e71
AWS CLI v2をpipからインストールしてみた
https://dev.classmethod.jp/cloud/aws/install-aws-cli-v2-from-sourcecode/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T23:20:07+09:00

勉強用にminikubeをEC2上で実行する

O’REILLYの「Kubernetesで実践するクラウドネイティブDevOps」をタイトルの全部入り感にひかれて買ったのですが、手持ちのローカル環境が貧弱なのでEC2上にminikube(学習用のローカルkubernetes環境)をインストールしました。

単純にググるとAWS vCPUは仮想化オプションがないので、インストールできなそうに思えたのですが、ちゃんと調べると導入可能だったので、まとめてみました。
(とはいえほとんど参考資料ママです）

環境

  • EC2 t3.micro / Ubuntu Server 18.04 LTS ※無料枠じゃないので注意(t2.microだとCPU数が足りない。最低2vCPU必要)
  • kubectl v1.18.2
  • minikube v1.9.2
  • docker
  • conntrack(インストール中にないと怒られた。コネクショントラッキングツール）

インストール

まず、dockerとconntrackをインストール

$ sudo apt-get update
$ sudo apt-get install docker.io
$ sudo apt-get install conntrack

kubectl(kubernetesのCLI操作ツール) を導入

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
$ chmod +x ./kubectl
$ sudo mv ./kubectl /usr/local/bin/kubectl

minkubeを導入

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ chmod +x minikube
$ sudo mv minikube /usr/local/bin/
$ ll /usr/local/bin
-rwxrwxr-x  1 ubuntu ubuntu 44032000 Apr 29 21:22 kubectl*
-rwxrwxr-x  1 ubuntu ubuntu 54639377 Apr 29 21:27 minikube*
$ minikube version
minikube version: v1.9.2

minikubeを起動
※ここがポイント [--vm-driver=none]オプションを付けないとEC2では起動しません。
これを付けるとローカルに環境を構成します。（デフォルトだとVirtualboxなどで仮想マシンを作成してその中にkubernetes環境を作る)

$ sudo -i
# minikube start --vm-driver=none
# minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

動作確認

公式チュートリアルをもとに、以下を実施します。

  • deploymentオブジェクト(サービス単位でコンテナの実行をコントロールしてくれるもの)の作成(テスト用のwebサーバ)
  • サービスとして、アクセス可能にする
  • webサーバにアクセスしてみる
  • 後始末

deploymentオブジェクトの作成

# kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10
deployment.apps/hello-minikube created

サービスオブジェクトの作成

# kubectl expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed

minikube serviceのコマンドでアクセス可能なURLを調べる

# minikube service hello-minikube --url
http://192.168.10.49:32357

curlでアクセスしてみます。nginxが動いているのがわかります。

# curl http://192.168.10.49:32357
Hostname: hello-minikube-64b64df8c9-hqtcv
Server values:
        server_version=nginx: 1.13.3 - lua: 10008
Request Information:
        client_address=172.17.0.1
 Request Headers:
 Request Body:

後始末。サービスオブジェクト、deploymentオブジェクトを削除して、minikubeを停止します。

# kubectl delete services hello-minikube
service "hello-minikube" deleted
# kubectl delete deployment hello-minikube
deployment.apps "hello-minikube" deleted
# minikube stop
?  Stopping "minikube" in none ...
??  Node "" stopped.

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T22:40:52+09:00

AWS Lambdaのメモリを増やすと処理が遅くなる事がある

背景

Lambdaで作成した関数のメモリー割当量を検証をしていた際にメモリー割当量を増やしたのにも関わらずレスポンスが遅くなることがありました。
そこで実際にCPU性能を調べてメモリ割り当て量によるレスポンスタイムの違いを調べてみたいと思います。

検証

検証方法

極力ネットワークの影響やファイルIOなど外部の影響を受けないようにするために今回は console.log を大量に行いCPUに負荷をかける。
Lambdaの画面よりテストボタンで下記のスクリプトを6回実行を行い、選択できる全メモリ量を記録して所要時間の中央値を比較するものとする。
ランタイムは Nodejs 12.x を使用する。

exports.handler = async (event) => {
    for (var i=0; i<100000; i++) {
        console.log(i);
    }
};

検証結果

各実行時間の中央値をグラフにしました。
グラフから分かる通り、特定容量の割当ての際にレスポンスが遅くなっていることがわかります。
特に320MB, 832MB, 1152MB, 1280MB, 1408MB, 1600MB, 1856MB, 2176MBを割当てている時は１つ前のメモリ割り当ての時より遅くなっているように見えます。
image.png

実際のデータ

(単位: ms)

メモリ割当て(MB) 128 192 256 320 384 448 512 576 670 704 768 832 896 960 1024 1088 1152 1216 1280 1344 1408 1472 1536 1600 1664 1728 1792 1856 1920 1984 2048 2112 2176 2240 2304 2368 2432 2496 2560 2624 2688 2752 2816 2880 2944 3008
1回目 10950.77 8201.07 5814.18 5966.13 5729.55 5723.14 4724.33 4153.5 3733.73 3565.68 2583.53 3190.4 2822.37 2569.92 2347.22 1981.93 2235.81 1848.89 2022.47 1534.96 1817.82 1597.62 1481.3 1747.87 1569.18 1654.93 1363.18 1544.76 1613.92 1181.73 1277.58 1006.02 1621.35 1117.45 1257.15 1292.14 1294.42 1233.39 1158.03 880.66 1077.74 1088.06 1212.63 952.35 1179.11 1153.72
2回目 10421.18 8521.08 5960.6 6250.09 5863.6 5415.62 4764.37 4473.18 3949.5 3520.41 2808.26 3442.74 2814.43 2728.59 2164.69 1795.63 2206.28 1680.51 2041.39 1702.64 2074.71 1446.24 1650.04 2024.75 1711.7 1669.22 1265.03 1524.88 1406.46 1092.27 1084.7 1049.3 1319.94 1069.22 1060 1269.98 1217.49 1166.16 1381.25 896.94 992.21 1265.96 1044.54 825.49 1267.98 1037.94
3回目 10222.12 9153.84 6069.04 6509.95 6414.02 4989.2 4679.15 4266.25 3895.65 3869.3 2510.32 3308.68 2813.33 2579.92 2121.47 2105.04 2385.77 2109.45 2421.56 1715.3 1765.66 1559.31 1397.52 1907.31 1605.9 1597.45 1274.13 1649.59 1306.1 1217.74 1136.2 1010.03 1284.73 1018.11 1200.73 1306.11 1116.84 1156.36 1197.12 930.91 1213.99 1079.63 1080.86 781.97 1022.66 1032.73
4回目 10305.98 8634.28 6110.45 6400.91 5479.86 5494.1 4631.91 4103.38 3661.71 3578.87 2898.53 3243.6 2844.66 2661.85 2100.88 1917.27 2227.38 1947.68 2079.02 1613.63 1972.19 1490.14 1406.78 1707.22 1734.4 1578.88 1119.14 1487.58 1674.75 1177.71 1081.94 1044.2 1383.72 1067.65 1224.56 1243.74 1391.61 1124.04 1225.27 910.26 1160.93 1282.11 1187.44 802.63 1058.49 1010.34
5回目 10291.44 8293.22 6082.04 6535.7 5839.27 5205.23 4623.24 4434.94 3778.08 3582.37 2895.32 3159.63 2976.67 2744.6 2020.52 2027.23 2364.78 1821.04 2276.9 1567.66 1900.94 1670.09 1494.78 1786.65 1615.66 1531.31 1226.62 1449.67 1338.4 1143.24 1179.26 1000.78 1274.51 892.29 1266.7 1312.06 1134.45 1191.96 1127.47 1035.05 1044.9 1342.09 1146.99 718.33 1172.24 1183.76
6回目 10492.8 9342.19 5719.58 6014.46 5840.15 5467.47 4487.31 4379.59 3912.33 3577.32 2815.24 3021.11 2965.64 3046.21 2127.71 2167.85 2538.71 1910.17 2060.21 1563.57 1830.7 1574.72 1368.29 1663.16 1705.49 1523.42 1425.23 1511.25 1536.57 1186.13 1315.22 1041.18 1476.96 991.06 1189.82 1150.31 1422.57 1264.08 1160.41 808.41 1098.36 1128.82 1038.49 852.77 1014.5 1053.97

(単位: ms)

メモリ割当て(MB) 128 192 256 320 384 448 512 576 670 704 768 832 896 960 1024 1088 1152 1216 1280 1344 1408 1472 1536 1600 1664 1728 1792 1856 1920 1984 2048 2112 2176 2240 2304 2368 2432 2496 2560 2624 2688 2752 2816 2880 2944 3008
中央値 10363.58 8577.68 6014.82 6325.5 5839.71 5441.545 4655.53 4322.92 3836.865 3578.095 2811.75 3217 2833.515 2695.22 2124.59 2004.58 2300.295 1879.53 2069.615 1590.645 1865.82 1567.015 1444.04 1767.26 1660.575 1588.165 1269.58 1518.065 1471.515 1179.72 1157.73 1025.605 1351.83 1042.88 1212.645 1281.06 1255.955 1179.06 1178.765 903.6 1088.05 1197.39 1113.925 814.06 1115.365 1045.955
平均 10447.38167 8690.946667 5959.315 6279.54 5861.075 5382.46 4651.718333 4301.806667 3821.833333 3615.658333 2751.866667 3227.693333 2872.85 2721.848333 2147.081667 1999.158333 2326.455 1886.29 2150.258333 1616.293333 1893.67 1556.353333 1466.451667 1806.16 1657.055 1592.535 1278.888333 1527.955 1479.366667 1166.47 1179.15 1025.251667 1393.535 1025.963333 1199.826667 1262.39 1262.896667 1189.331667 1208.258333 910.3716667 1098.021667 1197.778333 1118.491667 822.2566667 1119.163333 1078.743333
最大 10950.77 9342.19 6110.45 6535.7 6414.02 5723.14 4764.37 4473.18 3949.5 3869.3 2898.53 3442.74 2976.67 3046.21 2347.22 2167.85 2538.71 2109.45 2421.56 1715.3 2074.71 1670.09 1650.04 2024.75 1734.4 1669.22 1425.23 1649.59 1674.75 1217.74 1315.22 1049.3 1621.35 1117.45 1266.7 1312.06 1422.57 1264.08 1381.25 1035.05 1213.99 1342.09 1212.63 952.35 1267.98 1183.76
最小 10222.12 8201.07 5719.58 5966.13 5479.86 4989.2 4487.31 4103.38 3661.71 3520.41 2510.32 3021.11 2813.33 2569.92 2020.52 1795.63 2206.28 1680.51 2022.47 1534.96 1765.66 1446.24 1368.29 1663.16 1569.18 1523.42 1119.14 1449.67 1306.1 1092.27 1081.94 1000.78 1274.51 892.29 1060 1150.31 1116.84 1124.04 1127.47 808.41 992.21 1079.63 1038.49 718.33 1014.5 1010.34

まとめ

https://aws.amazon.com/jp/lambda/pricing/

関数に必要なメモリ量を指定すると、それに比例した CPU パワーとその他のリソースが割り当てられます。

Lambdaはメモリ割当て量を増やせば増やすほどパフォーマンスが良くなると言われていますが、1個下のメモリ量を指定したほうが若干パフォーマンスが良くなることがあるようです。
メモリ量を検証する際は選択できるメモリ量の2個前後も検討してみると良いかもしれません。

実務での検証時にGolangで見つけましたが、Python, Node.jsでも再現しているようなのでLambdaの特性のようです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T20:28:20+09:00

WINDOWS OSでAWS LAMBDAにGOをデプロイ

目的

現在、WINDWOS10 OSでGOを用いてWEBサービスを開発しており、
AWS LAMBDAを活用する場面がありましたが、
実際にデプロイを行う際に、無駄にはまったところがあったので、
この度は、実際にデプロイしてみてはまったことや感想を共有したいと思います。

AWS LAMBDAにGOをデプロイする方法

基本的でデプロイする方法はAWSの公式ドキュメントに記載されてあります。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/golang-package.html
特にデプロイパッケージ、Handlerがデプロイとは密接に関係があるので、
この辺はしっかりと読みましょう。

僕は、しっかり読まずいくつが見逃してしまい、苦労しましたね、、、:joy_cat:

僕がはまったところ

①ソースコードをLINUX用しなかったこと

問題

僕は以前、LAMBDAにPYTHON3をデプロイした経験があります。その際は、OSを気にせずデプロイしてもうまく動いてくれたので、
この度、GOをデプロイする際も、特に意識せず適当にアップロードしましたが、当然なことにエラーになりました。

解決策

LINUXにビルドすれば問題解決です。
AWS LAMBDAは実際にはコンテナ環境のAmazon Linuxの上動作するので、
デプロイするものもこの環境に合わせてビルドしてアップロードしなければならないとのことです。

WINDWOS環境でLINUX用にビルドする方法は、
cmdを用いて、デプロイ対象パスに移動し、
set GOOS=linux ←ビルドオプションをLINUXに設定
go build -o main main.go←ビルド　※このファイル名をLAMBDA操作画面にてハンドラとして入力
build-lambda-zip.exe -output main.zip main←ビルドしたファイルをZIPに圧縮する

build-lambda-zip.exeは
GOPATHから github.com/aws/aws-lambda-go/cmd/build-lambda-zip　入力するとダウンロードできます。

②ハンドラ名入力ミス

問題

LINUX用にビルドして、ZIPファイルをアップロード完了してコードテストを行うと
下のようなエラーメッセージが表示されました。

関数の実行から返された結果が以下のエリアに表示されます。
関数から結果を返す方法の詳細については、こちらを参照してください。

{
  "errorMessage": "fork/exec /var/task/☆☆: no such file or directory",
  "errorType": "PathError"
}

☆☆はLAMBDA画面上記載したハンドラに該当します。
1.png

解決策

ビルドしたファイルと、LAMBDA操作画面で入力したハンドラ名が異なるため発生するエラーでした。
例えば、go build -o main main.go　でビルドした場合は、ハンドラにmainと入力しないとLambdaがパスを認識できず、エラーになります。
必ずビルドしたファイル名とハンドラ名を統一しましょう。

2.png
僕は「ハンドラ」と記載されてあったため、
lambda.Startに登録するハンドラを書くのかなと思い、
ビルドパス名と異なる値を入力して、はまりました。。。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T20:12:05+09:00

Amazon Inspectorを実際に使ってみた（とりあえず動かしてみた版）

気がつけば、前の投稿から半年…恐ろしいものです。

おかげさまでAWS 認定セキュリティ – 専門知識に無事合格しました。残念ながら一発合格とはいきませんでしたが…。しかし取得がゴールではないので、これからも日々精進します。引き続きよろしくお願いします。

というわけで、今回から実際にAWSのセキュリティ関連サービス（セキュリティ、ID、およびコンプライアンス）を試してみたいと思います。まずはAmazon Inspectorです。

Amazon Inspectorとは？

Amazon Inspectorとは、AWSのセキュリティ脆弱性診断サービスです。ネットワーク診断とアプリケーション診断の両方が可能であるということです。具体的にどこまでの診断が可能か、早速試してみましょう。

公式ドキュメントはこちら。

環境を準備しよう

まずは環境の準備です。下記の構成で試してみます。

Inspector-Test-Env1.png

EC2インスタンス１つだけのシンプルな構成ですね。EC2は「Amazon Linux 2 AMI (HVM), SSD Volume Type」としました。
なお、Amazon InspectorおよびAgentはこの後の手順で準備します。

Amazon Inspectorを準備しよう（概要）

次にAmazon Inspectorの準備です。

  • サーバ側
    • 評価ターゲット
    • 評価テンプレート
  • クライアント側
    • エージェント

Amazon Inspectorを準備しよう（サーバ側）

まずはサーバ側の準備です。最初に評価ターゲットを設定します。評価ターゲットは、Amazon Inspectorを実行するリソース（EC2インスタンス）を識別するために使用します。今回は下記の設定とします。

スクリーンショット 2020-04-29 9.42.39.png

設定項目 設定値
名前 Qiita-Amazon-Inspector-Test(※なんでもよいです)
All Instances チェックなし
Use Tags　キー Inspector
Use Tags　値 True
Install Agents チェックなし

最後の「Install Agents」ですが、SSMエージェントやIAMロールの設定が準備できる場合は「チェックあり」にしてください。今回は「チェックなし」にして、別途Inspectorエージェントをクライアント側に導入します。

また、全てのEC2を対象にする場合は「All Instances」をチェックしてください（今回はインスタンス１台だけを対象とするため、チェックしません）。

なお上記設定の場合、EC2インスタンス側にタグ（キー：Inspector　値：True）を追加しておく必要がありますので、忘れずに。
スクリーンショット 2020-04-28 20.33.05.png

次に評価テンプレートです。評価テンプレートはどのような条件でAmazon Inspectorを実行するかを定義します。今回は下記の設定とします。

スクリーンショット 2020-04-29 22.31.51.png

設定項目 設定値
名前 Qiita-Amazon-Inspector-Test-Template(※なんでもよいです)
ターゲット名 Qiita-Amazon-Inspector-Test
ルールパッケージ Security Best Practices-1.0
所要時間 １時間（推奨）
SNSトピック (※今回は設定なし)
タグ　キー (※今回は設定なし)
タグ　値 (※今回は設定なし)
結果に追加された属性　キー (※今回は設定なし)
結果に追加された属性　値 (※今回は設定なし)
Assessment Schedule チェックなし

「ターゲット名」には先ほど評価ターゲットで設定したものを選びます。

「ルールパッケージ」は2020/04/28現在、下記４種類から選択できます。

分類 項目
ネットワーク評価 ネットワーク到達可能性
ホスト評価 共通脆弱性識別子
ホスト評価 Center for Internet Security (CIS) ベンチマーク
ホスト評価 Amazon Inspector のセキュリティのベストプラクティス

今回は「Amazon Inspectorのセキュリティのベストプラクティス」を選択してみます。なお、ネットワーク到達可能性を評価する場合は、エージェントの導入は不要です(参考)。

「所要時間」は推奨である「１時間」で。

「Assessment Schedule」は今回は「チェックなし」で。

「作成」ボタンを押せばサーバ側は準備完了です。

Amazon Inspectorを準備しよう（クライアント側）

今度はクライアント側の作業です。参考ドキュメントはこちらです。

まず、EC2インスタンスにログインし、エージェントをダウンロードします。

$ mkdir inspector-agent
$ cd inspector-agent
$ pwd
/home/ec2-user/inspector-agent

$ wget https://inspector-agent.amazonaws.com/linux/latest/install
--2020-04-29 01:12:03--  https://inspector-agent.amazonaws.com/linux/latest/install
inspector-agent.amazonaws.com (inspector-agent.amazonaws.com) をDNSに問いあわせています... 143.204.85.2, 2600:9000:2138:9800:4:6195:f549:e8e1, 2600:9000:2138:e600:4:6195:f549:e8e1, ...
inspector-agent.amazonaws.com (inspector-agent.amazonaws.com)|143.204.85.2|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 30215 (30K)
`install' に保存中

100%[======================================>] 30,215      --.-K/s 時間 0.001s  

2020-04-29 01:12:03 (32.3 MB/s) - `install' へ保存完了 [30215/30215]
$
$ ls -l
合計 32
-rw-rw-r-- 1 ec2-user ec2-user 30215  2月 13 17:50 install

<ダウンロードしたエージェントの正当性確認：ここから>
ここでダウンロードしたファイルが正しいか確認します。（セキュリティ的に大事な作業となりますので、皆さんも是非やってみてください。参考ドキュメントはこちら。）

gpgが導入済みであることを確認します。

$ which gpg
/usr/bin/gpg

Amazon Inspectorの公開鍵をインポートします。
※公開鍵の最新版はこちらで確認してください。

$ cat inspector.key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.18 (GNU/Linux)

mQINBFYDlfEBEADFpfNt/mdCtsmfDoga+PfHY9bdXAD68yhp2m9NyH3BOzle/MXI
8siNfoRgzDwuWnIaezHwwLWkDw2paRxp1NMQ9qRe8Phq0ewheLrQu95dwDgMcw90
gf9m1iKVHjdVQ9qNHlB2OFknPDxMDRHcrmlJYDKYCX3+MODEHnlK25tIH2KWezXP
FPSU+TkwjLRzSMYH1L8IwjFUIIi78jQS9a31R/cOl4zuC5fOVghYlSomLI8irfoD
JSa3csVRujSmOAf9o3beiMR/kNDMpgDOxgiQTu/Kh39cl6o8AKe+QKK48kqO7hra
h1dpzLbfeZEVU6dWMZtlUksG/zKxuzD6d8vXYH7Z+x09POPFALQCQQMC3WisIKgj
zJEFhXMCCQ3NLC3CeyMq3vP7MbVRBYE7t3d2uDREkZBgIf+mbUYfYPhrzy0qT9Tr
PgwcnUvDZuazxuuPzucZGOJ5kbptat3DcUpstjdkMGAId3JawBbps77qRZdA+swr
o9o3jbowgmf0y5ZS6KwvZnC6XyTAkXy2io7mSrAIRECrANrzYzfp5v7uD7w8Dk0X
1OrfOm1VufMzAyTu0YQGBWaQKzSB8tCkvFw54PrRuUTcV826XU7SIJNzmNQo58uL
bKyLVBSCVabfs0lkECIesq8PT9xMYfQJ421uATHyYUnFTU2TYrCQEab7oQARAQAB
tCdBbWF6b24gSW5zcGVjdG9yIDxpbnNwZWN0b3JAYW1hem9uLmNvbT6JAjgEEwEC
ACIFAlYDlfECGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJECR0CWBYNgQY
8yUP/2GpIl40f3mKBUiSTe0XQLvwiBCHmY+V9fOuKqDTinxssjEMCnz0vsKeCZF/
L35pwNa/oW0OJa8D7sCkKG+8LuyMpcPDyqptLrYPprUWtz2+qLCHgpWsrku7ateF
x4hWS0jUVeHPaBzI9V1NTHsCx9+nbpWQ5Fk+7VJI8hbMDY7NQx6fcse8WTlP/0r/
HIkKzzqQQaaOf5t9zc5DKwi+dFmJbRUyaq22xs8C81UODjHunhjHdZ21cnsgk91S
fviuaum9aR4/uVIYOTVWnjC5J3+VlczyUt5FaYrrQ5ov0dM+biTUXwve3X8Q85Nu
DPnO/+zxb7Jz3QCHXnuTbxZTjvvl60Oi8//uRTnPXjz4wZLwQfibgHmk1++hzND7
wOYA02Js6v5FZQlLQAod7q2wuA1pq4MroLXzziDfy/9ea8B+tzyxlmNVRpVZY4Ll
DOHyqGQhpkyV3drjjNZlEofwbfu7m6ODwsgMl5ynzhKklJzwPJFfB3mMc7qLi+qX
MJtEX8KJ/iVUQStHHAG7daL1bxpWSI3BRuaHsWbBGQ/mcHBgUUOQJyEp5LAdg9Fs
VP55gWtF7pIqifiqlcfgG0Ov+A3NmVbmiGKSZvfrc5KsF/k43rCGqDx1RV6gZvyI
LfO9+3sEIlNrsMib0KRLDeBt3EuDsaBZgOkqjDhgJUesqiCy
=iEhB
-----END PGP PUBLIC KEY BLOCK-----
$
$ gpg --import inspector.key
gpg: /home/ec2-user/.gnupg/trustdb.gpg: 信用データベースができました
gpg: 鍵58360418: 公開鍵"Amazon Inspector <inspector@amazon.com>"をインポートしました
gpg:         処理数の合計: 1
gpg:           インポート: 1  (RSA: 1)

フィンガープリントを確認します。引数--finterprintには、先ほどの鍵「58360418」を渡します。

$ gpg --fingerprint 58360418
pub   4096R/58360418 2015-09-24
   フィンガー・プリント = DDA0 D4C5 10AE 3C20 6F46  6DC0 2474 0960 5836 0418
uid                  Amazon Inspector <inspector@amazon.com>

出力されたフィンガープリントがこちらに記載されているフィンガープリント(2020/4/29現在「DDA0 D4C5 10AE 3C20 6F46 6DC0 2474 0960 5836 0418」)と一致していることを確認してください。

インストールスクリプトの署名を確認します。
まず、署名ファイルをダウンロードします。

$ curl -O https://inspector-agent.amazonaws.com/linux/latest/install.sig
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   543  100   543    0     0   4487      0 --:--:-- --:--:-- --:--:--  4487
$
$ ls -l
合計 40
-rw-rw-r-- 1 ec2-user ec2-user  1658  4月 29 01:36 inspector.key
-rw-rw-r-- 1 ec2-user ec2-user 30215  2月 13 17:50 install
-rw-rw-r-- 1 ec2-user ec2-user   543  4月 29 10:08 install.sig

次に署名を確認します。

$ gpg --verify ./install.sig
gpg: 2020年02月13日 17時50分48秒 UTCにRSA鍵ID 58360418で施された署名
gpg: "Amazon Inspector <inspector@amazon.com>"からの正しい署名
gpg: *警告*: この鍵は信用できる署名で証明されていません!
gpg:       この署名が所有者のものかどうかの検証手段がありません。
主鍵のフィンガー・プリント: DDA0 D4C5 10AE 3C20 6F46  6DC0 2474 0960 5836 0418

紛らわしいですが、「"Amazon Inspector inspector@amazon.com"からの正しい署名」と出力されていてばOKです（公式ドキュメントによると「Good signature from "Amazon Inspector inspector@amazon.com"」が正しい出力なので、不安な方は下記の通り実行してみてください）。

$ LANG=C
$ gpg --verify ./install.sig
gpg: Signature made Thu Feb 13 17:50:48 2020 UTC using RSA key ID 58360418
gpg: Good signature from "Amazon Inspector <inspector@amazon.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DDA0 D4C5 10AE 3C20 6F46  6DC0 2474 0960 5836 0418

<ダウンロードしたエージェントの正当性確認：ここまで>

それではようやく、エージェントをインストールしてみましょう。

$ sudo bash install
amzn.2.2
Distribution of the machine is Amazon Linux.
Distribution type of the machine is amzn.
Revision of the distro is 2.
Kernel version of the machine is 4.14.173-137.229.amzn2.x86_64.
ip-10-0-1-15.ap-northeast-1.compute.internal is an EC2 instance reporting region as ap-northeast-1.
Check for existing AwsAgent completed with error code:0
Existing version of agent installed is 0.0.0.0.
cannot find installed KM VERSION... assumed '0.0.0.0' 
get_installed_km_version: EXISTING_KM_VERSION:0.0.0.0 exit status:0
Existing version of kernel module installed is 0.0.0.0.
PUBKEY_FILE: /tmp/awsagent.G5SaJTZJ/inspector.gpg
Validated AWS_AGENT_INVENTORY signature with: 
HTTP/1.1 200 OK
x-amz-id-2: 9uzTFLame353medihAQh89KLreAeehmycxhFQe58KaIAcBXGvGkMKajFGWX91fjdk1LKZVQ3y7w=
x-amz-request-id: 0F680B339ED8A73E
Date: Wed, 29 Apr 2020 10:18:35 GMT
Last-Modified: Fri, 14 Feb 2020 18:29:43 GMT
ETag: "c905989143156a4310166a28a0f44eec"
Accept-Ranges: bytes
Content-Type: 
Content-Length: 952
Server: AmazonS3

AGENT_MANIFEST_URL: https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1595.0/AGENT_MANIFEST
AGENT_VERSION_URL:  https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1595.0/VERSION
PUBKEY_FILE: /tmp/awsagent.G5SaJTZJ/inspector.gpg
Validated AGENT_MANIFEST signature with: 
PUBKEY_FILE: /tmp/awsagent.G5SaJTZJ/inspector.gpg
Validated VERSION signature with: 
AGENT_PACKAGE_URL: https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1595.0/amzn-4.14.47-64.38.amzn2.x86_64-x86_64/AwsAgent-1.1.1595.0-102595.x86_64.rpm
EXPECTED_AGENT_PACKAGE_HASH: e892a8aef7750043ac881e8104ef22f42aa851e91a398d46042ed24949a0d6d4
NEW_AGENT_VERSION:1.1.1595.0
AGENT_PACKAGE_NAME:AWSAgent.rpm
Validated agent package sha256 hash matches expected value.
package_install:package_path:     /tmp/awsagent.G5SaJTZJ/AWSAgent.rpm
package_install:new_version:      1.1.1595.0
package_install:existing_version: 0.0.0.0
package_type                    : agent
/bin/yum
Installing with yum...
yum install -y /tmp/awsagent.G5SaJTZJ/AWSAgent.rpm
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
/tmp/awsagent.G5SaJTZJ/AWSAgent.rpm を調べています: AwsAgent-1.1.1595.0-102595.x86_64
/tmp/awsagent.G5SaJTZJ/AWSAgent.rpm をインストール済みとして設定しています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ AwsAgent.x86_64 0:1.1.1595.0-102595 を インストール
--> 依存性解決を終了しました。
amzn2-core/2/x86_64                                      | 2.4 kB     00:00     
amzn2extra-docker/2/x86_64                               | 1.8 kB     00:00     

依存性を解決しました

================================================================================
 Package         アーキテクチャー
                               バージョン                リポジトリー      容量
================================================================================
インストール中:
 AwsAgent        x86_64        1.1.1595.0-102595         /AWSAgent         34 M

トランザクションの要約
================================================================================
インストール  1 パッケージ

合計容量: 34 M
インストール容量: 34 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : AwsAgent-1.1.1595.0-102595.x86_64               1/1 
Redirecting to /bin/systemctl reload crond.service
  検証中                  : AwsAgent-1.1.1595.0-102595.x86_64               1/1 

インストール:
  AwsAgent.x86_64 0:1.1.1595.0-102595                                           

完了しました!
HTTP/1.1 200 OK
x-amz-id-2: uZkeRGwdBRchIPhiwfwmrAospTkXoQ5CDTc4cV6Dreg7CWV11ZjbIWIHDlhdQ6PpGoTqZY8gsiw=
x-amz-request-id: FC3709600E17ECF2
Date: Wed, 29 Apr 2020 10:18:43 GMT
Last-Modified: Fri, 14 Feb 2020 18:29:43 GMT
ETag: "c905989143156a4310166a28a0f44eec"
Accept-Ranges: bytes
Content-Type: 
Content-Length: 952
Server: AmazonS3

Installation script completed successfully.

Notice:
By installing the Amazon Inspector Agent, you agree that your use is subject to the terms of your existing 
AWS Customer Agreement or other agreement with Amazon Web Services, Inc. or its affiliates governing your 
use of AWS services. You may not install and use the Amazon Inspector Agent unless you have an account in 
good standing with AWS.
*  *  *
Current running agent reports to arsenal endpoint: 
Current running agent reports version as: 1.1.1595.0
This install script was created to install agent version:1.1.1595.0
In most cases, these version numbers should be the same.

無事インストールされたようなので、パッケージの詳細を確認してみましょう。

$ rpm -qi AwsAgent
Name        : AwsAgent
Version     : 1.1.1595.0
Release     : 102595
Architecture: x86_64
Install Date: 2020年04月29日 10時18分37秒
Group       : Unspecified
Size        : 35362737
License     : Amazon Proprietary and GPLv2
Signature   : (none)
Source RPM  : AwsAgent-1.1.1595.0-102595.src.rpm
Build Date  : 2020年02月11日 20時13分08秒
Build Host  : (*＊＊ 秘密 ***)
Relocations : (not relocatable)
URL         : http://docs.aws.amazon.com/inspector/latest/userguide/welcome.html
Summary     : Install the AwsAgent.
Description :
This package installs the Amazon Inspector Agent.  This is a part of the Amazon Inspector Service.

プロセスも確認してみましょう。

$ ps -ef | grep -i AwsAgent
root      5480     1  0 10:18 ?        00:00:00 /opt/aws/awsagent/bin/awsagent

ここまでで準備完了です（意外と長かったですね）。

Amazon Inspectorを実行しよう

それでは実行してみましょう。「評価の実行」ですが、一番最初は「評価テンプレート」から選択する形となります。先ほど作成した評価テンプレートを選択し、「実行」ボタンを押します。

スクリーンショット 2020-04-29 9.19.49.png

「直前の実行」が「開始準備中」となったらOKです。しばらく待ちましょう。

スクリーンショット 2020-04-29 19.30.16.png

約１時間で完了しました。

スクリーンショット 2020-04-29 21.20.50.png

Amazon Inspectorの実行結果を見てみよう

それでは結果を見てみましょう。結果は「評価の実行」から確認できます。全部で１つあるようです。

スクリーンショット 2020-04-29 23.41.05.png

中身を確認してみましょう。「結果」の「1」をクリックすると、下記の画面になります。

スクリーンショット 2020-04-29 23.41.55.png

詳細を見てみましょう。左から２列目の「▶︎」をクリックします。

スクリーンショット 2020-04-29 23.43.01.png
スクリーンショット 2020-04-29 23.43.22.png

どうやらSSHでroot接続が許可されているようです。
推奨事項を参考にして設定変更し、再度Amazon Inspectorを実行してみましょう。
と、その前に、結果のレポートを取得しておきましょう。「Reports」をクリックします。

スクリーンショット 2020-04-29 23.59.25.png

「Select report type」は「Full report」を、「Select report format」は「PDF」を選択して、「Generate report」ボタンをクリックします。

スクリーンショット 2020-04-29 23.59.50.png

すぐにPDFが表示されました。中身はこんな感じです。

スクリーンショット 2020-04-30 17.59.27.png

PDFを取得した後は、再度Amazon Inspectorの実行です。

スクリーンショット 2020-04-30 0.03.43.png

さて、結果を見てみましょう。Amazon Inspectorの「評価の実行」をみると…結果が「0」になっています、素晴らしい！

スクリーンショット 2020-04-30 17.55.25.png

PDFの中身もこんな感じです。

スクリーンショット 2020-04-30 18.00.13.png

使ってみた感想（まとめ的なもの）

今回はEC2インスタンス１台に対してAmazon Inspectorを実行してみて効果を確認しました。
とても操作は簡単で、見つかった問題に対する対処方法もレポートにまとめてあって、非常に便利でした。
今回EC2として「Amazon Linux 2」を使用しましたが、他のOSではどのような結果が出るのか、いろいろ試してみたいですね。
あと、4つのルールパッケージはそれぞれ評価範囲が異なるので、状況に応じて使い分けられるようになると良いですね。

AWSでシステム構築した際は、Amazon Inspectorで検査して脆弱性・設定不備を潰しておく、という進め方が良さそうですね。

おまけ

  • 前回調べたセキュリティ関連サービスですが、もうすでに「Detective」が増えてますね。Updateが早いですね。
  • ルールパッケージ「共通脆弱性識別子」も試してみたところ、結果は「0」でした。Amazon Linux 2はセキュリティレベルが高いですね。

スクリーンショット 2020-04-30 19.18.25.png

EOF

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T19:47:51+09:00

初心者がWordPressでタイピングのリアルタイム対戦ゲームを作ってみました

はじめに

この記事は、WordPressでしかホームページを作れないプログラミング初心者が、無理やりWordPressを使って、タイピングのリアルタイム対戦ゲームを作ってみた記事です。
alt
タイピング初心者用に、７０近くあるステージをクリアしていくモードもあります。

IT系の集まりで、「WordPressでこのサイト作ったよ」って言ったらどよめきが起こり、「Qiitaに書いてみれば？」と言われたので書いてみます。

ちなみに、タイピンガーＺというサイトです。

このサイトをWordPressでどうやって作ったのかを、ざっくり書いていこうと思います。

テーマのテンプレート

はるか昔に購入した有料テンプレートを使ってみましたが、改造しすぎて原型をとどめていないので、なんでも良かったと思います。

記事投稿と固定ページテンプレート

タイピンガーＺは、対人対戦を除いて、ステージをクリアしていく仕組みになっているのですが、それらのステージはWordPressの記事投稿で作りました。

記事には、敵キャラのセリフだったり、敵の強さだったり、音楽・背景だったりのパラメーターを記入します。
↓こんな感じ

<!--セリフ-->
<span id="pan2serifu">
（たけしさんブリーフ増えてる・・・）brbr
なんすかそれ,
ブリーフ型ターバンヲ発明シマシタ。22,
ヨガタケシデース22,
カレーガンジーヨガファイア22,
インド人に謝れ,
ヨガソーリー22,
さて、今回もがんばろう。
,*-,*del,((</span>
<!--速度基準-->
<span id="speedlinesetting1">20</span><!--遅い-->
<span id="speedlinesetting2">30</span>
<span id="speedlinesetting3">40</span><!--早い-->
<!--ミス基準-->
<span id="misslinesettei1">60</span><!--正確性低い-->
<span id="misslinesettei2">70</span>
<span id="misslinesettei3">85</span><!--正確性高い-->

それぞれのパラメーターは、Javascriptでゲットできるように、idかclassを付けておきます。
セリフに「22」とか、「*del」とか書いてますが、これはJavascript側に何かしてほしいときの自作コマンドみたいなものです。
このコマンドで、セリフを話してるキャラが消えたり、セリフが大きくなったり、BGMが変わったりと、いろいろ操作することができるようにしてます。

また、これだけではただのブログ記事のデザインにしかならないので、自分で作った固定ページテンプレートを当てます。

「初心者練習ステージテンプレート」「CPU対戦用テンプレート」などをPHPで書いて用意しました。

あとはパラメーターを書いた記事を大量に投稿して、それぞれに固定ページテンプレートを当てれば、ステージがどんどん増えていきます。

alt

リアルタイム対戦

リアルタイム対戦を導入するにあたってNode.jsを使いたかったのですが、僕が使っているロリポップレンタルサーバーが対応してなかったので、仕方なくAWSも使うことにしました。

AWSを「オッス」と読んでたくらい何も知識がなかったのですが、１年目が無料なのと、２年目以降もだいぶ格安っぽい感じだったので使うことにしました。

AWSでNode.jsを導入するにあたって、下記の記事をそのままやりました。

AWS EC2でNodeを動作させる

この記事でやってることが何なのか、何も理解しないまま人形のように作業したのですが、なんと普通にNode.jsが動きました。
記事の筆者さんありがとう。

しかし、この記事のままだとhttpsでのやり取りができず、そこではまりました。
何も理解しないまま進めると、応用が利かないから困ります。

なんとか解決したものの、どうやって解決したのか忘れてしまったという。。。
たしかロードバランサ―の部分でhttpsを受け入れてなかったとか、そんな感じだった気がします。

Socket.io

Node.jsのライブラリであるSocket.ioを使って、リアルタイム対戦を実現しました。
Socket.ioまじですごい。アホでも使えるようにしてくれてる。

基本的には、下の四つだけ覚えたら使えました。

.on()　受信
.emit()　送信
.broadcast()　自分以外に送信
.join()　部屋作る

Firebaseとやらがもっと簡単という噂を聞きましたが、Socket.ioも初心者でも扱えるとてもシンプルなものでした。

処理のフローをまとめると

無理やりWordpress使って、サーバーも２つ使ってるという構造なので、無駄に複雑です。

リアルタイム対戦の処理をまとめると・・・

１、サーバー１(WordPress)からクライアントにページ情報を送信
２、クライアント側でHTMLとかJavascriptが動く
３、クライアントからサーバー２(AWS、Node.js)に情報送信
４、サーバー２から対戦相手のクライアントに情報送信
５、以下サーバー２を通してクライアント同士で情報送受信

という流れです。

Qiitaの天才達、ありがとう

開発前は、プログラミング素人の自分が、リアルタイム対戦なんてできるのか？
とか思ってましたが、やってみればできるもんです。
１０年前だったら不可能だったと思いますが、先人の天才達が素人でもできるように、資料やライブラリを公開してくれているので、なんとかなった感があります。
Qiita、めちゃくちゃ参考にしました。

天才達、ありがとう。

Twitter：@pant2taicho
ホームページ：タイピンガーＺ

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T19:15:47+09:00

AWS LambdaのJavaは遅い？

AWS Lambdaで動作するJavaは初回が遅いですが、速くする方法がないか調べました。
末尾にある参考サイトの内容にたどり着いて、実際に試してみたのでその記録です。

レイテンシ情報はX-Rayにて取得しました。

テスト対象

S3にファイルをPUTするだけのものです

S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();
PutObjectResponse result = s3.putObject(
        PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
        RequestBody.fromString("contents"));

検証１　普通に実行

まずは普通に試してみます。

ソース全体
package helloworld;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.PutObjectResponse;

public class TestTarget0429 implements RequestHandler<Object, Object> {

    public Object handleRequest(final Object input, final Context context) {
        String ENV_BUCKET = System.getenv("BUCKET");

        S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();
        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);

        return null;
    }
}

回数 レイテンシ(ms) 処理内容
1 6200
2 422
3 217
4 210
5 315

1回目だけ遅い、いわゆるコールドスタートが遅い状態ですね。
S3に1ファイル作成するだけで6秒は遅いですよねぇ。

検証２　Provisioned Concurrencyを有効化

では昨年末に登場したProvisioned Concurrencyを使うとどうでしょう。
https://aws.amazon.com/jp/blogs/news/new-provisioned-concurrency-for-lambda-functions/

ソースコードは検証１と同じものです。

回数 レイテンシ(ms) 処理内容
1 5500
2 266
3 274
4 402
5 304

初回が遅いままじゃないか。。
同時実行1をプロビジョンドしただけでも月$14.42かかるのに、あんまりじゃないか。。。

なので、以降はProvisioned Concurrencyを無効にして検証を続けます

検証３　処理の分離（Provisioned Concurrencyなし）

初回に遅い原因を探るため、Lambda初回起動時と2回目起動時で処理を分けてみました。

staticなcount変数を作って、初回呼び出し時のみ速攻returnしてみます。

        if (count == 1) {
            count++;
            return null;
        }

ソース全体
package helloworld;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.PutObjectResponse;

public class TestTarget0429 implements RequestHandler<Object, Object> {

    private static int count = 1;

    public Object handleRequest(final Object input, final Context context) {
        if (count == 1) {
            count++;
            return null;
        }

        String ENV_BUCKET = System.getenv("BUCKET");

        S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();
        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);

        return null;
    }
}

結果

回数 レイテンシ 処理内容
1 625ms Initialization処理のみ
2 5600ms S3 PUT（1回目）
3 393ms S3 PUT（2回目）
4 401ms S3 PUT（3回目）
5 311ms S3 PUT（4回目）

Initialization処理が遅いわけじゃないことがわかりました。
S3 PUT（初回）に時間がかかっているようです。

検証４　初期化処理をstaticにする（Provisioned Concurrencyなし）

S3Clientを作る部分をstatic化してみます。

private static String ENV_BUCKET = System.getenv("BUCKET");
private static S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();

ソース全体
package helloworld;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.PutObjectResponse;

public class TestTarget0429 implements RequestHandler<Object, Object> {

    private static int count = 1;

    private static String ENV_BUCKET = System.getenv("BUCKET");
    private static S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();

    public Object handleRequest(final Object input, final Context context) {
        if (count == 1) {
            count++;
            return null;
        }

        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);

        return null;
    }
}

結果

回数 レイテンシ 処理内容
1 2400ms Initialization処理 と S3Clientインスタンスの生成
2 2200ms S3 PUT（1回目）
3 43ms S3 PUT（2回目）
4 46ms S3 PUT（3回目）
5 78ms S3 PUT（4回目）

お！少し1回目の処理時間がかかるようになって、2回目が少し早くなりましたね。
3回目以降も早くなってますがこれもなにか影響があるのでしょうか？

検証５　staticイニシャライザで1回やっちゃう（Provisioned Concurrencyなし）

staticで処理をすれば早くなることがわかりました。
一旦staticイニシャライザでダミーファイルを作成してみます。

static{
    PutObjectResponse result = s3.putObject(
            PutObjectRequest.builder().bucket(ENV_BUCKET).key("dummy.txt").build(),
            RequestBody.fromString("contents"));

    System.out.println(result);
}

ソース全体
package helloworld;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.PutObjectResponse;

public class TestTarget0429 implements RequestHandler<Object, Object> {

    private static int count = 1;

    private static String ENV_BUCKET = System.getenv("BUCKET");
    private static S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();

    static{
        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("dummy.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);
    }

    public Object handleRequest(final Object input, final Context context) {
        if (count == 1) {
            count++;
            return null;
        }

        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);

        return null;
    }
}

結果

回数 レイテンシ 処理内容
1 4000ms Initialization処理 と staticメソッドによるS3 PUT（1回目）ダミーファイル
2 42ms S3 PUT（2回目）
3 125ms S3 PUT（3回目）
4 42ms S3 PUT（4回目）
5 44ms S3 PUT（5回目）

めでたく2回目以降が速くなりましたよ～！

検証６　検証５＋Provisioned Concurrency

検証５で早くなったので、Provisioned Concurrencyも組み合わせたら、１回目から速くなるのか？！

ソースは検証５と同じものです。

回数 レイテンシ 処理内容
1 80ms Initialization処理
2 370ms S3 PUT（2回目）※Provisionedの際にstaticイニシャライザで1回実行済みのため
3 43ms S3 PUT（3回目）
4 72ms S3 PUT（4回目）
5 84ms S3 PUT（5回目）

やりましたよ！
期待してたのはこれです。

最終結果

最終形はこうなりました。

  • staticメソッドでダミーファイル作成を一回やっちゃう
  • Provisioned Concurrency有効

ソース全体
package helloworld;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

import software.amazon.awssdk.core.sync.RequestBody;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.s3.S3Client;
import software.amazon.awssdk.services.s3.model.PutObjectRequest;
import software.amazon.awssdk.services.s3.model.PutObjectResponse;

public class TestTarget0429 implements RequestHandler<Object, Object> {

    private static String ENV_BUCKET = System.getenv("BUCKET");
    private static S3Client s3 = S3Client.builder().region(Region.AP_NORTHEAST_1).build();

    static{
        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("dummy.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);
    }

    public Object handleRequest(final Object input, final Context context) {
        PutObjectResponse result = s3.putObject(
                PutObjectRequest.builder().bucket(ENV_BUCKET).key("filename.txt").build(),
                RequestBody.fromString("contents"));

        System.out.println(result);

        return null;
    }
}

回数 レイテンシ 処理内容
1 552ms S3 PUT（2回目）※Provisionedの際にstaticイニシャライザで1回実行済みのため
2 118ms S3 PUT（3回目）
3 44ms S3 PUT（4回目）
4 86ms S3 PUT（5回目）
5 146ms S3 PUT（6回目）

めでたし、めでたし。

考察

どうも、Javaのクラスローダーは初めてクラスが呼ばれたタイミングでクラスを読み込むようで、クラスの初期ロードに時間がかかるらしいです。
なので、一回読み込んじゃって、クラスをロード済みにしてしまえば次から速いということのようです。

呼ばれたタイミングじゃなくて、はじめに全部クラスをロードしてくれたらいいんですが、そんなことはできないのですかねぇ。

参考サイトはこちらです。

クラスメソッドさんのブログ
https://dev.classmethod.jp/articles/report-best-practive-for-java-on-lambda/

re:Invent 2019でのセッション資料
https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Best_practices_for_AWS_Lambda_and_Java_SVS403-R1.pdf
https://youtu.be/ddg1u5HLwg8

他に見つけたブログ
https://pattern-match.com/blog/2020/03/14/springboot2-and-aws-lambda-provisioned-concurrency/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T18:39:50+09:00

[入門者向け]　AWS Solution Architect Associate 合格までの道

初心者エンジニアの合格体験記です。
一度不合格で再受験したため、失敗経験も併せて
合格までのポイントを伝えられたらと思います:money_mouth:

前提

経験・能力について

・文系出身SE
・プログラミング経験なし(入社してからJavaの研修を7日ほど・・・)
・当然インフラ知識もなし
・入社するまでIT知識無し
・SIer勤務でPJ管理メイン・・・（書類作成に追われ業務ではほぼIT知識がつかない）

AWS受験のきっかけ

配属した時に学習を推奨されていたため。
6月くらいに存在を初めて知り、なんとなく面白そうだし将来の武器になりそうだと思った

学習期間

2019/12/9 ~ 2020/4/29
1回目の受験は3/7 スコア680 →不合格
2回目の受験は4/30 スコア820 →合格！！！
※1月、２月は業務が忙しい+サボりグセでおそらく合わせて10時間も勉強していないですが・・

学習に5ケ月かかっているので、とても優秀とは言えないですね:thumbsdown::thumbsdown:

1回目の受験

学習内容

・AWS認定資格試験テキスト AWS認定 ソリューションアーキテクト-アソシエイト

通称オレンジ本。のみです。
他の方の合格体験記を見ても明らかに学習が足りないと思います。
参考書に書いてあることは一通り抑え、オレンジ本の例題や問題は100%解ける、という状態で受験に臨みましたが、結果としては不合格。(スコア680)

ただ、この参考書を貶めたい訳では全くありません。
むしろIT知識皆無の私が学習するのに非常にわかりやすく助けになりました！！

反省点

上記のように初学の私にとってオレンジ本は非常に優秀でした。
では何が足りなかったかというと・・
・オレンジ本のみではサービスの理解のみになってしまう。
・問題演習量が全く足りない！！！
の2点が原因だと思います。

受験するのはソリューションアーキテクト。
つまり合格のために必要なのはサービスの理解だけでなく
「要件に合わせて、AWSサービスの設定やサービス同士の組み合わせが最適かを判断する」
能力だったのです。
この能力を育てるために手っ取り早いのが問題演習でした。

２回目の受験

学習内容

・【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）
・AWS Web問題集で学習しよう
この二つを重点的に取り組みました。
※便宜上「udemy模擬試験」と「小岩問題集」と呼びます。

udemy模擬試験のいいところは、実際の模擬試験と同様の時間・問題量を経験できること。
難易度は実際の試験より遥かに高いですが。
今の所あまり模擬試験レベルの問題を解ける教材などが少ないんですよね。。。

小岩問題集のいいところは、1セグメント7問でサクサク進められるところと解説に公式ドキュメントのリンクが貼ってあるところ。
隙間時間にサクサクできちゃいます。公式ドキュメントの確認も実は結構重要です。

学習の進め方

1.udemy模擬試験で1回模試を受ける
2.小岩で学習する
3.udemy模擬試験で残りの模試を受ける

簡単にするとこんな感じ。
まずは模試としてudemy模擬試験を受けてみてください。
私は1回目の受験の後受けましたが36%でした・・・・。低過ぎ・・・。:robot:

その後小岩で実力をつけて、模擬試験で仕上げて終わり！！！！！

締め

最後投げやりですが、以上です！w

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T18:07:45+09:00

AWS ubuntu18.04で IAM RoleによるCode Commit からのgit cloneには awscliが必要

AWS ubuntu18.04で IAM RoleによるCode Commit からのgit cloneには awscliが必要

環境

ubuntu18.04 on AWS EC2

Amazon linuxでは起きない？！

他のプロジェクトではamazon linuxを使っていて、ubuntuでやったのは初めてで気付かなかったので、メモ。※知っている人から見たら低次元の話です。すみません。

まずはgit-configで設定

git config --global credential.helper '!aws --region us-east-1 codecommit credential-helper $@' 
git config --global credential.UseHttpPath true

※リージョンはご自身の使用内容に修正して下さい。

これでhttpsでgit cloneしてもエラーになる！AWS Cliインストールを

curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
sudo python get-pip.py
sudo pip install awscli

結論から言うとAWS Cliのインストールが必要となります。
無事httpsでgit clone出来るようになりました！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T16:19:51+09:00

AWS Hands-on for Beginners #2 でサーバーレス環境自動構築チャレンジ

オンデマンドハンズオン「AWS SAM を使ってテンプレートからサーバーレスな環境を構築する」に参加しました。
前回に当たる「サーバーレスアーキテクチャで翻訳 Web API を構築する」のレポートについては以下の記事をどうぞ。
AWS「さぁ！サーバーレスを始めよう！サーバーレスハンズオンもくもく会」レポート
注意：前回同様に知識がなくても参加できますが、今回のハンズオンはCloudFormation・Linuxの仕様とコマンドを学んでいないと難しい部分があります。

前提知識① - AWS Serverless Application Model（SAM）とは？

「AWS Serverless Application Model（SAM）」は「AWS CloudFormation」の拡張機能です。
そもそもの「AWS CloudFormation」は、AWSのインフラサービスをコードで作成できる機能です。提携リソースを一度構築すれば使い回しができ、作成時にミスや不足が起きずに済む……と非常に便利です。
しかし、LambdaやAPI Gatewayなどのリソースを作成しようとすると、どうしてもテンプレートが長文化するのが難点でした。
AWS SAMはそういったリソースのテンプレートを、簡潔に記述可能にしたものです。
（処理としては、デプロイされたSAMテンプレートはAWS側でCloudFormation形式に変換されています）

前提知識② - AWS Cloud9 とは？

サーバーレスと直接関係はないのですが、Infrastructure as Codeに役立つ環境として「AWS Cloud 9」を利用します。
Cloud 9とは、ブラウザ上でコードの記述（コードエディタ）・実行（ターミナル）・デバッグ（デバッガー）が可能な、クラウドベースの統合開発環境です。
複数人でリアルタイムの共同コーディングを行え、チャット機能が付随しているのでペアプログラミングも行えます。
今回利用するうえで嬉しいのは、AWS Lambdaとの連携です。簡単なサーバーレスアプリケーション（Lambda関数）を、Cloud 9上で構築したり実行したりデプロイしたりできます。
また、AWS CLI（ただし2020年4月現在はv1）やDockerが最初からインストールされており、便利に利用することができます。

ハンズオン

はじめの小目標は「Cloud 9に慣れる」ことです。せっかくなので仕様をいろいろと確認してみます。
今回のスペックは以下の通りです。

  • Environment type：Create a new instance for environment 　（※選択したリージョンでEC2インスタンスを立て、Cloud 9環境を実行）
  • Instance type：t2.micro (1 GiB RAM + 1 vCPU)
  • Platform：Amazon Linux
  • VPC,subnet：default

Pythonのバージョンを確認します。（2020年4月現在）3.6.10です。

$ python --version
Python 3.6.10

デフォルトでAWS CLIも入っています。

$ aws --version
aws-cli/1.18.40 Python/3.6.10 Linux/4.14.171-105.231.amzn1.x86_64 botocore/1.15.40

アップグレードも可能です。

$ sudo pip install --upgrade pip
Cache entry deserialization failed, entry ignored
    ...
Successfully installed pip-20.1

一通り使用方法に慣れたら、SAMファイル（YAML形式）を作成します。
公式ドキュメントを参考にすれば、記述方法についてそれほど困ることはありません（といってもCloudFormationの知識がないと少し難しいです）。
前回のハンズオン同様、API GatewayやDynamoDBとの連携も行います。この辺りは目新しいこともないので省略します。

オプションとして、SAM CLIも使用してみました。
sam init → sam build → sam deploy --guided のたった3コマンドでデプロイができます（要Docker環境/Cloud 9なら最初からインストールされているので気にしなくて大丈夫です）。詳細は公式ドキュメント中のチュートリアルを参考にしてください。

XXXXXXXX:~/environment $ sam deploy --guided

Configuring SAM deploy
======================

        Looking for samconfig.toml :  Not found

        Setting default arguments for 'sam deploy'
        =========================================
        Stack Name [sam-app]: AWSserverlesshandson
        AWS Region [us-east-1]: ap-northeast-1
        #Shows you resources changes to be deployed and require a 'Y' to initiate deploy
        Confirm changes before deploy [y/N]: y
        #SAM needs permission to be able to create roles to connect to the resources in your template
        Allow SAM CLI IAM role creation [Y/n]: Y
        Save arguments to samconfig.toml [Y/n]: Y
    ...

加えてSAM テンプレートを事前検証するならsam validate、sam local start-lambdaでモック環境でのテストも可能です。
さらに大元がCloudFormationなので、CloudFormationコンソールからまとめて削除できます。
SAM.png
上から順にSAMテンプレートで作ったリソース、S3 bucket（内にアップロードしたsam-appフォルダ）、Lambda関数、Cloud 9です。
Cloud 9もCloudFormationスタックなんだという新たな気づきも得ました。
便利ですね。
短所があるとすれば、まだβ版なので本番運用はできない点でしょうか。

おわりに

  • サーバーレス環境もコード化できる！
  • サーバーレス環境をコード化してコマンド形式で実装できる！
  • サーバーレス環境をデプロイしなくてもローカルでテスト実行ができる！
  • SAM CLIもある！（まだβ版だけど……）

AWS SAMは、サーバーレスって結局コンソールをぽちぽちやる必要があるからめんどくさい！……という意見に応えられる画期的なサービスだと思います。
ハンズオンをはじめて、今日からIaCの世界へと飛び込みましょう。

弊社WebサイトではAWSを含むさまざまな技術記事を公開しています。ぜひご覧ください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T15:35:19+09:00

AWSのEC2にPHP、Nodejs、MySQL、Nginxをインストールする方法

自分用のメモとして、それぞれのインストール方法をまとめてみた。

はじめに

// ssh接続後、yumのバージョンを更新しておく
$ sudo yum update -y

PHP

// epel-releaseパッケージをインストール出来るようにする
$ sudo amazon-linux-extras install epel

$ sudo yum install epel-release

// remiリポジトリを使えるようにする
$ sudo rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-
  release-7.rpm
$ sudo yum install -y php74 php74-php php74-php-fpm
$ sudo ln -s /usr/bin/php74 /usr/bin/php
$ php -v

Node.js

$ curl -sL https://rpm.nodesource.com/setup_8.x | sudo bash -
$ sudo yum install -y nodejs

MySQL

//デフォルトで入っているmariadbをアンインストールする
$ sudo yum list installed | grep mariadb
$ sudo yum remove mariadb-libs

//mysqlのリポジトリを追加して、インストールする
$ sudo yum install http://dev.mysql.com/get/mysql57-community-
  release-el7-11.noarch.rpm
$ sudo yum install mysql-community-server

//正しくインストールされたか確認する
$ yum repolist enabled | grep "mysql.*-community.*" 
$ mysql --version

//MySQL の自動起動設定
$ sudo systemctl start mysqld.service
$ sudo systemctl enable mysqld.service
$ systemctl status mysqld.service

初期パスワードがデフォルトで設定されているため、それを確認後に変更しておく。

//初期パスワードの確認。以下コマンド実行後、一行目に記載されている。
$ cat /var/log/mysqld.log | grep password

//新しいパスワードに変更
$ mysql_secure_installation

デフォルトで設定されている文字コードを確認後、utf8mb4へ変更する。

//デフォルトの文字コードを確認する
$ mysql -u root -p
$ mysql> use データベース名;
$ mysql> show variables like "chara%";
$ mysql> exit

//設定ファイルを開いて文字コードをutf8mb4に設定する。
$ vi /etc/my.cnf

//下記を追加する
[mysqld]
...
character-set-server=utf8mb4

[client]
default-character-set=utf8mb4

//再起動する
$ restart mysqld.service

デフォルトでのパスワード制約が強いため弱めておく。

//ログイン後以下コマンドを実行
$ mysql> SET GLOBAL validate_password_length=8;
$ mysql> SET GLOBAL validate_password_policy=LOW;
$ mysql> ALTER USER root@localhost IDENTIFIED BY 'new password';

Nginx

$ sudo amazon-linux-extras install nginx1.12

//インスタンス立ち上げ時に自動で起動させておく
$ sudo chkconfig nginx on
$ nginx -v


  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T14:33:21+09:00

コロナ休みで増えた家事を分担！LINEBotでスッキリ解決する

この記事は下記の #GWアドベントカレンダー の 2日目の記事になります。

すごくなりたいがくせいぐるーぷ（ @inoue2002 ） | GWアドベントカレンダー

はじめに

記事をご覧のみなさんStayHomeお疲れ様です。
一刻も早い収束を願い、みなさんで協力していきましょう！

さて、学校が休校になり、毎日お昼ご飯を作ったり、その他家事をしたりとそろそろ疲れてきたところではないでしょうか？
そんな皆さんのために、（僕はお母さんの為に）家族で各仕事の役割と分担をして発表してくれるLINEBotを作成したのでご紹介します。

完成品

参考にした記事

1時間でLINE BOTを作るハンズオン

構成

Node.js ＋ now

画像&コード

ソースコードはこちら
煮るなり焼くなりお好きなようにしちゃってください！

使い方

１　リポジトリにある画像を適当にアップロードして画像URLを発行する
２　LINEBotのアクセストークンとシークレットキーを発行
３　index.jsを書き換えてデプロイ！

index.js
//キーを設定する
const config = {
  channelAccessToken: "ここにアクセストークンを入れる",
  channelSecret: "ここにシークレットキーを入れる",
}

//画像URLを打ち込む
 url: "５箇所に画像URLを入れる",

おわりに

日本中の家庭の助けになればいいなと思います(^^)
お疲れ様でした！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T14:31:00+09:00

タグを指定するだけでRDSを自動起動・停止する

はじめに

「タグを指定するだけでEC2インスタンスを自動起動・停止する」のRDS版です。

案件で必要になったためメモを残しておきます。

やりたいこと

RDSタグにStartTime:8am、StopTime:9pmを設定すると朝8時に自動起動、夜9時に自動停止させます。

手順は前回と全く同じなのでドキュメントのコンテンツだけの記事です。

注意点

タグに対応するDB識別子が取得できない場合、SSMAutomationは失敗します。
つまりCloudWatchRulesに7amに起動するルールを設定したとしてもRDSにStartTime:7amに対応するルールがないと失敗してしまうのでその点だけご注意ください。

RDSの自動起動

description: StartRdsInstances Using Tags:StartTime
schemaVersion: "0.3"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  StartTime:
    type: String
    default: 8am
    description: (Required) 7am,8am,9am
    allowedValues:
    - 7am
    - 8am
    - 9am
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ""
mainSteps:
  - name: StartRdsInstance
    action: aws:executeAwsApi
    inputs:
      Service: ssm
      Api: StartAutomationExecution
      DocumentName: AWS-StartRdsInstance
      TargetParameterName: "InstanceId"
      Targets:
        -
           Key: tag:StartTime
           Values: 
             - "{{ StartTime }}"

RDSの自動停止

description: StopRdsInstances Using Tags:StopTime
schemaVersion: "0.3"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  StopTime:
    type: String
    default: 8pm
    description: (Required) 8pm,9pm,10pm,11pm
    allowedValues:
    - 8pm
    - 9pm
    - 10pm
    - 11pm
  AutomationAssumeRole:
    type: String
    description: (Optional) The ARN of the role that allows Automation to perform the actions on your behalf.
    default: ""
mainSteps:
  - name: StopRdsInstance
    action: aws:executeAwsApi
    inputs:
      Service: ssm
      Api: StartAutomationExecution
      DocumentName: AWS-StopRdsInstance
      TargetParameterName: "InstanceId"
      Targets:
        -
           Key: tag:StopTime
           Values: 
             - "{{ StopTime }}"
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T14:08:21+09:00

スクレイピングしてくる不届きものを、AWS WAFを使ってブロックする話

概要

Webの集客をGAで監視していたところ、異様なトラフィックの増加が見られたので、スクレイピングされてるのでは…？と、対策することになったお話です。

Headless Chromeだけ弾く、とかいろいろ考えましたが、調べると現実的ではなさそうで、まずは、WAFで止めましょうという流れになりました。

結果

いくつかスクレイピングしてるだろう不届き者のIPを発見し、ブロックしてさしあげました。

やった処理は以下の通りです。

  1. 一定時間のアクセスが多すぎるIPを一時的に弾く
  2. BlackリストにいれたIPを弾く
  3. Whiteリストに入れたIPはBlackリストに引っかからないようにする

以下の図は、PV数を時間毎に表示したものですが、対策後の山が僅かに小さくなっていること、気づけますでしょうか？
（分母がそれなりに大きいので差分が分かりづらいですが）

image.png

WAF（Web Application Firewall）

WAF（ワフ）は、Webアプリケーションの脆弱性を狙った攻撃からWebサイトを保護するセキュリティ対策です。
Webサーバーの前段に設置して通信を解析し、不正なアクセスを弾きます。

AWS WAF

設置の仕方としては以下の設置方法があります。
①Cloud Frontの前段に設置して、Cloud Frontへのアクセスを監視する
image.png

②Cloud FrontとELB(ALB)の間に設置して、Cloud FrontからELBのアクセスを監視する
image.png

③Route53とELB(ALB)の間に設置して、Route53からELBのアクセスを監視する
image.png

ELBと同様にAPI Gatewayにも適用できます。

構成

今回のざっくりした構成はこんな感じです。
image.png

実装① 一定時間のアクセスが多すぎるIPをブロックする

AWSのコンソールを開いて、WAFと検索すると、「WAF & Shield」というページが見つかるはずです。
image.png

まず、最初にやることなのですが…
今回弾きたい対象に、cssやjsなど、Asset周りを含めるつもりはありません。
なので、その設定をおこなえるように、正規表現をあらかじめ作成しておきます。

正規表現のページから新規作成を行って行きます。
image.png

名前は分かりやすいものをつけて、弾きたかった/image//fonts/ /assets/を含めてくれるような正規表現を記載すれば完了です。
image.png

Web ACLsページからACLの新規作成に進みます。
※ACL: Access Control List --> IPに対してのルールをまとめたグループみたいなものです。

image.png

名前を入力します。名前を入れると自動的にCloudWatchのメトリクス名が入力されます。
※メトリクスも説明しておくと、CloudWatchはいくつもの情報の点を集積させてログを残していく仕組みなのですが、その点情報のグループにあたるものがメトリクスだと考えてもらえばいいかと。

リソースタイプの項目でCloudFrontに対して設置するのか、ELBまたはAPIGatewayに対して設置するのかを選択できます。
image.png

下段で、WAFに紐付けたいリソースを紐付けします。
image.png

次のページでルールを設定できます。
image.png

最初に実装したいのは、「一定時間のアクセスの多いIPを弾く」処理です。
「Add my own rules and rule goups」をまずクリックします。
image.png

IPListを使う処理ではないので「Rule builder」を選択します。

「Type」は「Rate-based rule」にします。
こうすることで、5分間のアクセスの数を設定することができます。
下段の詳細設定に許可するアクセス数を入力するだけです。
※100から設定できます。

詳細設定にあるラジオボックス。
これが以外と重要なのですが、「Consider all request」を選択してしまうと、すべてのIPに対してこのルールを適用してしまうことになります。
冒頭にも書きましたが、Asset周りのアクセスを同時にカウントして欲しくはないですよね。
ですので、「Only consider requests」を選択します。
image.png

そして、その次の段にでてくる設定で、正規表現に一致しないという条件を入れ、作った正規表現のパターンセットを選択します。
image.png

最後に、この条件に合う（五分間に指定した回数以上のアクセスがあった）場合にブロックするのか、またはカウントするだけなのかを選択すれば設定完了です。
image.png

実装の結果

でてくるでてくる。不届き者達。
最初びっくりさせられたのは5分間どころか10秒で500アクセスぐらいしてきてたIPがあったり。
（逆によく耐えてたな…サーバー）

↓WAFのACLsのダッシュボードです。
image.png

ブロックしたメトリックス（こちらもWAFのACLsのダッシュボード）を確認すると、どうやら同じIPが、順番にページを叩いていっているのが見える状況……
image.png

上手くいってるようにみえますが、ここで、もう一つ課題があります。

会社によっては同じルーターから外部にアクセスする場合が多いため、同じ場所の複数の人間が同時間にアクセスしてもこのルールに引っかかってしまう場合があるのです。
なので、あまり厳しい回数制限はできません。

そんなこんなで新たに以下の実装を加えるわけです。

  1. あからさまなクローラーはBlackリストへ
  2. 顧客になりそうなIPはWhiteリストへ
  3. 検索エンジン関連のクローラーはWhiteリストへ

実装② Blackリスト/Whiteリストの作成

まずは、IPがどこのものか調べます。
BlockされたIPを見て、これはAWSのサーバーだとか、これは某企業のサーバーだとか、仕分けします。

ページを順番に叩いていっている、サーバーっぽいIPは、Blackへ登録します。
image.png

名前をつけて、対象としたいIPを改行しながら追加していけばリスト完成です。
image.png
Whiteリストも同様の方法で作成します。

再度、Web ACLsのページに入り、Rulesからルールの追加をします。
image.png

今回は、IPリストを使うので、IPsetを選択します。

Blackリストであれば、IP setに先ほど作ったBlackリストのセットを選択し、Blockに。
Whiteリストであれば、Whiteリストのセットを選択し、Allowを選択します。
image.png

そして、ルールの優先度を
Whiteリスト → Blackリスト → 一定時間ルール
にすれば完成です。

image.png

実装の結果

Blackリストに入れたIPがしつこくアタックしてくるのが良くみえ、とても愉快な気分になりました。

実装してみて

たまに人力でIPを確認してやらないといけないので（ルールに引っかかってブロックされたものがあればメールで飛ばすようにしてますが）運用に少しだけ負荷がかかりますが、大事なデータを簡単にとられないようにするという目的はある程度達せられたのではないかなという感じです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T13:08:28+09:00

AWSを触る　～サーバーの構築～

前回

前回はVPC領域の構成をやりました。
AWSを触る　～VPC領域の構成～

サーバーの構築

今回はサーバーの構築をやっていきます。

AWSの仮想サーバーのサービスはEC2、Elastic Compute Cloudと呼ばれます。
ここの仮想サーバーのことを「インスタンス」と呼びます。

インスタンスの作成

では、インスタンスを作成していきます。
AWSマネジメントコンソールの「EC2」を開きます。
1.png

インスタンス画面を開き、「インスタンスの作成」を押下します。
2.png

AMIの指定

awsでAMIと呼ばれるイメージファイルを選択します。
今回は画面2番目のAmazon Linuxを選びました。
3.png

インスタンスタイプを選ぶ

インスタンスタイプを選びます。
当然無料枠の「t2.micro」を選びます。
「インスタンスの詳細の設定」を押下します。
4.png

インスタンスの詳細を設定します。
ネットワークに前回作っておいたVPCを選択します。
また、自動割り当てパブリックIPを「有効化」にして、下部のプライマリIPを「10.0.1.10」に設定します。
設定できたら「ストレージの追加」を押下します。
5.png

仮想ハードディスクを追加

AWSでは仮想ハードディスクをEBS、Elastci Block Storeといいます。
デフォルトのまま8GBのEBSを設定しますので、そのまま「タグの追加」を押下します。
6.png

インスタンスに名前をつけます。
「タグの追加」を押下します。
7.png

キーを「Name」とし、値を「Webサーバー」とします。
設定できたら「セキュリティグループの設定」を押下します。
8.png

セキュリティグループの設定

セキュリティグループを設定します。
名前を「WEB-SG」としました。
デフォルトでは、ソースが0.0.0.0/0となっており、どこからでもアクセスできると警告が出るので、ソースは自身のグローバルIPを指定しておきました。
「確認と作成」を押下します。
9.png

内容に問題がなければ、そのまま起動を押下します。
（関係ないけど、以前は作成ボタンだったようですが、バージョンが上がって起動ボタンになったようです。たしかに起動するのであれば作成ボタンより起動ボタンのほうがいいですね。細かい良い修正です。）
10.png

キーペアの作成

キーペアを作成します。
「新しいキーペアの作成」を選択し、名前を決めます。
「キーペアのダウンロード」ボタンでkeyを任意の場所に保存しておきます。
保存できたら「インスタンスの作成」を押下します。
11.png

「インスタンスの表示」を押下します。
12.png

起動の確認

インスタンスが起動されていることを確認します。
起動されていれば、インスタンスの状態がrunningになっているはずです。
13.png

ここまででサーバーの構築ができました。
さて、今回はテスト用でサーバを構築したので、使わない時はサーバを停止しておいたほうが無難です。
特に、AWSでは使った分だけ課金されますので、停止しておきます。

サーバーの停止

停止の方法ですが、EC2のインスタンス画面より、アクションボタンの「インスタンスの状態-停止」を実行します。
14.png

確認メッセージが出ます。
「エフェメラルストレージ上のデータが失われます」というメッセージが出ます。
あまりよくわかってませんが、特に触ってないので、そのまま「停止」ボタンを押下しました。
15.png

停止できたらステータスが「stoped」になりました。
16.png

おわり

サーバ作って起動停止できました。
次回は作ったサーバへのアクセスをやります。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T10:00:52+09:00

Redshiftのノードタイプによるパフォーマンス比較

はじめに

Redshiftのds2.xlargeとdc2.largeとでパフォーマンスを比較する機会があったので、その結果を記載します。

これはあくまでも性能測定の1例であり、
データの偏り具合など測定条件により結果は大きく変わります。
この結果を絶対視しないでください。

比較対象

比較したのは以下の通りです。

名称 クラス vCPU MEM ストレージ コスト(USD)
ストレージ1 ds2.xlarge * 1 4 31 GiB 2000 GiB 1.190 USD
ストレージ2 ds2.xlarge * 2 8 62 GiB 4000 GiB 2.380 USD
ストレージ3 ds2.xlarge * 3 12 93 GiB 6000 GiB 3.570 USD
ストレージ4 ds2.xlarge * 4 16 124 GiB 8000 GiB 4.760 USD
CPU8 dc2.large * 8 16 120 GiB 1280 GiB 2.512 USD
CPU12 dc2.large * 12 24 180 GiB 1920 GiB 3.768 USD
CPU16 dc2.large * 16 32 240 GiB 2560 GiB 5.024 USD

※「名称」は独自につけた名称です。
以後、この記事内ではこの名称で記載します。

処理速度の測定に使用したデータ

以下のテーブル2つをJOINしたSQLの処理速度を測定しました。

テーブル

テーブル名 件数 サイズ 分散キー ソートタイプ ソートキー
table_a 約7.2億件 約690 GB EVEN Interleaved column_a, column_b
table_b 約36.2億件 約230 GB column_a Interleaved column_a, column_c, column_d

SQL

select count(1) from table_a a
inner join table_b b
on a.column_a = b.column_a -- Interleavedキーの1番目同士で結合
where a.column_b = 'hogehoge' -- Interleavedキーの2番目

処理速度を測定するにあたっては以下に気を付けます。

  • キャッシュの影響を除く
    SET enable_result_cache_for_session = off;
    を実行してからSQLを流します。
  • コンパイル時間の影響を除く
    初回実行時はSQLのコンパイル時間が含まれるため、 2回目以降を測定します。
    2～6回目の計5回測定しての平均値で比較することにしました。
  • 構築直後は避ける
    環境を構築後、すぐにスナップショット取得が始まるので
    それが終わってから測定します。

測定結果

名称 測定1回目 測定2回目 測定3回目 測定4回目 測定5回目 平均
ストレージ1 217.0 221.0 225.0 221.0 215.0 219.8
ストレージ2 44.2 42.9 46.2 46.3 42.1 44.3
ストレージ3 33.8 31.3 31.9 30.5 31.3 31.7
ストレージ4 27.8 27.8 28.1 28.9 30.6 28.6
CPU8 7.8 7.5 7.8 7.5 7.6 7.6
CPU12 5.2 5.2 5.5 5.1 5.2 5.2
CPU16 3.3 3.4 3.4 3.3 3.2 3.3

単位は秒です。

ストレージ1を1としたときのストレージ2,3,4との比較

ストレージ比較.png
ストレージ1からストレージ2へ増強すると、
5倍もの性能向上が見られました。

ストレージ1を1としたときのCPU8, 12, 16との比較

CPU比較.png
データ容量さえ許せば、
ds2.xlargeよりもdc2.largeを並べたほうが
コストあたりのパフォーマンスが格段に良いようです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T07:06:37+09:00

JAWS-UG 初心者支部＆千葉支部 #26 新人さん歓迎！ハンズオン&LT(オンライン)

0. はじめに感謝の気持ちを伝えさせて下さい！

  • 世界中で非常事態宣言が発動されているという緊迫した状況にも関わらず、オンライン開催を実行されたスタッフさんの俊敏性が素晴らしい！と感じた勉強会でした。:clap:

  • いま一番興味あるテーマのサーバーレス＆Web APIをAWSさんの解説付きでハンズオンできるチャンスでしたので、モクモクさせていただきました。どうもありがとうございます。

  • 資料はこちらに公開されています。本メモでは「忘れちゃいけないな」と思った3つの点について、資料を一部使用させていただきましたこと、お許し下さい。:bow:

1. マスターすると決めた種目は、誰かへちゃんと説明できるまでのレベルを目指そう！

image.png

2. やらなくてことを止めて、やるべきことに集中しよう！

image.png

3. うぉーーー、サーバーレスの時代にインフラエンジニアの仕事はない！

image.png

4. 翻訳Web API（RESTでJapaneseをEnglishに翻訳します）

  • 興味のあるAPI Gatewayを使ったハンズオン2についてメモしておきます。（ハンズオンは3個ありましたが時間内にハンズオン3が完遂できなかったので、翌朝モクモクしてみました）

  • 東京リージョンを使いましたがターンアラウンドタイムがとても早いなと体感できます。

  • URLにクエリ文字列（翻訳したい文字列）を入れて、作ったAPIGatewayへリクエストを飛ばすと、Englishでレスポンスが返ってきます（おかえり:grin:）。
    image.png

  • 処理フローの内容を文字にすると...
    GETリクエスト➡️APIGateway➡️Lambda（python+AWStranslate）➡️レスポンス200

  • API Gatewayのマネコンで確認するとこんな感じです。
    image.png

5. Next Action

  • 宿題のハンズオン2の+α、翻訳した結果についてDynamoDBストリームと連携する。
  • よく分からんキーワードをトリガーにPythonをモクモク。
    • boto3
    • handler
    • event

最後に

  • エンタープライズ系のインフラエンジニアだってアプリケーションも創れるんだよ！ってことを証明できることを目標に、日々モクモクしている感じです。そんな時にSo Goodなセミナーを造っていただいた初心者支部のスタッフさんに感謝です。:grinning:

  • Next Actionが進んだら更新したいと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T03:39:36+09:00

【自分用】4/30進捗

やったこと（後ほど追記します）

awsにdockerでデプロイ
EC2のElasticIPとインスタンスの作成・紐付け（ssh通信設定）

参考url
https://qiita.com/hagyyyy/items/959c115e0a5001972604
https://qiita.com/Atsushi_/items/f10a6790972528682d25

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-04-30T00:10:36+09:00

ssh接続時の Permission denied (publickey).エラーについて~capistrano自動デプロイ、ローカル・サーバーからのssh接続~

概要

こんにちは。今回はcapistrano × unicornを用いた自動デプロイを行う時にGit Hubへのssh接続ができず、長時間エラーにはまってしまったので解決方法を書きました。

環境
Rails 5.0.7
AWS EC2
unicorn
capistrano

エラー内容

#bundle exec cap production deployコマンドを実行

Permission denied (publickey).

こちらはcapistranoで自動デプロイコマンドを実行した時に、EC2へのアクセスは上手くいくが、EC2にアプリをクローンする時に、EC2→Git Hubへのssh接続ができずに起きたエラーです。

このエラーはCapistranoを使用していない場合でも,手動でサーバーやGit Hubにssh接続を試みた時にも起こりうるエラーです。

解決策

解決策はズバリssh-agentでした。

このエラー内容で検索するとssh-agentを使用するという方法はかなりたくさん出てくるのですが、初心者の私には結局何をしたらいいのか理解するまでにかなり時間がかかってしまいました。

その時の私の設定としては

ローカルにEC2へ接続する鍵を置き、EC2サーバーにGitに接続する鍵を置くというものでした。

EC2への鍵→ローカル
Git Hubへの鍵→サーバー

このようにデプロイ時に必要なssh接続する為のkeyparは2セットです。

ssh接続とは手元に秘密鍵、接続先に公開鍵をセットしておくことでコマンドを実行するとアクセス可能になるという方法です。（私はこの時点でssh接続さえあまり理解できてませんでした。)

しかし検索したところサーバー上に秘密鍵を置いておくという環境はセキュリティ的によろしくないそうです。

スクールのカリキュラムや初学者用のデプロイ記事ではサーバー上に鍵を置く方法が書いてあることが多いように思えました。

では、どうするかというと

ローカル上に鍵を二つとも置いておきます。

EC2への鍵→ローカル
Git Hubへの鍵→ローカル

これではサーバーからGit Hubへ接続できないのでは、と思いますが
それを可能にするのがssh-agentです。

具体的には以下コマンドで実行します。(※ローカルにEC2,Git Hubそれぞれへの鍵を設置している前提です。）

#まずはローカル上で秘密鍵のディレクトリまで移動します。

$ cd .ssh

#続いてEC2,Git Hubそれぞれへの鍵があるかを確認

.ssh $ ls
github_rsa #GitHubの鍵
aws_rsa    #EC2の鍵

#確認した鍵をssh-agentに登録します。

.ssh $ ssh-add github_rsa

.ssh $ ssh-add aws_rsa

#↑での登録が上手くできているか確認します。

.ssh $ shh-add -l

#文字列が二つでるはずです。(※他の記事では鍵名が末尾に表示されるとありましたが私のターミナルではありませんでした。）
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx(RSA)
yyyyyyyyyyyyyyyyyyyyyyyyyyyyy(RSA)

#ダウンロードした鍵であれば.pemの可能性もあります。

以上が、
ローカルにあるEC2、Git Hubへの二つの鍵をssh-agentに登録する。
という作業になります。

それではこの鍵を用いて、
1.ローカルからEC2へ接続
2.EC2からGit Hubへ接続
を行ってみます。

#末尾の　-A に注目！
$ ssh -i ~/.ssh/aws_rsa username@IP -A


       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|
末尾の-Aというのがssh-agentを使用するというオプションになります。
これがないとssh-agentに登録しているGit Hubの鍵をEC２に持っていくことができません。

次にEC2からGit Hubにアクセスしてみます。

[username@ip ~] $ssh -T github
Hi "Git Hubのユーザー名"! You've successfully authenticated, but GitHub does not provide shell access.

このようにサーバーでコマンド一つでGit Hubと接続できれば成功です。

※もしこのコマンドでパスワードを聞かれた場合はssh-agentの使用に失敗しています。

以上がssh-agentを使用して　ローカル→サーバー→Git Hubへと接続する方法となります。

それでも自動デプロイできないという方は↓

補足

その他の理由で接続エラーが起きる事があります。

capistranoを用いて自動デプロイを行う際はサーバーへの接続鍵を指定しているコードにforward_agent: trueのオプションを追記する必要があります。

set :ssh_options, auth_methods: ['publickey'],
                  keys: ['~/.ssh/first_aws_rsa'],
                  forward_agent: true

ssh-agentは一度ターミナルを閉じるとリセットされます。
一度は上手く接続されたのに、急に接続されなくなったという方はssh-add -lで正常に登録されているかどうかを確認してください。

さらに毎回デプロイコマンドを実行する前に一度手動で接続をしなければなりません。

#一度は成功したのにしばらくするとエラーになるという場合はこのフローを行う。

#ローカル
$ ssh-add 鍵名

$ ssh -i ~/.ssh/aws_rsa username@IP -A

#サーバー
$ ssh -T github

ターミナルを落としてもssh-agentを持続させるオプションもあるようなのですが、私は今の所それを実行することはできませんでした。

以上です！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧