Google Cloud Storage で静的ウェブサイトを公開する

Google Cloud Storage でウェブサイトを公開してみました。最終的には、以下を実現しました。

  • 独自ドメインにて、Google Cloud Storageにアップロードしたファイルを閲覧できるようにする
  • 最初は、Mac上のリソースをrsyncにてアップロードする
  • Debian上のJenkinsにて、リソースを自動アップロードできるようにする。この時Jenkinsには、Google Cloud Storageにアップロードする権限だけを付与するようにする。

Amazon S3よりもGoogle Cloud Storageの方が2割程度安くなります。

  • Google Cloud Storage : $0.026 /GB/month
  • Amazon S3 東京リージョン : $0.0330 /GB/month

公式ドキュメントは以下になります。

Hosting a Static Website - Cloud Storage — Google Cloud Platform

1. プロジェクトを作る

Google Cloud Platform では、このプラットフォーム全体で、Projectという単位でリソースを区切る必要があります。以下のリンクからぷとジェクトを作成します。

プロジェクト

2. 独自ドメインをGoogleに認証させる

独自ドメインを利用できるようにするには、ウェブマスターセントラルにて所有していることを認証させる必要があります。

ウェブマスター セントラル

ドメインは、mydomain.comで取得し、サブドメインwww.mydomain.comを利用する場合であっても、domain.comで登録します。

お名前.comの場合は、確認方法で「GMO.jp」を選択すれば、ログイン画面が現れて認証できるようですが、うまく行きませんでした。私は表示されたTXTレコードを登録する方法で確認を実施しました。

3. バケットを公開するホスト名で作成し、公開の設定を追加する

以下のページから、作成したプロジェクトを選択し、バケットを作成します。この時バケットの名前は、公開するサブドメイン www.mydomain.com に設定します。

ストレージ ブラウザ - personal-storage

上記の画面から、作成したバケットに対して、右端のオプションボタンから「オブジェクトの規定の設定」を表示し、以下の設定を追加します。

  • エンティティ：ユーザ
  • 名前：allUsers
  • アクセス権：読み取り

この設定は、アップロードをする前に必要があります。

5. gcloudを使ってアップロードする

Macの場合は、homebrewを使って簡単にインストールできます。インストール後、初期設定を行ってgcloudコマンドが使えるようにします。表示されるままに記載のURLにアクセスし、キーを入力します。

brew install gcloud
gcloud init

アップロードするには、gcloudのrsyncを使います。

gsutil -m rsync -d -r <アップロードディレク取取り> gs://<バケット名>

この時点で、以下のURLにアクセスすると、確認できるようになります。

https://storage.googleapis.com/<バケット名>/

6. ドメインがGoogle Cloud Platformを指すようにする

ドメインを取得したレジストラにて、DNSレコードを以下のようにします。

  • ホスト名: <公開ホスト名>
  • TYPE: CNAME
  • VALUE: c.storage.googleapis.com

これで、目的のドメインにて、静的ウェブサイトを公開できました。

7. Debian/UbuntuのJenkinsにて、自動アップロードを出来るようにする

自分はDebianサーバにてJenkinsを立てており、Gitリポジトリをポーリングさせ、Jenkinsから自動でGoogle Cloud Storageにアップロードされるようにします。

まず、Jenkins用のサービスアカウントを作成します。

権限

サービスアカウント名に「Jenkins」などと入れると、自動的サービスアカウントIDが作成されます。「新しい秘密鍵の提供」を選び、キーのタイプを「JSON」とすると、秘密鍵が書かれたJSONファイルがダウンロードできます。

サービスアカウントIDをコピーしておきます。

バケットの一覧の画面から、目的のバケットの「バケットの権限の編集」を選び、以下のように先ほど作ったサービスアカウントに編集権限をもたせます。

ストレージ ブラウザ

  • エンティティ: ユーザ
  • 名前: サービスアカウントID
  • アクセス権: 書き込み

