GCP

discord の有名な reminder-bot がスケジュールリマインダー(特定の曜日に通知みたいなもの)に対応していなかったので、 自分で作成しました。今回は簡単にできるけど融通が効かないものと、面倒だけど融通が効くものを紹介していきます。 Cloud Scheduler + Cloud Workflow 完結に言うと、定期的に webhook するだけです。多分無料枠で納まります。 本来は Cloud Schduler から discord に直接送信したかったのですが、なぜか 400 エラーになってしまうので、Cloud Workflow 経由で実行しました。 作成手順 1. まず、discord 上でウェブフックを作成し、作成された URL を取得します。 2. workflow の作成 workflow は cloud console からの作成が容易なので、簡単なものならそちらで作成するのもいいと思います。コンソール上で以下のような workflow を作成します。 - postDiscord: call: http.post args: url: 先程発行したdiscordのwebhook url body: { "content": "メッセージは届いていますか？" } headers: Content-Typ: payload_json content に入れたメッセージが実際にチャンネルに投稿される内容になります。body の内容次第ではよりリッチなメッセージを送ることも可能です。 参考 workflow を作成したら実際に実行してみると、メッセージが届くことが確認できると思います。 3. cloud scheduler の設定 こちらのドキュメントに沿ってやっています。 リンクが死ぬ可能性もあるので、やった手順を一応載せときます。 gcloud iam service-accounts create bot-shedular # PROJECT_NAME を置換して下さい gcloud projects add-iam-policy-binding PROJECT_NAME \ --member serviceAccount:bot-shedular@PROJECT_NAME....

