GCE の無料枠のサーバを立るときに、初見でハマりそうなところ

このスライドについて

  • GCE の無料枠で遊ぶときに、やったほうがいいこととかを紹介します。
  • 大体無料で運用できますが、1年間以上の長期運用をする場合はお金がかかるかもしれません。

やったこと

お金をかけずに以下のことができるようにしてみました

  • GCE のサーバインスタンスを立てた
  • ドメイン取った
  • HTTPS 対応した

概要

私が気づいた「気をつけたほうがいいこと」は、大まかにこんなかんじ。


最初に支払いのログの設定をする

意図しない課金が発生するかもしれないので、そのときに原因がわかるようにします。

@hnw さんの 『GCPの課金データ取得のススメ』に従って、支払い料金の明細ログを残すようにします。


11月に1円課金されるかも

@hnw さんが『無料のはずのGCEのf1-microインスタンスで11月だけ1円課金された理由』で紹介しているように、11月に1円課金されるかもしれません。

こういうのを見つけるために、「最初に支払いのログの設定をする」わけですね。


GCS のバケット名に注意

ユーザー ID、メールアドレス、プロジェクト名、プロジェクト番号、個人を特定可能な情報(PII)をバケット名やオブジェクト名に使用しないでください。

保存先の GCS のバケット名の付け方に気をつけてください。『バケットとオブジェクトの命名ガイドライン』Google Cloud Storage のベスト プラクティスを参考にしましょう。


バケット名に注意

自分が見るために Google Cloud Console から参照できればいいので、私は以下のコードで生成しました。

バケット名を適当に作る
<?php
echo hash('sha256', microtime(true));
 // b1a4bde7cb21813360e98e16277d66934cb2c6d1c69e15a2b7485db84da8691f みたいなやつ

インスタンス立てる前に、SSHで使うユーザ名と認証鍵の登録をする

Google Cloud Console の SSH クライアントだと、遅かったりして使い勝手がびみょいので、普通に ssh できるようにしたほうがいいです。


ユーザ名と鍵の登録は、「Compute Engine」 の 「メタデータ」

初見だとわかりにくいです。

鍵の登録1.png

鍵の登録2.png


ed25519 がカジュアルにつかえる

私はとりあえず ed25519 の鍵を使っています。

新し目のアルゴリズムの鍵がカジュアルに使えるのは良いですね。


f1-micro のインスタンスを立てる


リージョンは us- のやつ選ぶ

リージョン選ぶ.png

us-** のインスタンスを選ぶ。他のリージョンは無料インスタンスの対象外です。

たぶん、西海岸のほうが早いので、私は西海岸のインスタンスにしました。
速度計測とかしてないけど、ストレスになるほど遅くはありません。(個人差があると思います)


インスタンスサイズを忘れずに micro にする

インスタンスのサイズを選ぶ.png

デフォルトだと、 vCPU x1 になっています。 micro にすると、無料になるっていうメッセージが出てきます。


ハードディスクのサイズを 30GB にする

OSと、ハードディスクのサイズを調整.png

デフォルトだと、 10GB になっています。30GBまで無料なので、30GBにしておきましょう。


80 と 443 を開けておく

HTTPとHTTPSは使う.png

Let's Encrypt の certbot を使いたいので、事前に開けておきます。


IPアドレスを固定しておく

サーバインスタンスが動いていれば、固定のIPアドレスにしても無料なので、使いましょう。

IPアドレス固定.png


使っていない固定のIPアドレスは、お金かかる

「ネットワークの外部IPアドレス」を確認して、あったら早めに開放しましょう。

未割り当てのIPアドレス.png


SSH のポート番号をかえる

22番ポート以外でつなげるようにし、「22番を閉じるルールを上書きする」ルールを適用します。

以下の手順でやります。

  1. 適当なポート番号で、FW開ける
  2. サーバに、1.の設定を適用するタグをつける
  3. sshd の設定をして、プロセスを再起動
  4. 22番を閉じるルールを作る
  5. サーバに、3. の設定を適用するタグをつける

これをする理由は、『22番ポートにブルートフォース攻撃されて、数円課金される可能性を潰す』ため。セキュリティ的な面でも、ポート番号変えておいたほうが良さそうです。


適当なポートをひとつ開ける

ポートをひとつ開ける.png
ルールの名前は、デフォルトのルールにならって、 allow-XXXX (XXXXはポート番号)にすると良いです。

