くりにっき

フルスタックキュアエンジニアです

condo3と地域.rbカレンダーを作った

夏の進捗です。

condo3

condo3について

connpassやDoorkeeper のグループのイベント情報をiCalendarやAtomで取得するためのサイトです

https://condo3.appspot.com/

f:id:sue445:20190811162205p:plain

モチベーション

connpassやDoorkeeperで特定のグループ(コミュニティ)の勉強会をウォッチするのに現状だと開催通知のメールしかないのが不便という問題がありました。(個人的にはSlackでウォッチする手段がほしかった)

本当は公式でこの手の機能(グループ単位のフィード)を提供してほしかったんですが、connpassには(Doorkeeperだったかも?)過去に要望投げたものの特に音沙汰がなかったので結局自分で作りました。

ユースケース

  • AtomのURLをSlackの特定のチャンネルで /feed subscribe 〜 すれば新しいイベントが作られた時にSlackに通知される
  • iCalendarのURLをGoogleカレンダーに登録すれば自分のカレンダーに表示できる。

ここではSlackとGoogleカレンダーのみ取り上げていますが、AtomもiCalendarも汎用的な規格なのでこれらの形式に対応している他のツールと連携させることもできます。

技術的なこと

リポジトリ

github.com

余談ですが個人開発だとCloud KMS, TypeScript, webpack, Bulma辺りは初採用です

技術の選択理由

  • Google App Engine/Go
    • アプリの性質上無限にAPIを叩かれることが容易に想像できたので、Herokuはあまり使いたくなかった
      • Herokuはアカウント単位でDyno hour(インスタンス起動時間)の無料枠を使うため。(既にHerokuで個人アプリ10個以上動いてるのでリクエストがガンガンくるアプリは立てたくない)
    • 業務的な話になるけど今期の個人目標が「GCPのスキルをつける」だったのでせっかくだからappengineを使ってみるかってことに
      • appengineは昔使ってたことがあるので全然知らないわけではなかった
    • appengineではいくつか言語が選択できるけど、爆速でリクエストさばくにはGoが一番向いてた
  • フロントエンド
    • 自分の中ではReactかVue.jsの二択だったけど、APIがメインで画面はトップページしか必要なかったのでVue.jsを選択
      • Reactは大規模開発のイメージがあった。(異論は認める)
    • 型安全が好きなのでTypeScript選択
  • CSSフレームワーク
    • Bootstrap以外思いつかなかったので社のSlackで募集したうちの1つがBulma
    • 実際に社のSlackに投げた時のスクショが下記

f:id:sue445:20190811165356p:plain

開発時に苦労したこと

  • 8〜9年ぶりにGoogle App Engineを触ったので浦島太郎状態
  • 特にappengine/GoはGo 1.11(1st generation)と1.12(2nd generation)で作り方が全然違う *1 のを知らずに最新版って理由だけで1.12で作り始めたので、1.12のドキュメントも少なくググった時に1.11以前のドキュメントが出てきて動かなくてそこでハマってた
    • 2nd genだとローカル開発時に dev_appserver.py が不要になってたり、appengine本体にmemcachedが入ってないのが一番のハマりでした...
  • フロントエンド赤ちゃんの状態で雰囲気でVue.jsやTypeScriptを書いたのでハマりしかなかった

名前の由来

connpassの con とDoorkeeperの do を足してcondo3です。

末尾の3に関しては諸説ありますが語呂が良かった説が一番有力です。(他にもappengineで作った3つ目のwebアプリだったり、appengine/Javaで使ってたSlim3というフレームワークにあやかったという理由もある(今思いついた))

地域.rbカレンダー

condo3の副産物です。日本各地の地域.rb情報がひと目で分かるカレンダーです

https://sue445.github.io/regional-rb-calendar/

f:id:sue445:20190815120012p:plain

github.com

技術的なこと

condo3のiCalendarのURLをGoogleカレンダーにインポートして表示させただけ。

僕が見つけた地域.rbは全部登録したけど漏れがあると思うのでその場合は issue で教えてください。

メリット

  • 一度iCalendarのURLをGoogleカレンダーに登録してしまえばあとは勝手に最新の情報に追従され続けるのでメンテが楽

8/15 16:50追記

