20200530のAWSに関する記事は16件です。

インフラ初学者がAWSでポートフォリオを公開するまでに独学で学んだこと(概要編)

先日、転職向けに作ったポートフォリオをAWSで公開したのですが、思い返すと公開までにかなり(無駄な?)試行錯誤を繰り返したので、備忘としてポイントを残しておきます。

筆者は、インフラ知識は独学なので、かなり使用技術に偏りがあるかもしれませんが、ご容赦ください。対象の読者は同じく独学でAWSを動かしており、アプリケーションの公開に悩んでいる初学者を想定しています。

進め方の反省点

アプリケーションの作成とインフラの構築を分けてポートフォリオ作成を進めてしまった点。デバッグ環境では動いていたのに、本番環境に移行すると動かない、とかあるあるなので、インフラ構築はアプリケーションの一部として考えるべきでした。

Hello Worldした時点で、ある程度時間をかけてでもインフラ公開できる仕組みを構築しておいて、アプリケーションを作り込みながら、インフラ周りの知識を深めていく、といった進め方が理想的だったと思います。

AWSを動かすのに必要な前提知識

とりあえず、公開できる程度まではAWSを触ってみた筆者の感想として、TCP/IPなどの通信の仕組み、Linux、Webサーバの知識は、ある程度ベースを固めておくべきだと感じました。

普段使わない知識を3種類も勉強するのは非常に負荷が高いのですが、最低限の知識がない状態で、アプリケーションを公開したい一心でAWSを動かしても、体系だった知識をベースに物事を考えられないので、ひたすら謎のエラーと格闘する不毛な時間に心が折れてしまうかと思います。

通信

HTTP、TCP/IPなどの知識がないと、AWSのセキュリティ設定(インバウンドルールなど)で相当苦労するはずです。ここが理解できないと、デバッグ環境では動いていたのに本番環境ではファイアウォールでブロックされて動かない、などのトラブル原因が切り分けできないというのも辛いです。

筆者の経験上、通信エラーに関しては、F12の開発者ツールでエラー内容を確認してもあまり有用な情報が落ちていないことが多く、通信が阻害される原因の仮説を立てて、開発を進めていくことが非常に重要です。

勉強するなら、マスタリングTCP/IP―入門編―(第6版)が知識としてよくまとまっているので、良いと思います。

image.png

Linux

仕事でLinuxを使う人は少数派だと思いますが、インフラの構築を行う上ではLinuxがまだまだ主流なので、AWSでもLinuxを選択しなるべく操作には慣れておいた方が良いと思います。

勉強するなら、本よりも実際にAWS EC2のLinux AMIなどの環境を手で動かして慣れてみた後、余裕があれば知識を網羅する為に、後述するLinuCという資格試験の勉強をしてみると良いかもしれないです。

筆者も普段Windowsを使用しており、GUIに慣れきっている状態だったのでLinuxのコンソール画面に当初かなり違和感を覚えていたのですが、使用しているうちに少しずつ勘所がつかめてきた気がします。

Linuxを動かす上で意識していたポイント

  • コマンドに慣れる(特にls、cd、pwdコマンド)

    • lsは現在いるディレクトリのファイルやフォルダを一覧表示するコマンド。
    • cdはディレクトリの移動のためのコマンド。
    • pwdは自分が存在するディレクトリを確認する為のコマンド。
  • 階層構造に慣れる。

    • 最初のうちはCUIに慣れないと思うので、迷ったらpwdコマンドで自分がどこにいるのか確認して進めていた。
  • 環境変数に慣れる。

    • .bashrcなど、基本的な環境変数周りの知識はあった方がいい。
  • VIMの操作に慣れる。

    • confファイル(後述)の編集にはVimを使用する為、苦手意識を持たない方が良い。
  • Linuxにも種類があることを理解する。

    • 混乱するかもしれないが、Linuxにもさまざまな種類があり使えるコマンドも若干異なる。Qiitaなどの記事内容をコマンド入力してエラーが出ても、放り出さずにエラー内容を確認する。(ここが一番辛かったかもしれない)

コツとして書いてみたものの、独学で知識の偏りがあることは否めないので、LinuCという資格試験には今後挑戦してみたいと思います。

Webサーバ(今回はNginxを使用)

Webサーバも、普段インフラ運用を行う人でなければ、設定を行うのが難しい所だと思います。

Webサーバを動かす上で意識していたポイント

  • Confファイルの変更箇所をメモしながら進めた点。

    • Nginx.confなど、Linux上でWebサーバの設定を行う機会は多い。
    • その分ネット上の参考記事も多く、却って混乱することが多かった。記事の内容を鵜呑みにせず、何を行いたいのか、その為にどこを編集したのか、振り返って後からでもわかるようにしておくことが重要だと思う。
  • Linux上でWebサーバのモジュール(Confファイル等)がどこにあるのか

    • 慣れている人ならともかく、初心者はLinuxのどこに何があるのか分からず、作業の大きなボトルネックになると思うので、Confファイルの場所は常にメモに書いてわかるようにしておいた。
  • 変更したらとにかく再起動

    • Webサーバに限らず、ツール系の再起動コマンドは暗記するくらい使いこなす。設定がうまく行っていないのか、再起動待ちで変更が反映されていないのか、考える時間が一番無駄だと感じた。

その他

細かいテクニックやハマリ所は別記事にもまとめてみました。

Vue.jsのアプリケーションをAWS上のNginxで公開する。(404エラーの罠)

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

インフラ初学者がAWSでポートフォリオを公開するまでに独学で学んだこと

先日、転職向けに作ったポートフォリオをAWSで公開したのですが、思い返すと公開までにかなり(無駄な?)試行錯誤を繰り返したので、備忘としてポイントを残しておきます。

