【Ruby】【6回目】Kawasaki.rb #042 に参加しました
まさかの1年3ヶ月の参加です。
Rubyから離れっぱなしなので、ちょっと気持ちを切り替える意味で参加してきました。
概要
内容
以下のページで素晴らしくまとまっているので一読必須です。
Togetter
まとめ
感想
今回、応募が15人という自分が去年参加していたころより
多くなっており、川崎Ruby会議をやった効果なのかな？と思いました。
また、地域コミュニティらしいフレンドリーな感じは健在で
1年ちょっとのブランクがあっても場に溶け込むことができました。
そして、いつも通り自己紹介から始まり、パーフェクトRuby読書会をやり
最後に発表ということをやりました。
※20分ぐらい話していたと思います。
自分が1つ発表したのが以下のものです。
Ruby勉強会なのに、Rubyのことではない過ちを犯していますが
その辺は主催者の寛大な心遣いに感謝です。
そのおかげで無事に発表して、Serverlessの1つの事例を共有できたと思っています。
懇親会
前は、ミューザ川崎の飲食店だったのですが
最近はその周辺の中華屋さんになっておいました。
安くて美味しい老舗な店でとても良かったです。
リピートする理由がわかりました。
そして、ダムの話が熱かったです。
宣伝
調度良い人数と雰囲気で、毎月開催しています。
とても参加しやすいので是非参加しましょう！
次回は年末年始なので開催日時が変則的になるようですが
今年の締めに参加してみてはどうでしょうか？
そして、参加する際は以下の本を持っていきましょう。
【AWS】スマートフォンを機種変更するとき、2段階認証（MFA）を解除し忘れたので解除依頼をした
はじめに
先日、満を持してiPhone7 SIMフリーに機種変更をしました。
そして、個人で使っているAWSアカウントはセキュリティ強化のため
2段階認証（以下、MFA）設定していました。
しかし、前の機種でMFAを解除し忘れたため
AWSコンソールにログインできなくなってしまいました。
今回はMFA解除するまでの話を書きます。
前提条件
解除方法
まず、ルートアカウントでログインするところまでは同じで
以下の箇所をクリックします。
次に以下の画面が表示されるので、囲っている箇所をクリックします。
お問い合わせフォームが表示されるので、以下のように記入していきます。
そして、送信します。
10 〜 15分待っていると電話がかかってきます。
もし、電話番号を間違っていた場合、メールが送られてきます。
最初の電話は英語なので、英語が喋れる人はそのまま解除の手続きを
すれば良いですが、筆者はまったく英語が喋れない状態です。
なので、相手がある程度喋りきった後にこちらから
「I can't speak english.」ということを伝えました。
そうすると、相手は日本からの問い合わせということを知っているので
すぐさま「日本のオペレーターに繋ぐから待っていてくれ」という旨のことを話します。
英語がわからなくても「Japanese operator」という単語が聞こえれば問題ないです。
翌日、14時過ぎに日本のオペレーターから電話があり、無事に解除することができました。
平日昼間の対応のみなので、人によってはかなり都合が悪い状況なので
1日待機してないといけないかもしれません。
まとめ
「英語を聞ける喋れるようになりましょう」というのが正直なところですが
英語がまったくできなくても解除はできるので、もし同じような状況になった人に対して
少しで参考になってもらえればと思います。
【Serverless】はじめてのServerless Framework v.1 rc1 その２
はじめに
前回に引き続き、Serverless Frameworkを使った開発をしていきます。
【Serverless】はじめてのServerless Framework v.1 rc1 その１ - FujiYasuの日記
アーキテクチャ図
Cloudcraftというサービスを使い書いてみました。
https://cloudcraft.co/view/5d16ea58-14e0-439b-a8eb-18c047e9f39a?key=wIxzJw5VW44YEquqe4O7Sw
※今回は、ServerlessなのでAPI GatewayとAWS Lambdaの話がメインです。
環境
- OS X El capitan
- nodebrew 0.9.6
- Serverless v.1 rc1
前提条件
- 前回の記事まで読み進んでいる人
やってみた
はじめに
前回までのAPIは、URLがわかってしまうと誰でもAPIを叩いてしまうことができ
セキュリティ的に良くない状況となってしまいます。
また、API GatewayはAPIを実行された分だけお金がかかるので
いたずらにやられてしまうと大きな金額の請求がきてしまいます。
API Keyの作成
ここでは、API Keyを発行します。 GUIからでも作れますが、AWS CLIからKeyを発行するします。
aws apigateway create-api-key --name 'dev-my-first-serverless-rc1' --description 'Used for development' --enabled --region ap-northeast-1
serverless.ymlを編集
Keyが作成されたので、API Keyの名前をServerless側で記述します。 さらにAPIをAPI Keyを指定するため、event単位で「private: true」を設定します。
provider: name: aws apiKeys: - dev-my-first-serverless-rc1 functions: hello: handler: handler.hello events: - http: path: handler/hello method: get private: true
ドキュメントは、以下のページです。
デプロイ
ここまで設定したら、後はデプロイするだけです。
[0:00:46] Y_Fujikawa:my-first-serverless-rc1 $ serverless deploy -v erverless: Packaging service... Serverless: Removing old service versions... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading service .zip file to S3... Serverless: Updating Stack... Serverless: Checking Stack update progress... CloudFormation - UPDATE_IN_PROGRESS - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - InsertLambdaFunction CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - HelloLambdaFunction CloudFormation - UPDATE_COMPLETE - AWS::Lambda::Function - InsertLambdaFunction CloudFormation - UPDATE_COMPLETE - AWS::Lambda::Function - HelloLambdaFunction CloudFormation - CREATE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474902440291 CloudFormation - CREATE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474902440291 CloudFormation - CREATE_COMPLETE - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474902440291 CloudFormation - UPDATE_COMPLETE_CLEANUP_IN_PROGRESS - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474902169689 CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474902169689 CloudFormation - UPDATE_COMPLETE - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev Serverless: Stack update finished... Service Information service: my-first-serverless-rc1 stage: dev region: ap-northeast-1 endpoints: GET - https://xxxx.execute-api.ap-northeast-1.amazonaws.com/dev/handler/hello functions: my-first-serverless-dev-hello: arn:aws:lambda:ap-northeast-1:201892032205:function:my-first-serverless-rc-1dev-hello
動作確認
Endpointsも書かれているので、Curlコマンドを叩けばすぐ確認できます。
[0:03:27] Y_Fujikawa:my-first-serverless-rc1 $ curl https://xxxx.execute-api.ap-northeast-1.amazonaws.com/dev/handler/hello
{"message": "Forbidden"}%
[0:05:49] Y_Fujikawa:my-first-serverless-rc1 $ curl -H "x-api-key: <作成したAPI Key>" https://xxxx.execute-api.ap-northeast-1.amazonaws.com/dev/handler/hello
{"message":"Go Serverless v1.0! Your function executed successfully!"}
まとめ
今回はAPI Keyの発行をAWS CLIから実行しましたが、Serverlessからでもできそうな感じがあります。
それでも、わざわざGUIから設定せずスムーズに作業をできるのはいいですね。
【Serverless】はじめてのServerless Framework v.1 rc1 その１
はじめに
先日、実践Serverlessの勉強会レポートを書きました。
そして、ちょうど良く業務でもサーバーレスでやってみる？という
話にもなったので、技術調査も兼ねてプライベートで触ってみました。
なお、今回はバックエンドではなく
フロントエンド寄りの構成の話となります。
今回は、Serverless Frameworkを使って効率的に開発できるか試してみます。
アーキテクチャ図
Cloudcraftというサービスを使い書いてみました。
https://cloudcraft.co/view/5d16ea58-14e0-439b-a8eb-18c047e9f39a?key=wIxzJw5VW44YEquqe4O7Sw
※今回は、ServerlessなのでAPI GatewayとAWS Lambdaの話がメインです。
環境
- OS X El capitan
- nodebrew 0.9.6
- Serverless v.1 rc1
前提条件
- Serverless Frameworkを触ったことない人
- AWSコンソールにログインできる
やってみた
インストールとプロジェクト作成
クイックスタートに書かれているように1 〜 5をやります。
Step 4に
serverless create --template aws-nodejs --path my-service
とありますが、nodejsで作られるようになっていますが
ServerlessはPython、Java8にも対応しているのでお好みで大丈夫です。
今回はそのままNode.jsを使います。
また、今回はプロジェクト名を「my-first-serverless-rc1」としました。
作られたものを確認
自動でプロジェクトの雛形が作られ、そのままデプロイできますが
それぞれのファイルを確認していきます。
・serverless.yml
API Gateway, Lambda, IAMに関する設定をまとめて管理するファイル。
デフォルトが東京リージョンでないため、注意。
また、そのままだとLambdaしか作られないため、API Gatewayも一緒に作る場合
以下の設定を追加します。
functions: hello: handler: handler.hello events: - http: path: handler/hello method: get
ドキュメントは、以下のページです。
・handler.js
AWS Lambdaでの「入り口」となる部分です。
自動生成した際は「Go Serverless v1.0! Your function executed successfully!」という
文字列が返却される状態となっています。
・event.json
ローカルテスト用のファイルだと思います。
あまり使う機会がなく、まだ詳しくないですがあっても問題ないです。
デプロイ
Step 6のコマンドでデプロイできますが、オプションをつけると経過がわかるのでオススメです。
[0:00:46] Y_Fujikawa:my-first-serverless-rc1 $ serverless deploy -v Serverless: Packaging service... Serverless: Removing old service versions... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading service .zip file to S3... Serverless: Updating Stack... Serverless: Checking Stack update progress... CloudFormation - UPDATE_IN_PROGRESS - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - HelloLambdaFunction CloudFormation - UPDATE_IN_PROGRESS - AWS::Lambda::Function - InsertLambdaFunction CloudFormation - UPDATE_COMPLETE - AWS::Lambda::Function - HelloLambdaFunction CloudFormation - UPDATE_COMPLETE - AWS::Lambda::Function - InsertLambdaFunction CloudFormation - CREATE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474556465062 CloudFormation - CREATE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474556465062 CloudFormation - CREATE_COMPLETE - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474556465062 CloudFormation - UPDATE_COMPLETE_CLEANUP_IN_PROGRESS - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474250545851 CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::Deployment - ApiGatewayDeployment1474250545851 CloudFormation - UPDATE_COMPLETE - AWS::CloudFormation::Stack - my-first-serverless-rc1-dev Serverless: Stack update finished... Service Information service: my-first-serverless-rc1 stage: dev region: ap-northeast-1 endpoints: GET - https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/handler/hello functions: my-first-serverless-rc1-dev-hello: arn:aws:lambda:ap-northeast-1:201892032205:function:my-first-serverless-rc1-dev-hello
動作確認
Endpointsも書かれているので、Curlコマンドを叩けばすぐ確認できます。
curl https://xxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/handler/hello
{"message": "Go Serverless v1.0! Your function executed successfully!"}
動作確認が済んだら、以下のコマンドを実行すればデプロイした内容が
すべて削除されてきれいになります。
serverless remove
注意
APIの認証をしていないため、APIのURLがわかってしまうと
いたずらにアクセスされる可能性があるため、認証キーを設定した方が良いです。
設定の仕方はまた次回に書きます。
まとめ
最初、便利だなぁと思っていたのですが
手動での設定が多すぎてとても大変な印象を受けましたが
すでに便利なフレームワークがあったことに驚きました。
もう少しいろいろ試してみて、便利さを実感していこうと思います。
【Linux】権限は問題ないのに「Permission denied」と出てコマンドが実行できない。
はじめに
業務で新サービスを立ち上げる際に、構成管理はプロビジョニングツールを使います。
最近はプロビジョニングツール職人（と言っても、難しいことはしていない）として
新サービスに携わっています。
そこで、ちょっとハマったところをメモします。
環境
- CentOS 6.8（プロビジョニング先のサーバー）
- itamae 1.9.9
前提条件
itamaeをホスト側で動作し、CentOSに接続できること。
詳細
itamaeでサクッと書きつつ、実行しました。
インストール系はうまく動作して問題なかったのですが
サービスの起動でエラーが発生してしまいました。
# 今回は、php-fpmが例です。 INFO : execute[/etc/init.d/php-fpm restart] executed will change from 'false' to 'true' ERROR : stdout | Stopping php-fpm: [60G[[0;31mFAILED[0;39m] ERROR : stdout | Starting php-fpm: [04-Aug-2016 11:35:59] ERROR: failed to open configuration file '/etc/php-fpm.d/default.conf': Permission denied (13) ERROR : stdout | [31-Jul-2016 11:35:59] ERROR: Unable to include /etc/php-fpm.d/default.conf from /etc/php-fpm.conf at line 11 ERROR : stdout | [31-Jul-2016 11:35:59] ERROR: failed to load configuration file '/etc/php-fpm.conf' ERROR : stdout | [31-Jul-2016 11:35:59] ERROR: FPM initialization failed ERROR : stdout | [60G[[0;31mFAILED[0;39m] ERROR : Command `sudo -H -u root -- /bin/sh -c cd\ \~root\ \;\ /etc/init.d/php-fpm\ restart` failed. (exit status: 1) ERROR : execute[/etc/init.d/php-fpm restart] Failed.
うーむ、なぜだろう。
実行権限、所有者、グループに間違いはないことは確認済みです。
解決策
調査したところ、SELinuxが悪さをしていたようです。
コマンドを叩いて現状を確認してみます。
$ getenforce Enforcing
SELinuxが有効のままでした。
そのため、Permissiveモードにしてみます。
$ setenforce 0 Permissive
変わっていたので、itamaeを再実行してみたところ正常に実行されました。
Linuxの知識が乏しいですが、SELinuxはよく邪魔者扱いされますが
実際OFFのままでもいいのでしょうか？難しいところです。
【レポート】「実践SERVERLESS」に参加しました。
はじめに
AWS Lambdaが出てからだいぶ経ちますが、プロダクションとしての実績も
チラホラ聞こえるようになり何かしら勉強会ないかな？と思っていたところに
調度良い勉強会があったため、参加しました。
最初は補欠でしたが、当日になり繰り上げ当選となったのは
ほんと運が良かったと思います。
後日、スライドが上がると思いますが、取り急ぎメモした内容を書きます。
セッション
Introducing Serverless Computing
Serverlessが使えるところや事例を聴くことができました。
活用するシステム一例
リアルタイムファイルプロセッシング
- イメージ変換（サムネイル作成）
- ドキュメントのメタデータのインデックス化
- ログの処理
- メディア・コンテンツのバリデーション
リアルタイムストリームプロセッシング
- ストリーム分析
- メトリクス作成
- インデクシング
Serverless Web and Mobile Application
下記のものを使うのが定番となっている。
新しいエコシステム
AlexaアプリとSlackを使い、ServerlessでのBotを実現できる。
AWS CloudTrailでログ管理
APIの呼び出しログを管理する「CloudTrail」と連携してログ監視を行える。
事例
海外
- VidRoll
- PlayOn! Sports
- easy ten
国内
Lambda と API Gateway の管理
サーバーレスの役割
- どこをサーバーレスにするか？
- いろんなところでできる。
- フロントエンド
- 通信データ取得や登録を行うところ
- バックエンド
- その他
管理方法の選定
管理ツールはたくさんある。 →ツールごとに観点が違う。
Lambda管理ツールを選ぶ4つのポイント
ツールの特徴
- API Gatewayの併用
- 対象は、API Gateway + Lambda、Lambdaのみの2パターン
- セットはフロントエンドを対象としているツールが多い
- Lambdaのみを対象としているツールは、汎用的に導入しやすい
他のリソース管理
観点は以下のとおり
- システムの規模の大きさによって変わってくる。
- 大きくなったら、分割するほうが良い。
- 小さい場合は、まとめた方が良い。
ロールバック
リリース時などに障害が起き、前の状態に戻したい場合がある。
その際に管理ツールでできるかどうか。
- 対応しているツールとしていないツールがある。
- 対応しているのは手早くロールバックできる。
使い回し
一度、作ったものはある程度汎用的の方が良い。
ただし、考えて作らないといけない。
- そのアーキテクトは他で使いまわせるか？
- 汎用性にする必要はあるか？
- 設定値は実行時パラメータを使うか？
- 環境変数は必要か？
管理ツール6種
今回は6種ですが、他にもたくさんあるとのこと。
- AWS Cloud Formation
- Serverless
- Apex
- Lambdaに特化
- Terraformと連携できる
- Gulp (node-aws-lambda)
- Swagger hub
- Swaggerのクラウドサービス
- IAMのポリシーも作ってくれるので便利
- Chalice (Beta)
- Flourish
- Serverless Confで発表されたもので、そろそろ出てくる？
まとめ
- 何を重要視するか？（フロントエンド全部か一部だけか）
- プロジェクトにあった、最適なものを選択すること
- まずは、触ってみてとのこと
実際に使う Cognito UserPools
すでに資料は公開されています。
cognito-userpools-in-production // Speaker Deck
Serverlessというと確かにLambdaだが、Cognito UserPoolsを使って
Serverlessのシステムを作成することができる。
デモで使用したサンプルは、以下のもの
※この辺は、自分にとって難しく「便利そう！」というぐらいしかわかりませんでした・・・
まとめ
事例や管理ツールについて詳しく聞けたのが良かったです。
欲を言うと運用方法（監視など）も聞ければ良かったなぁと思っています。
実際に運用されているシステムってどうやっているのでしょうか？気になります。
「Serverless Web and Mobile Application」であれば、比較的手軽に試せそうなので
いろいろ試して、ノウハウを蓄積していこうと思います。
【振り返り】業務で0からシステム構築をしてWebサービスをリリースした話
はじめに
つい最近の話になりますが、小さいWebサービスをリリースしました。
ほんとに小さなもので「これ、作ったんだぜ！」と大きな声で言えないため
細々と嬉しさを噛み締めつつ、1人振り返りしてツラツラ書きます。
これから何かしらリリースする人、リリースしたい人にとって
少しでも有益な情報となり、参考になってもらえればと思います。
チーム
若手が多かったので、それぞれアドバイザーがいましたが、
ディレクター、デザイナー、プログラマ、インフラ含めて
メインは7人ほどで対応していました。
自分はプログラマ側のリーダー的な立場でした。
インフラ
小さいサイトであり、かつ複雑なサイトではないため
「こんな感じでいいよね」という感じでスムーズに進みました。
サーバのランニングコストにもよりますが、最低限、冗長化をして
予期せぬアクセス増加を見据えた方が良いと思います。
なにより運用した際の安心感が違います。
また、同時にSTG環境の用意をしました。
テスト環境なので、そんなに高スペックでなくても良いですが
本番環境でいきなり試すこともできないので、なるべく本番環境と
同等のシステムを構築した方が良いです。
ミドルウェア
新卒から数年間、Javaをやっていましたが、恥ずかしながら
Apacheのメンテ経験は0に近く、実戦経験もなかったので
WebサーバはNginxとしてました。
DBはMySQLにしてレプリケーションを行い 障害に対しての対策を行いました。
アプリ
「小さいサイトなので、効率よく開発できるものを選ぼう」という
考えはあったものの「使いたい言語で開発をしよう！」という
考えもあったので、Ruby (Ruby on Rails)を選択しました。
インフラ（ミドルウェア）構築
過去の案件でAnsibleを使った、構築手順があったので
それを流用させてもらい、今回のシステムにあった形に
書き直しました。
過去に自分で勉強して内容を理解できるところまで
やっておいてよかったと実感した瞬間でした。
コーディング
フロントエンド
デザインが上がってくるまで時間があったため
機能的なところ（バリデーション、テーブル登録）を先に実装していきました。
Railsと便利なGemの数々を使い、レールから外れないようにして
実装をしてもらい、問題なく実装することができました。
後にデザインが上がってきて、デザインの取り込みをしていましたが
やはりリッチな動きとなるとJavascriptやちょっとしたデザイン崩れが発生します。
予期していたことなので、慌てずデザイナーの人に自分の席にきてもらい
対面で一緒に考えてもらいながら対応をしました。
そのおかげで、意思疎通もスムーズに行なえ対応できました。
バックエンド
フロントエンドで登録がある場合、必ずバックエンド（管理画面）が必要となります。
ただし、フルスクラッチで作っている余裕はなく、どうすれば良いか？と
考えていたのですが、2年ぐらい前から勉強がてら作っていたものを流用することにしました。
すでにVPSのサーバで動いているので、自分の中で実績は十分あったので
バックエンドの要件定義の話になった際、サンプルとして画面を見せて
すぐに合意を得ることができました。
ただ、バックエンドもやりたいことはたくさんありますが
期間が期間のた「め本当に必要な機能のみ実装する」ということを
ちゃんと合意を取った上で開発しました。
テスト
残念ながら、Rspecの経験がなく逆にコストが
かかりそうだったため、自動テストはなしとしました。
手で動かしても問題ない規模であったため、どうにかなりました。
リリース
新規サービスということもあり、本番環境は事前に構築しておき
IP制限を行い、社内からしか見れないようにしていました。
そのため、事前に構築→IP制限外して公開ということができたので
安心してリリースを行うことができました。
リリース後
リリースしてみて、気づくこともあり、またバグもあったので
リリース後対応として対応をしています。
ただ、致命的なバグというのはない（と思っている）はずなので
ホッとしています。
反省点
リリース延期ということがなくリリースできましたが
なんやかんやで残業が多かったのが残念なところでした。
ただ、自分が使ってみたい技術をすべて使えたので
100%悪い意味での残業ではなかったです。
次に「限られた期間内でこの規模なら大丈夫だろう」という
思いがあり、軽く見積りしただけで開始してしまいました。
間に合わなければ意味がなく、残業なんてしない方が良いはずで
「定業時間内でできる範囲を考える」というのを意識すれば
良かったと思いました。
上記の弊害として、当初、他の案件も見なければならなかったため
自分がこの案件に100%コミットする感じではありませんでした。
ただ、インフラ構築、バックエンドのコーディングもやらないと
いけなかったため、他のメンバーに迷惑をかけてしまいましたが
この案件に100%コミットすることになりました。
両立できるかな？と考えましたが、甘かったです。
良かった点
自分で勉強してきたことをフルに発揮できる内容であり
ある程度、実装イメージがついた状態で実装することが出来ました。
日々の勉強の賜物だなぁとつくづく思いました。
なお、勉強する内容も小難しいものではなく、単純に
Railsの基本的な開発方法、サーバへのデプロイをやってみたり
機能として、ユーザー登録、管理画面の作成をやっておいた方が良いです。
チームに関しては「チーム一丸となってやる！」ということを信念を持ち
ディレクター、デザイナー、インフラの方たちと接しました。
ベストなコミュニケーションだったかと言われると難しいところですが
結果的には予定通りリリースできたので、問題なかったと思います。
まとめ
今回初めて、自分1人でインフラ、ミドルウェア、アプリを構築したので
業務を通じて、とてもためになった内容でした。
また、短期間でここまでできたのは、日々の勉強の成果もあり
少しずつですが絶えず続けてきたことが実った業務でした。
まだ、大きなシステム構築する力がありませんが
小さいことを1つずつやっていき、かつ勉強も絶えず続けて
大きなことを成し遂げていければと考えています。
