「GCPUG Tokyo Container Builder Day February 2018」に行ってきました

GCPUGは神戸以来の2回目で参加させていただきました。
申し込もうかと思ったら、一般参加枠が定員を余裕で越えていたので、Blog枠で申し込みました。

コンテナ使ったことないし、知らないし、でももうやらないと、いよいよやべーぞと思ってた矢先だったので、知らない人ほど勉強会に参加するべきでしょ、って思ったので参加しました。
どこまで理解できるかってのはありますが、これを機に、ということでメモしながら食らいついてみます。

Cloud Tools Introduction

最初は「GCPに存在する開発時に利用するToolたちの中でContainer Builderに関わってくるサービスを紹介します。」との@sinmetalさんのセッション。

Cloud Tools Introduction (Googleスライド資料)

Container Builder

GCP上でDocker Container Imageを生成するサービス。
GitHubをトリガーに起動することも可能、なので、ちょっとしたCIとしても使えるらしい。
「gcloud contaner builds」コマンドで実行したものはgs://になっている。
トリガーは[Build Trigger] – [Create trigger]メニューから設定できる。
設定ファイルはDockerファイルか、YAMLでかける。
Docker Imageは公式で用意されているのがあるので、とりあえず始めるの楽そうです。
n1-standard-1なら毎日120分は無料なので、個人で試してみるのは、賄えそうな気がします。

ビルドの結果はGoogle Cloud PubSubトピックにメッセージが公開されるらしい。Google Cloud PubSubトピックも初めて聞きましたが、きっと名前から見てこれはキューのように使えるのだろうな。ビルドと結果の処理は非同期で実装する、ということだろうか。

secret.jsonをCloud KMSで暗号化してリポジトリに保存できる、そしてビルド時に復号化できる、これをCIでやろうとすると暗号化のメリットが享受出来ない(KMSのコマンドを実行するためのキーをCIに書くから？)ので包括されているのは嬉しいとのこと。

Container Registry

Container Builderで出来上がったDockerのイメージを保持しておくプライベートレジストリ。
実態はCloud Storageらしい。
「gcloud docker —pull」コマンドで手元のDocker環境に持ってこれる。

料金はCloud Storageのストレージ料金が課金される。Cloud Storageのライフサイクルを使うと自動で削除も出来る。

Cloud Source Repositories

プライベートのGitリポジトリであり、それ以上でも以下でもないとのこと。
名前のとおりですね。
GCPのIAMの権限が設定できるからその点が便利。なるほど。

Google Container Builder と友だちになるまで

続いては、「実例をお見せしながら、Google Container BuilderからGKEへデプロイするパイプラインを構築する際に行った様々な泥臭い施策について説明します。」との@lestrratさんのセッション。

「何か疑問に思ったら手をあげてください」
「1人が疑問に思ったことは他の人も疑問に思っているはず」という素敵なコメントから始まりました。
質問を躊躇する人の背中を確実に押していると思いました。

CIと構造が似ているけどCIサービスではないとのこと。

Google Container Builderを使うべきケースの理由は、
* コンテナイメージを作る目的
* GCP上にリソースが全部ある
* リモートデバッグをしたくない
とのこと。

Google Container Builderを使わないケースの理由は、
* コンテナ使わない
* テストをまじめに走らせたい
* GCPのサービスを使ってない
とのこと。

そりゃそうですよねw
これは私にも理解できた。

CIとGoogle Container Builder(GCB)の違いは、
* CIはコマンドを指定していく
* GCBはコンテナイメージを操作していく
とのこと

デバッグどうする？！

デバッグはentrypointを使うと任意のコマンドを実行できる。
これもドキュメントから探すのは非常に困難らしいw

Google Source Repositoriesを使えないのでプライベートレポジトリを使う

GitLabはGitHubのようにGoogle Source Repositoriesでサポートされていない。
Google KMSを使って、プライベートのGitLabレポジトリからソースをcloneしている。
このやり方をドキュメント群から探すのは非常に困難らしいw

ローカル環境での実行

クラウドCIサービスはジョブを送って待って失敗したら手元に環境がないので手探りでデバッグするのが辛い。
GCBは全部ローカルで実行が出来る。
ローカルで実行することで問題解決が早い、爆速とのこと。

確かにそうですね。
GitHubのリポジトリでテスト結果待ってて、直して、コミットしてプッシュしてまたテスト待ってまた直してって、待つ時間がわりともったいないですもんね。

「ドキュメントのクセとして、真実はAPIリファレンスにある」
これは、GCPに限らず、開発の現場ではよくある気がします。
「動いているものが真実」ってのは、うーん、仕方ないというか、ある程度はそれもでいいと思っている派です。

懇親会

メルカリさんからビールとおにぎりとメルカリ水のご提供！
ありがとうございます！

最後に

機能を知りたいだけでしたら、資料を見たり、試してみたらいいのかもしれないですが、サービスやツールやドキュメントに対しての現場の声が聞ける、そして困ったことやつまずいたポイントが聞けるのが、ユーザー会のいいところですね。

GCPを知らないまま参加したのに、Google Container Builderがなんとなく分かったので、GCP使われている方には、すごくいい、知見が溢れている勉強会だったんじゃと思いました。

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。

「AWS認定資格試験テキスト　AWS認定AIプラクティショナー」という本を書きました。

「AWS教科書 AWS認定デベロッパーアソシエイト テキスト＆問題集 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。