筆者は、インフラ知識は独学なので、かなり使用技術に偏りがあるかもしれませんが、ご容赦ください。対象の読者は同じく独学でAWSを動かしており、アプリケーションの公開に悩んでいる初学者を想定しています。

進め方の反省点

アプリケーションの作成とインフラの構築を分けてポートフォリオ作成を進めてしまった点。デバッグ環境では動いていたのに、本番環境に移行すると動かない、とかあるあるなので、インフラ構築はアプリケーションの一部として考えるべきでした。

Hello Worldした時点で、ある程度時間をかけてでもインフラ公開できる仕組みを構築しておいて、アプリケーションを作り込みながら、インフラ周りの知識を深めていく、といった進め方が理想的だったと思います。

AWSを動かすのに必要な前提知識

とりあえず、公開できる程度まではAWSを触ってみた筆者の感想として、TCP/IPなどの通信の仕組み、Linux、Webサーバの知識は、ある程度ベースを固めておくべきだと感じました。

普段使わない知識を3種類も勉強するのは非常に負荷が高いのですが、最低限の知識がない状態で、アプリケーションを公開したい一心でAWSを動かしても、体系だった知識をベースに物事を考えられないので、ひたすら謎のエラーと格闘する不毛な時間に心が折れてしまうかと思います。

通信

HTTP、TCP/IPなどの知識がないと、AWSのセキュリティ設定(インバウンドルールなど)で相当苦労するはずです。ここが理解できないと、デバッグ環境では動いていたのに本番環境ではファイアウォールでブロックされて動かない、などのトラブル原因が切り分けできないというのも辛いです。

筆者の経験上、通信エラーに関しては、F12の開発者ツールでエラー内容を確認してもあまり有用な情報が落ちていないことが多く、通信が阻害される原因の仮説を立てて、開発を進めていくことが非常に重要です。

勉強するなら、マスタリングTCP/IP―入門編―(第6版)が知識としてよくまとまっているので、良いと思います。

image.png

Linux

仕事でLinuxを使う人は少数派だと思いますが、インフラの構築を行う上ではLinuxがまだまだ主流なので、AWSでもLinuxを選択しなるべく操作には慣れておいた方が良いと思います。

勉強するなら、本よりも実際にAWS EC2のLinux AMIなどの環境を手で動かして慣れてみた後、余裕があれば知識を網羅する為に、後述するLinuCという資格試験の勉強をしてみると良いかもしれないです。

筆者も普段Windowsを使用しており、GUIに慣れきっている状態だったのでLinuxのコンソール画面に当初かなり違和感を覚えていたのですが、使用しているうちに少しずつ勘所がつかめてきた気がします。

Linuxを動かす上で意識していたポイント

  • コマンドに慣れる(特にls、cd、pwdコマンド)

    • lsは現在いるディレクトリのファイルやフォルダを一覧表示するコマンド。
    • cdはディレクトリの移動のためのコマンド。
    • pwdは自分が存在するディレクトリを確認する為のコマンド。
  • 階層構造に慣れる。

    • 最初のうちはCUIに慣れないと思うので、迷ったらpwdコマンドで自分がどこにいるのか確認して進めていた。
  • 環境変数に慣れる。

    • .bashrcなど、基本的な環境変数周りの知識はあった方がいい。
  • VIMの操作に慣れる。

    • confファイル(後述)の編集にはVimを使用する為、苦手意識を持たない方が良い。
  • Linuxにも種類があることを理解する。

    • 混乱するかもしれないが、Linuxにもさまざまな種類があり使えるコマンドも若干異なる。Qiitaなどの記事内容をコマンド入力してエラーが出ても、放り出さずにエラー内容を確認する。(ここが一番辛かったかもしれない)

コツとして書いてみたものの、独学で知識の偏りがあることは否めないので、LinuCという資格試験には今後挑戦してみたいと思います。

Webサーバ(今回はNginxを使用)

Webサーバも、普段インフラ運用を行う人でなければ、設定を行うのが難しい所だと思います。

Webサーバを動かす上で意識していたポイント

  • Confファイルの変更箇所をメモしながら進めた点。

    • Nginx.confなど、Linux上でWebサーバの設定を行う機会は多い。
    • その分ネット上の参考記事も多く、却って混乱することが多かった。記事の内容を鵜呑みにせず、何を行いたいのか、その為にどこを編集したのか、振り返って後からでもわかるようにしておくことが重要だと思う。
  • Linux上でWebサーバのモジュール(Confファイル等)がどこにあるのか

    • 慣れている人ならともかく、初心者はLinuxのどこに何があるのか分からず、作業の大きなボトルネックになると思うので、Confファイルの場所は常にメモに書いてわかるようにしておいた。
  • 変更したらとにかく再起動

    • Webサーバに限らず、ツール系の再起動コマンドは暗記するくらい使いこなす。設定がうまく行っていないのか、再起動待ちで変更が反映されていないのか、考える時間が一番無駄だと感じた。

その他

細かいテクニックやハマリ所は別記事にもまとめてみました。

Vue.jsのアプリケーションをAWS上のNginxで公開する。(404エラーの罠)

GolangのWebAPIをsupervisorでデーモン化して公開する。

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

AWS Lambdaを使ってみる① | のび太とジャイアンのあの関係?

はじめてAWS Lambdaを使ってみたので、備忘録もかねて遊んだ内容をここに記します。

AWS Lambdaを使って、あるS3バケットにデータをアップロードすると別のS3バケットにそれをコピーして保存するということを実現したいと思います(バックアップもどきみたいな)

