App Engine VS Cloud Run
Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a
Cloud Datastoreのクエリでがんばるハナシ 2 〜 ライブラリ作った 〜 - Qiita
１週間前にCloud Datastoreのクエリでがんばるハナシという記事を書きましたが、そこで書いた各種テクニックをサポートするライブラリを作ったので紹介します。 XIAN 注意: 現時点でまだβ版(v0.1.0)です。正式版の前に後方互換のない修正が入る可能性があります モチベーション Search APIあまり使いたくない Datastoreクエリの不足する機能を補う為にSearch APIを併用するテクニックがあります。 Search APIはとても便利ですがいくつかの制限があり、何よりインデックスサイズに上限がある為スケーラビリティに難があります。 参照: GAEでハマったこと(´･ω･`) Search APIに出来るだけ頼らないことが本ライブラリの第一の目的です。 LIKEやINを使いたい Cloud DatastoreはLIKEやIN/OR条件のフィルタをサポートしません。
GAE 2nd-gen でのサービス間認証
TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため
Google App Engineでローカル開発をするときにdispatch.yamlをもとにReverse Proxyしてくれるツールを書いた - 時計を壊せ
これです github.com なぜ作ったのか dispatch.yaml や dispatch.xml はGoogle App Engine(以下GAE)のFrontendでルールベースでL7 HTTP Reverse Proxyしてくれるものです。 cloud.google.com これはMicroservicesをやる上では大変便利なものになっています。 一方で、これをローカルで動かす手段が少なくとも自分の知る限りはありませんでした。 なので、いままでは各サービスを連携して動作検証したいときは、GAEにデプロイしてしまうか、 あるいは各サービスをそれぞれ別々のポートで立ち上げながら、各サービスに何らかの方法でそれらのマッピング情報を入れてサービス間で連携が可能なようにするなど工夫をする必要がありました。 別々のポートで立ち上げるところまではよしとしても、めんどくさいのでその後の各サー
CloudBuildを利用してGAEへのデプロイを自動化 - Qiita
普段、GitLabを利用してソースの管理をすることが多いので、今まではGitLabCIを利用して色々CI/CD周りを作ることが多かったのですが、最近、GCPをメインで使っているので、CloudBuildで出来ないかなと言う事で実験して見ました。 今回、作成した構成は、以下の通りです。自分の為のメモ書きです。 構成図 GitLab->CloudSourceRepositories間の連携 下記記事を参考に設定しました。 https://qiita.com/tarosaiba/items/850042d6383ac5b7ef47 CloudBuildの設定 ここに関しては、UIに表示された通りに選択する事で基本的に詰まる事はありませんでした。 リポジトリの直下に専用のフォルダ(hogehoge)を作成してあったので、各コマンド実行時にcd してから実行しています。 gaeの古いバージョンを定期
GAE Go 1.11 ランタイムが公式には 2nd gen ではなくなった件について - Qiita
Google Cloud Platform(以下 GCP) におけるサーバーレスは Google Cloud Next '19 会期中の 2019年4月10日に Cloud Run が発表されたことで新たな局面を迎えました。その裏で、歴史ある App Engine の Go 1.11 ランタイムの説明が Google の公式な説明がないまま変化したことが GCP コミュニティを騒がせそうなので、経緯と共に私の理解を書いておきます。 なおこの記事では Flexible Environment と明記している部分を除き Standard Environment について書いています。また、 Java 8 ランタイムについても同様のことが起こっていますが、今回は Go ランタイムについて言及します。 TL;DR second generation(以下 2nd gen) ランタイムとしてリリース
Firestoreを本番で半年運用したアーキテクチャ：その① 〜Firestoreを中心に据えた全体設計のコンセプト〜 - Qiita
これは？ Firebase Meetup #10 で 「Firestore導入前に検討したかったベスト５」 というテーマで発表したのですが、 まさかのメインの話の部分を図2枚で済ますという荒業をしてしまったので、ちゃんと書き納めます。 (反省のツイート...→ https://twitter.com/pitown/status/1093141514186706944 ) そしてなんか、書きたいこと多くない？と気付いたので、3回くらいに分けました。 ①Firestoreを中心に据えた全体設計のコンセプト ←今回 ②PubSubとCloud Functionsを使って、FirestoreのCollectionをマイクロサービスに見立てた話 ③パフォーマンスの劣化対策として、CacheのCollectionを作った話 ちなみに、書き終えてから、初期構成の話しかしていないな、と思ったのですが、それ
GAE のログに憧れて – google-cloud-jp – Medium
Google App Engine (GAE) は GCP の他のサービスとの連携が豊富で非常に便利なのですが、その中でも個人的に好きな機能の一つに、Stackdriver Logging に出力されるログの見やすさがあります。 Logging from Google App EngineGAE のログは、上記画像のようにアクセスログとアプリケーションログを一箇所にグルーピングして表示してくれるので、両者のログを行ったり来たりする必要がありません。これは日々の開発や運用で非常に役に立ちます。 今回はこの GAE のようなログ表示に憧れて、他の GCP サービス(特に GKE)でも似たようなことを行えないか模索してみた結果をお話ししたいと思います。 TL;DR条件付きですが、GKE でも以下のようにログをグルーピングして表示することができました。 Logging from Google Ku
Google App Engine/Python で無料でAIサービスをホストする - Qiita
前書き 今更GAE/pかよ！ って感じですが、これがやっぱり良くできてるのですよ。 自分用に作ったAI論文検索ツールをGoogle App Engine/pythonでウェブサービス用にしてみたら結構さくっと動いてしまったので、またやる時のためにメモ書きとして残しておきます。 TL DR; Facebook fasttext を使ったディープラーニング論文の検索／クラスタリングツールをwebサービスにする手順。使ったものは fasttext, scikit-klearn, GAE/p, jinja2です。無料でまずはパパッと公開しようぜ！ ＞＞ サービスサイトはこちら。コードはgithubに。 AI系論文のサイトがとても使いにくいポンコツ ってこと、ありますよね。CVPR2018という画像処理のトップ学会があります。ディープラーニングブームを盛り上げて来た学会で、東京では毎年論文読み会が開
Nuxt.js on Google App Engine（GAE) - Qiita
Nuxt.js on GAE Nuxt.jsは、Vue.js向けのSSR用フレームワークで日本語ドキュメントも充実しており、SSRしないページでも開発するのには十分な機能をもっているといえる便利なものです。 Nuxt.js - 日本語公式ドキュメント また、GAEとはGoogle App Engineの略で、一言で言うならば PaaSです。スタンダード環境、フレキシブル環境と呼ばれる2種類の環境があり、スタンダード環境は無料枠で利用ができます。 Node.js がスタンダード環境で利用可能に スタンダード環境では、Java,Python, PHP, Go のみ利用が可能でしたが2018年6月12日にNode.jsがサポートされました。 Google App Engineがスタンダード環境でNode.jsをサポート。パッチ適用は自動、カスタムドメインでのHTTPSも利用可能 つまり、今までは
サーバサイドレンダリング for Google App Engine / Server Side Rendering for Google App Engine
https://gaeja.connpass.com/event/90133/
GAE/Node.js Standard Environmentでスピンアップからテキストが返るまでの速度をゆる〜く確認する - 文系プログラマによるTIPSブログ
appengineに待望のNode.js standard environmentが正式リリースされたので、早速計測してみました〜 前回のあらすじ 計測の仕方 環境 計測に使用したソースコード スピンアップしてフレームワークを初期化してテキストが返るまでの速度 計測1回目 計測2回目 計測3回目 計測4回目 計測5回目 結果と平均値まとめ 雑感 前回のあらすじ www.bunkei-programmer.net GAE/Javaは8になってもやはり初動が遅かったのだ。というかGAE/Java1.7とほとんど違いは無かったのだ。 www.bunkei-programmer.net GAE/Goは（javaと比較すると）くっそ速かったのだ。 そしてGAE/Node.jsが出たので計測してみたのだ。 計測の仕方 前回のGAE/Java8の時と同様に、インスタンスを削除して、必ずスピンアップが発生
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nouhau/README.md at feature/id/76 · gcpug/nouhau · GitHub
Nuxt.js v2とGAE/SE Node.jsでSPA×SSR×PWA×サーバーレスを実現する - DMM inside
Web Apps Articles & Tutorials — Google Cloud Platform
GCP Update June 2018
GAE FEのdeployストレスを軽減する10の方法
go.mercari.io/datastore はいいぞ！ / go.mercari.io/datastore is pretty good!
App Engine Scaling Config
Java 8 ランタイム以降のサンドボックスと gVisor
