CircleCIでSAMをデプロイする

概要

業務でSAMを使って、Lambdaの管理を行っていますが、CI/CDの設定ができておらず、手動でデプロイしています。
READMEに手順は書いていますが、「手順がかけているなら自動化だろう!」ということで、デプロイ設定を行っていきます。

準備

アプリケーション

SAMアプリケーションを作成します。
SAMをホストマシンに入れ、下記を実行します。

$ sam init

言語は何でもOKです。自分はGoを選択しました。

AWS

AWSではCircleCI用にユーザを作成します。
ユーザには必要な機能が操作できるように、権限を与えてください。

  • IAM
  • S3
  • CloudFormation
  • Lambda
  • APIGateway

CircleCI

デプロイはCircleCIで行っていきます。
社内ではEnterprise版を使っているため、バージョンは2.0で記載していきます。
※2.1だとOrbsが使えるので、もうちょっと楽できそうな気はします。

ContextにAWSユーザを設定

aws-cliを使うため、ユーザ情報を設定する必要があります。
直接ユーザ情報を書くと漏洩してしまうので、CircleCIのContextにユーザ情報を記載します。
(FYI コンテキストの使用 - CircleCI)

必要な値は下記です。 リージョン以外は事前に作った値で大丈夫です。

設定を記載

CircleCIの設定を記載していきます。
awscliとaws-sam-cliをインストールするため、Pythonのイメージを使います。

今回はmasterブランチをトリガーにします。
対象のブランチ or タグは、適時設定でOKです。

version: 2

jobs:
  deploy:
    docker:
      - image: circleci/golang:1.13
    working_directory: ~/ディレクトリ
    steps:
      - run:
          name: Install awscli
          command: |
            sudo apt-get update && sudo apt-get install -y awscli
      - checkout
      - run:
          name: build
          command: make build
      - run: aws cloudformation package --template-file template.yaml --output-template-file packaged.yaml --s3-bucket バケット名
      - run: aws cloudformation deploy --template-file packaged.yaml --stack-name スタック名 --capabilities CAPABILITY_IAM

workflows:
  version: 2
  default:
    jobs:
      - deploy:
          context: 設定したcontext
          filters:
            branches:
              only: master

これで準備OKです。 あとはmasterへのマージを行えば、CircleCIが動いてデプロイが走ります。

躓いたこと

S3のバケットがないと怒られる

CircleCIでデプロイを実行したところ、下記のエラーがでました…。

S3 Bucket does not exist.

IAMで権限は付与しているので、作成もやってくれるかと思いましたが、バケットの作成はやってくれないようですね…。

CloudFormationのスタックが更新できない

一度デプロイに失敗したので、再度実行したところ下記のエラーがでました…。

Error: Failed to create changeset for the stack: スタック名, An error occurred (ValidationError) when calling the CreateChangeSet operation: **** is in ROLLBACK_COMPLETE state and can not be updated.

CloudFormationは最初のデプロイで失敗したときは更新できないので、一度削除してから対応する必要があります。
(FYI AWS SAMを使う前にCloudFormationテンプレートを書こう - Qiita)

CloudFormationで経験していましたが、忘れてしまっていました。
SAM自体もCloudFormationのテンプレートを作るので、ここらへんの挙動は同じみたいですね。

ビルドを忘れていた

当たり前ですが、Goのコードはビルドをする必要があります。
普段はNode.jsを使っているため、失念していました…。

最後に

いかがでしょうか?
これから対応する人の参考になれば幸いです。

参考

Object-Oriented Conference #ooc_2020

概要

まさかの2週連続カンファレンス参戦。
前回の参加記録はこちら。

juve534.hatenablog.com

先週のPHPerKaigi2020に続いたカンファレンスは、Object-Oriented Conferenceになりました。
今まではPHPの名を冠するカンファレンスに参加していたので、PHPがタイトルについていない初のカンファレンス参加になりました。

なかなか難しい話が多かったですが、実りあるカンファレンスでした。

セッション

今回は1つ1つのセッションが重厚だったと思いました。
下記に参加したのですが、どれも頭をかなり使うので、あまりツイートする余裕はなかったです…。

どれも重厚で、その場で理解するのは難しかったので、あとから振り返ろうと思います。
個人的には増田さんの話を聴き、PHP以外の言語でも、業務で使えるレベルにしたいと思いました。

その他

今回はスポンサーブースをぐるっと回ってみました。
知っている会社も知らない会社もあり、それぞれ業務の話が聴けたのは良かったです。
人見知りするため、今までカンファレンスでスポンサーブースは回ってきませんでしたが、こうやって回ってみると良いなと思いました。

SOLID原則のステッカー
SOLID原則のステッカー

GMOのブースでは、SOLID原則のステッカーを配っていました。
1人1つ投票ができましたので、自分はOCPに投票しました。
PHPerKaigi2018の後藤さんのセッションで、初めてSOLID原則を知ったためです。

