このスライドについて
- GCE の無料枠で遊ぶときに、やったほうがいいこととかを紹介します。
- 大体無料で運用できますが、1年間以上の長期運用をする場合はお金がかかるかもしれません。
やったこと
お金をかけずに以下のことができるようにしてみました
- GCE のサーバインスタンスを立てた
- ドメイン取った
- HTTPS 対応した
概要
私が気づいた「気をつけたほうがいいこと」は、大まかにこんなかんじ。
- 最初に支払いのログの設定をする
- GCP の無料枠でなんとかなるようにする
-
無料ドメインをとる
- DDNS（ieServer.net系）だと、証明書発行できない
- 1年間までなら無料で使えるドメインはある
- 有料でも、安めのドメインを買ったほうがいいかもしれない？
-
Let's Encrypt の証明書を使って HTTPS対応
- certbot やるだけ
- 更新忘れないように、cron する
- マシンパワーがないので、PHPのビルドとかはしない
-
yum installとかapt-get installとかは許容範囲 -
.configure && makeとかやるなら、数時間かかることを覚悟する
-
最初に支払いのログの設定をする
意図しない課金が発生するかもしれないので、そのときに原因がわかるようにします。
@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」 の 「メタデータ」
初見だとわかりにくいです。
ed25519 がカジュアルにつかえる
私はとりあえず ed25519 の鍵を使っています。
新し目のアルゴリズムの鍵がカジュアルに使えるのは良いですね。
f1-micro のインスタンスを立てる
リージョンは us- のやつ選ぶ
us-** のインスタンスを選ぶ。他のリージョンは無料インスタンスの対象外です。
たぶん、西海岸のほうが早いので、私は西海岸のインスタンスにしました。
速度計測とかしてないけど、ストレスになるほど遅くはありません。（個人差があると思います）
インスタンスサイズを忘れずに micro にする
デフォルトだと、 vCPU x1 になっています。 micro にすると、無料になるっていうメッセージが出てきます。
ハードディスクのサイズを 30GB にする
デフォルトだと、 10GB になっています。30GBまで無料なので、30GBにしておきましょう。
80 と 443 を開けておく
Let's Encrypt の certbot を使いたいので、事前に開けておきます。
IPアドレスを固定しておく
サーバインスタンスが動いていれば、固定のIPアドレスにしても無料なので、使いましょう。
使っていない固定のIPアドレスは、お金かかる
「ネットワークの外部IPアドレス」を確認して、あったら早めに開放しましょう。
SSH のポート番号をかえる
22番ポート以外でつなげるようにし、「22番を閉じるルールを上書きする」ルールを適用します。
以下の手順でやります。
- 適当なポート番号で、FW開ける
- サーバに、1.の設定を適用するタグをつける
- sshd の設定をして、プロセスを再起動
- 22番を閉じるルールを作る
- サーバに、3. の設定を適用するタグをつける
これをする理由は、『22番ポートにブルートフォース攻撃されて、数円課金される可能性を潰す』ため。セキュリティ的な面でも、ポート番号変えておいたほうが良さそうです。
適当なポートをひとつ開ける
ルールの名前は、デフォルトのルールにならって、 allow-XXXX （XXXXはポート番号）にすると良いです。
ターゲットタグは、デフォルトのルールにならって、 allowXXXX-server （XXXXはポート番号）にすると良いです。
この「ポートを開けるルール」を適用したサーバは、この設定をした時点では存在しないので、タグを付けなければいけません。
サーバに「ポートを開ける」タグを付ける
「ポートを開けるルール」で指定した "ターゲットタグ" を追加。
sshd_config のポート番号の設定をかえる
sudo vi /etc/ssh/sshd_config で、SSH のポート番号を変更して、 systemctl restart sshd する
@@ -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 を閉じるルールを追加
ポートを開けるときと同じようにやります。
ルールの名前は、allow のルールと対になるように、 disallow-22にすると良いです。
ターゲットタグは、私は disallow22-server にしています。
「22 を閉じる」ルールを、サーバにタグ付け
ポート開けたときと同様に、ポートを閉じるタグを追加する。
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 ドメインを買ったあとで、 「そいうえば無料ドメインあるんじゃね？」と思って、ｇｇったらあった、という感じです。（悲しみ）
一番安いドメインとかだと １年で 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 で ７.１.４ をビルドしたら、62分かかりました。
ビルドした時の様子
/* ここにビルドした時の画像を貼る */
その他参考になる資料
エンタープライズ企業のベスト プラクティス
エンタープライズ企業が Google Cloud Platform を最大限活用するための、重要な概念とベスト プラクティスについて学んでみましょう
個人で使うにも参考になりそう（？）な情報があったりなかったり。
一から学べる Google Cloud Networking リファレンス ガイド
Google Cloud Networking について知りたい人のためにリンク集を作りました。それがこの投稿です。