さっき から予算の50%メールが届く。いつもより遅い。

を使って を外出しにしたところ、レスポンスは遅くなったが、以前は恒常的に出ていた VMの性能アラートが出なくなった。 の無料プランも限界に達したことはない。やはり、Redisを中に入れていたいままでの構成が、実は無駄だったんじゃないか?という気がする。

> 2. 内部IPアドレスを のデフォルトからカスタムVPSに更新した。

Googleデフォルトの10.128.0.0/9は巨大すぎて小規模プロジェクトで使うには気が引けるので、192.168.0.0/16の中から/24を計2つ使用した。
ひとつはVM用で、もうひとつはCloud SQL用。

Show thread

(つづき)
> 1. OSを 7からCentOS 8に更新した。サーバは で変更なし。実はここで地味に時間がかかっている。

はもちろんEnforceしているが、SELinuxの設定はそこまで時間がかかっていない。
もうひとつ時間がかかったのは のエラーや、ディスクマウントエラーなど。
前者は`gcloud compute instances update <ホスト名> --shielded-learn-integrity-policy --project=<プロジェクト名>`をしつつ、
セキュアブートを一時的に無効にして対応した(vTPMをオンにする・整合性のモニタリングを有効にする、の2つはそのままにする)。

(つづく)

Show thread

地味に時間がかかってしまったのだけどこの サーバを更新、更新内容は以下の通り。

1. OSを 7からCentOS 8に更新した。サーバは で変更なし。実はここで地味に時間がかかっている。
2. 内部IPアドレスを のデフォルトからカスタムVPSに更新した。
3. もIPアドレスをリナンバー。
4. をマネージドにした。Google Cloud Memorystore for Redisではなく、 の無料版として外出し。

予行演習を兼ねて、さきほど 上でCentOS 7のVMとして動かしていた blessedgeeks.org/~h12o を、CentOS 8に移行した。もちろんSELinuxはEnforced。

移行の本命はこのサーバなのだけど、GCEのVPCネットワークとCloud SQLとのプライベート接続をどう設定すればいいかがまだ分からなくて、移行できていない。

なんでこれを延々と調べているかというと、このMastodonを入れている Platformプロジェクトでも、VPC設計をきちんとやってみようという考えから。

最初はどこかのクラスCの/24、つまり図で言えばひとマスを、16分割して/28単位でウェブ・アプリケーション・Redis・データベースに割り当てるつもりだった。

Show thread

で、このサーバはGCEなのだけど、今日になって知った驚愕の事実はこれ。
```
[h12o@mastodon-000a]~% hostname
mastodon-000a
[h12o@mastodon-000a]~% ip a
....
2: eth0: <BROAD...
link/ether 42:01:XX:XX:00:0a ....
inet XXX.XXX.0.10/32 ....
....
```
GCEのネットワークインタフェースのMACアドレスが逆にIPv4アドレスをベースにして生成されていることだった。
悩んで損した気分である。

Show thread

そろそろひとりでGCPにまつわる問題を解決するのも難しくなってきたので、GCPUGに入るかな…
gcpug-tokyo.connpass.com/

SQLは静的プライベートIPアドレスの予約ができないのか…残念。

この サーバで障害を起こしました…。

1. Mastodonを3.1.3にアップデートしようとした。
2. アップデートしたら が4.0以上を要求されていた。
3. redis-4.0を )で入れた。
4. も2.7がwarning出しまくるので2.6にダウングレードした。
5. ところがgemがライブラリまわりでエラーになったので、面倒くさがって/etc/ld.so.conf.d/linuxbrew.confを作成してld.so.cacheを作った

→ELFエラーで詰んだ。

というわけで、 というかGCEのディスクスナップショットから書き戻したインスタンスを新たに生成しました。

そこで~/google-cloud-sdkを調べたのだけど、
google-cloud-sdk/lib/googlecloudsdk/command_lib/util/ssh/ssh.pyの556〜558行目にその答えがあった。
```python:
# TODO(b/33467618): Rename the file itself
DEFAULT_PATH = os.path.realpath(files.ExpandHomeDir(
os.path.join('~', '.ssh', 'google_compute_known_hosts')))
```

いわゆるfixmeだった(笑)。

Show thread

そういえば`gcloud config-ssh`で のconfigファイルに へのログイン設定を挿入してくれるのだけど、鍵ペアがgoogle_compute_engine{,.pub}なのにknown_hostsファイルがgoogle_compute_known_hostsで、違和感を感じていた。

以前 CentOS 7 VMのカーネルを更新したらSheilded VMの完全性エラーが出たが、このインスタンスでやってみたら問題なく新しいカーネルでブートした。もちろんこちらもSheilded VMなのだが、なぜ…
QT: blessedgeeks.social/@h12o/1039

Hidetomo Hosono (h12o)  
結局VMを作り直した。なお、1時間ほどでVM削除→ディスクのスナップショット作成→VM再作成→スナップショットから追加ディスクを作成してマウント→etcとhomeの必要な中身を取り出しまで成功した。 #GoogleCloud

補足。「実際には だとリージョンごとに/20で切られている」のは自動モードのVPCネットワークで自動的に作成されるサブネットで、リージョンごとに 1 つのサブネットとして構築されている。

Show thread

もっというと、VPCのアドレスレンジも多くてせいぜい/16で、実際には だとリージョンごとに/20で切られているので、下3桁を使えば確実に一意になる(内部FQDNはリージョン名が入るので、リージョンのネットマスク(?)部分を考慮する必要はない)。

Show thread

結局VMを作り直した。なお、1時間ほどでVM削除→ディスクのスナップショット作成→VM再作成→スナップショットから追加ディスクを作成してマウント→etcとhomeの必要な中身を取り出しまで成功した。

Show thread

うーん。

`gcloud compute instances update "${INSTANCE_NAME}" --shielded-learn-integrity-policy`してから`gcloud compute instances stop "${INSTANCE_NAME}"`→`gcloud compute instances start "${INSTANCE_NAME}"`を順にやったら、エラーは出なくなったものの、`Kernel Offset: 0x9e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)`から先に進まなくなってしまった。

正直よく分からないのだけど、インスタンスを作り直した方がよさそうだ。ディスクの中身は拾えたらラッキーか。

Show thread
Show more