知らなかった...

開発時にソース内検索してrssatomが無かった気がしたんだけど今見たら普通に埋め込まれてた(つらい)

f:id:sue445:20190815165516p:plain

AWS Lambda CI/CD俺的ベストプラクティス

Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです

tl;dr;

  • ライブラリインストール時にmakeが走る言語(例:Ruby, Python, nodejsなど)の場合はServerless Framework使うのが楽
  • それ以外はServerless FrameworkかAWS SAMのどっちかならまず困らない

このエントリで書いていること

  • 自分が過去に試した手法
  • 逆に言えば自分がやったことないことは書いてないので誰かいい感じに紹介してほしいw

Lambdaをデプロイするのに肝になること

  • AWSAPIを実行するために必要なライブラリ(Rubyならaws-sdk gem)は実行環境に含まれているのでインストールする必要はないが、それ以外のライブラリを使いたい場合にはインストール済の状態でzipに固めてアップロードする
  • さらにライブラリインストール時にmakeが走る場合(Rubyのgemだとnative extensionと呼ばれるもの)、Lambdaと同じ実行環境(Amazon Linux)上でコンパイルをする必要がある。(以降、native extension問題と呼称)
    • ローカルのMacUbuntuとかで bundle install してzipに固めてデプロイするのは絶対ダメ
    • Rubyに限らずPythonとかでも同じことが言える
      • LambdaのPythonからMySQLdb(PythonMySQLを使うためのライブラリ)を使おうとするとAmazon Linuxでビルド済の mysqlclient.so もzipに含める必要がある
  • Lambdaを使いたい場合、大抵の場合Lambda以外のリソースも必要になるのでそれらを含めたデプロイを考える
    • 例えばLambdaでHTTPリクエストを受けたい場合にはAPI Gatewayが必要だし、cronみたいに定期実行させたい場合にはCloudWatchが必要だし、Lambdaでこれらのリソースを操作するにはIAMの権限を追加する必要がある
    • 純粋にLambda(とLambdaの実行しかできないIAMロール)だけで済むケースは見たことないです

デプロイしやすさに着眼したフレームワーク紹介

論外

コンソールからアップロードする

軽くお試し利用するくらいならコンソール上で直接編集してもいいんだけど、各種ライブラリを使いたい場合にはzipで固めてアップロードする必要があります。

問題点

  • Vim のような使い慣れたエディタが使えない
  • gitによる履歴管理できない
  • CIとの連携ができない
  • 手でzipを固めてアップロードするのは時代遅れ感
  • 冒頭で書いたように真面目にやるならEC2にAmazon Linuxインスタンスたててからインストールしてzipに固める必要があるので面倒
    • ライブラリを使わないんならそこまで気にしなくてもいいんだけど、一定規模以上のアプリ作る場合にはライブラリは必須だし、そのライブラリのインストール時にmakeが必要かを依存してるライブラリのその先の依存まで人間が全部気にかける必要はないと思ってます。(それはbundlerやnpmなどのパッケージマネージャの役割)

できなくはないがかなり厳しい

Terraform

www.terraform.io

AWS全般のオーケストレーションといえばTerraformが一番有名ですが、Lambdaのデプロイには向かないです

理由

  • Terraformだけだとライブラリのインストール込のzip圧縮ができない
    • ファイル名直打ちやディレクトリ丸ごと圧縮とかはできる *1
    • Terraform外でzipに固めてそれをTerraformに渡せばまあできないことはなさそうだけど、そこを自分で作り込むくらいなら他の出来るツールを使った方がいい
  • 仮にTerraformでzipを作った場合、zip上は差分が全くないのにTerraform上で差分が出ることがある
    • ローカルだと差分がないのにCIだと差分が出ることが割とよくある(その逆もよくある)
  • Terraform使えばAWSに関することはだいたいなんでもできるんだけど、AWSAPIをそのまま使うのとそんなに変わらないので記述が割と冗長になる
    • 後述のServerless FrameworkやSAM(実質Cloud Formation)の方が多少楽

Apex

メリット