そこで今回はのび太とジャイアンと名付けられた2つのS3バケットを用意して、のび太バケットにデータをアップロードすると、ジャイアンバケットに同じものが保存されるということをやります。

つまり、「オマエノモノハオレノモノ」ということです。

奪っているわけではないので、言わば、まさに、その中で、健全だということを申し上げたいと思っている次第であります。

※Lambdaの実行環境はをNode.js 12.xを使います

のび太バケットとジャイアンバケットをつくる

S3バケットをつくります
Bucket nameを入れてcreateするだけでOKです(それ以外なにも設定しなくてOK)
1.png

IAM でロールをつくる

LambdaをつくるにはそのLambda関数にロールを与えなければいけないからです。

Services > IAM > Roles > Create roleをclick
1). Lambdaを選択してNext: Permision
2). 今回はお勉強のためにポリシーを自分で書いてみたいと思うので、Create policyをclick(別タブでポリシーを作る用の画面が開きます)
3). JSONタブを押して以下を直書きしてReview Policy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "のび太バケットのARN/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": [
                "ジャイアンバケットのARN/*"
            ]
        }
    ]

4). 名前をつけてCreate policy (OmaeNoMonoHaOreNoMonoという名前にしてみました)
5). ロールの設定画面に戻り、Filter Policyを選択してCustomer managedにチェックをいれると、↑でつくったOmaeNoMonoHaOreNoMonoポリシーが見つかります
2.png

6). OmaeNoMonoHaOreNoMonoポリシーにチェックしたらNext: Tags
7). なにも書かないでOK、Next: Review
8). Role nameを決めてCreate role(whats_yours_is_mineと名付けてみました)

  • Rolesの一覧に追加されていることを確認します
    3.png

  • whats_yours_is_mineロールの中身をみてみると、OmaeNoMonoHaOreNoMonoポリシーが適用されていることがわかります
    7aae9826-4b9c-4181-9472-785b824a4370-1920x475r.png

いざ、Lambda

Services > Lambda > Create functionをclick

1). lambdaGianismという名前にして以下の設定で作成
4.png

2). のび太バケットにデータがアップロードされたらこのLambda関数が発動されるようにトリガーを設定します。Add trggerを押して以下の設定にしてAdd
5.png
6.png

3). index.jsにコードを書いてく
参考: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#copyObject-property
7.png

const AWS = require("aws-sdk");
const s3 = new AWS.S3();

exports.handler = (event) => {
    const sourceBucket = "nobi-nobita";
    const destinationBucket = "goda-takeshi-aka-gian";
    const objectKey = event.Records[0].s3.object.key;
    const copySource = encodeURI(sourceBucket + "/" + objectKey);
    const copyParams = { Bucket: destinationBucket, CopySource: copySource, Key: objectKey };
    s3.copyObject(copyParams, function (err, data) {
        if (err) {
            console.log(err, err.stack);
        } else {
            console.log('オマエノモノハ');
        }
    });
};

のび太バケットになんかアップロードしてみる

2020-05-30-231558.gif

参考:
https://www.youtube.com/watch?v=97q30JjEq9Y
これを元に作りました。
ちなみに動画通りだと実現できないです。

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

awsのEC2でpostfixとdovecotの構築

時間がかかった作業なので備忘する

基本は下記のサイトを参考して構築した

https://genchan.net/it/server/1566/

いくか留意点を記録する

1、centos7なのでソフトの起動及び自動起動につき、下記のコマンドで行う
systemctl restart postfixとか

2、SMTP-Authの設定について、saslauthd実装されていない場合があり、ネットで調べinstallする

3、awsにおいてまず、E メール制限緩和および逆引き申請が必要、ネットで調べ行う

4、下記のようにRoute 53で設定すること
q29.png

5、下記をインストールすること
sudo yum install cyrus-sasl-plain
そうしないとログには下記のエラーが出る
SASL authentication failure: Internal Error -4 in server.c near line 1757

dovecotについては、上記の参考サイトプラス下記の設定が必要

まずは「10-auth.conf」というファイルを編集する。

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

AWS認定試験対策問題集まとめ&最短合格手順をおすすめしてみる

AWSエンジニアを目指している皆様こんばんは。

弊社はAWS関連のインフラサービス、WEBサービスを提供している会社で日頃よりAWSエンジニア(特にフリーのAWSエンジニア様にご活躍いただいています)の皆様方へAWS関連案件のお仕事のご依頼をしている業務柄、今回はAWSエンジニア様の育成という観点からAWS認定試験対策を自前で行い最短で認定を受けるためのフローをおすすめしてみたいと思います。
合格までの一般的な流れ

一般的な流れとしては以下のような形になると思います。

・WEB問題集で実力だめし
・AWS公式模擬試験を受験 https://www.aws.training/certification?src=cert-prep
  ※画面右上に「日本語」への切り替えがあります。
・問題なく得点が取れるなら受験
・得点があまり取れなかった方は学習
・改めてWEB問題集で試験を想定して復習
・AWS公式模擬試験を改めて受験する
・問題なく得点が取れるなら受験
・本番の受験をする

この繰り返しかと思います。
主なWEB問題集

弊社でもAWS問題集を随時提供(ほぼ毎日更新)していますのでぜひご活用ください。

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

アプリケーションサーバーとwebサーバーの違い

詳しくは、下記サイトがとてもわかりやすかったです!
https://kitsune.blog/affiliate-build

結論

rubyなど、動的な動きを実現させるために必要なのが
アプリケーションサーバー。

でも、大多数からのアクセスへの負荷には対応していいないため
webサーバーも必要になります。

アプリケーションサーバー

  • Puma
  • Unicon など

webサーバー

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

Lambdaでwebhookをとりあえず受け取れているかを確認するための関数を作ってみた

