1 - 40 件 / 57件
最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。 前提としてはこんな感じ。 仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない 技術スタックは技術的な実験とか学習を兼ねているので多少オーバースペックになるのはいい お金はなるべくかけたくない 移行前のスタック フロントエンドはNuxt.js、Netlify バックエンドはRailsでgRPC、envoyを噛ませてフロントエンドからはgRPC-Webで呼んでる VPS上にバックエンドのアプリケーションとDB(postgres)を動かしてる バックエンドは普通のRailsアプリにしてHerokuにするのが一番楽でお金もかからないんだけど、gRPC-Webを試してみたくて、そうするとproxyが必要にな
こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。 Twitterもやっているのでフォローしてもらえると嬉しいです! こんなアイコンです 本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。 この記事の要約 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。 SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。 Azure OpenAIも利用して効率化した。 きっかけ 2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。 情報システムを色々と
Zennは、Next.js + Ruby on Rails(APIモード)を Google Cloud の App Engine へデプロイして稼働していました。最近、Rails の実行環境を App Engine Flexible から Cloud Run へ移行したので、その記録を残します。 ロードバランサーのバックエンドサービスを付け替えることで実現 最初に、どうやって移行したかです。Zennのバックエンドはもともとロードバランサーで構成されていました。以下の図のように、ロードバランサーの Backend Service より背後を切り替えることにより実現しています。Cloud Run とそこにアクセスするための Serverless NEG はあらかじめ稼働させておくことで、ダウンタイムなしで切り替えられました。 参考:負荷分散 | Google Cloud https://clo
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
Googleは、Dockerコンテナをサーバレスで実行するサービス「Cloud Run」の新機能として、非同期処理などを可能にする「CPU allocation on Cloud Run」機能をプレビューとして発表しました。 非同期処理などが難しかったCloud Run サーバレスコンピューティングでは一般に、何らかのイベントやリクエストをトリガーにインスタンスが起動し、処理が終わるとインスタンスが終了します。 Google CloudのCloud Runではこうした処理をDockerコンテナで実現するサービスです。HTTPやgRPCなどによるリクエストによってあらかじめ用意されていたDockerコンテナが起動し、レスポンスを返したところでDockerコンテナが終了してCPUの割り当てが解放されるようになっています。 そのため、Cloud Runでは処理を非同期にしてレスポンスを先に返し、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 趣味でWebサービスを作ったはいいものの、サーバーの運用にコストがかかり結局停止してしまった経験、ありませんか? これらの趣味で作ったサービスはアクセス数が少なく、数日に1人程度しかアクセスがないことも多いため、収益がない場合がほとんどです。 しかし、せっかく開発したのだから動かし続けたい気持ちはあると思いますし、運用し続けることで機能追加などをしてさらに楽しめることもあると思います。 このような運用コストに悩みがちな趣味開発Webアプリケーションですが、自分は趣味で現在いくつかのWebアプリケーションを月当たり2円というほぼ無料と言っ
はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか? 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変...と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか? 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた
2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。 最終日、25日目は Cloud Run を中心としたサーバーレス アーキテクチャをいくつか紹介します。2023年にちなんで23個のアーキテクチャを用意しました。 Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。 Web アプリケーション + API の 3-Tier 構成 (SPA) Web アプリケーション + API の 3-Tier 構成 (SPA) SPA (Single Page Application) がフロントになり、バックエンドの API サーバーとして Cloud Run を使用するアーキテクチャです。SPA は N
はじめに Rails 8が新たにリリースされ、SQLiteを本番環境でも使用できるようになりました。 これまで、Google CloudでRailsアプリを運用する際、Cloud RunとCloud SQLを使うと簡単に構築できて便利だったんですが、Cloud SQLだけで最低月2,000円弱かかってしまっていました。 SQLiteは、PostgreSQLやMySQLと違いライブラリとして動作するため、データファイルを保存できるストレージがあれば別途CloudSQLなどのサービスを使う必要がなくなります。 なので、Cloud StorageのバケットにSQLiteのデータを置いて、Cloud RunでGCSバケットをボリュームマウントとして設定することで、ほぼ無料のRails環境が作れそうと考えて試してみました。 インフラ構成 Cloud RunとCloud Storageの構成にしていま
module.exports = { - experimental: { - outputStandalone: true, - }, + output: 'standalone', } Next.js の experimental features のひとつに、スタンドアロンモードがあります。 通常モードでは、本番リリース可能なビルドを用意する場合、yarn build による .next/ ディレクトリとあわせて node_modules も含めます。依存関係を解決するために必要ですね。一方スタンドアロンモードを有効にした上で yarn build するとビルド結果が異なります。.next/ディレクトリが作られる点は同じですが、そこにstandaloneディレクトリが追加されます。ここにはアプリを動かすためのファイルが依存関係も含めてすべて入っていて、.next/standalone/
engineering.mentemo.com この記事は↑の記事の後編です。 前編からだいぶ日が空いてしまいましたが、今回はメンテモのWebアプリケーションがVercelからCloud Runに移行するまでの実際の作業を紹介します。 はじめまして。 @itometeam です。メンテモで業務委託として開発全般のお手伝いをしています。 メンテモのWebアプリケーションはフロントエンドにNext.jsを使っています。 元々は例に漏れずVercelを使っていましたが、スケールするにつれてどうしてもボトルネックになる部分が増えてきたため別の環境に移すことを検討し始めました。 もちろんVercelはNext.jsのデプロイ先として今後も一番の選択肢としてあり続けると思います。 Webサーバをクラウド上に構築する上で意識するべきことをほとんどおまかせでやってくれますし、プレビューURLの自動生成など
TL;DR 今話題のOpen InterpreterをSlack botにしました。 Codeはこちらのリポジトリをご覧ください。 はじめに Open Interpreter楽しんでますか? 「どうやらヤバイやつが爆誕したらしい」という認識で間違いなさそうです。 でも、このヤバさがわかってるのはまだ一部の人だけ、もったいない! ということで今回はこのOpen Interpreterを誰でも使えるようにSlack botにする方法を紹介します。 ファイルのアップロード、ダウンロードも可能ですので、最低限必要な機能を全て備えたものが完成すると思います。 この記事を読めばわかること Cloud Runを使ってサーバーレスなOpen Interpreter実行環境を構築する方法 Cloud Storageを使ってステートレスなCloud Runでも会話とファイルを維持する方法 Slack Botを
TL; DRCloud Run にバッチ処理などを実行するのに便利な機能「Cloud Run jobs」が追加されました。従来の Cloud Run と違い、HTTP リクエストに依らず、任意のタイミングでコンテナ(Task)を実行可能で、より長時間の実行、 明示的な並列処理を行うことが可能です。 Cloud Run jobs とはCloud Run jobs とは Cloud Run で、バッチ処理などを行うための機能です。Cloud Run の第二世代の実行環境で動作し、「CPU を常に割り当てる」が適用されます。 従来の Cloud Run との違いは以下の通りです。 HTTP リクエストに依らない実行より長時間の実行 ( 複数の Task を組み合わせることにより 60 分以上の実行を実現 )明示的な並列処理注意: 2022 年 5 月 13 日現在、Cloud Run jobs
Googleは、Dockerコンテナをサーバレスで実行するCloud Runの第二世代実行環境と、Cloud Runの新機能であるCloud Run Jobsが正式版になったことを明らかにしました。 Cloud RunはHTTPSリクエストをトリガーとしてDockerコンテナを実行するサーバレス基盤です。 すなわち、HTTPリクエストがない場合にはDockerコンテナは起動されず、HTTPリクエストに応じて自動的に多数のコンテナが起動するスケーラビリティが特長です。Dockerコンテナであれば、どんな言語で作られたサービスであっても関係なく利用できる柔軟さを備えています。 課金もおよそ100ミリ秒ごとに、起動しているサービス数などによって計算されます。 Cloud RunはKubernetes上でサーバレスコンピューティング環境を実現するフレームワークとしてGoogleがオープンソースで開
この記事はクラスメソッド Google Cloud Advent Calendar 2021の9日目の記事です。 Google Cloud自体ナンもわからないマンが、以前から気になっていたCloud Runをあれこれ動かしながら学んでみた様子をお届けします。もともとAWSのApp Runnerがお気に入りのサービスだったので、それとの機能上の違いも入れています。 (祭) ∧ ∧ Y ( ゚Д゚) Φ[_ソ__y_l〉 Cloud Run祭りダワッショイ |_|_| し' ́J 注意事項:この記事には両者のサービスの優劣をつける意図は全くありません そもそも、違うプラットフォームに存在するサービスを単独で機能比較して優劣がはっきり出るほど、パブリッククラウドは単純なものではありません。AWSもGoogle Cloudもサービス単体で利用するよりは、そのエコシステムの中でビルディング
TL;DRCloud Run で Always on CPU (プレビュー)が選択可能にコンテナインスタンス起動中は CPU がフルに利用できます利用形態によっては料金面でメリットもCloud Run とはひとことでいうと「サーバーレス コンテナ」を提供するフルマネージドコンピューティング環境であると言えます。コンテナ上のアプリケーションは、HTTPS、gRPC、WebSocket または イベントでトリガー されます。 処理した分だけ課金される サーバーレスサービスで、無料枠もありお手軽に利用を開始することができます。 また大規模なサービスにも多くの実績がある大変人気のサービスです。 Always on CPU (プレビュー)従来、Cloud Run では リクエストを受け付け処理している間のみ CPU の割当てが保証されていました。つまりレスポンスを返したあとは CPU 割当てが無効に
はじめに こんにちは。メディアプラットフォーム本部 WEAR部 WEAR-SREの笹沢(@sasamuku)です。 ZOZOが新しく展開する「FAANS」というショップスタッフ向けアプリをクローズドβ版としてテスト運用しています。本アプリは、WEARと連携したコーディネート投稿や、その成果を可視化する機能などをショップスタッフの皆さんに提供するtoBのソリューションです。現在、正式リリースに向け開発を進めています。 そして、FAANSのAPIはCloud Runと呼ばれるサーバレスなコンテナ実行基盤で稼働しています。本記事では、FAANSの実行基盤としてCloud Runを選定した理由や、構築・運用するためにSREとして取り組んだことをご紹介します。 Cloud Runを選んだ理由 まず、クラウドサービスはGCPを選択しています。FAANSでは開発速度の向上と運用負荷の軽減のため、認証やメ
こんにちはdelyでサーバーサイドエンジニアをしているyamanoiです この記事は「dely #2 Advent Calendar 2020」の12日目の記事です。 adventar.org adventar.org 昨日は@yochidrosさんの「KMMでiOS・Android を共通化しよう」でした。 みなさんwebサイトを作成する時にSPAを利用していますか? SPAはユーザーに対してメリットが大きいですが、SEO観点やOGPタグのレンダリング等で SSRが避けられない場面に出くわすことがあると思います。 SSRが不要であればビルドして生成された成果物をs3等でホスティングするだけなのでデプロイや、運用が楽なのですが、 SSRをするとなるとNode jsの実行環境必要になります。 ある程度大きなプロジェクトであればECSやGKE, GAEに載せてガッチリと運用すべきだと思いますが
この記事は 2024 年 2 月 28 日に執筆されました.今後この問題が Cloud Run 側で修正された場合,再現しない可能性がありますのでご留意ください. TL; DR Cloud Run は執筆時現在 zstd による圧縮に対応していない ヘッダの Content-Encoding: zstd のみが削除され,ボディは圧縮されたまま応答される ブラウザはこの応答を正しく解釈できないため文字化けのような表示となる zstd による圧縮は,執筆時現在 Chrome に実装されているもののデフォルトでは無効だが近い将来に有効化される 悲劇は突然訪れる 弊社では,コーポレートエンジニアリングチーム [1] [2] において,社内向けにいくつかのサービスを提供しています. これらのサービスはもともと AWS でホストされていましたが,アクセス制限に Identity-Aware Proxy
https://zenn.dev/voluntas/scraps/f4939cbe92525c を見て、Cloud Run でもホストできると個人的にはうれしいかもなーと思って実験してみた コツとしては、 第二世代の実行環境 で動作させる コンテナ起動時にrestoreしてGCSからデータをロードするようにする 最大インスタンス数を1にする LitestreamのGCS対応はCloud Runの実行環境のサービスアカウントでは実行されないので、サービスアカウントを作り、SecretManager経由で鍵情報をファイルとしてマウントし、GOOGLE_APPLICATION_CREDENTIALS としてパスで与える。 といったところだった。 litestream replicate -exec が実行している内容を考えると、定期的にGCSへ更新する処理が走るので、Always on CPU
. ├── backend.conf ├── main.tf ├── registry.tf ├── terraform.tfvars └── variables.tf main.tfでは、terraformのバージョン指定とサービスアカウントのroleの指定が定義されています。repo_nameは権限を与えるgithubリポジトリなので、この段階で連携するリポジトリを決めておく必要があります。 terraform { required_version = "~> 1.1.9" backend "gcs" { prefix = "terraform/state" } } locals { cloudrun_roles = [ "roles/run.developer", "roles/iam.serviceAccountUser" ] } resource "google_project_
※(注記)この投稿は米国時間 2023 年 8 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。 Go はクラウドベースの開発のために世界的に採用されている主要なプログラミング言語です。クラウド アプリケーションやビジネス クリティカルなクラウド インフラストラクチャを構築、スケーリングする目的で何百万人もの開発者に利用されています。CLI、ウェブ アプリケーション、クラウド サービス、ネットワーク サービスなど、どのようなものを構築するにしても、Go は習得するのも保守も容易で、組み込みの同時実行性や堅牢な標準ライブラリをはじめとする便利な機能が満載です。 このたび、Go を Google Cloud で使い始める際のハードルを少し下げることが可能になります。Go は最近、事前定義されたテンプレートを使用して新しいプロジェクトを Go でインスタンス化できる、gon
Run your AI inference applications on Cloud Run with NVIDIA GPUs Developers love Cloud Run for its simplicity, fast autoscaling, scale-to-zero capabilities, and pay-per-use pricing. Those same benefits come into play for real-time inference apps serving open gen AI models. That's why today, we’re adding support for NVIDIA L4 GPUs to Cloud Run, in preview. This opens the door to many new use cases
はじめに こんにちは。ブランドソリューション開発本部 WEAR部 SREの笹沢(@sasamuku)です。 FAANSはショップスタッフの効率的な販売をサポートするスタッフ専用ツールです。FAANSの一部機能は既にリリースされており全国の店舗で利用いただいております。正式リリースに向け、WEARと連携したコーディネート投稿機能やその成果をチェックできる機能などを開発中です。 FAANSのコンテナ基盤にはCloud Runを採用しており、昨年にSREとしての取り組みをテックブログでご紹介しました。しかし、運用していく中で機能需要や技術戦略の変遷があり、Cloud RunからGKE Autopilotへリプレイスすることを決めました。本記事ではリプレイスの背景と、複数サービスが稼働している状況下でのリプレイス方法についてご紹介します。 目次 はじめに 目次 リプレイスの背景 なぜCloud R
Cloud Run でマルチコンテナ機能がプレビューで利用可能に GA になりました(2023年11月)! 長らく待ち望まれていたCloud Run のマルチコンテナが、パブリックプレビュー GAになりました!! Cloud Run の第一世代、第二世代ともに利用が可能です。 Update: Google Cloud コンソールからマルチコンテナが設定できるようになりました。 ドキュメントはこちらです。 マルチコンテナのサポートにより、複数のコンテナを使いながら ロギング、モニタリング、トレーシング Nginx や Envoy、Apache2 などのリバースプロキシ 認証、フィルタの追加 データベースのプロキシ など、ユースケースが柔軟に広がることが期待できます。 より具体的な例として PHP を使ったアプリケーション は、Nginx と PHP-FPM の組み合わせが多いため、恩恵が大き
Cloud Run with IAPを利用しているアプリを開発中にPull Requesのレビューをする時、専用の環境で動作確認したいと言われたので、考えてみた。 Cloud Runには Revision Tagを利用して、任意のRevisionにRequestを送る独自URLを発行する機能 があるが、IAP(Identity Aware Proxy)を利用している場合、Serverless NEGを利用して、HTTP LBからRequestを受けるため、この機能を使っただけでは解決しない。 最終的なCloud Runの構成 作る時に考えたこと 前提 Identity Aware Proxyがかかっている MarkdownをHTMLに変換しているStaticなWeb Site 開発チームは数人 更新頻度はそんなに高くはない 対象はIAPをかけているStaticなWeb SiteでPull
TL; DRCloud Run の Always on CPU を使うと、Cloud Pub/Sub から Pull する Worker を Cloud Run で実行出来ます。ただし、スケーリング等にいくつか諸注意があります。 はじめにCloud Run の Always on CPU が Preview でリリースされて、バックグラウンド タスクや非同期処理で使えると Twitter で宣伝したところ、私の tweet 史上、一番の反響を頂きました。ありがとうございます。また同僚の Shingo-san が素敵な解説記事を書いてくれたり、同じく同僚の Pottava-san も素敵なサンプルコードを書いてくれてたり。「tweet してるだけでいいのかい?本当に?」という私のエンジニアとしての良心の呵責があったため、私もこうして記事を書いています。 試したこと以前、お客様から Cloud
執筆時点で Public Preview な内容を扱っています。GA になった際に内容に誤りが生じる場合があるため、最新の一次情報も確認してください。 https://cloud.google.com/iap/docs/enabling-cloud-run Cloud Run は Google Cloud Platform (GCP) で提供されている Serverless Computing の1つで、Container のフルマネージドホスティングサービスです。 Identity-Aware Proxy (IAP) は GCP で提供されている、アプリケーションレベルの認証、承認のためのアクセス制御サービスです。 これまで、IAP は GCE や GKE、GAE でしか使えませんでした。 そのため Cloud Run で認証を行う場合はアプリケーションに実装するか、Cloud Endp
本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第3回では、サーバーレス開発とGoogle Cloudのサーバーレス製品であるCloud Runに焦点を当てます。 まず、サーバーレス開発の基本概念と利点について説明し、従来のサーバーに依存しないアプリケーション開発手法の重要性を探ります。次に、Cloud Runの概要を紹介し、コンテナイメージの実行をサポートするサーバーレスプラットフォームとしての役割を説明します。この回を通じて、サーバーレス開発の基礎を学び、Cloud Runを利用して効率的なアプリケーション開発を実現する方法を理解できます。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築する
※(注記)この投稿は米国時間 2020 年 11 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 サーバーレスのコンテナ化は、大きな負担となるインフラストラクチャ管理なしでステートレス マイクロサービスをデプロイする方法をデベロッパーに提供し、世界を席巻しました。Cloud Run ではインフラストラクチャ管理が一切不要です。ウェブサーバーとステートレス ロジックを持つコンテナ イメージを渡し、メモリ / CPU と許可される同時実行の組み合わせを指定するだけです。 Cloud Run は、HTTP エンドポイントの作成、コンテナへのリクエストのルーティング、処理するリクエスト量に応じたコンテナのスケールアップとスケールダウンを行います。また、Cloud Run はアイドル インスタンスなど、応答時間のレイテンシを短縮するためのネイティブ機能をいくつか提供しています
こんにちは。新規IAMプロダクトでフロントエンドアーキテクトを担当している@shisama_です。 この記事では、開発スピードを上げるためにGitHub Actionsを使ってプルリクエストごとにレビュー用の検証環境をGoogle Cloud Run(以下、Cloud Run)に構築する仕組みについて紹介します。 今回紹介する内容のサンプルのリポジトリはこちらになります。 github.com この仕組みは業務委託でお手伝いいただいていた@chimame_rtさんが考案し設計してくれました 👏 はじめに フロントエンドチームが抱えていた課題 プルリクエストごとに Cloud Run に検証環境を構築する Step 1. プルリクエストにラベルを適用して GitHub Actions を起動 Step 2. Next.js のビルド Step 3. Google Cloud の認証 Ste
G-gen の佐々木です。当記事では Google Cloud(旧称 GCP)のサーバーレスなコンテナプラットフォームサービスである Cloud Run を解説します。 Cloud Run とは 4種類の Cloud Run 4つの実行モデル Cloud Run サービス(services) Cloud Run ジョブ(jobs) Cloud Run 関数(functions) Cloud Run ワーカープール(worker pools) Cloud Run サービスの基本 動的スケーリング サービスの冗長性 デプロイ デプロイ元のコンテナイメージ コンテナの要件 トラフィック移行とロールバック コンテナ実行環境(世代) サービスの構成 エンドポイント URL コンテナインスタンスの最大・最小数 コールドスタートとその対処 Startup CPU boost CPU・メモリ リクエストの
Google Account でサインインする The email you entered is associated with a Google account. Sign in with Google to continue.
こんにちは。GMO NIKKO エンジニアのALPHです。 いよいよ寒くなってきましたね。鍋がおいしい季節です。 最近、不注意で指を痛めたことがあり焦ることがありました。痛烈に自動化の重要性を改めて実感しました。 やはり、GUIからの操作からだけでは運用が辛いですよね。 簡単にコマンドで操作したい、バッチ処理で自動化したいと思うのが人の心。 そのような流れで 今回は、最近話題の「Cloud Run」の操作自動化手法の一例をご紹介します。 なんでCloudRunかというと、まだ情報量がちょっと少なかったので苦戦した記憶があるためです。 Cloud Run の概要はこちら Cloud RunのAPI とリファレンスはこちら Cloud Runで操作の自動化をするにあたって、APIの操作をやはり覚える必要があります。 GUIコンソールからできることは、大抵APIからできます。 それぞれ一つ一つ対
Cloud Run, Google Cloud's serverless container platform, offers a very granular pay-per-use pricing, charging you only for CPU and memory when your app processes requests or events. By default, Cloud Run does not allocate CPU outside of request processing. For a class of workloads that expect to do background processing, this can be problematic. So today, we are excited to introduce the ability to
安いRDBといえばPlanetScaleのHobbyプランだったり、D1だったり、古き良きVPSでセルフマネージなんて選択肢もあるが、GCPで完結すると嬉しいだとかホストマシンの面倒を見たく無いだとか、そういう場合もあると思う。 なお今回の構成で本当に激安になるかどうか無料枠で収まるかどうか、などはインスタンス設定やワークロード次第の部分もあるので試算したり予算アラートを設定した方がいい。 また個人でのホビー用途など、データが欠損してもごめんごめんで許される用途での利用に留めておいた方が無難だとは思う。ごめんごめんで許されない場合にはCloud SQLとかへ移行するなり、最初からCloud SQLとかを採用するなりしたほうがいい。 完成品のサンプルコード これはeslint設定やらローカル環境向けのdocker-compose.ymlやらも一式入った、開発環境スターターキットになっている。
以下の記事が面白かったので、簡単にまとめました。 ・AI deployment made easy: Deploy your app to Cloud Run from AI Studio or MCP-compatible AI agents 1. Cloud Run「Cloud Run」は、Google Cloud が提供するサーバーレスのコンテナ実行環境で、Docker などで作成したコンテナイメージをそのままデプロイして実行できます。リクエストに応じて自動的にインスタンス数をスケールし、アクセスがなければゼロにできるため、利用した分だけ課金されます。 本日 (2025年5月21日)、AIの導入をより容易かつアクセスしやすくするため、「Cloud Run」にアプリをデプロイする新しい方法が追加されました。 (1) Google AI Studio のアプリを1クリックで Cloud
Cloud Run min instances: Minimize your serverless cold starts One of the great things about serverless is its pay-for-what-you-use operating model that lets you scale a service down to 0. But for a certain class of applications, the not-so-great thing about serverless is that it scales down to 0, resulting in latency to process the first request when your application wakes back up again. This so-c
目的 GCPのマネージド証明書では扱えなかったワイルドカード証明書がCertificate Managerでは扱えるようになったそうなのでCloudRunのサービスごとに独自ドメインを割り当てます。 注意! この記事は2022年06月11日時点でのCertificate Manager(Preview)を取り扱っています。 必要なコマンドやコンソール操作の手順だけを記しており、gcloudのインストール・設定やAPIの有効化等は記載していません。 簡単な動作しか確認していないため設定やセキュリティに不備が あるかもしれませんので利用の際はお気をつけください。 事前に必要なもの 独自ドメイン(この記事ではexample.comとしているので読み替えてください) DNS(Cloud DNS,Route53等) 課金が有効なGCPプロジェクト CloudRunの用意 CloudRunはサービス・リ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く