デメリット

  • Lambdaの実行にLambda以外のものが必要な場合、結局Terraformが必要になる
    • Lambda実行用のIAMロールは自動で作ってくれるんだけど、それに新しくポリシーを追加したい時はTerraformにimportする必要がある
    • Apex自体はTerraform連携機能があるんだけど、最初からそれ用のディレクトリ構成にする必要があるので移行コストがある
    • 上でも書いたけどTerraformだと記述が冗長になりがち

8/12 17:20追記

リポジトリトップに

This software is no longer being maintainted and should not be chosen for new projects.

って書いてるので新規に採用しない方がよさそう。

実用レベル

Serverless Framework

メリット

  • Terraformに比べたらAWSAPIを意識しなくていい
  • プラグインが充実してる(後述)
  • Lambda以外のリソースも作れるので、Serverlessのリポジトリだけで完結する

デメリット

  • npmなので実行環境にnodejsが必要
  • デプロイにCloudFormationを利用してるので、デプロイ時にエラーになったらCloudFormationのjsonを読む必要があって大変

AWS SAM

native extension問題と戦う

Amazon LinuxのEC2インスタンス内でビルドする

AWS Lambda RubyでNative Extensionsを使用するgemを使うには?serverlessも使ってみた! - GA technologies Tech Blog に書かれているやり方

ただしこれだとCircleCIなどとの連携がやりづらいという欠点があります。(GitLab CIであれば自分でRunnerを立ててshell executorで動かせば使えないことはない)

Amazon Linux互換のDockerイメージを使う

  • https://hub.docker.com/r/lambci/lambda/
  • AWS公式ではないけど、活発にメンテされていて信用できる
  • LambdaのCIをしようとするとだいたいこのDockerイメージにいきつくくらいにはメジャー

昨今のCIサービスはDockerイメージを使うのがデファクトなので、 lambci/lambda を使うのがいいでしょう

ただし注意点として lambci/lambda のコンテナ内ではrootユーザではない&sudoもないので権限がだいぶ制限されてます。

Serverless Frameworkのプラグインを使う

Serverless Frameworkはプラグインが充実しています。その中にライブラリのインストール時に任意のDockerイメージからコンテナを起動して、コンテナ中でライブラリのインストールを行ってデプロイしてくれるプラグインがあります。

僕が把握しているのは下記です

これらを使えばCIで使うのも容易でしょう。

ただしCIが起動したDockerコンテナの上でさらに lambci/lambda のコンテナを起動する構図になるのでちょっと特殊な構成になります。

また、そのためにはDockerのprivilegedオプションを有効にしてdind(Docker in Docker)が必要になるので、CIサービスによってはセキュリティ的な観点で使えないケースもあるかもしれません。(GitLab CIであればprivilegedオプションを有効化したRunnerを自分で作れば可、CircleCIはやったことないので不明)

ライブラリをインストールするジョブとデプロイするジョブを分ける

AWS SAMのクライアントはnpmなので実行環境にnodejsが必要になります。

例えばSAMでデプロイするためにlambci/lambda 内でbundle installすることを考えると、もし1つのイメージで行おうとするとlambci/lambda 内にnodejsとRubyのランタイムをインストールする必要があるのですが、先に書いたようにlambci/lambda 内では権限が制限されているためインストールができません。*2

そのため、「ライブラリのインストールを行うジョブ」と「デプロイを行うジョブ」をわけて、それぞれのジョブで使うDockerイメージを別々にするのが現実的な解決方法だと思います。

CircleCIであれば persist_to_workspaceattach_workspace を使えば同一ワークフローの複数のジョブ間でファイルの受け渡しが可能です。

https://circleci.com/docs/2.0/configuration-reference/

もしCircleCIでRubyのアプリをSAMでデプロイしようとするなら

  1. lambci/lambda:ruby2.5 を使ったジョブでbundle installして persist_to_workspace する
    • ここでzip圧縮をしないのは lambci/lambda:ruby2.5 にはzipがインストールされていない&権限の関係でインストールもできないため
  2. 後続のジョブで attach_workspace してインストール済のライブラリを受け取り、zip圧縮してSAMでデプロイする

という構成になるでしょう。

Serverless Frameworkを使う場合に比べたらジョブを分ける必要があって若干手間ですが、個人的にはギリギリ許せる範囲かなと思っています。

【9/4 0:00追記】sam build --use-containerを使う

