最近は GCP 関連のイベントもほとんどがオンラインになりましたね。
興味ありそうな内容のイベントがあっても気づけなかったり、知っていても調べるのが大変、というのがあったと思いますが、公式にイベントアーカイブページが公開されていました。
Google Cloud Japan '20 イベント アーカイブ - ホーム
とても便利ですね。
私も漏らしているものなど、振り返っていろいろ見てみようと思います。
ではでは。
最近は GCP 関連のイベントもほとんどがオンラインになりましたね。
興味ありそうな内容のイベントがあっても気づけなかったり、知っていても調べるのが大変、というのがあったと思いますが、公式にイベントアーカイブページが公開されていました。
Google Cloud Japan '20 イベント アーカイブ - ホーム
とても便利ですね。
私も漏らしているものなど、振り返っていろいろ見てみようと思います。
ではでは。
タイトルの通り、IntelliJ 版の Cloud Code プラグインを利用して、 Cloud Run をデプロイすることを試してみます。
内容は こちら GCP ドキュメント をベースにしています。
GCP のプロジェクトの課金を有効にしておく必要があります。
また、その他、開発などに必要なツールや、IntelliJ などはすでにインストール済みである前提です。
また、Cloud Run を利用する GCP プロジェクトを事前に作成しておく必要があります。
IntelliJ のプラグインマーケットプレイスから [Cloud Code] を検索してインストールします。
インストール後は再起動を求められるので IntelliJ を再起動します。
Cloud Code のテンプレートを利用しながらアプリケーションを作成する場合には、「File]→「New Project」から 「Cloud Code: Cloud Run」 を選択し、プロジェクトを作成します。
今回は言語は 「Go」 を選択しました。
作成されたプロジェクトは、 Web アプリケーションを作成する際の最低限のスケルトンが用意されています。
出来上がったファイルを書き換えるなどしてアプリケーションを作成していくことができます。
せっかくなので、一気に Cloud Run へのデプロイまで試してみましょう。
上段の実行バーの中から 「Cloud Run: Deploy」 を選択します。
「▶ Run」 をクリックすることで、初回は「Edit Configuration」 のウィンドウが開きます。
GCP とインテグレーションを行い、 Project を指定した後、Run を起動する際に必要な様々な設定を入力します。
入力内容が問題ないようであれば、最下段の 「Run」 ボタンを押して実行します。
しばらく IntelliJ 上のコンソールにログなどが流れるので、エラーが発生していないか確認しておきます。
ちなみに、このタイミングで Docker image を Build などするようで、端末の Docker を事前に起動しておく必要があります。
流れ的には、ローカルで Docker コンテナのビルド → GCRにpushする → Run へのデプロイを行う ということをやってくれているようですね。
コンテナのビルドがなにげにそこそこ時間がかかるっぽい・・・^^;
初回はキャッシュがなかったりするのでなおさら。気長に待ちましょう。あと、Macがだいぶ唸ります。笑
デプロイが成功すると、コンソールに run にアクセスするための https な URL が表示されます。
URLをクリックすると以下のように Run で公開されたウェブコンテンツを確認することができます。
IntelliJ 上で Run にデプロイしたサービスのステータスが確認できるようです。
ログ画面を開くこともできる
めちゃくちゃ便利ですね。
これだけかんたんにデプロイまでできたので、ちょっとだけHTMLファイルを修正してデプロイしてみましょう
この画面の It's running!
の部分をちょっといじってみましょう。
index.html ファイルの 148行目がこの表示部分に当たります
両脇に星をつけてみましょう
~snip~ <div class="message"> <h1>★It's running!★</h1> <h2>Congratulations, you successfully deployed a container image to Cloud Run</h2> </div> ~snip~
変更が完了したら、ファイルを保存し、右上の 「▶ Run」ボタンを実行しましょう
初回とは違い、今回は設定内容などは確認されず、そのまま新しいコンテナがビルドされデプロイが行われます。
このように新しいリビジョンが表示されました
URLからアクセスしてみます。
変更点が反映されましたね。
めでたしめでたし。
みなさん、Amazon で買い物してますか?
以前から、Amazon の価格履歴が確認できるアプリがあることは知っていたのですが、関係ないっしょって感じでインストールしていなかったのですが、何かのきっかけでインストールしてみたら快適だったので共有します。
すでに Keepa をインストールしている人はこのタイミングでブラウザのタブを閉じて良いです。w
よく、 Amazon のタイムセールがタイムセール前に値上げして、タイムセールであたかも大幅値引きしている風に見せる罠などの話を聞きますが、このツールをインストールするだけでそういう罠を回避できます。
比較的高価な家電なども高値づかみすることなく安心して購入でき、いろいろなサイトを検索して最低価格など相場感を調べる時間などが削減できるので個人的にとても助かっています。
(別にお金をもらっている記事ではありません)
こちら のサイトからインストールできます。
一般的なブラウザは大体サポートしているようです。私は Chrome にのみインストールしているので Chrome の例で下記します。
Chrome ウェブストア からインストールするだけです。
ワンクリックポチーで終了。
これであとは快適な Amazon ライフが楽しめます。
まもなく販売される Sony の WH-1000XM4 というヘッドフォンを見てみましょう
まだ発売されていない商品なので価格の変動は少ないですが、なぜか一時期安い時期があったようですね。
その時期に買いたかった・・・
また、M4 の前のモデル WH-1000XM3 に関しても見てみましょう。
プラグインをインストールしていれば↑のリンクから開くだけです。
なるほど、直近が過去イチぐらいの勢いで値段が下がってるようにも見えます。
新しいモデルが出るというタイミングですが、私も M3 を使っていますがとても満足度の高いヘッドフォンで3万以下で買えるのは買いですね。
そんな感じで最近 Keepa という Chrome Extension を入れたら買い物が捗るよ、という話でした。
ではでは。
Cloud Run を利用する際、defaultではデプロイした新しいリビジョンに対してトラフィックが移行されるような振る舞いになっていると思います。GAE の gcloud app deploy
コマンドで言う --promote
オプション相当です。
ただ、Web の UI などから過去のリビジョンにトラフィックを切り替えたりすると、次回からその appendine の --promote オプション相当の振る舞い(新しいバージョンにトラフィックが流れる)が無効になり、前回トラフィック切り替えをした状態が維持されます。
そのため、 gcloud run deploy
コマンドで新しいバージョンをどんどんデプロイし、新しいリビジョンでリクエストを処理したい場合には新しいバージョンへのトラフィック切り替えが必要になります。
今回はそれをもとに戻しましょうという記事になります。
早速ですが、必要なコマンドは
gcloud run services update-traffic
になります。
GAE に慣れている人の感覚だと gcloud run deploy
のオプションにありそうな気もしますが、 Run の場合には Traffic をコントロールするための別のコマンドで操作します。
必要なオプションは
--to-latest True to assign 100 percent of traffic to the 'latest' revision of this service. Note that when a new revision is created, it will become the 'latest' and traffic will be directed to it. Defaults to False. Synonymous with '--to-revisions=LATEST=100'.
これですね。
マニュアルには default で false になっていると書いてあります。(が、振る舞い的に true な気もするが・・・)
以下のようなコマンドで実行します。
gcloud run --project=${PROJECT_ID} services update-traffic --to-latest
最低限上記のオプションぐらいで実行できますが、
--region
, --platform
あたりの引数を渡すとコマンド一発で実行できるようになるでしょう。
以上です。
https://cloud.google.com/sdk/gcloud/reference/run/services/update-traffic#--to-latest https://cloud.google.com/sdk/gcloud/reference/run/deploy
Go のテストに並列機能があるので、それで単純に速度アップができるのかという点と、 parallel オプションで並列数操作したらちゃんと反映されるよね。という点を確認した。
slow_test.go
func Test_slow1(t *testing.T) { time.Sleep(3 * time.Second) } func Test_slow2(t *testing.T) { time.Sleep(1 * time.Second) } func Test_slow3(t *testing.T) { time.Sleep(2 * time.Second) }
fast_test.go
func Test_fast1(t *testing.T) { t.Parallel() time.Sleep(3 * time.Second) } func Test_fast2(t *testing.T) { t.Parallel() time.Sleep(1 * time.Second) } func Test_fast3(t *testing.T) { t.Parallel() time.Sleep(2 * time.Second) }
見てわかるように fast の方ではテスト内で Parallel()
を呼び出して並列処理を許可している。
% go test ./slow_test.go ok command-line-arguments 6.276s
6秒ちょい。
3 + 1 + 2 = 6秒なのでだいたい正しい。
% go test ./fast_test.go ok command-line-arguments 3.729s
3.7秒。
3並列で実行され、一番遅い3秒のテスト時間+αという感じだろうか。
% go test -parallel 1 ./fast_test.go ok command-line-arguments 6.502s
6.5秒。
期待通り、並列化していない slow の結果とだいたい近い値になった。
Parallel() を呼び出していないものよりちょっと遅いのは Parallel() 呼び出しのオーバーヘッドがそこそこあるのだろうか。
% go test -parallel 2 ./fast_test.go ok command-line-arguments 3.342s
3.3秒。
3 : (1 + 2) で3秒少々で終わったという感じだろうか。
% go test -parallel 3 ./slow_test.go ok command-line-arguments 6.350s
6.3秒。
もちろんそうなるよね。という感じ。
Go のテストは実行順序や、同時実行などを考慮しなくて良いテストに関しては Parallel()
を実行し、並列化したほうがパフォーマンスが出る。
確認で使った環境は go1.14.3 で、このバージョンであれば、 go test
コマンドに特に並列数など渡さなくてもテスト側で Parallel()
を読んでいれば必要な数だけ並列化されそう。(もしくはPCのCore数に応じて?)
GitHub Actionsなどは時間課金なのでテスト高速化して削減できそう。
ではでは。
キャッシュレス関連用語集 が公開されていて良さそうな感じだったので。
目次はこんな感じ。
https://www.meti.go.jp/policy/mono_info_service/cashless/image_pdf_movie/cashless_glossary_R1_06.pdf
Cloud Run が GitHub と接続設定をするだけで、 GitHub 上に push したコードをデプロイ出来る仕組みが簡単に作れるので、静的ファイルを簡単にデプロイ出来るミニマムな方法になります。
GCSで公開やFirebase Hostingなど他にも公開するシンプルな方法はありますが、 GCP や Firebase など GitHub 以外の存在を隠蔽して static file を公開する仕組みを作りたい場合(社内の非エンジニアなどにも対応してほしい場合)などに利用できるかと思います。
カスタムドメイン化やSSL化も容易だし。
こちら がサンプルになります。
初期設定時に必要なものとしては、 Dockerfile, default.conf は仕組みとして必要です。
これがなぜ必要なのか理解できない人は Docker で nginx コンテナを利用してコンテンツを公開する方法などを検索して学ぶと良いと思います。
仕組みが理解できていれば、 node でも go でもこのパターンを応用して公開できます。
話が脱線しましたが、このリポジトリで外部に公開したいファイルは index.html になります。
中身は超手抜きで以下のようなもの(Hello!と大きく表示されるだけ)です。
<h1>Hello!!</h1>
上記のようなイメージで GitHub にリポジトリを用意します。
すでに作成しているものがあれば Cloud Run を有効化し、
未作成の場合にはプロジェクトの作成の後、Cloud Run の有効化を行います。
(細かい手順は省略します)
まずは GCP の Cloud Run の画面を表示します
まずは、何もない状態だと思いますので、上段の 「CREATE SERVICE」ボタンを押します。
Service settings
の項目は、自分が利用したいリージョン、サービス名を入力します。
Authenticationは外部に公開するのであれば Allow unauthenticatec invocations
を選択しましょう
入力が済んだら 「NEXT」ボタンを押します。
ここからがポイント。
Configure the service's first revision
の設定項目では、
Continuously deploy new revisions from a source repository
を選択します。
選択すると表示が狭まるので、「SET UP CLOUD BUILD」ボタンを押します。
リポジトリは GitHub/Bitbucket が選択できます。
今回は GitHub
を選択しましょう。
尚、この際に、 Cloud Source Repositories API
, Cloud Build API
の有効化が必要になります。
それに伴い billing の有効化も必要になります。リンクから遷移して有効化しておきましょう。
有効化が済むと、 「Authenticate」のリンクが表示されます。
これは GCP から GitHub に接続するための認証になりますので実行しておきます。
認証が完了すると、リポジトリの選択ができるようになります。
以下のように選択し、有効な状態になっていることを確認しましょう(ちゃんと青くなる)
確認できたら 「NEXT」を実行します。
こちらのように Build 設定が表示されます。
任意のブランチを選択し、今回は Dockerfile を利用しますので、 Source location は /Dockerfile
を利用します。
設定が完了したら 「SAVE」 ボタンを実行します。
入力がすべて完了したら、 一番下段の 「CREATE」ボタンを実行します。
尚、デプロイの際の細かいパラメータを変更したい場合には、 ADVANCED SETTINGS
を展開することで設定の変更が可能です。
メモリの量や、CPUのコア数などの指定が行なえます。
CREATE ボタンを実行すると Cloud Run のサービス詳細画面に遷移し、サービスのデプロイ状況が確認できます。
GitHub で管理しているコードを変更して master に push してみます。
このような感じでデプロイが行われました。
コンテンツも表示されました。
めでたし、めでたし。