動機

先日M5STICKCを使ってLINE Beaconを試してみた際に、
Webhook先を今まで使ったことないGASにしてみたところ、
どこでハマってしまっているのかよくわからない状態になってしまった。

知らない機能同士をまとめてためしたのが原因なので、Webhook先は毎回固定にしておいた方がいいのかもしれない

作ってみたもの

ということで、作ってみたのが個人的にWebhook先として汎用的に使える環境。

環境は一番慣れ親しんだものとしてAWSのLambda(とAPI Gateway)とする。

Lambda関数の中身は以下で、POSTで受けてもGETで受けてもログに出力できるようにする。

import json

def lambda_handler(event, context):
    # 引数:eventの内容を表示
    print("Received event: " + json.dumps(event))
    # rawQueryString
    rawQueryString = event['rawQueryString']
    if(len(rawQueryString) != 0):
        queryStringParameters = event['queryStringParameters']
        print(queryStringParameters)

    # body
    body = event.get('body')
    if(not body is None):
        json_body = json.dumps(body)
        print(json_body)

    return {
        'isBase64Encoded': False,
        'statusCode': 200,
        'headers': {},
        'body': json.dumps('Hello from Lambda!')
    }
  • API Gatewayの作成については割愛。久々に作ってみたら前とかなり雰囲気が違っていてかなり戸惑った。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]苦労したエラー:Mysql2::Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'

状況

AWS(EC2)で、railsサーバーを立ち上げるため
DBを新規作成したい。

しかし、実行すると下記のエラーが、、、

