タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。 前提としてはこんな感じ。 仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない 技術スタックは技術的な実験とか学習を兼ねているので多少オーバースペックになるのはいい お金はなるべくかけたくない 移行前のスタック フロントエンドはNuxt.js、Netlify バックエンドはRailsでgRPC、envoyを噛ませてフロントエンドからはgRPC-Webで呼んでる VPS上にバックエンドのアプリケーションとDB（postgres）を動かしてる バックエンドは普通のRailsアプリにしてHerokuにするのが一番楽でお金もかからないんだけど、gRPC-Webを試してみたくて、そうするとproxyが必要にな
Cloud Run で作るサーバーレス アーキテクチャ 30 連発 - これのときはこう！
Local SEO for real people: 20 hard-hitting (and hilarious) audit lessons
Zennのバックエンドを Google App Engine から Cloud Run へ移行しました（無停止！YES！）
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
GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう
GraphQL スターターパック | Prisma + NestJS + Next.JS製 個人ブログサイトをCloud Runで運用しよう 「GraphQLの仕様はなんとなく知っているけど、それを使ってどうアプリを作るのかいまいちイメージがわかない」 この本はそんなスキマを埋めるべく書きました。 近年ではReactをはじめフロントエンドの選択肢が豊富になっており、フロントエンドとバックエンド間のやりとりにはより汎用的かつ効率的な方法が求められます。 GraphQLはその選択肢のひとつです。本書では NestJS で GraphQLバックエンドを実装し、それをNext.jsから利用して、個人ブログサイトを構築してみます。 GraphQL開発の流れを体験し、ご自身のアプリ開発に役立ててください。 v1.10 refactor github deploy
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
Dockerコンテナをサーバレス化する「Google Cloud Run」で、非同期処理やバックグラウンドタスクなどが実行可能に
Googleは、Dockerコンテナをサーバレスで実行するサービス「Cloud Run」の新機能として、非同期処理などを可能にする「CPU allocation on Cloud Run」機能をプレビューとして発表しました。 非同期処理などが難しかったCloud Run サーバレスコンピューティングでは一般に、何らかのイベントやリクエストをトリガーにインスタンスが起動し、処理が終わるとインスタンスが終了します。 Google CloudのCloud Runではこうした処理をDockerコンテナで実現するサービスです。HTTPやgRPCなどによるリクエストによってあらかじめ用意されていたDockerコンテナが起動し、レスポンスを返したところでDockerコンテナが終了してCPUの割り当てが解放されるようになっています。 そのため、Cloud Runでは処理を非同期にしてレスポンスを先に返し、
はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか？ 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変…と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか？ 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた
前から気になっていた Litestream を Cloud Run で使ってみたので、そのメモです。 Litestream とは？ サンプルコード 手順 動作確認してみる 制限事項 おまけ まとめ 参考 Litestream とは？ Litestream は、 SQLite のデータベースファイルを Amazon S3 や Google Cloud Storage などのオブジェクトストレージにリアルタイムでレプリケートすることができるオープンソースのツールです。 例えば通常 Cloud Run で DB エンジンとして SQLite を使用しようとしても、コンテナが破棄されると同時に毎回 SQLite のデータベースファイルも消えてしまうため、データを永続化することができません。 しかし Litestream を使用すれば、 SQLite のデータベースファイルをオブジェクトストレージに
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
Next.jsといえば、Vercelで簡便なデプロイができることで有名ですが、GCPのCloud Runでもそれに負けないくらい簡単にデプロイできるようになってきました。 本記事では、GitHubでソース管理されたNext.jsアプリケーションをCloud Runにデプロイし、mainブランチへのpushをトリガーとしたデプロイの自動化を設定する方法を紹介します。 1. Next.jsアプリケーションの作成 Cloud Runでデプロイするためには、Next.jsをDockerに対応させる必要があります。Next.js公式がwith-dockerというexampleを公開しているので、今回はこれを利用しましょう。
技術記事は はてなブログ へお引越ししました。 興味を持ってくださった方はZennではなくこちらをご購読いただければと思います🙏 導入 ローカルの開発環境は各々のマシンに直接構築し、STGや本番はコンテナの上で動かす。 こういった構成を取ることは珍しくありません。 あるいは、開発用にいろいろライブラリを入れたDockerfileと、本番用に最小限のライブラリのみを入れた構成を取ることもあるでしょう。 このような場合はいずれにしても、Dockerfileを書くということからは逃れられません。 今回は、 ローカルの開発環境は各々のマシンに直接構築し、STGや本番はコンテナの上で動かす。 という場合に、Dockerfileを開発者が書かずにCloud Runへコンテナイメージをデプロイし、アプリケーションを動かす技術について、実践してみた経験を書いてみようと思います。 アプリケーション 今回は
module.exports = { - experimental: { - outputStandalone: true, - }, + output: 'standalone', } Next.js の experimental features のひとつに、スタンドアロンモードがあります。 通常モードでは、本番リリース可能なビルドを用意する場合、yarn build による .next/ ディレクトリとあわせて node_modules も含めます。依存関係を解決するために必要ですね。一方スタンドアロンモードを有効にした上で yarn build するとビルド結果が異なります。.next/ディレクトリが作られる点は同じですが、そこにstandaloneディレクトリが追加されます。ここにはアプリを動かすためのファイルが依存関係も含めてすべて入っていて、.next/standalone/
注意 この機能は2024年11月3日現在、まだPrivate Previewのため、利用申請が必要です。 申請方法はGoogle担当者にご相談ください。 IAPとは Identity-Aware Proxy（IAP）はGoogle Cloudが提供するセキュリティ機能で、特定のユーザーのみがリソースにアクセスできるように制御するプロキシサービスです。 これまではCloud RunでIAPによる認証を利用するにはCloud Load Balancerを構築する必要がありましたが、今回のアップデートによりCloud Run単体でIAPを設定できるようになりました！ 手順 今のところはgcloudコマンドからしか設定できないようなので、Cloud Shellで実行します。 IAP用サービスアカウントの作成と権限付与 まず、IAPに必要なサービスアカウントを作成し、「run.invoker」権限を
経緯 ここ6,7年くらいはバックエンドに関してはRails + EC2/ECSあたりのAWS環境を中心に過ごしてきたが、昨今はフロントエンドでReact/Vue + TypeScriptを書く機会も増えている。なのでこの際NestJS等でバックエンドを書けるようになれば言語のコンテキストスイッチの切り替えが容易になりそうと思った(ちなみにモバイルアプリはFlutterで書くのでDartだが、ではDartでバックエンドを書くかと言われると一人でそんな勇気はないわ...となるのでひとまず置いておく) 最近はinputとoutputを型注釈によって守れたりすることの主に開発体験方面への恩恵が個人的に大きくて、Rails以外で安住の地を見つけたいとは予々思っていた。なので先に挙げたNestJSに全ベットするわけではないにしろ何かしらフレームワークは試していきたい。 AppEngineは大昔に少し触
Cloud Run jobs を解説する
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 Cloud、Dockerコンテナをサーバレス化するCloud Runの第二世代実行環境が正式版に。すべてのLinuxの機能と互換、ファイルサーバへのマウントも可能
Googleは、Dockerコンテナをサーバレスで実行するCloud Runの第二世代実行環境と、Cloud Runの新機能であるCloud Run Jobsが正式版になったことを明らかにしました。 Cloud RunはHTTPSリクエストをトリガーとしてDockerコンテナを実行するサーバレス基盤です。 すなわち、HTTPリクエストがない場合にはDockerコンテナは起動されず、HTTPリクエストに応じて自動的に多数のコンテナが起動するスケーラビリティが特長です。Dockerコンテナであれば、どんな言語で作られたサービスであっても関係なく利用できる柔軟さを備えています。 課金もおよそ100ミリ秒ごとに、起動しているサービス数などによって計算されます。 Cloud RunはKubernetes上でサーバレスコンピューティング環境を実現するフレームワークとしてGoogleがオープンソースで開
Cloud RunがGitと連携して勝手にデプロイできるようになったのでやってみた - inductor's blog
はじめに こんにちは。inductorです。 GCPのCloud Runはご存知でしょうか。世界一簡単に単一のコンテナをデプロイできるサービスだと私は考えています。 さて、以下のようなリリースノートの通知があって、Cloud RunがGitと連携して更新まで自動でできるようになったみたいです。 Continuous deployment from Git using Cloud Build まとめるとこんな感じのことが書いてあります Cloud Buildのトリガーを使用して新しいコミットがGitリポジトリの特定のブランチにプッシュされるたびにコードを自動的にビルドしてデプロイすることで、ビルドとCloud Runへのデプロイを自動化できます。 Cloud Buildトリガーを使用してコンテナをビルドすると、Cloud Runにデプロイした後、ソースリポジトリ情報がサービスのCloud C
概要 本記事では、Next.jsをコンテナをサーバーレスで実行するサービスであるCloud Runで動作する軽量のDocker環境構築について紹介します。 ネットにある様々な記事を見てきましたが、動作目的でDockerイメージが大きくなっており、パフォーマンスとセキュリティに課題がありました。そこでDockerの軽量化および最適化を試みました。 Docker環境 シングルステージビルド（slim） シングルステージビルドしたDockerイメージです。本番環境に必要無いデータを多く含んでいるため、イメージサイズも大きくなっています。構成はシンプルのため、理解しやすいですがパフォーマンス/セキュリティ面には課題があります。 FROM node:14.17.0-slim WORKDIR /app COPY package.json yarn.lock ./ RUN yarn --frozen-l
フィヨルドブートキャンプというプログラミングスクールのEラーニングアプリをCloud Run + Railsで動かしています。 1ヶ月使ってみた結果、8,000円ぐらいでした。 Cloud Runが300円でCloud SQLが7,000円って感じです。Cloud Buildとかちょこまかしたのはありますが誤差の範囲。 Cloud Runは1コンテナだったら1日10円ぐらいなんですよね。信じられないほど安い。 これでDockerイメージ放り込んでおけば自動スケールの環境が手に入るならほとんどの仕事のアプリはこれでいい気がします。パフォーマンスもいいし、これからのアプリは全部これで行こうと思います。
Rails の非同期処理を Sidekiq から Cloud Tasks にリプレイスして Cloud Run のコストが6分の1になった話
成果 最終的に、Cloud Run のコストが$6/day前後から$1/day前後に！ ちなみに、Cloud Tasks は1ヶ月あたり最初の100万回のオペレーションまで無料なので余裕で収まっています。 モチベーション 今回リプレイスを検討したシステムは軽量な非同期処理が大半で、もともと絶対に Sidekiq でないと困るということが少なかった Sidekiq は Redis をポーリングしてジョブを取得する方式なので、Cloud Run で実行するには min-instances を1以上にしなければいけない 何もジョブがない状態が続いてインスタンスが0になると起こしてくれる人がいないので... 絶対に Sidekiq でないと困らないなら Cloud Tasksにして、非同期処理がない時は寝ていても良いようにしたい => コストダウン！ Pub/Sub との比較検討もしましたが今回は
はじめに Herokuの無料枠が終了することにあわせて、個人で動かしているRailsアプリケーションを他の場所へ移行する。 いままで無料で使わせていただいたこと感謝しつつも、月千円ほど払うほどのアプリケーションでもないので、ほぼ無料で移行できそうな場所を探すことにした。1 コンテナをホスティングできるGoogle Cloud Runは従量課金制だが、個人で使う分にはほぼ無料なので、これを選ぶことにする。 Cloud Runで使うRDBは一般にはGoogle Cloud SQLが推奨されていそうだが、ここでは安さのためにSQLite3 + Litestream + Google Cloud Storage(以下GCS)を使うこととしたい。 実装の方向性 Litestreamは、SQLite3のデータベースを、オブジェクトストレージやNFS、SFTPのストレージにレプリケーションできるOSSの
Google Cloudなんもわからないマンが、Cloud Runの凄さをあれこれ調べてみた | DevelopersIO
この記事はクラスメソッド Google Cloud Advent Calendar 2021の9日目の記事です。 Google Cloud自体ナンもわからないマンが、以前から気になっていたCloud Runをあれこれ動かしながら学んでみた様子をお届けします。もともとAWSのApp Runnerがお気に入りのサービスだったので、それとの機能上の違いも入れています。 （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 Cloud Run祭りﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ 注意事項：この記事には両者のサービスの優劣をつける意図は全くありません そもそも、違うプラットフォームに存在するサービスを単独で機能比較して優劣がはっきり出るほど、パブリッククラウドは単純なものではありません。AWSもGoogle Cloudもサービス単体で利用するよりは、そのエコシステムの中でビルディング
https://gdg-tokyo.connpass.com/event/201523/
Cloud Run（フルマネージド）でリクエスト外に処理をすると200倍遅くなる - orangain flavor
はじめに Cloud Runはサーバーレスなコンテナ実行基盤です。この記事ではフルマネージド版のCloud Runのみを対象とし、フルマネージド版のCloud Runを指して、単にCloud Runと表記します。 Cloud Runの料金プランの特徴として、リクエストの実行中のみ課金対象になるという点が挙げられます。しかし、リクエストのたびにコンテナの起動と終了を繰り返すわけではなく、起動したコンテナはある程度使い回されます。リクエストが無い間は、コンテナが起動していても課金されないというわけです。 課金対象の時間 (https://cloud.google.com/run/pricing?hl=ja より引用) だからと言って無料で使い放題というわけではなく、コンテナランタイムの契約として、リクエスト中しかCPUが使えないと明記されています You should only expect
TerraformとGitHub Actionsで複数のCloud RunをまとめてDevOpsした結果, 開発者体験がいい感じになった話. - Lean Baseball
ざっくり言うと「TerraformとGitHub ActionsでGoogle Cloudなマイクロサービスを丸っとDeployする」という話です. Infrastructure as Code（IaC）は個人開発（趣味開発）でもやっておけ 開発〜テスト〜デプロイまで一貫性を持たせるCI/CDを設計しよう 個人開発（もしくは小規模システム）でどこまでIaCとCI/CDを作り込むかはあなた次第 なお, それなりに長いブログです&専門用語やクラウドサービスの解説は必要最小限なのでそこはご了承ください. あらすじ 突然ですが, 皆さんはどのリポジトリパターンが好きですか? 「ポリレポ（Polyrepo）」パターン - マイクロサービスを構成するアプリケーションやインフラ資材を意味がある単位*1で分割してリポジトリ化する. 「モノレポ（Monorepo）」パターン - アプリケーションもインフラも
2022/05/11にCloud Run Jobsがプレビューでリリースされました！ Unlike services, which listen for requests, a job does not serve requests but only runs its tasks and exits when finished. 従来のCloud Runのserviceでジョブ的なことを実装する場合、ポートをリッスンしてリクエストを受け取り、ジョブを実行して、成功/失敗のレスポンスを返すという流れでした。 今回リリースされたCloud Run Jobsでは、ポートをリッスンする必要がなくなったということで、ついに待ち望んでいた機能がきたのか！？とさっそく動作確認し、僕が期待してたことは全部できそうでした🎉 これまでCloudBuildでワークフロー組んでたんですが、対応リージョン増えてC
TL;DRCloud Run で Always on CPU （プレビュー）が選択可能にコンテナインスタンス起動中は CPU がフルに利用できます利用形態によっては料金面でメリットもCloud Run とはひとことでいうと「サーバーレス コンテナ」を提供するフルマネージドコンピューティング環境であると言えます。コンテナ上のアプリケーションは、HTTPS、gRPC、WebSocket または イベントでトリガー されます。 処理した分だけ課金される サーバーレスサービスで、無料枠もありお手軽に利用を開始することができます。 また大規模なサービスにも多くの実績がある大変人気のサービスです。 Always on CPU （プレビュー）従来、Cloud Run では リクエストを受け付け処理している間のみ CPU の割当てが保証されていました。つまりレスポンスを返したあとは CPU 割当てが無効に
Cloud RunとIdentity-Aware ProxyとGitHub ActionsでPull RequestごとのDeployment Previewを実現する - Hatena Developer Blog
マンガ投稿チームでWebアプリケーションエンジニアをしているid:stefafafanです。この記事では、最近私がチーム向けに整備したDeployment Preview環境の事例を紹介します。 Deployment Previewとはどのようなものか？ チームとして求める要件 実現したDeployment Previewの全体像 1. DockerイメージをビルドしてArtifact RegistryにpushしてCloud Runで動かすまで GitHub Actionsでどのように実現したか 2. ロードバランサーと証明書の準備、またServerless NEGによる振り分け Certificate Managerでワイルドカード証明書を取得 Serverless NEGを用意してURL MaskでCloud Runのリビジョンタグと対応づける Identity-Aware Prox
Cloud Runで新規サービスを構築・運用するためにSREとして取り組んだこと - ZOZO TECH BLOG
はじめに こんにちは。メディアプラットフォーム本部 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に載せてガッチリと運用すべきだと思いますが
Cloud Run + OpenTelemetryでもトレースが途切れないようにPropagatorを自作する - 株式会社ヘンリー エンジニアブログ
株式会社ヘンリーでSREをしているsumirenです。 ヘンリーではオブザーバビリティバックエンドにHoneycombを採用しています。 Cloud Runでサービス間通信をしている場合、こうした外部オブザーバビリティバックエンドとOpenTelemetryを使うと、トレースが途切れてしまう課題があります。 解決してから1年弱経ってしまったのですが、対処事例を紹介します。 Cloud Run + OpenTelemetry + 外部バックエンドでトレースが途切れてしまう理由 途切れてしまう理由を解説するために図解を用意しました。ここでは2つのCloud Runアプリケーションがサービス間通信を行い、番号順に処理を行ってトレースを生成しています。便宜上各アプリケーションはスパンを1つしか生成しない形で図解していますが、スパン数が増えても問題の本質は変わりません。またトレースIDやスパンIDは
概要 この記事は 一休.com Advent Calendar 2023 16日目の記事です。 RESZAIKO開発チームの松村です。 一休では各サービス毎に、開発中のサービスの動作を社内で確認できる環境があります。 それぞれmain(master)ブランチと自動的に同期している環境と、特定のブランチを指定して利用できる環境の2種類があります。 今回、RESZAIKOの新規サービス(予約画面)に対してブランチを指定してデプロイできる環境を作成したので、その方針と反省点と今後について記述していきます。 現在運用中の予約画面 開発環境を作る理由 一休では長らく、EKS上に複数の環境を用意して、ブランチを指定すると開発環境にデプロイするシステムが利用されてきました。 一般的にこのような環境を構築するのは以下のような理由が挙げられます。 動作確認 マイクロサービスで、異なるブランチ同士の組み合わせ
こんにちは！Google Cloudでオブザーバビリティを担当しているものです！Cloud Runでマルチコンテナーサポートがパブリックプレビューになりましたね！これはCloud Runでサイドカーを走らせられるということです！というわけで今日は1ユースケースとしてOpenTelemetry CollectorをCloud Runのサイドカーとして走らせてみようと思います。 TL;DR Cloud Runのマルチコンテナーサポートを使うと、アプリケーション側はOTLP送信の実装だけして、OpenTelemetry Collectorをサイドカーとして走らせて、テレメトリーをCloud Opsや外部のオブザーバビリティツールに送ることが可能になります。 構成 Kubernetesで使っているようなポッド内のサイドカーの構成をCloud Runでもできますよ、というだけなので、それをわかってる
技術書典#16向けに 「The Cloud Run (Google Cloudコンテナ設計本)」を執筆しました - How elegant the tech world is...!
はじめに お久しぶりです。iselegantです。 今日は技術書典#16向けに執筆した「The Cloud Run」本の紹介をさせてください。 今回のテーマは「Google Cloud」です！ 特に、コンテナサービスとして代表的な「Cloud Run」のアーキテクチャ設計をテーマに執筆しました。 techbookfest.org これまで、「クラウドネイティブシリーズ」と称して3冊執筆してきましたが、その第4弾の位置付けになります。 いつもであれば、わりとゆるくかわいい感じの表紙でしたが、今回は「ちょっと本気でCloud Runに向きあって、読者のみなさまに価値を届けようか」とのコンセプトなので、本気度を表現するためにシリアスな表紙を作成いただきました。 今回の書籍のコンセプト 僕たちが今回の書籍を執筆する際、2つのコンセプトを大切にしています。 実務に通用する学びを届ける とにかく楽しく
Amazon ECSとCloud Runの相互理解で広げる�クラウドネイティブの景色 / Mutually understanding Amazon ECS and Cloud Run
CloudNative Days Winter 2024の登壇資料です。 https://event.cloudnativedays.jp/cndw2024/talks/2438
Dockerfileを書かずにNext.jsアプリケーションをCloud Runにデプロイする｜GCP｜開発ブログ｜株式会社Nextat（ネクスタット）
こんにちは、ナカエです。 当ブログでも何度か紹介している Cloud Native Buildpacks はDockerfileを書くことなくコンテナイメージをビルドできる仕組みの一つです。 参考：Dockerfile不要！Cloud Native BuildpacksでLaravelアプリケーションのコンテナイメージを作成する Google Cloud Buildpacks Google Cloud Platformには Google Cloud Buildpacksとして Buildpacks への公式サポートが存在します。 参考： Google Cloud now supports buildpacks | Google Cloud Blog 以前のBuildpacksとCloud Runの組み合わせを紹介した記事では、Google Cloud BuildpacksがPHPのアプリケ
こんにちは、インフラ部の id:sue445 です。 今回はRendertronをGKEとCloud Runの両方で構築した話をしたいと思います。 tl;dr; 前置き 今までのRendertronの問題点 GKE版Rendertronについて GKEの採用理由について GKE版Rendertronの構成 全体 GKE内部 pod内部 Kubernetesの設定と解説 rendertron-deployment.yaml rendertron-hpa.yaml rendertron-ingress.yaml rendertron-service.yaml Tips nodeのストレージサイズをケチり過ぎたらpodが起動できなくなった N1マシンタイプのnodeとN2マシンタイプのnodeを比較した結果、N2マシンタイプが安くなった Cloud Run版Rendertronについて Clou
Firebase AuthenticationとCloud Runを使ってマイクロサービスっぽく認証機能を作り直してみた (1/2)｜yusukeoshiro
Firebase AuthenticationとCloud Runを使ってマイクロサービスっぽく認証機能を作り直してみた (1/2) 大城です。 今日は僕が大好きなFirebaseについて書いて見ようと思います。皆さんFirebaseも使っていますか? 一人のエンジニアとしては本当にお世話になっているサービスです。(しかもほぼタダで。。。) さて、アプリケーションを構築していれば当然認証と認可の機能は必要になってきます。しかし最近のモダンなアプリケーション開発における認証についてはとても複雑になって来たと思います。 古き良き時代もありました。一つのWebサービスがあって、ユーザのIDとPWはハッシュ化してデータベースにいれておけばよかったわけです。しかし今はユーザはログインする際にいろんなオプションを求める様になりました。 • SNSアカウント(Google, Facebookなど)でログ
※この投稿は米国時間 2023 年 2 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run を使用すれば、デベロッパーは、Google のスケーラブルなインフラストラクチャ上で実行されるサーバーレス環境に本番環境のウェブ アプリケーションと API を簡単にデプロイできます。開発チームは Cloud Run を活用して開発のアジリティを向上させ、迅速に反復処理できますが、多くの場合、インフラストラクチャのセキュリティ体制が見落とされています。十分な注意が払われていないセキュリティの側面として特に注目すべきなのが、アクセス管理と最小権限の原則です。 最小権限の原則とは、あるリソースに対してその機能に必要なリソースのみへのアクセスを許可することを示します。この原則は、ID の侵害によって攻撃者に幅広いリソースへのアクセスが許可されるリスクに対応
Google Cloud Run と AWS Lambda のコールドスタート時間を言語別に観察してみる - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? コンテナをリクエスト処理時間ベースの料金体系で実行できるサーバレス環境としては、Google の Cloud Run（2019年11月GA）と AWS Lambda（2020年12月にコンテナに対応）が特に有名でしょう。 これらの環境は、一度起動したコンテナインスタンスをしばらく生かしておき、その後のリクエストに使いまわします。しかし、生きているインスタンスが足りない場合は新たなコンテナの起動から始めるいわゆる「コールドスタート」となり、応答のオーバーヘッドが大きく増加します。用途によっては、このコールドスタートにかかる時間が問題になり
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
個人開発のサービスをVPSからVercelとCloud Runに移行した話
Cloud Run でマイクロサービスを作る 5 つのポイントをまとめてご紹介！
Cloud Run + Litestream で RDB を使いつつ費用を格安に抑える
Cloud Run で作るサーバーレス アーキテクチャ 23 連発 - これのときはこう！
ここまで簡単になったNext.js on Cloud Run
Dockerfileを自前で書かずにCloud Runを動かす技術
Next.jsのスタンドアロンモードでビルドしたイメージを Cloud Run へデプロイする
Cloud RunがIAPでよりお手軽に認証できるようになりました！
NestJS + Prisma + Cloud Run + Cloud SQLを試す
【Node.js/Next.js】Cloud Runで動作する軽量なDockerを構築してみた
RailsでCloud Runは1月いくらかかるか - komagataのブログ
HerokuからCloud Run + Litestreamへ移行した - memo.yammer.jp
Introduction to Cloud Run 2021
Cloud Run Jobs がリリースされたので、何ができるか試してみた！
サーバーレス コンテナ Cloud Run に待望の新機能 Always on CPU が登場しました
Cloud Runで手軽にサーバーレス・SSR(サーバーサイドレンダリング) - dely Tech Blog
Cloud Runで開発用環境を沢山作る - 一休.com Developers Blog
Cloud RunでOpenTelemetry Collectorをサイドカーとして動かす
RendertronをGKEとCloud Runで構築しました - pixiv inside
最小権限の原則による Cloud Run のデプロイ保護 | Google Cloud 公式ブログ
www.upcomingevents.com
amass.jp
blog.takaumada.com
news.yahoo.co.jp
www.tetsudo.com
ozlink.co.jp