Debian/Ubuntuに、Google Cloud SDKをインストールします。Debian/Ubuntuの場合には、リポジトリを追加すると、apt-getでインストールできます。無理してCentOSなどを使わずに、Debianを使いましょう。

Quickstart for Debian and Ubuntu - Cloud SDK — Google Cloud Platform

このJSONファイルをJenkinsサーバに移動し、Jenkinsにしかアクセス出来ないところへ配置します。そして、JenkinsユーザにてこのJSONキーの有効化をします。

sudo su jenkins
gcloud auth activate-service-account --key-file <鍵のjsonファイル>

これで、Jenkinsからもgsutil rsyncが使えるようになります。

困った点

  • AWS S3と異なり、https://storage.googleapis.com/<バケット名>/とプラットフォームの方でドメインを割り振ってくれないため、サイトによってはCNAMEを設定するまでサイトをきちんと確認できない。
  • 「オブジェクトの規定の設定」はアップロード時に付く権限らしく、アップロード後に設定しても、公開設定されない。なので、アップロード前に権限設定をする必要がある。
  • まだ東京リージョンがないので、ちょっと遅いかもしれない。

最後に

一時、github.ioでサイトを公開していましたが、なんとなくオープンソースでもないのに無料のサービスに間借りするなんてという気分になり、Google Cloud StorageのWebサイトへ移行しました。

npmの-gをローカルユーザのディレクトリで管理する

node

npmのアップデートなどで、よくnpm update -g npmとsudoを付け忘れて実行してしまい、何故かnpmが使えなくなることが良くありました。

ここのところ、golangのgo getコマンドを使うために、GOPATHを以下のように設定するよう、.bashrcに書いていました。

if [ -e $HOME/golang ];then
    export GOPATH=$HOME/golang
    export PATH=$GOPATH/bin:$PATH
fi

このようにgolangでは、外部ライブラリのディレクトリをユーザディレクトリに全て持つことができます。これと同じことを、npmでできないかと思い調べました。

公式Documentによるとprefixがそのようです。これを/Users/yourname/npmに設定します。

$ npm config edit
prefix=/Users/yourname/npm

npm config editを使うと、~/.npmrcに設定を追加することができます。また、$HOME/npmは使えず、~/npmとすると自動で上記に書き換えられました。

また、$home/npm/binへパスを通すようにします。

if [ -e $HOME/npm/bin ];then
    export PATH=$HOME/npm/bin:$PATH
fi

これで、npmをインストールします。sudoは付けません。

$ npm install -g npm

これで、npmコマンドのパスを確認すると、ユーザディレクトリになります。

$ which npm
/Users/yourname/npm/bin/npm

これで以後、npm install -g packagenameにsudoを付ける必要はなくなりました。やったね。

1.0になったVisualStudioCodeの強みと弱点

vscode

ついにVisualStudioCode(以下、VSCode)の1.0がリリースされました。ずっとVim以外の、人に勧められるエディタを探していた私にとって、VSCodeはまさにちょうど良いエディタでした。 このVSCodeで、エッジの振られている強みと、弱点を紹介します。

強み1 入力補完機能が優れている

VisualStudioの名を冠するだけあって、入力候補機能が標準で付いています。 C#やJSは文脈を読んで補完してくれます。文脈を読めない形式でも、同じファイル中に出てきた単語を補完候補として利用できます。 スニペットや言語対応の拡張フレームワークが用意されており、拡張機能をインストールすることで多くの形式に対応できるようになります。

強み2 デバッグ機能が整備されている

ブレイクポイントをつけたり、変数を見たりするデバッグ機能が、当然のように標準で付いています。4つの機能タブのうち、1つがデバッグになっています。 デバッグ機能の拡張フレームワークが提供されており、今後も拡張機能により様々な言語がサポートされていくと思われます。

強み3 カスタマイズしなくても使える

