寝ても覚めてもこんぴうた

プログラム書いたり、ネットワーク設計したり、サーバ構築したり、車いじったり、ゲームしたり。そんなひとにわたしはなりたい。 投げ銭は kyash_id : chidakiyo マデ

Google Cloud Japan イベントアーカイブ(オンラインイベントのアーカイブ一覧ページ)ができたっぽい

f:id:chidakiyo:20200901134824p:plain

最近は GCP 関連のイベントもほとんどがオンラインになりましたね。

興味ありそうな内容のイベントがあっても気づけなかったり、知っていても調べるのが大変、というのがあったと思いますが、公式にイベントアーカイブページが公開されていました。

Google Cloud Japan '20 イベント アーカイブ - ホーム

とても便利ですね。

私も漏らしているものなど、振り返っていろいろ見てみようと思います。

ではでは。

Cloud Code (IntelliJ) を利用して、 Cloud Run にアプリケーションをデプロイする

f:id:chidakiyo:20200831183254j:plain

タイトルの通り、IntelliJ 版の Cloud Code プラグインを利用して、 Cloud Run をデプロイすることを試してみます。

内容は こちら GCP ドキュメント をベースにしています。

事前に必要なこと

GCP のプロジェクトの課金を有効にしておく必要があります。
また、その他、開発などに必要なツールや、IntelliJ などはすでにインストール済みである前提です。
また、Cloud Run を利用する GCP プロジェクトを事前に作成しておく必要があります。

Cloud Code のインストール (IntelliJ 版)

IntelliJプラグインマーケットプレイスから [Cloud Code] を検索してインストールします。

f:id:chidakiyo:20200831182210p:plain

インストール後は再起動を求められるので IntelliJ を再起動します。

アプリケーションの作成

Cloud Code のテンプレートを利用しながらアプリケーションを作成する場合には、「File]→「New Project」から 「Cloud Code: Cloud Run」 を選択し、プロジェクトを作成します。

f:id:chidakiyo:20200831182248p:plain

今回は言語は 「Go」 を選択しました。

作成されたプロジェクトは、 Web アプリケーションを作成する際の最低限のスケルトンが用意されています。
出来上がったファイルを書き換えるなどしてアプリケーションを作成していくことができます。

f:id:chidakiyo:20200831182341p:plain

アプリケーションを Cloud Run にデプロイする

せっかくなので、一気に Cloud Run へのデプロイまで試してみましょう。

上段の実行バーの中から 「Cloud Run: Deploy」 を選択します。

f:id:chidakiyo:20200831182319p:plain

「▶ Run」 をクリックすることで、初回は「Edit Configuration」 のウィンドウが開きます。

GCP とインテグレーションを行い、 Project を指定した後、Run を起動する際に必要な様々な設定を入力します。

f:id:chidakiyo:20200831182546p:plain

入力内容が問題ないようであれば、最下段の 「Run」 ボタンを押して実行します。

しばらく IntelliJ 上のコンソールにログなどが流れるので、エラーが発生していないか確認しておきます。
ちなみに、このタイミングで Docker image を Build などするようで、端末の Docker を事前に起動しておく必要があります。

流れ的には、ローカルで Docker コンテナのビルド → GCRにpushする → Run へのデプロイを行う ということをやってくれているようですね。
コンテナのビルドがなにげにそこそこ時間がかかるっぽい・・・^^;
初回はキャッシュがなかったりするのでなおさら。気長に待ちましょう。あと、Macがだいぶ唸ります。笑

デプロイが成功すると、コンソールに run にアクセスするための https な URL が表示されます。

URLをクリックすると以下のように Run で公開されたウェブコンテンツを確認することができます。

f:id:chidakiyo:20200831182629p:plain

IntelliJ 上でのステータスの確認

IntelliJ 上で Run にデプロイしたサービスのステータスが確認できるようです。

f:id:chidakiyo:20200831182906p:plain

ログ画面を開くこともできる

f:id:chidakiyo:20200831182938p:plain

めちゃくちゃ便利ですね。

ちょっとだけ更新してみる

これだけかんたんにデプロイまでできたので、ちょっとだけHTMLファイルを修正してデプロイしてみましょう

f:id:chidakiyo:20200831183026p:plain

この画面の It's running! の部分をちょっといじってみましょう。

index.html ファイルの 148行目がこの表示部分に当たります

f:id:chidakiyo:20200831183045p:plain

両脇に星をつけてみましょう