モチベーション pubsub トリガーの cloud function は非同期にリクエストを投げるため、同期的な API と比べ自動テストを行なうのが困難です(成功失敗のレスポンスが帰ってこないため)。 また、今回僕が作成した function は特に gcp 上でテストを行ないたいものだったため、この問題を真剣に考える必要がありました。 pubsub のリクエストの確認 まず、テストを導入するにあたって、テストで topic を push するさいの方法を確認します。 以下のような形で topic の push をします。 $ gcloud pubsub topics publish sample-topic messageIds: - '2134505983662900' 上記のようにレスポンスで返ってくるのは message の ID のみです。 この情報からどのように cloud function の成功失敗を取ってくるかが肝になります。 cloud function に渡される情報 次に cloud function を見ていきます。cloud function で実行される関数は以下のようなものです。 type pubSubMessage struct { Data []byte `json:"data"` } func ExampleFunction(ctx context.Context, m pubSubMessage) error { // 処理... return nil } この ctx から metadata 関数を使用することで、EventID を取得することができます。 これが先程の messageIds の値と一致します。...

なぜ絞り込む必要があるか PR Times の RSS は一日 300 件近くニュースが飛んできます。これを普通の RSS リーダに登録すると PR Times で全て埋まります。テロです。 実際 slack に登録してみたところ、1 時間おきとかに、通知が 10 件飛んできて、とてもじゃないけど見る気になりませんでした。この中から絞り込んで欲しい情報だけの RSS にしたいというのが今回の目標です。 他の絞り込みツール こちらの記事が参考になります。この記事を読んでわかることは、PR Times やばいです。 実際にこの記事のツールを試してみましたが、PR Times がやばすぎて、zapier の上限に達したりとなかなか上手くいかなかったです。 Cloud Function で絞り込む そこで最後の手段の自作です。 流れとしては以下のような流れで絞り込みを行ないます。 今回は Go 言語の、RSS をパースするツールの mmcdole/gofeed と RSS を作成する gorilla/feedsを使用しています。 コードの全体はこんな感じ package rssfilter import ( "context" "log" "net/http" "regexp" "time" "github.com/gorilla/feeds" "github.com/mmcdole/gofeed" "github.com/pkg/errors" ) const feedURL = "https://prtimes.jp/index.rdf" var searchText = regexp.MustCompile(`Cloud|cloud|クラウド|IOT|DX|テクノロジー|GCP|Google`) func FilterRss(w http.ResponseWriter, r *http.Request) { if err := filterRss(w, r); err !...

はじめに 現在（2020 年 9 月 14 日） cloud run には Identity-Aware Proxy(以後 IAP)が google cloud の機能として追加されていません。IAP を使いたいけど使えない、cloud run を使っている人なら一度は思ったことがあるはずです。 しかし、先日 pomerium というオープンソースの IAP プロバイダーを使い cloud run で IAP を使う記事が公開されました。試してみて思ったより詰まったので、知見として記事を書いて行きます。 Pomerium とは Pomerium is an identity-aware proxy that enables secure access to internal applications. Pomerium provides a standardized interface to add access control to applications regardless of whether the application itself has authorization or authentication baked-in. Pomerium gateways both internal and external requests, and can be used in situations where you’d typically reach for a VPN....

目標 grpc 使用時に、zap の出力結果が stackdriver logging でまとまるようにしていきます。 cloud run での出力条件 Cloud run の標準出力はデフォルトで logging にエクスポートされます。しかし、特定の出力は特殊フィールドとみなされます。まずは、その特殊フィールドを見ていきます。 公式ドキュメントには以下のように記載されています。 When the Logging agent receives a structured log record, it treats the following fields specially, allowing you to set specific fields in the LogEntry object that get written to the Logging API. つまり、jsonなどで出力された際に、特定の名前のフィールドが特殊フィールドと扱われることが分かります。 一個ずつ特殊フィールドを見ても公式をなぞるだけなので、今回目指したい出力を以下に記します。 { "severity": "ログの重要度(例：DEBUG)", "message": "ログメッセージ", "time": "ログのタイムスタンプ", "logging.googleapis.com/trace": "トレースID(例：projects/[PROJECT-ID]/traces/[V])", "logging.googleapis.com/spanId": "同一トレース内のスパンID(例：000ddfff3)" } 上記のようなフィールドが特殊フィールドとみなされ、標準で出力されるリクエストのログに対してまとまってくれます。それではこれを目指して行きます。logging.googleapis.com/trace_sampled はopencensusなどのtraceライブラリの設定が必要なので、今回はやりません。 zap で出力する zap の設定 上記のように出力するために、zap の設定は以下のようにしました。今回はプラグインなどを使わず自力で実装しています。...

背景 cloud run + nuxtjs でサイトを作ってみたので、普段業務で使っている appengine と比較して感じたことなどを書いて行きます。 ※この記事は書かれてから 1 年以上経っているため、当時の気持ちぐらいに取らえてください。 公式の見解は？ そもそも公式ドキュメントでは、どのように使い分けるよう書いてあるか見ていきます。 この記事を書いている段階では、こちらの公式ドキュメントにサーバーレスの選択について書いてあります。ぱっと見分かりやすいのが下の図ですね。 こちらを見る限りは、単純（少数）な api なら cloud function。複雑（複数）な api やアプリケーションなら基本的に appengine を使っておいて、cloud run は言語などが対応していない時の appengine の代替案かなという印象を受けます。 flexible 環境は論点にも上がらない感じですね。 使用しての個人的な比較 それでは実際に使用してみての比較について書いていきます。個人的な感想なので、使っていない anthos 周りについては書いてありません。 build & deploy サーバーレスアプリケーションにおいて、ci & cd でどのようにサーバに反映されるかはかなり重要だと思うのでまずはここから。 最初に cloud build の公式サンプルを見ていきます。 appengine の build & deploy steps: - name: "gcr.io/cloud-builders/gcloud" args: ["app", "deploy"] timeout: "1600s" github の push でトリガーされて、これで deploy 完了というのはほれぼれしますねー。 個人的な難点としては appengine のデプロイルールに縛られることだと思います。app.yml の設定、依存関係の解決、ディレクトリ構造。。。少し凝ったことをすると意外とハマりやすい印象です。 はまればすごい楽というイメージです。 cloud run の build & deploy steps: # Build the container image - name: "gcr....