スタンプラリー後の抽選で、GMOタンブラーをGETできました。
会社で使ってみようと思います。

GMOタンブラー
タンブラー

最後に

カンファレンスとしては初めてということで、硬い雰囲気だったなという印象です。
トイレが少ない(女子大だしね…)と気になるところはありましたが、全ホール中継も起こっており、全体的にGREATで楽しかったです。

スタッフ・スピーカーの皆様、お疲れ様でした。

PHPerKaigi2020に参加しました #phperkaigi

概要

juve534.hatenablog.com

juve534.hatenablog.com

3年連続の参加です。
今回は滑り込みでCfPしましたが通らず、サポーターで参加しました。
1年目が一般、2年目がスピーカーだったので、サポーターで名札の色を全制覇しにいきました。

結果から言うとジョーカーという枠があり、全制覇はなりませんでしたとさ…。

イベント全体

会を重ねても、参加者が楽しめること・コミュニケーションを取りやすいことを重視しているなという印象です。

名札にTwitterアイコンを印刷してくれるので、声をかけてもらえることが多かったですし、他の勉強会でも使えるので便利ですね。

茶会と懇親会と2回交流イベントがあることで、色々な人と交流できるのが良いですね。
本当は懇親会は参加する予定はなかったですが、運も見方したことで参加することになりました。 東口さん、めもりーさん、k1LoWさん、のりこさんに感謝です。

そして、今年はやはりトレカですね。

juve534トレカ
juve534トレカ

まさか自分のアイコンがトレカになるとは思いませんでした笑
このトレカが名刺代わりになり、トークが弾んだりしていて良いなと思いました。 長谷川さんの発想とまつぴーさんのデザインは素晴らしいですね!

セッション

今回は印象に残ったのは、下記の4つのセッションでした。

  • 知らないWebアプリケーションの開発に途中からJOINしたとき、どこから切り込むか?
  • Zend VMにおける例外の実装
  • マスターデータの管理運用と実装について
  • PHPとEventSauceで始めるイベントソーシングアプリケーションを聴く

特にk1LoWさんの話は良かったですね。
自分たちも、新しい人が入るときの導入コストを感じており、参考になる部分がありました。

nさんとは、発表後に茶会で話すことができ、インフラ構成の変更が途中で入ると辛いという話をしました。
自分たちもそれでキューの導入を悩んだ経験があり、最初のうちからイベントソーシングを検討しておきたいと思いました。

まとめ

今回も素晴らしいカンファレンスでした。 スタッフ・スポンサー・スピーカーの皆様、ありがとうございました!!

シェルでDBからデータを取得する

概要

普段はPHPを使って、DBからデータを取得しています。
通常はそれで問題ないですが、PHPだとサーバに入れる必要があります。

ちょっとしたデータを取る際に、いちいちサーバにPHPを入れるのが面倒だと感じました。
そこで、PHPを入れないでもDBからデータを取得できるように、シェルでスクリプトを書いてみます。 (CentOSならPythonも選択肢になりますが、Pythonはかけないので除外)

コード

#!/bin/bash

# DB定義
DB_HOST="host"
DB_USER="ユーザ名"
DB_PASS="パスワード"
DB_NAME="DB名"
MYSQL_COMMAND="/usr/bin/mysql"

# DBからデータを取得
QUERY="SELECT * FROM hoge WHERE hogehoge;"
ROWS=`${MYSQL_COMMAND} -N -u ${DB_USER} --password=${DB_PASS} -h ${DB_HOST} ${DB_NAME} -e "${QUERY}" 2>&1`
IS_QUERY_SUCCESS=`echo "$ROWS" | grep "ERROR"`
if [ -n "$IS_QUERY_SUCCESS" ]; then
    echo "Failed to getChatHistory\n"
    echo "$ROWS"
fi

# csv形式で格納
echo "$ROWS" | tr '\t' ','

これでざっくりデータをとってきて、csv形式の吐き出しは完了。
ちょっとしたデータを引っ張るなら、これくらいで良いかなと思いますが、エラーキャッチとか出来ていなそうだし、DB周りの情報はベタだし…、ちゃんと使うのは微妙なコードですね^^;

Cookpad Tech Kitchen #23 Live・動画配信の開発最新事情に行ってきた #cookpad_tech_kitchen

概要

金沢の同僚から勉強会の存在を教えてもらったので、 19卒のメンバーと一緒に行ってきました。

発表

Android cookpadLiveの開発改善

内容

Androidについての話がメインなので、あんまりついていけず…。
とりあえず、メモを箇条書きで。

QA

Q.
VIPERからMVVMへの変更にはどれくらいの期間かかりましたか?
VIPERはCleanArchtecture + MVPなアーキテクチャだったと思いますが、MVVMに変えた時にどのくらい修正量あったのか気になります。
A.
1ヶ月くらいコツコツやった。
UIが大幅に変わるタイミングでガツッと変えた。
修正量は20くらい。
テストはしっかり目でやった。