sam build--use-container があるという知り合い情報

docs.aws.amazon.com

If your functions depend on packages that have natively compiled dependencies, use this flag to build your function inside an AWS Lambda-like Docker container.

なるほどー

aws.amazon.com

If we include dependencies with native extensions, such as nokogiri, we want to make sure we’re building on an Amazon Linux-compatible image. With SAM CLI, you can do that in a single command as well.

トノコト

【2021/2/4 20:30追記】

Lambdaでコンテナ対応されたのでデフォルトのランタイムではなくコンテナを使うのがよさそうです。 *3

aws.amazon.com

native extension問題と無縁な言語

Go言語はクロスコンパイルに対応しているのでlinux_amd64でビルドしていればどの環境でビルドしてもLambdaで動くバイナリが作れて楽です。(Javaもnative extension問題と無縁だと思うけど自信ない)

この手の言語で開発するのであればServerless FrameworkとAWS SAMのどっちで作ったとしてもまず困ることはないと思います。

8/12 01:20追記

ブコメレス

id:asuka0801

Serverless Framework使うためだけにnodejs入れるのが嫌

ローカルでの話なのかCIでの話なのか分からないけど(まぁこのエントリではCIのことしか書いてないので後者と予想)、公式じゃないもののserverlessインストール済のDockerイメージもあるのでCIでnodejs入れる必要はないです。(公式じゃないから嫌とかDocker入れるのが嫌とかいうのはさすがに面倒見きれない)

https://hub.docker.com/r/amaysim/serverless

とはいえ amaysim/serverless だとdockerが入っていなくてdindができないので実際のところ docker:dind にnodejs入れてさらに npm ci が現実解だと思います。(社のserverlessリポジトリだとそうやってた。deployジョブの実行時間見たら諸々のインストールの時間含めて1分半前後)

2019/8/12 11:00追記

ブコメレス

id:esodov

そもそも例であげてるlambdaでmysqlって構成どうなのという気も。そこ主題じゃないか。

重箱の隅をつつくような指摘ありがとうございます。

一応補足しておくと、RDSやAuroraのMySQLの監視を行うスクリプトpythonで、そいつをLambdaで動かしていたのです。

8/12 17:20追記

id:YonmanHasse

Apexは"This software is no longer being maintainted and should not be chosen for new projects."なので挙げるにしてもそこを書いた方が

あー、元々は半年以上前に会社のesaに書いてたやつなので、社外向けに書き直した時にリンク先のリポジトリは見てなかったです。追記しました。

2020/9/18追記

Cloud Functions版はこちらをどうぞ

sue445.hatenablog.com

*1:https://www.terraform.io/docs/providers/archive/d/archive_file.html

*2:むっちゃ頑張ればできるかもしれないけど未確認

*3:追記時点で試していないので解決するかどうか断言はできないですが

go-doorkeeperを作った

github.com

go-doorkeeperについて

golangDoorkeeper API を利用するためのAPIクライアントです

最近golangでDoorkeeperのAPIを叩きたい需要が発生したんですが誰も作ってなさそうだったので作りました。*1

使い方

READMEからコピペ

package main

import (
    "github.com/sue445/go-doorkeeper"
    "os"
)

func main() {
    accessToken := os.Getenv("DOORKEEPER_ACCESS_TOKEN")
    if accessToken == "" {
        panic("DOORKEEPER_ACCESS_TOKEN is required")
    }

    client := doorkeeper.NewClient(accessToken)

    // List all featured events
    events, rateLimit, err := client.GetEvents(&doorkeeper.GetEventsParams{})
    // more options
    events, rateLimit, err := client.GetEvents(&doorkeeper.GetEventsParams{Query: "golang", Sort: doorkeeper.SortByPublishedAt()})

    // List a community's events
    groupName := "trbmeetup"
    events, rateLimit, err := client.GetGroupEvents(groupName, &doorkeeper.GetEventsParams{})

    // Show a specific event
    eventID := 28319
    event, rateLimit, err := client.GetEvent(eventID)
    // or
    event, rateLimit, err := client.GetEvent(eventID, doorkeeper.WithLocale("en"))

    // Show a specific group
    groupName := "trbmeetup"
    group, rateLimit, err := client.GetGroup(groupName)
    // or
    group, rateLimit, err := client.GetGroup(groupName, doorkeeper.WithLocale("en"))
}

