先日、GCPからGCEインスタンスに付与した外部IPを有料化するという連絡がきました。 現在はGCEの料金表にも次の記載があります。 月額300円程度ですが、月々かかってくる費用なので少しでも安いほうが嬉しいです。 そこで、外部IPを持たないGCEインスタンスでWEBサービスの開発を行う方法を試してみました。 GCEインスタンスの作成 まずは、外部IPを持たないGCEインスタンス instance-1 を作成します。 ここでは80番ポートで開発用webサーバを起動するために、「Allow HTTP traffic」にチェックをつけました。 もし他のポートを利用する場合は、そのポートで通信できるようにFirewallルールを設定してください。 少し待つとインスタンスが作成され、外部IP(External IP)が付与されていないことが確認できます。 SSHによる接続とwebサーバの起動 作成
ナウなヤングにバカウケのMastodonのアカウントをそろそろ作った方がいいかな〜と思ってついこの前アカウントを作りました1。 しかしただアカウントを作るだけではあんまり面白くないので、この際だからということで自分だけの個人インスタンスを建ててみました。せっかくドメイン名も持ってるし 構成 今回はGCEの無料枠インスタンス(e2-micro @ us-west-1)一本で建てました。Postgresもredisもnginxも全部この中です。 ディスク30GB、メモリ1GBと小さいインスタンスですが、1ユーザくらいであれば問題なく動きます。 OSは少し気になっていたNixOSを導入してみました。 システム構成をすべてテキストで書くのはなかなか難しいところがありましたが、結果としてはこのOSを選んで正解だったと思います。 NixOS NixOSはLinuxディストリビューションのひとつで、特徴
この記事の内容 GCP(Google Cloud Platform)上の Compute Engine にグローバルIPを振らなくても、IAP(Identity Aware Proxy) を経由すれば、内部VPCに直接乗り込める その手順を sshクライアントの設定ファイルに書くと、openSSHなどでホスト名を指定するだけでIAP経由で接続できるようになる VS Code の Remote SSH を併用することで、VS Code でCompute Engine側の環境上での開発がはかどる 必要な予備知識 こちらをどうぞ 手順 GCEの「ssh接続」をドロップダウンすると「gcloudコマンドを表示」と出てくる。こいつに --tunnel-through-iap をつけると iap経由で接続できる。 つまり HTTPS経由で接続できる。なお、https_proxy環境変数に http:/
はじめに コスト削減のため、踏み台VMや開発・ステージング環境でのVMは、営業時間外は停止しておきたいという要件はよくあると思います。 GCPでは自動停止構成を組む選択肢2つあり、個人的には後述2つ目がシンプルで良いなと思ったので、メリデメとterraformの例をまとめました。 構成案 案1. Scheduler + Functionsで停止 AWSでも EventBridge + Lambda でEC2やRDSを自動停止させたりする上、ドキュメントでも紹介されており真っ先に思いつきそうな構成です。自分も最初はこの構成組んでました。 terraformで管理する場合は、下記リソースが必要です。 Cloud Functions + Cloud Scheduler + Pub/Sub Functionsのソースコード Cloud Storage(ソースコードをアップロードする用) 案2. G
TL;DR こちらのリポジトリを参考にしてください -> https://github.com/nekoshita/gcp-ssh-to-vm-instance-using-iap-example こんな人向け Cloud IAP について知りたい GCPのVPCとかsubnetとかFirewallとかよくわかんない GCPのVMインスタンスに踏み台サーバーなしで接続したい terraformでGCPさわりたい 解説 CloudIAPの仕組み こちらの図がわかりやすいです https://cloud.google.com/iap/docs/concepts-overview#how_iap_works GAEやGCEなどで動作するアプリケーションへのアクセスを制御するためのID認証プロキシサービスです なので、VMインスタンスに外部IPアドレスがなくてもSSH接続できるようになります GC
TL;DR こちらのリポジトリを参考にしてください -> https://github.com/nekoshita/gcp-cloud-nat-example こんな人向け Cloud NAT について知りたい&使ってみたい GCPのVPCとかsubnetとかFirewallとかよくわかんない terraformでGCPさわりたい Cloud NAT について Cloud NAT とは NATを提供してくれるGoogleのマネージドサービスです 外部IPアドレスを持たないVMインスタンスや限定公開のGKEクラスタからインターネットへアクセスできるようになります Cloud NAT のメリット 個々のVMに外部IPアドレスを割り振る必要がなくなるのでよりセキュアになる 分散マネージドサービスなのでプロジェクト内のVMや単一の物理ゲートウェイデバイスには依存しない NATのIPアドレスを自動で
TL;DR こちらのリポジトリを参考にしてください -> https://github.com/nekoshita/gcp-vm-instance-in-subnet-example こんな人向け GCPのVPCとかsubnetとかFirewallとかよくわかんない GCPで踏み台サーバー立てたい AWSと全然違うからよくわかんない terraformでGCPさわりたい 解説 ネットワークとサブネット まずは新しいVPCネットワークを定義します。 (VPCネットワークについて: https://cloud.google.com/vpc/docs/vpc?hl=ja ) GCPプロジェクトを作成すると、デフォルトのVPCネットワークが作成されますが、こちらは公開設定されているので使いません。 VPCネットワークはグローバルリソースなので、リージョンやゾーンは指定しません。 resource
Google Cloud、仮想マシンのサスペンド/レジュームが正式機能に。開発環境の未使用時にサスペンドでコスト削減など実現 仕組みもノートPCの実装に似ている サスペンド/レジューム機能は文字通り、まるでノートPCの画面を閉じて作業を一時停止させ、画面を開いて作業を再開するように、仮想マシンの一時停止と再開を可能にします。 そしてレジュームによって保持された状態から処理が再開できます。 仮想マシンのサスペンドでは、ゲストOSのメモリ、デバイスの状態、アプリケーションの状態が保持されます。これがインスタンスの停止とは異なります。 サスペンド機能は一時停止信号の「ACPI S3」がOSに送信されることで実現されるため、技術的な面でもノートPCのサスペンド/レジュームの実装に似ていると言えるでしょう。 そのためCompute Engineで提供されているほとんどのOSでサポートされています。
はじめに こんにちは、CX事業本部MAD事業部の森茂です。 本エントリーはクラスメソッドGoogle Cloud Advent Calendar 2021の18日目の記事です。 本記事の執筆でGoogle Cloudデビューしました。 みなさんもojichatをもっと手軽に利用できないかという相談をうけることがよくあるかと思います。 今回はそういったご要望に応える方法のひとつとして、Google Cloudの仮想マシンを作成できるサービスであるGoogle Cloud Compute Engine(以下GCE)をTerraformで構築し、手軽にコンソールのSSHターミナルからojichatを実行できる環境を構築してみました。 環境構築 Terraformを使って環境を構築するには事前の準備が必要になります。下記ツールのインストールとGoogle Cloudで利用できるプロジェクトを管理コ
TerraformでGCE環境を構築した際の手順です。(Terraformは予めインストールしておいてください) サービスアカウントの用意 TerraformでGCE環境構築する際に使用するサービスアカウントを用意します。 サービスアカウントを用意したらJSON形式で鍵を作成してください。 また、インスタンスを立てる際、サービスアカウントにインスタンスを立てる権限がないと権限エラーでひっかかります。 公式ドキュメント(https://cloud.google.com/compute/docs/access/iam?hl=ja#the_serviceaccountuser_role)によるとCompute インスタンス管理者(v1) とサービスアカウントユーザーの2つの権限が必要になるのでIAMから付与してあげてください。 .tfファイルを用意 サービスアカウントが用意できたら、.tfファイ
目次 これは何 やってみた履歴 手順詳細 1. これは何 今回は「グローバルIPアドレスを持たないセキュアなGCE環境」と「VSCode Remote Development」を組み合わせて、グローバルIP経由しないリモート開発環境を実現する方法を記載しています。 VSCode Remote Development、もしくはGoogle IAP単体記事は見つけましたが、両方を組み合わせた記事が無かったので忘備録として記録しておきます。 最後に詳細な手順を記載していますので、経緯飛ばして手順を知りたい方は 手順詳細 から読んでください Identity-Aware Proxyとは Google Cloud のIAP(Identity-Aware Proxy)ってご存知ですか? 既存のWEBサービスに対して認証機能を挟むことができる仕組みです。その機能の中に TCP 転送での IAP の使用
最近 iPad Pro を購入したため、これを開発環境のとしても活用できると良いなと思い、GCP でプリエンプティブな GCE インスタンスを作成した。 インスタンスに https://github.com/<username>.keys 経由で取得できる github に登録した自分の公開鍵を設定した。こうすることで秘密鍵を github に使っているものを利用することができる。 これで手元の ~/.ssh/config をこんな感じで修正すればもう使えるものだと思ってた。 Host gce Hostname <external-ip> IdentityFile ~/.ssh/github User codehex ForwardAgent yes 実際には使えていたが、暫くすると external-ip (以降、外部 IP)が突然変わってしまって毎回 config ファイルを修正してい
GCPでブログ立ち上げ後、半日に一回くらいDBに接続できない旨のエラーが出ます。そのトラブルシューティングは別にするとして、対症療法的にVMを停止→起動したところサーバは復旧したもののIPアドレスが変わってしまいました。 そういえばGCPのコンソールで、IPアドレスの欄には「エフェメラル」と書いてあります。 なんか最強の武器の材料になる魔法石みたいな単語だけどephemeral(短命な)という英単語で、恒久的に割り当てられたIPアドレスではないという意味みたいです。停止、起動のたびにDNSを設定し直すのは大変面倒。 再起動しても変わらない静的IPアドレスを割り当てられるみたいなので設定してみました。 GCPのコンソールでインスタンスの詳細画面で「編集」をクリック。 編集画面でネットワークインターフェースの鉛筆マークを押す。 「外部IP:エフェメラル」となっているプルダウンリストをクリック。
ども、takiponeです。GCPの500ドルクーポンをゲットしたので、GCEをいろいろ触ってみたいと思います。 GCP(Google Cloud Platform)はGoogleが提供するクラウドサービスの総称で、GCE(Google Compute Engine)は、そのうちの仮想マシンを提供するサービスです。AWS(Amazon Web Services)とAmazon EC2の関係に似ていると思っていただければ良いと思います。(厳密に言うと、GCEにはネットワーキングやディスクストレージも含まれるので、Amazon VPC、Amazon EBSなどを内包します。) GCE自体の入門は、以下のブログ記事が詳しいです。 Google Cloud Platformをはじめようチュートリアル #gcpja - インフラエンジニアway - Powered by HEARTBEATS 今回は
GAE/GCEのログ監視 & GAE/GCEのエラーログをCloud Logging -> Cloud Pub/Sub からの GASでSlackへ流すGoogleAppsScriptGoogleAppEngineGoogleCloudMonitoringgooglecloud この記事はGoogle Cloud Platform Advent Calendar 2015 10日目に投稿する予定だったのですが筆者が胃腸炎になり書くことができず投稿が遅れてしまった記事です。 楽しみにされてた方申し訳ございませんでした。。。。 システムを運用しているとログってとても重要ですね。 ただエラーログを検知して、問題があるシステムのログを閲覧可能な場所にアクセスし、そのログを特定するのは結構面倒だったりします。 GAEでもLogs Viewerがありますが、そこまでパフォーマンスも良くはなく、わざわざ
前回、Google Compute EngineでオートスケールするWebサーバーを構築しましたが、ログが各サーバーに分散したり、インスタンスが終了するとログも消えるので、Fluentdでログを一カ所に集めることにしました。 オートスケールは便利だがどこに接続しているかわからん前回の記事↓ 前回、GCE上に負荷に応じて自動でサーバーが勝手にできあがっては消えていくオートスケールのWordPressサーバーを構築しましたが、問題が起きたときのログを確認するのが非常に面倒だと気づきました。 MarsEditからWordPressに画像投稿すると、絶対に投稿に失敗するという問題が起きていまして(現在は解決)、ただWebサーバーが複数あるので、一体どこのサーバーにエラーログが残っているかわからない。片っ端から見るのは面倒…。 Fluentdというのが流行 最初はsyslogでログを転送して一カ所に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く