Cloud Run

モチベーション 絵文字を作成する際は、普段こちらで行なっているのですが、できるならコマンドで実行したいなとか、もっとランダム要素あった方が楽しいのにな、と思ったので自分で作成してみました。 作成物 今回はコマンドと api のどちらでも動くものが作りたかったため、Go 言語で作成しました。作成したものはこちらです。 どんな感じの挙動になるかをぱっと見たい方は、https://wordimg-otho5yxlgq-an.a.run.app/wordimg を叩くと分かりやすいと思います。以下で軽く使い方の説明をやっていきます。 Http README に書いてある URL に対してクエリとして text を設定するとその text に設定した文字が絵文字として生成されます。試しに以下の URL を叩いてみると分かりやすいと思います。 https://wordimg-otho5yxlgq-an.a.run.app/wordimg?text=helloworld アクセスするたびに違う画像が表示されるはずです。下の画像も見る人によって変わるはずです。この見る人によって変わる画像ってのが面白そうっていう気持ちだけで作成しました。 他にもいくつかクエリを用意したので、試しに色々試してもらえるといいかもです。 ちなみに特定の行に文字サイズを収めたい時は size=j${line} のように指定して下さい。size=j1 と指定すると 1 行に、size=j2 と指定すると 2 行に収まるように文字サイズが決定されます。 CLI こちらは結構癖があります。適当に go のお作法でインストールしたら、使えるといわけでもありません。 go get github.com/komem3/wordimg/cmd/wordimg 絵文字の生成にはフォントのデータが必要です。デフォルトでは go のライブラリの goregular という中に含まれているフォントデータを使用して絵文字の作成を行ないます。そのため、当然のように日本語なんか文字化けします。 絵文字は日本の文化のため、絵文字を作成する方は日本語を使いたい方が多いと思います。その場合、適当な日本語が含まれるフォントファイル(ttf) を用意して引数で指定してください。 $ wordimg -m "こんにちは世界" -f ./SawarabiGothic-Regular.ttf アルファベットしか含まない文字の場合はフォントを指定する必要がないので以下だけで問題なくいけます。 $ wordimg -m "hello world" ちなみに、こちらも 1 行とかで収めたい場合は、size に j1 などと指定すると、収まるように文字サイズが決定されます。 $ wordimg -m "hello world" --size j1 感想 Go で絵文字作るのすごい面倒でした。ドキュメント無いに等しくて手探りすぎて辛かったです。昔 php でやったことあったので、ちょろちょろってできるかなって思ったんですが、いやーさすが go って気持ちになりました。 いつもお世話になっているサイトにはまだまだ機能が及ばないので、もう少し機能性豊かにできたらいいなと思っています。...

はじめに 現在（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....