GCBを利用したContinuous Delivery環境
GKEのContinuous Delivery環境といえばSpinnakerが有名ですが、私達はもっと簡単に、GCB(Google Container Builder)を使ってデプロイしています。今日はその設定方法について説明したいと思います。 GKEサービスであるvte.cxは、以下のような構成になっています。 GitHubリポジトリにpushすると、GCBでDockerイメージを作成し、コンテナ起動、サービス起動を自動で行うことができます。既に起動しているPodがあれば安全に終了させて新しいPodを起動します。いわゆる、ローリングアップデートが可能です。 設定方法上記のようなCD環境を実現するための設定方法について説明します。 API追加 Google Cloud Platform 管理画面左の「APIとサービス」をクリック「APIとサービスの有効化」をクリックGoogle Cloud
kubernetes使いは全員 stern を導入すべき
まぁこれは基本的に膨大なログを見ている時に、ピンポイントで絞り込み検索をするという行動を前提としてるからだと思うんだけど、デバッグとかしてるときは「スゴク、コレジャナイ感…」がするわけです。 なので、そんな時はもう素直にkubectl get podsして、kubectl logs -f …. している自分がいました。 まぁこれでも充分なんです。充分なんですけど、辛い事が二つあって。 まず複数のコンテナにロードバランスされるペイロードに関しては自分が見てるコンテナにアクセスが来るとは限らないから全部のコンテナのログを見てるか、自分の見てるコンテナにアクセスが来るまで読み込み続けなければならない。 もうひとつは、開発をしている間の話なので、kubectl applyでdeploymentをガンガン入れ替えているのでコンテナもどんどん世代交代するわけです。そうすると… そう、当然コンテナはデコ
GAE で PubSub に毎分毎時毎日メッセージを投げると便利
TL;DR Google App Engine を用いて Cloud PubSub に一定時間でメッセージを投げると、 それをトリガーに Cloud Functions を実行することができます（もちろん GKE などもサブスクライブできます）。 これは定期的に何か処理を実行したいときにとても便利です。 用語説明 Google App Engine (GAE) Web Application を GCP 上において実行できるサービス PubSub パブリッシャ・サブスクライバ型のメッセージングモデル Cloud PubSub の説明はこちら Cloud Functions AWS でいう Lambda UseCase ある Web サイトを定期的に監視して、その Web サイトに”変化”があったら Slack に通知を投げて自分のスマートフォンで Push通知を受け取りたい というのはよく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jyane/gae-cron: GAE Cron for Cloud PubSub