様々な言語が標準でシンタックスハイライト、入力補完が使えるようになっています。ShellScriptや、Dockerfileといった今までエディタがあるようでなかったものまで、標準で対応しています。 インストールして、作業ディレクトリさえ指定すれば、そこそこ良い感じの作業環境が手に入ります。

強み4 gitフレンドリーである

4つの機能タブのうち、1つがgitのためのタブになっています。初めてgitを使う人でも使えるように、マウス操作で、diffの確認、commit、push、pullができるようになっています。

強み5 Syntaxエラー、Lintエラーが表示できる

IDEでよくお世話になる、Syntaxエラーの表示、またLintエラーの表示ができるフレームワークが乗っています。Lint用の拡張フレームワークが提供されており、今後も拡張機能で様々な言語が対応していくと考えられます。

ほかの特徴

  • F1キーで呼び出す、全ての機能の起点となるコマンドパレットがあります。またコマンドは正確に覚えていなくても使えるように、候補の絞り込みがよく効くようになっています。
    • ただし、日本語設定では、検索する文字も日本語になってしまうため、言語設定を英語にするのがおすすめです。
  • Windows、Mac、Linuxのマルチプラットフォーム対応。
  • 複数ファイルを同時に開いて、並べて表示できます。
  • jsonの設定ファイルにより、キーバインドや各種設定を行うことができる。
  • メソッド名の一括変換など、今までIDEでしか得られなかったリファクタリングの機能が利用できます。

弱点1 拡張機能で拡張できる範囲が限定的

Atomのようになんでも拡張できることはなく、拡張可能な部分は、デバッガーや、Linter、文章編集など限られた範囲でしか行うことができないようになっています。 例えば、拡張機能によって新たな画面や、ボタンを追加することはできません(DOMの操作はできない)。

弱点2 設定、デザインツールは含まれない

.NETのプロジェクトファイルを、mavenの設定を編集するためのGUI画面や、ASP.NET等の画面デザインツールは、今の拡張機能では作ることはできません。 それらはテキストベースで入力し、拡張機能によってあくまでテキストベースの入力支援や、Linterによって入力ミスを指摘する機能しかありません。

弱点3 デバッグやタスクの実行には専用の設定ファイルを用意する必要がある

.NETやJavaのIDEのように、プロジェクトの作成と同時にデバッグを開始はできず、専用のjson形式の設定ファイルを記述する必要があります。

弱点4 ディレクトリの文脈を読まない

VSCodeを起動後、作業ディレクトリを指定すると、ディレクトリ下のファイルを全てをディレクトリツリーで表示します。例えば、ソースコードに関連する設定ファイルや生成ファイルがあったとしても、全てのファイルをそのまま表示を行います。VisualStudioやEclipseのJavaのようにディレクトリの文脈に応じた表示はできません。

弱点5 起動に多少の時間がかかる

VSCodeは起動や、プロジェクトファイルディレクトリの変更には、早くとも2、3秒はかかります。よって、ちょっとした設定ファイルの編集には不向きと思っています。

以上

入力補完、Git、デバッグにエッジを向けた、テキストエディタ以上、IDE未満のエディタと言えます。私はSIerでアーキテクトとして開発技術の選定を仕事にしており、IDEにさほで期待できないプラットフォームの場合に、多くの開発者に勧められる良いエディタを探していました。私一人であればVimを拡張すれば済みますが、多くの開発者にVimを強要するわけにはいきません。そんな位置付けにちょうど良いエディタ出してきたのは、さすがMicrosoftだと思います。私自身、VisualStudioCodeをgolangの開発に日々利用しています。

あと、私はVisualStudioCode上でVimの入力をエミュレートする拡張機能を作成しています。最近、他のVim系プラグインにダウンロード数を抜かれましたが、私の拡張機能が一番イケてると思っているので、Vimerの皆さん良ければ使ってやってください。