Q.
cookpad LIVE: なぜ初めにVIPERを選択されていたのですか?
A.
iOSストアを視野にVIPERにしていた
詳細不明
iOSとAndroidで設計を統一しようとしたため

Q.
cookpad LIVE: multi moduleにする際にfeaturesはどのような単位で切られているのですか?
A.
機能がまとまった単位で作成する
1画面だと分けすぎ

アーカイブ配信でもライブ感を味わいたい

内容

メインイベントの1つ。
LCのリプレイスでも、コメントを保存する仕組みが必要になるため。

  • アーカイブコメントとLive配信への影響の切り離し
  • Fluentd → S3 → SQS → Lambda → DynamoDB
    • オーソドックスなイベントソーシング?
  • Fluentd を選んだわけ
    • ECS は負荷によってオートスケール
    • Fluentd はサイドカーにいるので、一緒に増える
    • オートスケールで負荷が増える可能性ありだけど、そういうやり方でカバーか
  • レビューはGoogleのDesign Doc?で行う
    • フォーマットを統一することで、レビュー観点を抑える

QA

Q.
Design docで運用してみての感想を聞きたいです
A.
開発をすすめるときに、レビューを素早くできる。
※思想が素早くできるため
開発後の最終型を、みんなでイメージしやすい

Q.
アーカイブコメントと映像の時間同期について詳しく!
A.
HLSの送信時間をベースに、クライアントから送信してもらっている?
ライブ配信で中断した時間を、アーカイブで削除することがある。
その際は、地道な制御でカバー

cookpadLiveのLive配信基盤

内容

動画配信基盤を AWSのマネージドサービスですべて作る

  • media services!
    • MediaLive→MediaStore→CloudFront→Media Talior
  • アーカイブ配信は MediaConvert を噛ます
  • S3にHLSのファイル?を置いて、それをコンバーターで変換ってことか
  • マネージドサービスを使うとリソースは無限にみえるけど、有限で不要なコストを出しちゃう
  • 予約?とかでリソースプーリング

QA

Q.
CMAF対応の展望、遅延
A.
10秒ごと?にファイルを分けている
CMAF対応
料理の代替え等が話が出るので、遅延を早くしたい
→CMAFもAWSのマネージドサービスでできる

ここから storeLive におけるスーパーでアプリを動かし続けるためにやったこと

内容

スーパーで大型サイネージ(Android)を動かす

  • 単純に動画は流すだけじゃなく、途中で動画を切り替え、元の再生位置に戻す必要がある
    • Room + LiveDataで実現。
    • Android のDBにデータを入れて、オフライン再生を頑張る
  • エンジニアが端末状態をログから追うのはしんどい
    • AWS IOTで解決する
    • 端末から10分に一回状態を送る
    • 端末→AWS IOT→ :KinesisDataFirehose: → Lambda

QA

Q.
IoTで、端末ごとの認証などはやっていますか?
A.
アプリをキッキングするとき、端末に証明書を作り、それを使う

所感

CookPad Liveは子会社で人数は少ないということですが、CookPadという大企業の恩恵は受けていると思いました。

というのが全社的な方針で決まっているらしいです。

またSQSだったか忘れてしまいましたが、特定のAWSサービスを使い倒してフィードバックしているようでした。
※こうなりたい…

Design docの保守について伺ったところ、「ドキュメントは腐るので保守していない」とのことでした。
メンバーが少ないので、あまり過去を振り返る必要がないのも大きいとのこと。

Design docはその時の設計レビューで使うが主なようです。

懇親会でももさんに貴重なお話が聞けてよかったです。

Go言語を始めるときに色々入れる

概要

Go言語でなにか作る際に、色々準備をするのでメモを残します。

内容

go mod

最近のバージョンで、パッケージ管理が標準で装備されたようです。
※前は dep とか使っていた

標準のものを使うので、プロジェクトを始める際は初期化をします。

go mod init github.com/xxxxx

これでバージョン管理の準備はできたので、必要なパッケージを入れていきます。

lintチェック

Go言語は書きなれていないので、リンターチェックを充実させます。

$ go get -u golang.org/x/lint/golint
$ go get golang.org/x/tools/cmd/goimports

ひとまずはこれだけ入れます。
あとは、プロジェクトに合わせ、必要なパッケージをインストールしていきます。

参考

pecoでGitのブランチを手軽にお掃除

概要

GitHub上ではプルリクエストを出したときに、ブランチを削除するようにしていたが、ローカルは毎回削除していなかった。

そうすると、ローカルにブランチが溜まってしまい、一々削除するのが面倒になっていた。

前回はpecoを使って、Gitリポジトリを移動したが、今回はGitのブランチを掃除する。

juve534.hatenablog.com

コマンド

削除コマンドは d でも D でも可です。

git branch -d $(git branch | peco)

こうすると動的にブランチを検索して消すことができます。
ブランチが溜まって、どれを消したらよいか迷っている人は、ぜひ使ってみてください。