~snip~
<div class="message">
                <h1>★It's running!★</h1>
                <h2>Congratulations, you successfully deployed a container image to Cloud Run</h2>
            </div>
~snip~

変更が完了したら、ファイルを保存し、右上の 「▶ Run」ボタンを実行しましょう

初回とは違い、今回は設定内容などは確認されず、そのまま新しいコンテナがビルドされデプロイが行われます。

このように新しいリビジョンが表示されました

f:id:chidakiyo:20200831183115p:plain

URLからアクセスしてみます。

f:id:chidakiyo:20200831183156p:plain

変更点が反映されましたね。

めでたしめでたし。

Amazon の価格履歴が確認できる Chrome Extension の Keepa を利用したら高値づかみしなくなって QOL 上がった話

f:id:chidakiyo:20200825150709j:plain

みなさん、Amazon で買い物してますか?
以前から、Amazon の価格履歴が確認できるアプリがあることは知っていたのですが、関係ないっしょって感じでインストールしていなかったのですが、何かのきっかけでインストールしてみたら快適だったので共有します。

すでに Keepa をインストールしている人はこのタイミングでブラウザのタブを閉じて良いです。w

よく、 Amazon のタイムセールがタイムセール前に値上げして、タイムセールであたかも大幅値引きしている風に見せる罠などの話を聞きますが、このツールをインストールするだけでそういう罠を回避できます。

比較的高価な家電なども高値づかみすることなく安心して購入でき、いろいろなサイトを検索して最低価格など相場感を調べる時間などが削減できるので個人的にとても助かっています。
(別にお金をもらっている記事ではありません)

どういうもの?

こちら のサイトからインストールできます。
一般的なブラウザは大体サポートしているようです。私は Chrome にのみインストールしているので Chrome の例で下記します。

インストール方法

Chrome ウェブストア からインストールするだけです。

ワンクリックポチーで終了。
これであとは快適な Amazon ライフが楽しめます。

使い方(というほどの話ではないけど説明)

まもなく販売される SonyWH-1000XM4 というヘッドフォンを見てみましょう

f:id:chidakiyo:20200825150739p:plain

まだ発売されていない商品なので価格の変動は少ないですが、なぜか一時期安い時期があったようですね。
その時期に買いたかった・・・

また、M4 の前のモデル WH-1000XM3 に関しても見てみましょう。
プラグインをインストールしていれば↑のリンクから開くだけです。

f:id:chidakiyo:20200825150758p:plain

なるほど、直近が過去イチぐらいの勢いで値段が下がってるようにも見えます。
新しいモデルが出るというタイミングですが、私も M3 を使っていますがとても満足度の高いヘッドフォンで3万以下で買えるのは買いですね。

まとめ

そんな感じで最近 Keepa という Chrome Extension を入れたら買い物が捗るよ、という話でした。

ではでは。

Cloud Run で最新のリリースバージョンにトラフィックを流す

f:id:chidakiyo:20200824092244j:plain

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 のテスト並列化してテストが速くなることを改めて確認してみた

f:id:chidakiyo:20200625164918j:plain

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() を呼び出して並列処理を許可している。

早速実行

slow の方を実行する

% go test ./slow_test.go
ok      command-line-arguments  6.276s

6秒ちょい。
3 + 1 + 2 = 6秒なのでだいたい正しい。

fast の方を実行する

% go test ./fast_test.go
ok      command-line-arguments  3.729s

3.7秒。
3並列で実行され、一番遅い3秒のテスト時間+αという感じだろうか。

fast を並列数 1 で実行してみる

% go test -parallel 1 ./fast_test.go
ok      command-line-arguments  6.502s

6.5秒。 期待通り、並列化していない slow の結果とだいたい近い値になった。
Parallel() を呼び出していないものよりちょっと遅いのは Parallel() 呼び出しのオーバーヘッドがそこそこあるのだろうか。

fast を並列数 2 で実行してみる

% go test -parallel 2 ./fast_test.go
ok      command-line-arguments  3.342s

3.3秒。
3 : (1 + 2) で3秒少々で終わったという感じだろうか。

slow を並列数 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などは時間課金なのでテスト高速化して削減できそう。

ではでは。

キャッシュレス関連用語集 [経済産業省]

f:id:chidakiyo:20200625113614j:plain

キャッシュレス関連用語集 が公開されていて良さそうな感じだったので。

