h12o is fully Modernized @h12o@blessedgeeks.org

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

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

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

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

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

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

（つづく）

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

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

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

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

で、このサーバは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アドレスをベースにして生成されていることだった。
悩んで損した気分である。

#GoogleCloud #GoogleComputeEngine

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

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

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

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

→ELFエラーで詰んだ。

というわけで、 #GoogleCloud というか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だった（笑）。
#GoogleCloud #google_compute_engine #ssh

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

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

https://cloud.google.com/vpc/docs/vpc?hl=ja#ip-ranges
#googlecloud

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

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

~/public_htmlのrestoreconはこちら
http://park1.wakwak.com/~ima/centos4_apache0005.html
#SELinux #GoogleCloud

#SELinux まわりに気を付けつつ、~/public_htmlのポリシングはこのあたりを参照して復旧。
https://qiita.com/kieaiaarh/items/3455040597ee34c8c49e#nginx%E5%81%B4%E3%81%AE%E8%A8%AD%E5%AE%9A
#GoogleCloud

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

うーん。

`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)`から先に進まなくなってしまった。

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