ターゲットタグは、デフォルトのルールにならって、 allowXXXX-server (XXXXはポート番号)にすると良いです。

この「ポートを開けるルール」を適用したサーバは、この設定をした時点では存在しないので、タグを付けなければいけません。


サーバに「ポートを開ける」タグを付ける

「ポートを開けるルール」で指定した "ターゲットタグ" を追加。

タグ追加1.png


sshd_config のポート番号の設定をかえる

sudo vi /etc/ssh/sshd_config で、SSH のポート番号を変更して、 systemctl restart sshd する

/etc/ssh/sshd_config
@@ -14,7 +14,7 @@
 # SELinux about this change.
 # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
 #
-#Port 22
+Port XXXX (XXXX は さっき開けたポート番号)
 #AddressFamily any
 #ListenAddress 0.0.0.0
 #ListenAddress ::

これをやるまでは、普通に22 番ポートで作業してください。sshd が使うポート番号の設定をしていないのだから、当然22番ポートで待機しています。

systemctl restart sshd したら、新しく設定したポート番号で待機するようになります。
sshd_config の編集をしたターミナルは閉じずにそのまま で、新しく設定したポートでログインできるかを、新規に繋いで確認してください。確認できたら、閉じていいです。

確認できたら、次に進んでください。


22 を閉じるルールを追加

22を閉じる.png

ポートを開けるときと同じようにやります。
ルールの名前は、allow のルールと対になるように、 disallow-22にすると良いです。

ターゲットタグは、私は disallow22-server にしています。


「22 を閉じる」ルールを、サーバにタグ付け

ポート開けたときと同様に、ポートを閉じるタグを追加する。

タグ追加2.png

22番でアクセスできないことを確認してください。


ドメイン取って証明書発行する


DDNS(ダイナミックDNS) では証明書を取得できない

自宅サーバでは、 ndxbn.dip.jp っていう DDNS を使っているのですが、 dip.jp で証明書が取れません。
DDNS は 「dip.jp にサブドメインを割り当てて、正引きできるようにする」のを自動化したサービスだからです。

HTTPSを使いたい場合は、証明書の発行をするのにドメインを取らざるを得ません。


無料ドメインを取る

freenom.com というサービスがあって、12ヶ月間は無料で使えるドメインがとれます。

ndxbn.tk をとりました。tk が tokyo の略っぽく見えるので。


1年以上使うなら、安いドメインを取るのも良さそう

10年契約でも、1万円を切るドメインがあります。

freenpm.com の無料ドメインが1年分までしか取れないので、1年以上使う予定があるなら、安いドメインを長期で買ってしまっても良いかも。


【余談】無料ドメイン取る前に、安いドメイン取ってた

無料のドメインを取る前に、 ndxbn.tokyo を10年契約でとってしまいまいた。

ndxbn.tokyo ドメインを買ったあとで、 「そいうえば無料ドメインあるんじゃね?」と思って、ggったらあった、という感じです。(悲しみ)

一番安いドメインとかだと 1年で 1000 円くらいですが、それでも「とりあえず無料で全部やってみたい」という人に同じミスはしてほしくないです。


Let's Encrypt で証明書を発行

certbot で発行します。お手軽。

(日本語の)解説サイトを見てやります。オプションの説明とかがややこしいです。

とりあえず、以下のようにやっておけば大丈夫です。

sudo yum install epel-release
sudo yum install certbot
certbot certonly --webroot -d XXXX.tk #XXXX.tk は、取ったドメイン

その他 注意事項


PHPのビルドとかはしない

性能ないので、PHPのビルドとかは厳しいです。

phpenv で 7.1.4 をビルドしたら、62分かかりました。


ビルドした時の様子

/* ここにビルドした時の画像を貼る */


その他参考になる資料


エンタープライズ企業のベスト プラクティス

エンタープライズ企業のベスト プラクティス

エンタープライズ企業が Google Cloud Platform を最大限活用するための、重要な概念とベスト プラクティスについて学んでみましょう

個人で使うにも参考になりそう(?)な情報があったりなかったり。


一から学べる Google Cloud Networking リファレンス ガイド

Google Cloud Networking について知りたい人のためにリンク集を作りました。それがこの投稿です。

一から学べる Google Cloud Networking リファレンス ガイドより引用

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.