ローカルlinuxでubuntu22利用がうまく行ったので、こっちもバージョン上げた。
基本はローカルlinuxでやったことと同じセットアップをするけど、ネットワークだけきちっと想定しながら作らなあかん。
マシンイメージでubuntu22選べるんかなぁって見たら、下から２つ目にあった。
前はfocal-fossaってネコっぽかったけど、次はjellyfishでクラゲ。
フワフワと動きが軽かったらええんやけどなぁ。
Google cloudのubuntu
centosのバージョンアップも同じようなことやったけど、ubuntuでも行程はだいたい同じ。
ローカルlinuxで練習したから、スンナリできた。
やっぱり開発環境で練習して本番環境でも同じことするってやり方だと安心できる。
グローバルIPの予約
いきなりVMを作るわけじゃなく、まずはネットワークから。
どこにどう作って、許可設定どうするかとかをイメージしてからやる。
新しくグローバルIPを予約し、ubuntu22を新OSとしてインストールして、ssh鍵とか作っていく。最終的には古いグローバルIPは開放する（使わずにリザーブするとお金かかるし）。
昔使ったgoogle cloudコンソールのssh接続どうやるんやったか忘れた。
コンソールから一時的にsshを許可するように設定して、終わったらteraterm接続のみしかしないからファイアウォール設定を無効にしとく。
コンソールからsshを許可する方法を説明されている方がおられた。
作者さんありがとう。
こんな感じのgcloudコマンドライン使うらしい。
gcloud projects add-iam-policy-binding gvis-XXXXXX \
--member=user:XXXXXXXXXX@gmail.com \
--role=roles/iap.tunnelResourceAccessorVPCにあるFW設定も新しく予約したグローバルIPで許可設定入れて接続確認してく。
VPCの中にローカルIPも必要なので、それも予約しとく。
グローバルIPは１つだけ予約しておき、使い終わったら返却。ローカルIPは２つを確保しておく。
バージョン上げたりOS変える都度、ローカルは末尾118と218を行ったり来たりする。
新ＯＳを準備
元からディスクはOS用(30GB)とデータ用(300GB)を使っているので、新OS用を一時的にもう１つ用意する。
データ用のディスクには、excelのファイルとかpdfとかもあるけどdockerの永続化領域とイメージが入った領域を持ってる。
永続化領域にはmariadb/rdp用のlinux/gitlabのデータとか入ってて、ubuntu20で使ってたものをubuntu22にマウントしてdocker起動すると一発で動くはず。
「１か月動かしたら$25.66やぞぉ」って書いてあるけど、別にずーっと動かすわけじゃないので気にしない、気にしない。
接続確認した後でdockerコンテナ使い始める直前に、cpuのコア数とメモリサイズ増やすから今は適当に設定。
「ネットワークインターフェースの編集」ってとこでVPCを先につけとく。タグづけしたローカルIPとグローバルIPもつける。この２つをマシン作るときに忘れると、ローカルＰＣからうまく接続できない。最初これを忘れて、後で変更したら接続できんなぁって悩んだ。
昔はVPN接続使ってて、３年ぐらい前にVPC作った。ホンマはなくてもなんとかなるんやけど、まぁせっかくあるしそのまま使う。
ssh鍵作成とtera term接続
いっつもこのやり方忘れる。
ssh接続するときに秘密鍵と公開鍵を使う。
パスワードもつけておく。
nari@nafslinux-ubu22:~$ ssh-keygen -t rsa -b 4096 -C "nari@gmail.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/nari/.ssh/id_rsa): /home/nari/id_rsa_nari.txt
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nari/id_rsa_nari.txt
Your public key has been saved in /home/nari/id_rsa_nari.txt.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx nari@gmail.com
The key's randomart image is:
+---[RSA 4096]----+
| ooo . |
| + + |
| o o . . . |
| S . ..=.o|
| = *. +oo=*|
| o . .+B.|
+----[SHA256]-----+
nari@nafslinux-ubu22:~$作ったファイルは大事に保管。
tera termのマクロでも使わせるし、sshトンネリングするときにも使う。
google cloudのコンソールに貼り付けると、仮想マシンの.sshフォルダに置いてくれる。
んじゃ、起動してブラウザウィンドウでssh開いてみる。
おー、開く。
ここでrootのパスワードを設定。
このへんまで来たら、宅内のDNSを変更して新しいほうの外部IPを設定しとく。
直後に気づいたけど、sshdがtera term接続を拒否しよる。
Jun 7 21:50:05 jelly-fslinux sshd[1105]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]ぬぬぬ。
作ったキーが許可したアルゴリズムにないらしい。
今度バージョン上げるときは新しめのアルゴリズムにしたるから、今は許しといてーや。
sshd_configを更新したった。
PubkeyAcceptedAlgorithmsにssh-rsaを追記したらなあかん。
sshd再起動してつないだら、次は行けた。
dfしたらルートパーティションも30GB取れてる。これでセットアップの続きができる。
google cloudはディスクの使用量じゃなく確保量で課金。
こっからちょっと急いでく。
スクリプトの流し込み
インストールやサービス起動を平準化するための稼働用のスクリプトをubuntu20で使っててtar.gzで作ってあるので、tera termのscpでubuntu22へ流し込む。
ディレクトリ構成を作って、権限もつけていく。
あ、ユーザIDはたまたまIDが同じやったみたいやけど、グループIDが違うのになってて「197121」とか数字表示になってるからchownで直してった。
システム更新のためaptやっとく。
centosからubuntuに乗り換えた時、普段使ってる運用スクリプトの内容を変更した。
810_aptUpdate.shは前は810_dnfUpdate.shやったり810_yumUpdate.shってなってた。
「810」って文字入力して、あとはタブキーで入力補完させるとすぐに更新処理が使える。OSを変えたりバージョン上げたとき、運用スクリプトがあると、ああ楽チンって思う。
あとはローカルlinuxのインストールでやったsamba/apache/dockerを同じようにインストールしてsystemctlで起動確認する。
データディスクのマウント
接続とサービス起動確認できたら、データ用ディスクをubuntu22のローカルディスクにつなぐ。
sshトンネルの接続確認とrcloneでバックアップ
gcloudコマンドはもう入ってて、それ以外としてローカルlinuxのインストールでやったのと同じことをする。
ローカルlinuxからsshトンネル経由でxrdp接続し、全部のサービスが使えることを確認。
ubuntu22ベースのxrdpコンテナは後日作りなおした。
バックアップからローカルlinuxへクローン
google cloudからgoogle driveに入れたバックアップを、ローカルlinuxの置き場にcyberduckでダウンロードし、バックアップからDBとファイルをzipから展開してクローンできることを確認。
zipをダウンロードしておく。nariDocs.zipが文書、Docker.zipがdockerの永続化領域でmariadbのデータとか、djangoのアプリケーションが入ってる。
ローカルlinuxのdockerの永続化領域にコピーすると、データベースとdjangoアプリケーションで同じものが使える。
もちろんpip3でモジュールのバージョンを同じレベルに上げておき、データベースや処理に変更を加えたらmanage.py makemigrationsとmanage.py migrateは必要。
djangoアプリケーションは、この永続化領域の１つ上のフォルダにあるdocker-compose起動スクリプトの中で、google用とローカル用のcssファイル/settings.pyを切り替えするようにしておくことで画面表示やDBMS接続先を変えて稼働させることができてる。
ローカルlinuxの文書置き場にコピーすると、これも同じものが使える。アプリケーションと同じようにgitlabで月単位の世代管理してるから、古いファイルが欲しければ過去のブランチから文書を取り出せばいい。
後始末とか片づけとか
ファイアウォールの許可設定に新しいグローバルIPアドレスを追加したので、古いほうの記述を削除した。
google cloudコンソールにあるブラウザsshからの接続許可していたのを無効にした。
旧OSの削除とグローバルIPの開放
ubuntu22で動作確認終わったら、ubuntu20のディスクを削除する。
古いグローバルIPは予約したままだと費用計上されるので、これもあわせて開放する。
だいたいのコスト
google cloudの利用頻度は、普段は週に１回ぐらい使う程度で、毎月２０００円行かないぐらい。
確保したディスクの占有期間をできるだけ短くすると費用は抑えられる。
あとはバックアップ結果をgoogle driveに置くときは外向きのパケット費用がかかるので、何回もバックアップ結果を書き出さないようにすればいい。
本当は１日１２時間かけて実施したほうが安くはなるけど、本業あるので休むわけにもいかんしねぇ。
今回は毎朝１日３時間ぐらい作業して４日かかった。
１日目：ネットワークの一時変更とubuntu22の作成とsmb/apache2/docker導入
２日目：データディスクのマウントとフォルダ構成の調整
３日目：rclone設定とgoogle driveへのバックアップ確認
４日目：google driveからのローカルlinuxへのリストア確認
午後になるとだいたいの費用が見えるから、普段月半ばで８００円ぐらいなのが１１００円ぐらいになってた。
５日目に古いほうのubuntu20のディスクを開放したから、プラス５００円ぐらいで済むはず（来月の２日午後に確定する）。
２日午後に確認したら、
おお、2500円未満程度で済んでる！！
だいたいの費用予測も一致。
マシンタイプの再検討
今まで「e2-standard-4」を使ってた。CPU４コアで、メモリ16GB。
gitlabが重たいのもあるから、今回から「e2-standard-8」にして性能上げてみた。
前にも似たようなことしたけど、これぐらいの変更だと数百円しかかわらないはず。
体感する処理速度上がるとええなぁ。
windowsのteratermからの接続と、macのterminalからの接続
普段使う接続の調整もやらなあかん。
クリックするだけでsshできる環境はずーっと維持してる。
面倒やったけど、最終形はこんな感じ。
windowsのteraterm
keygenで鍵ファイル作り直したから、そのパスとファイル名指定をgvis.iniの中を書き直した。
includeさせて動くteratermのマクロはだいたいこんな感じ。
include 'Y:\94_connect\connect\teraIni\gvis.ini'
; --- 接続 --------------
conSTR = 'gcp-nadklinuxdirect.intra.gavann-it.com /ssh /auth=publickey /user=nari /passwd='
strconcat conSTR gvis_nari
strconcat conSTR ' /keyfile='
strconcat conSTR gvis_KY1
strconcat conSTR ' /F='
strconcat conSTR gvis_iPTH
strconcat conSTR 'wineBlue.ini '
strconcat conSTR '/timeout='
strconcat conSTR gvis_TOUT
; ---debug --------------
; messagebox conSTR 'info'
connect conSTR
if result <> 2 goto end
wait gvis_wS1
sendln "df -h"
wait gvis_wS1
sendln "w"
:endこれ使うと、teraterm接続はこうなる。
ログインしてdfとwが投入できてる。
macのterminal
妄想してここでやった内容を更新。
terminalの設定を念のため確認。
色合いとか画面サイズ設定が入ったプロファイルに紐づけた、呼び出しシェルの名前を確認。
ssh-gcp-naLinuxDirect.shでOK。
このプロファイル設定の左下のほうにあるアイコンをクリックして書き出したterminalってファイルをクリックして呼び出すと、呼び出しシェルが動く。
呼び出してるシェルの内容はこんな感じ。
ホスト名は宅内DNSで名前解決してるから以前のままでOK。
#!/bin/sh
# 汎用自動sshスクリプトの読み込み
. autoLogin-gcp-onlchk.sh
# 自動ログインを実行
auto_ssh 'gcp-nadklinuxdirect.intra.gavann-it.com' 'nari' 'xxxxxxxx' 22autoLogin-gcp-onlchk.shを呼び出してるから、そのチェック。
#!/bin/sh
auto_ssh() {
host=$1
id=$2
pass=$3
ptNum=$4
ptTime=10
expect -c "
set timeout ${ptTime}
spawn ssh ${id}@${host} -p ${ptNum} -i /Users/nari/Documents/personal/script/terminal/key/20220608key_id_rsa_nari.txt
expect \"${id}@${host}'s password:\"
send \"${pass}\n\"
} \"key_id_rsa_nari.txt': \" {
send \"${pass}\n\"
expect \"nari\"
send \"onlchk\n\"
expect \"nari\"
send \"df -h\n\"
}
interact
"
}つなぐ前に、macの中にある.sshディレクトリのknown_hostsにある古いホスト名の設定業をviで開いて削除しておく。元のが残ってると「わけわからんホストつなぐのはアカンで、管理者に相談してや」みたいなメッセージが出て接続できん。
削除した行はこのへん。鍵文字列満載やから読みにくいのでawkで端的に出すと、こんな感じ。
nari@gvisMac .ssh % pwd
/Users/nari/.ssh
nari@gvisMac .ssh % ls
config known_hosts known_hosts.old
nari@gvisMac .ssh % cat -n known_hosts | grep gcp | awk '{print $1,$2}'
10 gcp-nadklinuxdirect.intra.gavann-it.com
11 gcp-nadklinuxdirect.intra.gavann-it.com
12 gcp-nadklinuxdirect.intra.gavann-it.com
nari@gvisMac .ssh %初回はknown_hostsに書き足すかどうかの確認メッセージが来るからyesってして続ける。
２回目つないでみる。
おお、いけるやん。
後で妄想したmacからdockerコンテナのredhatクローンへの接続設定もついでに作った。
まずはredhat8.6のクローン。
次はredhat9.0のクローン。
どっちもつながってくれた。
コメント