*1:「doorkeeper api」でググると全く関係ない方のdoorkeeper gemしか見つからなかったのでそいつがノイズになって見つけられなかった説はある

プリッカソン8でえもいwebhookを作った #prickathon

prickathon.connpass.com

えもいwebhookとは?

emoji notify webhook、略してemoy(えもい)webhookです

何番煎じか分からないですがSlackにemojiが登録された時に通知するwebhookです

f:id:sue445:20190721224711p:plain

リポジトリ

github.com

技術的なこと

のいつもの感じです

特徴

  • emojiを1つ登録しただけなのにたまに2回webhookが飛んでくることがあるのですが、Slack通知はなるべく最初の1回だけになるようにしてます
    • memcachedで通知を5分間キャッシュしてるだけなので完全に同時にリクエストがくると無理
  • emojiのaliasも判別(冒頭のスクショ参照)
  • Deploy to Herokuボタンに対応してるのでHerokuのアカウントさえあれば1クリックでデプロイできます

f:id:sue445:20190721225132p:plain

スライド版

esa-pages.io

【追記あり】Docker Hubのrubyイメージで急にbundle installできなくなった時の対応

tl;dr;

export BUNDLE_PATH__SYSTEM=false をつける

あらすじ

会社で 今日のアニメボット を動かしているんですが、7/11夕方までは動いていたのに7/12分から急に動かなくなる現象になりました

エラー内容

+ bundle install --jobs=4 --retry=3 --path=vendor/bundle --gemfile=Gemfile --clean --without development
Using a custom path while using system gems is unsupported.

path:
Set for your local app (/usr/local/bundle/config): "vendor/bundle"

path.system:
Set via BUNDLE_PATH__SYSTEM: true

disable_shared_gems:
You have not configured a value for `disable_shared_gems`

コードの変更点は無いのでDocker Hubのイメージ( https://hub.docker.com/_/ruby/ruby:2.6-slim )に変更があったことはすぐに分かりました。

修正方法

環境変数

export BUNDLE_PATH__SYSTEM=false

をつければbundle installできるようになりました

CircleCIの場合

.circleci/config.yml に下記を追記

environment:
  BUNDLE_PATH__SYSTEM: "false"

GitLab CIの場合

.gitlab-ci.yml に下記を追記

variables:
  BUNDLE_PATH__SYSTEM: "false"

対応PR

github.com

追記:2019/7/13

BUNDLE_PATH__SYSTEM=true するやつがrevertされたので新しくimageをpullし直せば大丈夫そうに見える。(まあCIサーバだと自分でコントロールできないので BUNDLE_PATH__SYSTEM=false 固定でいいかもしれないけど)

github.com

Code Climate Test Reporter用のCircleCI Orbsを作った

https://circleci.com/orbs/registry/orb/sue445/codeclimate

github.com

経緯

自分のリポジトリ.circleci/config.yml にあった野良commandをコピペ運用するのが嫌だったというのと、既存のCode Climate系のOrbsを探した時にいいのがなかったのでOrb化しました

使い方

version: 2.1

orbs:
  codeclimate: sue445/codeclimate@x.y.z

jobs:
  test:
    environment:
      CC_TEST_REPORTER_ID: YOUR_CODE_CLIMATE_REPORTER_ID
  
    steps:
      - checkout
  
      - codeclimate/with-cc-test-reporter:
          after_build_args: "--coverage-input-type simplecov"
  
          steps:
            - run: bundle exec rspec

Orbでやってること

Code Climate Test Reporter を使う時は

  1. バイナリをダウンロード
  2. ./cc-test-reporter before-build を実行
  3. 任意のテストコマンドを実行
  4. ./cc-test-reporter after-build を実行

という流れなのですが、3以外の部分を codeclimate/with-cc-test-reporter の中に隠蔽しています。

小ネタ

commandのparameterの steps typeを使うとRubyでいうところのブロックを使ったサンドイッチメソッドのようなリファクタリングができて割と便利

https://github.com/sue445/circleci-orb-codeclimate/blob/0.1.0/src/commands/with-cc-test-reporter.yml#L4-L7