TCP 転送に Cloud IAP を使用する | Identity-Aware Proxy のドキュメント | Google Cloud
こんにちは、インフラ開発部のsandatsです。 今日はGoogle Cloud認定資格 Associate Cloud Engineerの話をします。 Google Cloud認定資格 Associate Cloud Engineerについて Google Cloud認定資格 Associate Cloud Engineerは、Google Cloud認定資格の1つです。 Google Cloud認定資格の中では初めの一歩的な位置付けで、公式から推奨される経験としては「GCPの実務経験が6か月以上」と記載がありました。 また、補足ですが2019年7月23日時点で日本語で受験できるGoogle Cloud認定資格は以下の4つでした。 Google Cloud Certified – Associate Cloud Engineer Google Cloud Certified – Prof
はじめにお仕事でGCP使って環境を構築することがあったのですが、色々とハマることが多かったので供養を兼ねて共有したいと思います。 当時の私の経験値としては「AWSの一部サービスは触ったことがある」程度でクラウド環境を下地から構築するのは初めての経験でした。一度触ってみれば常識だよねって内容が多いですが、初心者が小石につまずいてもすぐに立ち上れるようになれば幸いです。 今回構築した環境の概要 既存のオンプレ環境との共存を前提とし、使えるアドレス範囲もオンプレのNWから払い出し オンプレ環境とインターネットVPNでつなぐプロジェクトは1つ(ホストプロジェクト) 各環境(production、staging・・)は共有VPCで接続(サービスプロジェクト) なお、構築はTerraform, Ansibleで行いました。 GCPで環境構築してハマったこと本編です。 カテゴリ別に記載しています。 1.
GCP ではオンプレミスで稼動する VMWare 上の多くの仮想サーバを、効率的にマイグレーションする事ができる Migrate for Compute Engine(旧 Velostrata)が利用できます。Migrate for Compute Engine を利用するためには事前の環境整備が重要です。このセ...
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 を入れてくれるヘッダです。そのため
個人用メモです。 !! ======================== !! ※この記事は2019年の記事です。著者はもうWordPressを使用しておりません。この記事で紹介している内容は2019年当時の内容である事を理解した上で、実際に設定する際は最新の情報を確認しながら行ってください。 2019/9/26追記 2020年1月1日より静的IPが有料になる旨Googleから発表がありました。 $0.004/時間=最大約300円/月が有料となります。 それ以外の部分についても無料でなくなり次第記事を更新してまいります。 情報: @mattn 様 2020/3/20追記 まだ請求額が0円だったので「あれ?」って思って調べたら、上記の静的IP有料の変更は1/1から反映されてるものの、キャンペーンで2020/4/1までは割引されている事に気がついたので注釈追記しました。ちなみに割引されなかった
概要 Cloud Run on GKEでKnativeがどう使われているのかを調べたい Cloud Run on GKEの挙動と仕様をなんとなく理解した気になりたい 現在Cloud Run on GKEはCloud Run for Anthosになっている 環境構築 公式ドキュメントにCloud Run on GKE関連のチュートリアルベースにGoogle Cloud Shellで準備していきます。 Cloud Run on GKEが使えるクラスタの準備 Knativeでオートスケールを試すためのDockerイメージ利用 ソースコード: autoscale.go この記事では一からKnative自体の説明はしないので、公式ドキュメントや拙著『Knativeの歩き方 KubernetesからServerlessを訪ねて』、登壇資料などを参考にしてください。 ここからGoogle Cloud
普段、GitLabを利用してソースの管理をすることが多いので、今まではGitLabCIを利用して色々CI/CD周りを作ることが多かったのですが、最近、GCPをメインで使っているので、CloudBuildで出来ないかなと言う事で実験して見ました。 今回、作成した構成は、以下の通りです。自分の為のメモ書きです。 構成図 GitLab->CloudSourceRepositories間の連携 下記記事を参考に設定しました。 https://qiita.com/tarosaiba/items/850042d6383ac5b7ef47 CloudBuildの設定 ここに関しては、UIに表示された通りに選択する事で基本的に詰まる事はありませんでした。 リポジトリの直下に専用のフォルダ(hogehoge)を作成してあったので、各コマンド実行時にcd してから実行しています。 gaeの古いバージョンを定期
2019/5/2 に現れた、GCPリソースをTerraform用のtfファイル化するっぽい https://github.com/GoogleCloudPlatform/terraformer を使ってみた。 小さく躓いたものの、使うことはできた。 まだ v0.7 のようだし、今後に注目したい。 自分の狙いは Datastore の Terraform 化(?) だったので、叶わなかったのですが。[^1] 実行時環境情報 macOS Mojave 10.14.4 Terraform v0.11.13 provider.google v1.20.0 -> v2.0.0 を指定して terraform init することで upgrade 可能 [^2] terraformer v0.7 [^3] インストール https://github.com/GoogleCloudPlatform/te
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) ランタイムとしてリリース
Google Cloud Next 2019 in San Francisco が 2019 年 4 月 9 ~11 日に開催されました。その中で、DevOps 関連の発表をまとめました。 Cloud Code for IDEsCloud Code を利用することで、クラウドネイティブアプリケーションを、より速く、より簡単に、開発・デプロイ・デバッグすることができます。Cloud Code for VS Code (Beta)、Cloud Code for IntelliJ (Alpha) で利用可能です。 コンテナを使ったアプリケーションを開発する場合、ソースコードを編集するたびに、コンテナのビルド・デプロイを繰り返す作業が頻繁に発生するため、開発以外の作業に多くの時間を取られてしまいます。 Cloud Code を利用することで、ソースコードの変更を自動的に検知し、本番環境へのデプロイ
[18 分 20 秒 ~] Cloud Runの概要とデモ、特に [34 分 00 秒 ~] のオートスケーリングのデモはCloud Runの優位性が分かる内容ですさらに Cloud Run に全振りしたセッションとしては以下がオススメです。Cloud Run のリソースモデルや、またCloud Tasks や Cloud Scheduler との連携、さらに具体的なユーザー事例まで盛り沢山です。また、このセッションを見る限り東京でも Cloud Run がすぐに使えるようになりそうです。 [36 分 50秒 ~] VELOLIA 社の事例紹介現状は何に使えそう?Knative をベースにしているものの、今のところ Eventing は Cloud Run と Cloud Run on GKE 両方ともにサポートされておらず、当面は Web や API をホストする環境として使うことになる
はじめにGCP にはあらかじめ HTTP のエンドポイントを登録しておくと、そこに対して HTTP リクエストが送られてくるようなプロダクトがいくつか存在します。 Cloud Pub/SubCloud TasksCloud Schedulerどれも非同期系の処理を行うプロダクトであり、非同期処理を行う Worker を HTTP の Web サーバとして記述できるのが大きなメリットになっています。 しかしそれらの Web サーバはパプリックなエンドポイントとして用意することも多いことから、送られてきた HTTP リクエストが本当に GCP の特定のプロダクトから送られてきたものなのか?という「認証」をどうやるかが長らく問題になっていました。 既存のやり方としては Web サーバの実装方式によっていくつかありますが、 App Engine (1st gen) を使う場合: “login: a
こんにちは! App EngineのスタンダードランタイムにRubyが追加されて喜んでいるバックエンドエンジニアのりほやん(高木)と、オレンジ色のチンアナゴは実はニシキアナゴという別種だったことに驚きを禁じ得ない塩ちゃん(塩崎)です。 4/9, 10, 11の期間で開催されたGoogle Cloud Next '19にZOZOテクノロジーズから高木と塩崎が参加しました! GCPの新しい機能や活用についての事例が多く紹介されました。 その中でも2人がカンファレンスで気になった技術を紹介します。 Cloud Run Cloud Runとは Cloud Runの特徴 実際に使ってみる 1. アプリケーションの準備 2. コンテナイメージをビルドする 3. Cloud Runにサービスを作成する App Engineとの違い サービスの比較 各サービスの概要 App Engine Cloud Ru
Cloud Run とはGoogle Cloud Next 18では serverless containers on the Google Cloud Functions infrastructure + GKE Serverless addonと説明されたものですね。 早速、こちらのQuickStartやってみましょう 事前に必要なことプロジェクトを作成する(既存のプロジェクトを利用することもできます。終了後の後片付けを考えると新しくプロジェクトを作っても良いです)プロジェクトのbillingを有効にするCloud Run APIを有効にするCloudSDKのインストール済み/設定済みであることcomponentsのupdateと、beta componentsのinstallが必要です。コンポーネントをupdateするgcloud components updatebetaコンポーネ
GCPを利用すると、アジア、アメリカ大陸、ヨーロッパなどのリージョンを選ぶことが出来ますが、その各リージョンがネットワーク的にどのぐらい遠いか(RTT)を計測してみます。 リージョンはこのぐらいあります。 リージョン間のRTTを計測する際の注意点 こちら にある図を見るとわかりますが、Googleのネットワークは、日本⇔ヨーロッパと言う経路を考えた際、インドから西を通るルートが無いようです。 実測するとわかりますが、日本⇔ヨーロッパ間でアクセスすると、太平洋を経由しアメリカ大陸経由でアクセスされます。 実際に計測してみる 今回は、 アジア : 東京 アメリカ(西) : Los Angeles アメリカ(東) : N Virginia ヨーロッパ : Frankfurt を利用して計測します。 経路的には以下の6つのルートに対して計測をしました。 東京 → ヨーロッパ 東京 → アメリカ(東
この記事はGoogle Cloud Platform その1 Advent Calendar 2018 - 18日目の記事です。 以前こういうブコメをしたのですが、言いっ放しだとダサいので、具体的なやり方を書きます。 "アカウントごと/日付ごとのBigQueryコストを可視化できるダッシュボード" なら Stackdriver + BQ + Datastudio を使うと作業時間10分・ほぼ無料で作れるので、うちはそのやり方を採用していますね。… https://t.co/9yoni22iw7— ゆずたそ (@yuzutas0) August 17, 2018 もくじ もくじ はじめに この記事のゴール 解決したい課題 課題の背景 実行方針 完成イメージ 作業手順 1: BQクエリ実行ログを流す 2: DataStudioでダッシュボードに表示する 応用編 1: 全体コストを可視化する 2
本記事は Google Cloud Platform その2 Advent Calendar 2018 の4日目の記事です。 はじめにCloud Spanner はトランザクションの一貫性保証のレベルに External Consistency を採用しており、複数のトランザクションが一貫性のある状態で並行に走れるよう制御されています。 ではその一貫性保証とは、具体的にどのような問題 (Anomaly) を防いでくれるのでしょうか。 本記事では、一貫性保証のレベルが弱い時に起こりうる以下の様々な Anomaly を Cloud Spanner ではどのように防いでくれるか、実際に複数のトランザクションを実行して検証していきたいと思います。 Dirty ReadLost UpdateNon-repeatable ReadPhantom ReadRead SkewWrite Skewこれらの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く