Cloud Run で Pull Request 毎の確認環境を作ろう
この記事は Google Cloud Advent Calendar 2023 (通常版) の 12/6 の記事です。 Cloud Run はコンテナ アプリをサーバーレス で実行するためのプロダクトですが、統合されている機能を利用せずに、単にアプリ基盤として利用するだけではもったいありません。今回は開発用途、また CI/CD を応用する例を考えてみたいと思います。 要約 ソースコード管理として GitHub を利用し、CI/CD 経由で Cloud Run へアプリをデプロイするフローを応用して、Pull Request 毎にアプリを確認できる URL を作成するフローを作ってみたいと思います。GitHub 以外でも可能ですが、今回の例では GitHub Actions を一部利用しています。 全体のアーキテクチャは以下のようになります。 サンプル コードはこちらにあります。 gclou
Google Cloud Serverless Product History
Google Cloud Champion Innovators Advent Calendar 2023 の6日目の記事です。 sinmetalから見たGoogle Cloud Serverless Productたちの歴史と現状を振り返ります。 リリース順 App Engine Standard Environment (2008年) App Engine Flexible Environment (2016年) Cloud Functions (2017年) Cloud Run (2018年) App Engine Standard Environment 最古のServerless Productで昔はServerlessという言葉は使われておらず、WebアプリケーションのためのPlatform as a Serviceと呼ばれていました。 Google Cloudより昔からあるた
完全マネージドな k8s ! GKE Autopilot を解説する
Kubernetes / GKE ファンの皆様こんにちわ。Google Cloud の Kazuu (かずー) です。GKE Autopilot が GA になりました。弊社公式ブログに続きまして、GKE Autopilot を日本語で解説していきたいと思います。 本記事は以下、3 部構成となります。 GKE Autopilot 概要GKE Autopilot を試してみるGKE Autopilot がハマりそうなユースケースは？ 1. GKE Autopilot 概要GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopil
Why Is The Google Cloud UI So Slow? | DebugBear
We can see that each page loads over 15 MB of JavaScript code. A look at the performance timeline in Chrome DevTools confirms that running this code is the primary cause of the poor page performance. This article will take a closer look at the page load process of the Google Cloud Functions page, and examine how it could be sped up. You can use these strategies to investigate and improve the perfo
お知らせ: Google Cloud の Buildpacks でコンテナ イメージ作成が簡単に | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 10 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。 新しいアプリケーションを構築する開発者が集中して取り組むべきなのは、コードの記述であって、コンテナ化ではありません。また、すでにコンテナを使用している開発者であれば、適切で安全なコンテナ イメージの作成がどれだけ複雑で時間のかかる作業かということをご存じでしょう。そこで本日、安全かつ本番環境ですぐに使えるコンテナ イメージを、Dockerfile がなくてもソースコードからすばやく簡単に作成できるオープンソースのテクノロジー、Buildpacks を Google Cloud 全体で幅広くサポートする体制が整いましたことをお知らせいたします。 このリリースの目玉は、なんといってもオープンソースの Buildpacks とビルダーです。CNCF の Buildpacks
gcloudコマンドで試すGCP Secret Manager - Qiita
Secret Managerは、GCP上でパスワードやAPIキーなどの秘密情報を安全に管理するためのサービスです。2020年3月にGAしました。 似たカテゴリのサービスであるCloud Key Management Service（KMS）は、秘密情報そのものではなく、それらを暗号化・複合するための鍵を管理します。 以前はKMSと独自の暗号化・複合ソリューション、その他BerglasやHashiCorp Vaultを利用していたケースの一部もSercert Manager単独で賄えるはずです。 概念 SecretとVersionという単位を理解する必要があります。 Secretは各プロジェクトのグローバルに作成されます。Secretに対しては削除、Versionの追加、ラベルの付与などの操作が可能です。 SecretはVersionを持ちます。個々のVersionは秘密情報や有効、無効、削
Spanner 向けのアジアとヨーロッパの新しいマルチリージョン構成 | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 8 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Spanner は Google Cloud の非常にスケーラブルなリレーショナル データベース サービスです。Spanner のビジョンの基本原則は、外部の強整合性によるアプリケーションの高可用性の確保です。これを裏付けるものとして、99.999% の可用性を提供する Spanner の新しい 2 つのマルチリージョンをリリースしました。それが、アジアのマルチリージョン（asia1）とヨーロッパのマルチリージョン（eur5）です。マルチリージョンが増えると、高可用性を確保しながら、高品質で統一されたカスタマー エクスペリエンスを世界中のユーザーに提供できます。 マルチリージョン構成の主な利点は次のとおりです。 99.999% の可用性: Spanner のマ
HTTP だけではない：Cloud Run で gRPC の利用が可能に | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 3 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run は、Google Cloud が提供するマネージド型のサーバーレス コンピューティング プラットフォームです。基盤となるインフラストラクチャの管理に煩わされることなく、フルマネージドの環境でステートレスなサーバー コンテナを実行できます。Cloud Run はリリース以降、多数のお客様にご採用いただいております。プロビジョニングや構成、スケーリングといった処理は Google 側で行うため、お客様はビジネス ロジックに注力できます。 Cloud Run で動作するほとんどのアプリケーションは HTTP JSON REST を使用してリクエストを処理しますが、サポートするプロトコルはこれだけではありません。9 月からは、単項 gRPC サービスのサポー
【GCP】Cloud Functions の Go 1.13 でファイル構造に変更があった - Qiita
Cloud Functions Go 1.13 GA GCF/Go 1.13 が GA になったので Go 1.11 から移行してみた。しかし、デプロイに失敗するようになった。 原因 コード内で設定ファイルを読み込むようにしていたが、GCF/Go 1.13 からファイルの構造が変更され読み込みエラーが起きてしまった。 調査 どのようにファイルの構造が変更があったのか調べたところ、ファイルの構造を調査したリポジトリを発見。 どうやら、静的ファイル保存ディレクトリは以下に保存されるようだ。 /workspace/serverless_function_source_code/ ファイル構造について、公式ドキュメントでは見つけることはできなかった。 対応 コードの静的ファイルを指定している箇所を下記のように変更した。
小さいプロダクト開発におけるGCP利用の勘どころ - 個人的なプロダクトを三日でローンチした話 - Lean Baseball
私個人の話なのですが. 最近は仕事でAWSやGCPのサーバレスアーキテクチャにふれる機会が増えた*1と同時に, 自分が気になる世の中のニュース（グルメとかいろいろ）だけをいい感じに集めてまとめて読みたい その中でも特に⚾, 速報とかいい感じに通知させたい という怠け者欲ライフハック欲が高まってきたので, GCP（とちょっとしたPythonスクリプト）でSlack Botを作りました. 趣味開発で雑にはじめた結果, 三日程度でできちゃった*2のでその知見をメモ代わりに残します. おしながき おしながき TL;DR 対象読者 作ったもの GCPをフル活用して実質三日でBotをローンチした Bot本体の開発 GCPの何を使うかで試行錯誤 プランA「GCEを使う」 プランB「Cloud Run + Cloud Scheduler」 採用した構成「Cloud Functions + Cloud Sc
外部 ID | Identity-Aware Proxy | Google Cloud
フィードバックを送信 外部 ID コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 この記事では、Google アカウントの代わりに外部 ID を Identity-Aware Proxy（IAP）で使用する方法について説明します。 概要 IAP は、Google Cloud で実行される App Engine アプリや Compute Engine VM へのアクセスを制御します。ユーザー ID とリクエストのコンテキストを利用して、ユーザーにアクセスを許可するかどうかを判断します。IAP は BeyondCorp の構成要素です。BeyondCorp は、信頼されないネットワークから VPN を使わずに従業員が作業できるようにするためのエンタープライズ向けセキュリティ モデルです。 IAP は、デフォルトで Google ID と IAM を使用します。
強力なコンピューティング能力: 「スパイダーマン: ファー・フロム・ ホーム」を Google Cloud 上で レンダリング | Google Cloud 公式ブログ
強力なコンピューティング能力: 「スパイダーマン: ファー・フロム・ ホーム」を Google Cloud 上で レンダリング ※この投稿は米国時間 2019 年 8 月 28 日に Google Cloud blog に投稿されたものの抄訳です。 「スパイダーマン: ファー・フロム・ホーム」では、スパイダーマンがおなじみの舞台ニューヨークを離れ、学校の研修旅行でベニス、プラハ、ベルリン、ロンドンを訪れます（でもパリには行きません）。この映画の視覚効果（VFX）を担当する Luma Pictures 社も、それまで利用していたロサンゼルスのオンプレミス データセンターから Google Cloud へとレンダリング パイプラインを移行して、登場キャラクターの風と火のエレメンタルズ（サイクロンとモルテンマン）を作りました。 「この移行は非常に良い結果をもたらしました」と、Luma Pict
cloud runでpuppeteerを使ってクローラーを作る - 839の日記
もともと借りていたVPS(ubuntu)の上でchromeとchromedriverを入れてクローラを動かしていたが、 何気ないapt-get upgradeで動かなくなってしまい、今後も発生することを考えると憂鬱になったので移行先を探すことに…。 cloud runは感覚的にはdocker imageを投げつけられるlambdaみたいなもので、手元で動くものを作ればimage投げるだけでいけるかな、という算段で選択した。 rest api的にurlにアクセスしたらcrawlした結果を返すようにしたかったため、expressを間に挟んでいる。 常に使いたいわけでもなかったので、使うときだけ起動するcloud runは要件とマッチしていた。 サンプルリポジトリとしては以下で公開している。 github.com 内容としては、GAEでpuppeteerを動かしているサンプルのcloud run
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 を入れてくれるヘッダです。そのため
Extensible Service Proxy と Cloud Endpoints Frameworks の比較 | App Engine 用 Cloud Endpoints Frameworks | Google Cloud
フィードバックを送信 Extensible Service Proxy と Cloud Endpoints Frameworks の比較 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このページでは、App Engine スタンダード環境の Endpoints Frameworks と Extensible Service Proxy（ESP）の違いについて説明します。ESP は OpenAPI または gRPC を使用する API の Cloud Endpoints で使用されます。Endpoints のオプションについての詳細は、Cloud Endpoints オプションの選択をご覧ください。 概要 Cloud Endpoints は、Google が独自の API に使用しているのと同じインフラストラクチャを使用して、API の保護、モニタリング、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GCPでMinecraft マルチサーバー管理している(更新) - .ごっちの日記
Kelsey Hightower on Twitter: "Cloud Run is dope but I can't use it because ..."
GitHub - mingrammer/diagrams: Diagram as Code for prototyping cloud system architectures
cloud-foundation-toolkit/terraform.md at master · GoogleCloudPlatform/cloud-foundation-toolkit
D1-2-S06: 組織変革をもたらすプラットフォームの力｜Slack API でつながるクラウドサービスとチーム