🌊

Google Cloud Storageをブログ記事の画像置き場にする

2021/04/30に公開

Google Cloud

idea

背景

Qxxtaに書いてみたり、ブログに書いてみたりしてきたけれど、
画像の類を貼る方法が媒体を移るたびに変わるのはどうしても避けられない。

どうせなら自分のストレージを用意して、そこにアップロードすることとすれば、
自分の記事を書く体験を大きく変えずに色んな所を渡り歩けるはず。
記事の移行とかもしやすいし。

やってみたのでメモ。

使用するもの

Google Domains
Google Cloud Storage
Google Cloud Load Balancing
Google Cloud SDK
gsutil ツール

静的コンテンツのホストを用意

画像だの何だのを置く場所として、GCPを使って整備する。
基本的には以下に掲載されたGCP公式のチュートリアルに従っていく。

流れを一応書いておく。ただ、チュートリアル見たほうが正確だし親切。

Domainの用意

Google Cloud Storageと組み合わせる都合上、Route53よりGoogle Domainsの方が良かった。
Route 53ではSSL証明書のプロビジョニングが上手く通らなかったので断念したとも言う。

kyoh86.devをもともと持っていたので、サブドメインを適当に決めて使うことにした。

Storageの用意

アップロードするStorageを管理するプロジェクトを作る。

https://cloud.google.com/resource-manager/docs/creating-managing-projects?hl=ja
支払いの有効化などがあるので多少面倒

バケットを作る

使うドメインの名前(e.g: post.kyoh86.dev)でバケットを作っておく

バケットを共有

基本的に全公開。
- allUsers に対して、 ストレージオブジェクト閲覧者 を割り当て
なので、この目的のためだけのバケットとしておく。変なファイル置かないように注意

サンプルファイルをアップロード

適当に画像をアップロードしておくと、後で確認するのも楽になる

ドメインの割当

Cloud Storage単体では独自ドメインでの接続を受け付けられない（固定IPがない）ので、
Google Cloud Load Balancingを使って設定していく。

ロードバランサと、その固定IPが用意できたら、Google Domains側でAレコードを作って、
サブドメインをロードバランサに割り当ててやれば良い。

CLIアップロード環境の整備

いちいちGoogle Cloud Platformの管理画面までいってアップロードするのもバカバカしいので、
CLIベースで作業できるようにしておく。

流れとしては

サービスアカウントの用意
サービスアカウントにバケットに対するロールを割当
Google Cloud SDKのインストール
Google Cloud SDKの構成
gsutil ツールのインストール
アップロード

サービスアカウントの用意

先のGoogle Cloud Storageを作ったプロジェクトで、サービスアカウントを用意する。
サービスアカウントは、利用する端末ごとに用意したほうがいいと思う。
万が一端末が盗まれた、故障して修理に出さなければならない、などのときに無効化する単位が明確でわかりやすいので。

名前は自由なので、 post-(マシン名) のように作ることにする。
説明もつけられるので、 post.kyoh86.dev のアップロードする（for 自宅desktop）` とかなんとか書いておく。
鍵ファイルも忘れずに用意する。どうせGoogle Cloud SDKからしか使わないので、JSON形式でよろしい。

バケットへの権限割当

Cloud Storageでバケットを開き、権限タブでメンバーを追加する。
このとき、追加するメンバーの「名前」を聞いてくるが、サービスアカウントの場合に入力するべきは、
識別子たるメールアドレス（xxx@xxx.iam.gserviceaccount.com みたいなやつ）。

ロールはストレージコンテンツ管理者あたりが良い。
更新や削除を禁止したいなら、カスタムロールを作って割り当てる。

Google Cloud SDKのインストール

公式が最高なので割愛。環境によって違いすぎる。

Google Cloud SDKの構成

このサービスアカウントを使う構成を独立して作ったほうが良さそう。
（単に他のと一緒にできるのかどうか知らんだけ）

公式のガイドラインがバカわかりやすいので、あんまり書くこと無い。

構成名はサービスアカウントの名前とかがわかりやすい気がする。

$ gcloud config configurations create `post-desktop`

作ると直後はその構成がアクティブになるので、すぐに認証もしてしまう。
サービスアカウントで作った鍵ファイルを指定してログインするだけ。

$ gcloud auth activate-serice-account xxx@xxx.iam.gserviceaccount.com --key-file project-xxxxxxxxx.json

gsutil ツールのインストール

公式が最高なので割愛。こちらも環境によって違いすぎる。

アップロード

先程作った構成が有効になってないと、対象サービスアカウントの認証が通った状態にならないので気をつける。

$ gcloud config configurations list
NAME             IS_ACTIVE  ACCOUNT                                     PROJECT  COMPUTE_DEFAULT_ZONE  COMPUTE_DEFAULT_REGION
default          True
kyoh86           False      chili.pepper86@gmail.com
post-kyoh86-dev  False      post-xxxxxx@kyoh86.iam.gserviceaccount.com

デフォルトになっちゃってる。切り替える。

$ gcloud config configurations activate post-kyoh86-dev

あとはgsutilでcpするだけ

$ gsutil cp ./alfred-neo-vim-2.mov gs://post.kyoh86.dev/image/
Copying file://./alfred-neo-vim-2.mov [Content-Type=video/quicktime]...
| [1 files][  6.0 MiB/  6.0 MiB]
Operation completed over 1 objects/6.0 MiB.

展望

Vim/Neovimとの統合

Vim/Neovimでアップロードできるように設定したい。
拡張となると構成が限定的すぎてきついので、設定にとどめておきたいところ。

Markdownの記法で画像リンクがあったら、DownloadしてUploadしてリンク先書き換える、くらいがいいかも

防御

大した記事を書くわけでもないので、さほど問題ないと思うけど、
CDNとかWAFとか置いてもいいんだろうね。