目次はこんな感じ。
f:id:chidakiyo:20200625113305p:plain f:id:chidakiyo:20200625113448p:plain f:id:chidakiyo:20200625113316p:plain f:id:chidakiyo:20200625113338p:plain f:id:chidakiyo:20200625113349p:plain f:id:chidakiyo:20200625113406p:plain

リンク先はPDFです

https://www.meti.go.jp/policy/mono_info_service/cashless/image_pdf_movie/cashless_glossary_R1_06.pdf

Cloud Run と GitHub を連携して、GitHub にコードをプッシュするだけでファイルをインターネットに公開できるように設定する

f:id:chidakiyo:20200624111932j:plain

Cloud Run が GitHub と接続設定をするだけで、 GitHub 上に push したコードをデプロイ出来る仕組みが簡単に作れるので、静的ファイルを簡単にデプロイ出来るミニマムな方法になります。

GCSで公開やFirebase Hostingなど他にも公開するシンプルな方法はありますが、 GCP や Firebase など GitHub 以外の存在を隠蔽して static file を公開する仕組みを作りたい場合(社内の非エンジニアなどにも対応してほしい場合)などに利用できるかと思います。
カスタムドメイン化やSSL化も容易だし。

GitHubにコードを配置する。

こちら がサンプルになります。
初期設定時に必要なものとしては、 Dockerfile, default.conf は仕組みとして必要です。
これがなぜ必要なのか理解できない人は Docker で nginx コンテナを利用してコンテンツを公開する方法などを検索して学ぶと良いと思います。
仕組みが理解できていれば、 node でも go でもこのパターンを応用して公開できます。

話が脱線しましたが、このリポジトリで外部に公開したいファイルは index.html になります。
中身は超手抜きで以下のようなもの(Hello!と大きく表示されるだけ)です。

<h1>Hello!!</h1>

上記のようなイメージで GitHubリポジトリを用意します。

GCPにプロジェクトを作成する

すでに作成しているものがあれば Cloud Run を有効化し、
未作成の場合にはプロジェクトの作成の後、Cloud Run の有効化を行います。
(細かい手順は省略します)

Run と GitHub を統合する

まずは GCP の Cloud Run の画面を表示します

f:id:chidakiyo:20200624112012p:plain

まずは、何もない状態だと思いますので、上段の 「CREATE SERVICE」ボタンを押します。

f:id:chidakiyo:20200624112025p:plain

Service settings の項目は、自分が利用したいリージョン、サービス名を入力します。
Authenticationは外部に公開するのであれば Allow unauthenticatec invocations を選択しましょう

入力が済んだら 「NEXT」ボタンを押します。

f:id:chidakiyo:20200624112046p:plain

ここからがポイント。

Configure the service's first revision の設定項目では、
Continuously deploy new revisions from a source repository を選択します。

選択すると表示が狭まるので、「SET UP CLOUD BUILD」ボタンを押します。

f:id:chidakiyo:20200624112058p:plain

リポジトリGitHub/Bitbucket が選択できます。
今回は GitHub を選択しましょう。

尚、この際に、 Cloud Source Repositories API , Cloud Build API の有効化が必要になります。
それに伴い billing の有効化も必要になります。リンクから遷移して有効化しておきましょう。

有効化が済むと、 「Authenticate」のリンクが表示されます。
これは GCP から GitHub に接続するための認証になりますので実行しておきます。

認証が完了すると、リポジトリの選択ができるようになります。
以下のように選択し、有効な状態になっていることを確認しましょう(ちゃんと青くなる)

確認できたら 「NEXT」を実行します。

Build 設定を行う

f:id:chidakiyo:20200624112111p:plain

こちらのように Build 設定が表示されます。
任意のブランチを選択し、今回は Dockerfile を利用しますので、 Source location は /Dockerfile を利用します。

設定が完了したら 「SAVE」 ボタンを実行します。

Cloud Run のサービスを作成する

入力がすべて完了したら、 一番下段の 「CREATE」ボタンを実行します。

尚、デプロイの際の細かいパラメータを変更したい場合には、 ADVANCED SETTINGS を展開することで設定の変更が可能です。
メモリの量や、CPUのコア数などの指定が行なえます。

CREATE ボタンを実行すると Cloud Run のサービス詳細画面に遷移し、サービスのデプロイ状況が確認できます。

変更の際にデプロイされるか確認する

GitHub で管理しているコードを変更して master に push してみます。

f:id:chidakiyo:20200624112131p:plain

このような感じでデプロイが行われました。

f:id:chidakiyo:20200624112144p:plain

コンテンツも表示されました。

めでたし、めでたし。