サーバー
[ec2-user@ip-●●● <リポジトリ名>]$ rails db:create RAILS_ENV=production
Mysql2::Error::ConnectionError: Access denied for user ''@'localhost' to database '<リポジトリ名>_production': CREATE DATABASE `<リポジトリ名>_production` DEFAULT CHARACTER SET `utf8`
Couldn't create '<リポジトリ名>_production' database. Please check your configuration.
rails aborted!
ActiveRecord::StatementInvalid: Mysql2::Error::ConnectionError: Access denied for user ''@'localhost' to database '<リポジトリ名>_production': CREATE DATABASE `<リポジトリ名>_production` DEFAULT CHARACTER SET `utf8`
/var/www/<リポジトリ名>/bin/rails:9:in `<top (required)>'
/var/www/<リポジトリ名>/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'

Caused by:
Mysql2::Error::ConnectionError: Access denied for user ''@'localhost' to database '<リポジトリ名>_production'
/var/www/<リポジトリ名>/bin/rails:9:in `<top (required)>'
/var/www/<リポジトリ名>/bin/spring:15:in `<top (required)>'
bin/rails:3:in `load'
bin/rails:3:in `<main>'
Tasks: TOP => db:create
(See full trace by running task with --trace)

解決策

結論は一番下に記載。
まずは試したことから。

解決先として一番解説されているのが、
mySQLの確認。

コマンドで立ち上げる。

サーバー
sudo service mysqld start

これでもダメで、変に作成されていないか
下記記事でリセットを試したが、これでも解決せず。

https://qiita.com/potterqaz/items/ea6db5c5be2be389c0bb

散々エラー文と、なぜ起こっているかを確認して
やはり
「設定がおかしいから」というのは間違いないようなので
再度、database.yamlのファイルを見直して間違いを発見!!

結論

database.yaml
  username: root
  password: <%= ENV['DATABASE_PASSWORD'] %>
  socket: /var/lib/mysql/mysql.sock

この3行を編集したが、
編集をした項目を間違えていた。
default: &defaultをいじってしまっていたため
production:の方をしっかりと修正。

gitで編集前の記述も拾ってこれたので
再度修正し、無事にDB作成ができました!

以前はエラーにならなかったので
今回は新しい学びが多かったです。

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

[AWS]git pull origin master

勘違いしていたため、メモ書き。

gitと連動させたので、自動で連携しているのかと思ったら
しっかりとサーバー側でもマスターを読み込む必要があるそうでした><

[ec2-user@ip-●●● <リポジトリ名>] git pull origin master

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

[AWS]よくあるミス →Usage: rails new APP_PATH [options]

状況

サーバー
#DBを作成
[ec2-user@ip-●●●●●● ~]$ rails db:create RAILS_ENV=production

その結果、以下が表示。

サーバー
Usage:
  rails new APP_PATH [options]

Options:
      [--skip-namespace], [--no-skip-namespace]            # Skip namespace (affects only isolated applications)
  -r, [--ruby=PATH]                                        # Path to the Ruby binary of your choice
                                                           # Default: /home/ec2-user/.rbenv/versions/2.5.1/bin/ruby
  -m, [--template=TEMPLATE]                                # Path to some application template (can be a filesystem path or URL)
  -d, [--database=DATABASE]                                # Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
                                                           # Default: sqlite3
      [--skip-yarn], [--no-skip-yarn]                      # Don't use Yarn for managing JavaScript dependencies
      [--skip-gemfile], [--no-skip-gemfile]                # Don't create a Gemfile
  -G, [--skip-git], [--no-skip-git]                        # Skip .gitignore file
      [--skip-keeps], [--no-skip-keeps]                    # Skip source control .keep files
  -M, [--skip-action-mailer], [--no-skip-action-mailer]    # Skip Action Mailer files
  -O, [--skip-active-record], [--no-skip-active-record]    # Skip Active Record files
      [--skip-active-storage], [--no-skip-active-storage]  # Skip Active Storage files
  -P, [--skip-puma], [--no-skip-puma]                      # Skip Puma related files
  -C, [--skip-action-cable], [--no-skip-action-cable]      # Skip Action Cable files
  -S, [--skip-sprockets], [--no-skip-sprockets]            # Skip Sprockets files
      [--skip-spring], [--no-skip-spring]                  # Don't install Spring application preloader
      [--skip-listen], [--no-skip-listen]                  # Don't generate configuration that depends on the listen gem
      [--skip-coffee], [--no-skip-coffee]                  # Don't use CoffeeScript
  -J, [--skip-javascript], [--no-skip-javascript]          # Skip JavaScript files
      [--skip-turbolinks], [--no-skip-turbolinks]          # Skip turbolinks gem
  -T, [--skip-test], [--no-skip-test]                      # Skip test files
      [--skip-system-test], [--no-skip-system-test]        # Skip system test files
      [--skip-bootsnap], [--no-skip-bootsnap]              # Skip bootsnap gem
      [--dev], [--no-dev]                                  # Setup the application with Gemfile pointing to your Rails checkout
      [--edge], [--no-edge]                                # Setup the application with Gemfile pointing to Rails repository
      [--rc=RC]                                            # Path to file containing extra configuration options for rails command
      [--no-rc], [--no-no-rc]                              # Skip loading of extra configuration options from .railsrc file
      [--api], [--no-api]                                  # Preconfigure smaller stack for API only apps
  -B, [--skip-bundle], [--no-skip-bundle]                  # Don't run bundle install
      [--webpack=WEBPACK]                                  # Preconfigure for app-like JavaScript with Webpack (options: react/vue/angular/elm/stimulus)

Runtime options:
  -f, [--force]                    # Overwrite files that already exist
  -p, [--pretend], [--no-pretend]  # Run but do not make any changes
  -q, [--quiet], [--no-quiet]      # Suppress status output
  -s, [--skip], [--no-skip]        # Skip files that already exist

Rails options:
  -h, [--help], [--no-help]        # Show this help message and quit
  -v, [--version], [--no-version]  # Show Rails version number and quit

Description:
    The 'rails new' command creates a new Rails application with a default
    directory structure and configuration at the path you specify.

    You can specify extra command-line arguments to be used every time
    'rails new' runs in the .railsrc configuration file in your home directory.

    Note that the arguments specified in the .railsrc file don't affect the
    defaults values shown above in this help message.

Example:
    rails new ~/Code/Ruby/weblog

    This generates a skeletal Rails installation in ~/Code/Ruby/weblog.

何だ何だと思って調べたりいじったりしていたが、
結果、下記で解決。

サーバー
cd  /var/www/アプリ名

結論

アプリのあるフォルダに移動できていなっかっただけ

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

【個人的メモ】AWS関連でよく使うコマンドまとめ

強制的にgitで上書きしたいとき

$ git fetch origin master
$ git reset --hard origin/master

インスタンスの再起動したら・・・

MySQLの再起動

[username|app_name]$ sudo service mysqld start

Nginxの起動

[username|app_name]$ sudo service nginx start

Unicornの起動

[username|root]$ unicorn_rails -c /var/www/rails/app_name/config/unicorn.conf.rb -D -E production
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

SageMakerでセッションタイムアウトせずに学習を実行する方法

トラブル内容

SageMakerのjupyter Notebookで数時間くらい必要な処理を行う場合、12hでセッション切れになってしまい、セルの出力が消えてしまう。

解決策

基本的にスクリプトにしてから実行するしかない。

通常のノートブック内で
!python xxxx.py >> log.txt
のように実行してもいいが、任意のconda環境を利用したい場合は下記のようにactivateできる。

sh-4.2$ conda info --envs
# conda environments:
#
base                     /home/ec2-user/anaconda3
JupyterSystemEnv      *  /home/ec2-user/anaconda3/envs/JupyterSystemEnv
R                        /home/ec2-user/anaconda3/envs/R
amazonei_mxnet_p27       /home/ec2-user/anaconda3/envs/amazonei_mxnet_p27
amazonei_mxnet_p36       /home/ec2-user/anaconda3/envs/amazonei_mxnet_p36
amazonei_tensorflow_p27     /home/ec2-user/anaconda3/envs/amazonei_tensorflow_p27
amazonei_tensorflow_p36     /home/ec2-user/anaconda3/envs/amazonei_tensorflow_p36
chainer_p27              /home/ec2-user/anaconda3/envs/chainer_p27
chainer_p36              /home/ec2-user/anaconda3/envs/chainer_p36
mxnet_p27                /home/ec2-user/anaconda3/envs/mxnet_p27
mxnet_p36                /home/ec2-user/anaconda3/envs/mxnet_p36
python2                  /home/ec2-user/anaconda3/envs/python2
python3                  /home/ec2-user/anaconda3/envs/python3
pytorch_p27              /home/ec2-user/anaconda3/envs/pytorch_p27
pytorch_p36              /home/ec2-user/anaconda3/envs/pytorch_p36
tensorflow_p27           /home/ec2-user/anaconda3/envs/tensorflow_p27
tensorflow_p36           /home/ec2-user/anaconda3/envs/tensorflow_p36

sh-4.2$ source /home/ec2-user/anaconda3/bin/activate pytorch_p36
(pytorch_p36) sh-4.2$ 

これでjupyterlabのターミナルから任意の環境を利用できる。

参考

AWS Developer Forums: Jupyter Notebook Session Expiring after ...

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

AWS StepFunctinsで大きめのデータを並列処理する話

TL;DR

  • AWS StepFunctionsを使うと、外部連携が安心してできていい感じ。
  • AWS StepFunctionsは動的並列処理というものができ、入力された配列を並列で処理できる。
  • ただし、入力が32KBを超えると落ちるので大きいデータはS3を経由して処理することが推奨されている
  • そうすると並列処理したいはずの配列が入力に渡されなくなるので、やりたかった並列処理ができない。
  • なので、32KBごとにS3にJSONを突っ込んで、JSONファイルのARNの配列を並列処理に渡し、さらにそのARNからデータの配列を作り、ネストした並列処理で1行ずつ実行すればOK!

ユースケース

Google Calendar連携のInitial full syncを例にする。
やりたいことは、予定の全取得と、次回以降に利用するsync_token(Etagみたいなもの)を取得・永続化すること。

手順

  • [1] 引数で受け取ったアカウントの認証情報、対象のカレンダーIDから、本日以降の全予定とsync_tokenを取得する。
  • [2] 取得した予定を自分のアプリのDBに永続化する。
  • [3] 全ての予定が永続化されたら、最初に取得したsync_tokenを永続化する。
  • [4] sync_tokenが永続化されたら、channelを作成して以降の変更をリッスンする。

懸念点

  • [1] で取得したデータが多く、時間がかかる
  • [2]が失敗したのにも関わらず[3]に進んでしまうと、予定の取りこぼしが発生する
  • [3]が失敗すると次回も大量データ処理を行う必要が生じて非効率

AWS StepFunctions

https://aws.amazon.com/jp/step-functions

AWS StepFunctionsを使うと、上記のような手順をLambdaベースで簡単に作ることができるうえ、
エラーの捕捉やリトライが簡単なのでこういうユースケースにはハマると思う。

素直にやった場合の構成

stepfunctions_graph.png

こういう感じになる。

定義JSON(参考)
{
  "StartAt": "doQueryGoogleCalendar",
  "States": {
    "doQueryGoogleCalendar": {
      "Type": "Task",
      "Resource": ***,
      "Next": "putGoogleCalendarEventParallel",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "putGoogleCalendarEventParallel": {
      "Type": "Map",
      "ItemsPath": "$.events",
      "ResultPath": "$.events",
      "Next": "postGoogleCalendarSyncToken",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ],
      "Iterator": {
        "StartAt": "putGoogleCalendarEvent",
        "States": {
          "putGoogleCalendarEvent": {
            "Type": "Task",
            "Resource": ***,
            "End": true
          }
        }
      }
    },
    "postGoogleCalendarSyncToken": {
      "Type": "Task",
      "Resource": ***,
      "Next": "kickGoogleSync",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "kickGoogleSync": {
      "Type": "Task",
      "Resource": ***,
      "End": true,
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "onGoogleSyncFail": {
      "Type": "Task",
      "Resource": ***,
      "Next": "FailState"
    },
    "FailState": {
      "Type": "Fail"
    }
  }
}

ポイントとしては、
"Type": "Map"のステートを使って、doQueryGoogleCalendarの返り値のevents配列の要素ごとに動的並列処理を行う
というところ。

疑似的に書くとこんな感じ。

doQueryGoogleCalendar(input).then(({events})=>Promise.all(events.map(event=>putGoogleCalendarEvent(event))))

課題:32KB制限

StepFunctionで受け渡しする入力・出力は32KBを超すことができない。
ここで、doQueryGoogleCalendarの返り値が32KB以上あった場合、並列処理に入る際に落ちてしまう。
公式では、S3に一度データを格納し、データそのものの代わりにS3のARNを入力に渡すことが推奨されている。
https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/avoid-exec-failures.html

ただし、"Type":"Map"StepFunctionsの入力を対象に並列処理を行うため、
S3にデータを格納してしまった時点で並列処理の恩恵が受けられない。

ネストする

stepfunctions_graph (1).png

ということで、こんな感じにしてみた。

右側のルートが従来のケースで、左側のルートが32KBを超えた場合のルート。

定義JSON(参考)
{
  "StartAt": "doQueryGoogleCalendar",
  "States": {
    "doQueryGoogleCalendar": {
      "Type": "Task",
      "Resource": ***,
      "Next": "choiceParallel",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "choiceParallel": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.parallel",
          "StringEquals": "s3",
          "Next": "parallelizeS3Parallel"
        }
      ],
      "Default": "putGoogleCalendarEventParallel"
    },
    "parallelizeS3Parallel": {
      "Type": "Map",
      "ItemsPath": "$.events",
      "ResultPath": null,
      "Next": "postGoogleCalendarSyncToken",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ],
      "Iterator": {
        "StartAt": "parallelizeS3",
        "States": {
          "parallelizeS3": {
            "Type": "Task",
            "Resource": ***,
            "Next": "putGoogleCalendarEventParallelNested"
          },
          "putGoogleCalendarEventParallelNested": {
            "Type": "Map",
            "ItemsPath": "$.events",
            "ResultPath": null,
            "End": true,
            "Iterator": {
              "StartAt": "putGoogleCalendarEventNested",
              "States": {
                "putGoogleCalendarEventNested": {
                  "Type": "Task",
                  "Resource": ***,
                  "End": true
                }
              }
            }
          }
        }
      }
    },
    "putGoogleCalendarEventParallel": {
      "Type": "Map",
      "ItemsPath": "$.events",
      "ResultPath": null,
      "Next": "postGoogleCalendarSyncToken",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ],
      "Iterator": {
        "StartAt": "putGoogleCalendarEvent",
        "States": {
          "putGoogleCalendarEvent": {
            "Type": "Task",
            "Resource": ***,
            "End": true
          }
        }
      }
    },
    "postGoogleCalendarSyncToken": {
      "Type": "Task",
      "Resource": ***,
      "Next": "kickGoogleSync",
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "kickGoogleSync": {
      "Type": "Task",
      "Resource": ***,
      "End": true,
      "Catch": [
        {
          "ErrorEquals": [
            "States.ALL"
          ],
          "Next": "onGoogleSyncFail",
          "ResultPath": "$.error"
        }
      ]
    },
    "onGoogleSyncFail": {
      "Type": "Task",
      "Resource": ***,
      "Next": "FailState"
    },
    "FailState": {
      "Type": "Fail"
    }
  }
}

やっていることを解説すると以下のようになる。

  • doQueryGoogleCalendarは、取得したデータが32KB以上だったなら、32KBごとにデータを分割してJSON化してS3にアップし、S3のARNを配列にして次のステートに渡す。
    その際、parallelModeみたいな属性を次のステートに渡しておき、inputモードとS3モードを後続が区別できるようにする。
  • choiceParallelステートは、受け取ったparallelModeinputS3かで後続を決定する。
  • inputだった場合は従来通り、入力を直接並列処理に渡して処理する。
  • S3だった場合、まずARNの配列を並列処理に回し、ARNからJSONを取得、取得したデータの配列をさらに子の並列処理に渡して、最終的にはデータ配列要素分の処理を実行する。(2重ネスト)
  • 並列処理の結果は後続処理には不要なので、ResultPath: nullを指定する。これをやらないと、並列処理完了後に32KB制限にかかってしまう。
  • 予定データの並列処理完了後の動きはinput / S3で共通。

S3のパターンを疑似的に表現するとこんな感じになる。

doQueryGoogleCalendar(input).then(({jsonArns})=>Promise.all(jsonArns.map(jsonArn)=>(paralellizeS3(jsonArn).then(events=>events.map(event=>Promise.all(putGoogleCalendarEvent(event))))

構成のメリット

  • putGoogleCalendarEventpostGoogleCalendarSyncTokenなど、コアな部分の処理は同じものを使いまわせる。
  • 並列なので処理時間が短くなる。

まとめ

  • AWS StepFunctionsを使うと、外部連携が安心してできていい感じ。
  • AWS StepFunctionsは動的並列処理というものができ、入力された配列を並列で処理できる。
  • ただし、入力が32KBを超えると落ちるので大きいデータはS3を経由して処理することが推奨されている
  • そうすると並列処理したいはずの配列が入力に渡されなくなるので、やりたかった並列処理ができない。
  • なので、32KBごとにS3にJSONを突っ込んで、JSONファイルのARNの配列を並列処理に渡し、さらにそのARNからデータの配列を作り、ネストした並列処理で1行ずつ実行すればOK!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

はじめてAWSを使うときにやる設定

はじめてAWSを使うときにやる設定

AWSではじめてハンズオンをする前に、やった方が良い設定をUdemy様から学びましたのでまとめてみました。

周りにAWSを教えてくれる人がいたり、業務で使用している人は当然の内容かと思いますがご容赦ください。

はじめにやることは、IAM(Identity and Access Management)のダッシュボードを開いて、セキュリティステータスの項目を上から実施することです。

1.png

:balloon:IAMは、AWSのマネジメントコンソールから「IAM」と検索してください。

ルートアカウントのMFAを有効化

MFA = Multi-Factor Authentication = 多要素認証

ルートアカウントのセキュリティを高めるために実施します。

設定すると、ルートユーザでログインする際、従来のパスワード入力に加え、
別デバイス(スマホ等)で生成する確認コードが必要にとなります。

2.png

その後、表示されるQRコードをデバイス側の認証ツールで読み取ります。

デバイスでの認証ツールとして、私はGoogle Authenticatorを利用させていただきました。

IAMグループとIAMユーザの作成

今後、セキュリティの観点からrootユーザではなく、ここで作成するIAMユーザを使用します。
そのためのユーザとグループを作成していきます。


IAMユーザの作成


まずはユーザを作成します。
左ペインの「ユーザ」を選択しユーザを追加していきます。

画面に従い作成していきます。
なお、ユーザには「AdministratorAccess」を付与します。

3.png
4.png

タグは設定してもしなくてもOK。


IAMグループの作成


続いてグループを設定します。
左ペインの「グループ」を選択しユーザを追加していきます。

ユーザ同様、作成するグループには「AdministratorAccess」を付与します。

5.png

グループの作成が完了したら、ユーザを追加してあげます。

7.png

最後に、アカウントにエイリアスを設定します。
:cherry_blossom:初期状態だと数字と英語の羅列ですのでログイン時に不便です。

8.png

課金対策

rootユーザは基本的には使用しませんので、IAMユーザで「請求情報」にアクセスできるようにします。
rootユーザで画面右上の「マイアカウント」を選択します。

10.png

あとは以下画面の感じで設定していきます。

11.png

これで作成したIAMユーザで請求情報にアクセスすることができます。
以降、以下2つのアラームを設定していきます。


無料枠超過防止アラート


無料枠が超える前に指定したメールアドレスにアラートを送信する設定を行います。

13.png

下記画面のように、無料請求枠を超える前にアラートが飛ぶように設定をします。

14.png

リソースの過使用防止アラーム


AWSリソースをモニタリングしてしきい値を超えた場合にアラームを飛ばす設定を行います。
サービスの検索から「CloudWatch」と入力します。

15.png

左ペインの「請求」から「アラームの作成」を行なっていきます。
左ペインの請求を選択すると、リージョンを「バージニア北部」に選択するよう言われので、その場合は言われた通りにします。

16.png

800円をしきい値として設定します。

17.png
18.png

設定したアラームの名前と、送付先のメールアドレスを入力します。
その後「トピックの作成」を選択すると登録したアドレス宛にメールが送付されてきますので、
確認して「次へ」を選択します。

20.png

最後に、アラームの名前と内容の確認を行えば完了となります。
東京リージョンに戻るのをお忘れなく!!

終わりに

他にも証跡対応(ユーザ操作の記憶)も行った方が良いみたいです。
現時点でS3の課金が怖くて設定していません。

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

AWS 利用方法メモ(S3)

書いてあること

  • S3の利用方法メモ

S3の利用場面

バケット作成

  1. S3
  2. バケットを作成
  3. 必要事項を入力
  4. バケットを作成

ファイルを公開

パブリックアクセスを許可してオブジェクトURLで画像を参照する

  1. S3
  2. バケットを選択
  3. アクセス管理
  4. 編集
  5. パブリックアクセスをすべてブロックのチェックを外す
  6. 保存
  7. 公開するファイルを選択
  8. アクション
  9. 公開する
  10. 公開する
  11. オブジェクトURLでファイルが参照できることを確認

バージョン管理

  1. S3
  2. バケットを選択
  3. プロパティ
  4. バージョニング
  5. バージョニングの有効化を選択
  6. 保存

レプリケーション

レプリケーション機能を有効化する前にバケットにアップロードされたファイルは自動では同期されない。
別途AWS CLIなどでコピーを行う必要がある。

  1. S3
  2. バケットを作成する
  3. 必要事項を入力
  4. 東京以外のリージョンを選択
  5. バケットを作成
  6. レプリケーション元のバケットを選択
  7. 管理
  8. レプリケーション
  9. 今すぐ始める
  10. バージョニングの有効化
  11. 次へ
  12. 送信先バケットを選択
  13. バージョニングの有効化
  14. レプリケートされたオブジェクト用の・・・をチェック
  15. Glacierを選択
  16. 次へ
  17. 新しいロールを作成を選択
  18. ロール名を入力
  19. 次へ
  20. 保存する
  21. レプリケーション前にアップロードされたファイルを下記コマンドでコピー
bash
# バケット一覧を取得
$ aws s3 ls

# バケットのファイルをコピー
$ aws s3 cp --recursive s3://コピー元バケット名 s3://コピー先バケット名

# コピーでエラーとなる場合はこちらを実行
$ set tz=jst

静的ウェブホスティング

  1. S3
  2. バケットを選択
  3. プロパティ
  4. Static website hosting
  5. このバケットを使用して・・・を選択
  6. 必要事項を入力
  7. 保存
  8. Static website hostingに表示されたエンドポイントを確認
  9. アクセス権限
  10. ブロックパブリックアクセス
  11. 編集
  12. パブリックアクセスをすべてブロックのチェックを外す
  13. 保存
  14. 確認
  15. バケットポリシー
  16. 下記バケットポリシーを貼り付けて保存(●●●はバケット名に置換)
  17. 保存
  18. index.htmlをアップロード
  19. ブラウザでエンドポイントを表示
バケットポリシー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForGetBucketObjects",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::●●●/*"
        }
    ]
}

ライフサイクル管理

  1. S3
  2. バケットを選択
  3. 管理
  4. インベントリ
  5. 新規追加
  6. 必要事項を入力
  7. 保存
  8. ライフサイクル
  9. ライフサイクルルールの追加
  10. 必要事項を入力
  11. バケット内のすべてのオブジェクトに適用を選択
  12. 次へ
  13. 現行バージョンをチェック
  14. 移行を追加する
  15. 標準-IAへの移行の期限 30日Glacierへの移行の期限 60日を選択
  16. 以前のバージョンをチェック
  17. 移行を追加する
  18. 標準-IAへの移行の期限 30日Glacierへの移行の期限 60日を選択
  19. 次へ
  20. 不完全なマルチパートアップロードをクリーンアップするをチェック
  21. 次へ
  22. 保存

EC2からS3ファイルを取得

  1. S3
  2. バケットを選択
  3. htmlファイルをアップロード
  4. EC2
  5. インスタンスを起動
  6. アクション
  7. インスタンスの設定
  8. IAMロールの割り当て/置換
  9. ロールを選択
  10. 適用
  11. 閉じる
  12. SSH接続してApacheをインストール
  13. htmlファイルのバケット名、キーを確認
  14. 下記コマンドでS3からファイルを取得
bash
# バケット一覧を取得
$ aws s3 ls

# htmlファイルがないことを確認
$ ls -l /var/www/html

# S3からファイルをコピー
$ aws s3 cp s3://バケット名/キー /var/www/html
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS Certificate Manager(ACM)でSSL証明書の発行

目的

個人アプリでssl化が必要だったためSSL証明書の発行が求められた。
筆者の備忘録

前提条件

AWS、ALB(Application Load Balancer)、ec2、を活用します。
開発環境 rails

ssl化までの手順

Route53でドメインを購入(有料です) 
AWS Certificate Manager(ACM)でSSL証明書の発行 <=今回はここ
ロードバランサーでALBにhttpsの設定を入れて作成
Route53でAレコードのエイリアスを作成

AWS Certificate Manager(ACM)でSSL証明書の発行

AWSのサービスからCertificate Managerを選択
証明書のリクエストをクリック
aws2.png

パブリック証明書のリクエストを選択し証明書のリクエスト
aws3.png

ドメイン名を記入し、次へ
aws4.png

検証方法の選択
今回は、前回でドメインを購入したのでDNSの検証を選択
aws5.png

タグと値は必要ならば記入。
確定とリクエスト

今回のポイント 検証保留中

検証保留中は、発行されない!
証明書を検証して承認するには、追加のアクションが必要。
つまり、自分で手を動かさないとSSLを発行されない。

発行されるまでの手順

・route53でドメインを購入(aws)を購入していればroute53で登録とでる。
・手動の場合route53では、紐付けたいドメインを選択、レコードを作成し、名前と値を入れると良い。
aws8.png

あとは、発行と待つだけです。

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