今年のGWの勉強はazure利用。
前にもやりかけたことあったけどwebページ見て概要掴むだけやった。
実際に30日トライアル使わせてもらう。
価格比較もしたいから、普段google cloudでやってるdockerコンテナ稼働を目指す。
Azureでサーバ作ってみる
普段はGoogle cloudのubuntuでデータ本番利用しといて、ローカルのubuntuにもdocker入れて使ってる。
DjangoとmariadbはときどきLTSのバージョンが上がってくからローカルでモジュールを変更してテストしてgitlabでバージョン管理してる。
+-local ubuntu22 linux--------+ +-GCE ubuntu22 linux----------+
| +-docker---------+ +-vmdk-+ | | +-docker---------+ +--pv--+ |
| | +-container-+ | | data | | | | +-container-+ | | data | |
| | | Django | | | d1 | | | | | Django | | | d1 | |
| | +-----------+ | +------+ | | | +-----------+ | +------+ |
| | +-container-+ | | | | | | +-container-+ | | | |
| | | mariadb | | | d2 | | | | | mariadb | | | d2 | |
| | +-----------+ | +------+ | | | +-----------+ | +------+ |
| | +-container-+ | | | | | | +-container-+ | | | |
| | | xrdp-ubu22| | | d3 | | <- | | | xrdp-ubu22| | | d3 | |
| | +-----------+ | +------+ | <- | | +-----------+ | +------+ |
| | | | <- | | +-container-+ | |
| | | | | | | gitlab | | |
| | | | | | +-----------+ | |
| | +-container-+ | | | | +-container-+ | |
| | | https | | | | | | https | | |
| | +-----------+ | | | | +-----------+ | |
| +----------------+ | | +----------------+ |
+-----------------------------+ +-----------------------------+今回は、ローカルのubuntuで使ってる環境をazureに展開できるかやってみる。
+-Azure ubuntu22 linux--------+
| +-docker---------+ +-vmdk-+ |
| | +-container-+ | | data | |
| | | Django | | | d1 | |
| | +-----------+ | +------+ |
| | +-container-+ | | | |
| | | mariadb | | | d2 | |
| | +-----------+ | +------+ |
| | +-container-+ | | | |
| | | xrdp-ubu22| | | d3 | |
| | +-----------+ | +------+ |
| | | |
| | +-container-+ | |
| | | https | | |
| | +-----------+ | |
| +----------------+ |
+-----------------------------+結論としては、同じようなことをしようとしてgoogle cloudよりazureのほうが高いように感じた。
- ネットワーク費用が高くてイマイチで、特にNATでの計上がマシンを稼働させてないときにも発生して納得できない
- 仮想マシンのcpu/メモリの課金具合やその性能は問題ないけど、ディスクの費用が５倍ぐらい高い(azureで60GB確保したとき、googleの300GBのディスクと同じっぽい)
- セキュリティグループの設定が不慣れでうまくつながらないことがあると、接続設定を補助してくれる仕組みがあって好感が持てる
日常的にgoogle cloud/awsでwindows/linuxのサーバ作ったりサービス構成して接続設定してるので、用語とか概念をトランスファする何かがあったらazureにもスンナリ理解が進んで、1日目で使えるようにはなるかも。
安全に使えるかとか、費用をつきつめて使うにはまだまだやけど。
課金ではnatあたりが高い。
左がazureで右がgoogle cloud。
azure仮想マシン停止してるのに固定IP確保してインターネットに出るときの設定維持費用が高かった。
google cloudで同じようなことして月２５００円未満なのに、azureの予測グラフは７０００円以上かかる。
左下の円グラフではNATが食い過ぎ。仮想マシン停止しててもネットワーク系の費用は計上するらしい。
どうにかして見える方法あるんかもしれんけど、azureは何時間ほど使ったのかが表示されないから、料金が不明確。ここは右がazureで左がgoogle cloud。
自分の設定とか扱い方が悪いんかもしれんけど、やっぱり自分にはgoogle cloudが一番あってる。
無料枠とかあるのか
googleは300ドルの無料枠があった。しかも３ヶ月ほど使える。
去年に業務用のgoogleアカウントでkubernetesの練習させてもらった。
今とは為替レートが５０円ぐらい違うけど、10年ぐらい前に使い始めたときもgoogleに無料枠あって最初は費用感を掴んだ。
誰でも最初は初心者なんやから使い始めの価格って大事で、敷居が低いってことはエエこと。それだけで印象変わる。
2024年のazureどうなんやろ。
ググったらすぐ出てくる。30日 or 200ドル無料なんやな。
今は１ドルが150円以上やから３万円分ぐらいか。
１ヶ月じゃ、時間的に仮想ホスト作れてもkubernetesまでは踏み込めん。
linuxホスト作ってdockerでコンテナ動かして、windowsホストから利用確認するみたいなところまで行けたらええか。
windowsホストはライセンス料かかるんやろし、dockerも動かんやろからやっぱubuntuを動かすとこまでを目指す。
msアカウントはあるから、普通にスマホの番号入力して確認コード受け取りして契約に同意してサインアップしてった。
クレジットの情報とか必要やけど、同意せん限りは請求来ることないっぽい。
一般的な手順やから割愛。
多重要素認証でgmailにログインの確認コードがきたら入力したら使い始められるようになる。
使い始めと参考記事
azureのポータルに入るとクイックスタートがある。
チュートリアルもあるんやけど、Eric Boydさんが英語でフツーに解説してくれるだけでなんとなくしか聞き取れず。
字幕入れといてくれよー。リスニング苦手や。
ちょっとだけ見てわかったのはクラウドシェルがあって、bashだけじゃなくてpowershellが使える。
やってみたら選べるんやけど、powershell使う人いるんかなぁ。
自称「windowsバカ」な人やったらええんやろけど、自分は「unixバカ」を目指してるし、powershell苦手やからbash選ぶわな。
無料枠やし今は放っとくけど、お金払ってディスク使わな始められへんらしい。あ、ハードコピー忘れた。
クラウドシェルは、awsやったらaws xxx、gcpやったらgcloud xxxとかやる。
azureはaz xxxってやるらしい。
最初やしqiitaとか頼ることにする。
なるほど、基本的なことはこんな感じなんや。
作者さんありがとう。
さっと読んでだいたいの設定どころを理解しとく。
最初はsshできるようにして、あとはコンテナへの接続を目指す。
実際に設定しはじめると、案内がちょくちょく見える。
踏み台が有料で使えるそうな。
ファイアウォールも有料のがあるらしい。外部公開のサイトとか利用制限させたいときに使うんかな。
セキュリティグループ使えばエエから今は設定せん。
仮想マシン作る
普通に作る。
まずはサブスクリプションってのを作る。
google cloudではプロジェクトのことで枠のことっぽい。
適当に自分が連想しやすい名前つけといた。
次は踏み台とファイアウォールの設定。
使わん。
IPアドレスの利用範囲の設定。
今は１つしかIPアドレスいらんけど、これも適当。
ローカルマシンからazureの仮想マシンへ接続する外部IPがいるから、パブリックIPを使う。
タグもいらん。
確認画面で作成概要をチェック。
はいできた。
自分は固定IP使ってるので、そこからだけ接続を許可するように設定を作る。
先に作ったサブスクリプションとリソース指定で検証OKらしい。
優先順位上のほうにしていったんsshだけ許可設定作る。
デフォルトで設定されてる拒否設定はそのままにしとく。
と、思ったらソースポートは「*」にしとかなアカンらしい。
ネットワーク作る。
パブリックIP作る。
設定はデフォルトのまま。
保護設定もデフォルトのまま。
タグいらん。
検証結果OKみたいなんで作ってもらいましょ。
仮想マシンを作る。
google cloudの仮想マシンと同じ条件で４コア１６GBを選ぶ。
後でハマったんやけど、ここでマシンタイプしっかり精査せんかった。
このマシンタイプは勝手に一時ディスク作りよる。
OSユーザはデフォルトのまま、鍵ファイルの名前を指定しとく。
OSが使うディスクを用意。
データ用ディスクを用意する。
ここにdockerのフォルダ作って永続化領域とかも設置してくのに使う。
さっき作ったネットワークとか選ぶ。
削除設定とかロードバランスみたいな箇所も選べるんやな。
いったんデフォルト設定のままにしとく。
ここはようわからんかった。
いったんデフォルト設定のままにしとく。
自動停止の設定できるらしい。
crontab使うからいらんけど、ちょっと試しにやっといたら普通に停止してくれてた。
ここもようわからんかった。
いったんデフォルト設定のままにしとく。
拡張機能って何やろ？
アンチウィルスとか入れてくれるんや。
親切やね。
GPUのドライバとかもあるんや。
ようわからんからそのまま。
やっと確認画面。
取りこぼさんように鍵ファイルをダウンロードしとく。
やっとできた。
ここまで来ても初日やから費用はゼロ円。明日になったら前日のが見えるかな。
次の日に見たらこうなってた。まぁ３００円行かんぐらいやわな。
ssh接続
一般的には、作った鍵を.sshにおいとくこと多いんやろけど、置き場決めて管理してるから接続文字列はアレンジして準備。
結論としてはこれでつながるんやけど、azureのファイアウォール設定で自分のIPで許可の仕方間違ってたから修正した。
コマンドラインやったらこれで繋がった。
ssh -l azureuser -p 22 -i /Users/nari/Documents/personal/script/terminal/key/gvis-jellyfish_key.pem xx.xx.xx.xx
macからteraterm使えるわけやないから、spawnをからめたssh接続するスクリプト使ってるので、ターミナルの設定で色とかサイズ定義した後でスクリプト呼び出しを書いとく。
んで、ターミナルで指定したシェルスクリプトをgoogle cloudの接続設定をコピーして用意する。
nari@gvis-mac script % cat ssh-azr-naLinuxDirect.sh
#!/bin/sh
# 汎用自動sshスクリプトの読み込み
. autoLogin-azr-onlchk.sh
# 自動ログインを実行
auto_ssh 'xx.xx.xx.xx' 'azureuser' 22
nari@gvis-mac script % さらに呼び出してるautoLogin-azr-onlchk.shを用意する。
nari@gvis-mac script % cat autologin-azr-onlchk.sh
#!/bin/sh
auto_ssh() {
host=$1
id=$2
ptNum=$3
ptTime=10
expect -c "
set timeout ${ptTime}
spawn ssh -l ${id} -p ${ptNum} -i /Users/nari/Documents/personal/script/terminal/key/gvis-jellyfish_key.pem ${host}
expect \"azureuser\" {
send \"df -hT \| grep \-v tmpfs \n\"
}
interact
"
}
nari@gvis-mac script % dfぐらいして欲しいからexpectの後でsendさせとく。
つないだらこうなる。
はい開通完了。
データディスクっぽいの見えてへんけど、次はマウントさせたいフォルダ箇所にマウントさせよっか。
データディスクのマウントで困惑した
ディスクは最初こう見えてるなぁ。scsiディスクの見せ方で/dev/sdaはええけど、/dev/sdb1があるなぁ。
これがデータディスクなんやろか。
azureuser@gvis-jellyfish:~$ sudo su -
root@gvis-jellyfish:~# blkid
/dev/sdb1: UUID="e70f89c2-be59-41bb-8048-5e882d6281a5" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2de82418-01"
/dev/sda15: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="3C45-1400" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="37690b3e-bb85-4541-bb5d-ecd9f26be6cd"
/dev/sda1: LABEL="cloudimg-rootfs" UUID="6ad1c370-b98c-4944-86bd-1a0958e820a1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="ee9c7d94-5a1c-449f-abf6-66a8068ffd5e"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/sda14: PARTUUID="b20b6f15-2c6d-433a-bab5-8940e68df014"
/dev/loop3: TYPE="squashfs"
root@gvis-jellyfish:~# もうちょっと見てみると、64GBのデータディスクは見えてへん。
/dev/rootで31GB、efiとかで128K/105M食うのはわかるけど、/mntで32GBってなんやねん？
仮想マシン作ったときそんなん作ってへんで？
root@gvis-jellyfish:~# df -hT | grep -v tmpfs
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 31G 1.7G 30G 6% /
efivarfs efivarfs 128K 32K 92K 27% /sys/firmware/efi/efivars
/dev/sda15 vfat 105M 6.1M 99M 6% /boot/efi
/dev/sdb1 ext4 32G 28K 30G 1% /mnt
root@gvis-jellyfish:~#ext4でフォーマットして/dev/sdb1が勝手にマウントされてるやん。なんで32Gなんや？ 確保したディスクに寄せてる？
/mntの中見てみたら、テキストファイルが１個入ってて「テンポラリディスクやから使ってくれるな」みたいなことが書いてある。
root@gvis-jellyfish:~# ls -l /mnt
total 20
-r--r--r-- 1 root root 639 Apr 27 21:05 DATALOSS_WARNING_README.txt
drwx------ 2 root root 16384 Apr 27 21:05 lost+found
root@gvis-jellyfish:~# cd /mnt
root@gvis-jellyfish:/mnt# cat DATALOSS_WARNING_README.txt
WARNING: THIS IS A TEMPORARY DISK.
Any data stored on this drive is SUBJECT TO LOSS and THERE IS NO WAY TO
RECOVER IT.
Please do not use this disk for storing any personal or application data.
For additional details to please refer to the MSDN documentation at:
http://msdn.microsoft.com/en-us/library/windowsazure/jj672979.aspx
To remove this warning run:
sudo chattr -i /mnt/DATALOSS_WARNING_README.txt
sudo rm /mnt/DATALOSS_WARNING_README.txt
This warning is written each boot; to disable it:
echo "manual" | sudo tee /etc/init/ephemeral-disk-warning.override
sudo systemctl disable ephemeral-disk-warning.service
root@gvis-jellyfish:/mnt# ちょっと調べたら出てくるんやけど、スワップみたいな使い方するドライブを勝手に作るらしい。
しかもwindowsホストやったらdドライブ使うんやて！！！
勝手にディスク利用の底上げしてんのかいな！！！ そんな設定したつもりないで！！！
なんやねん、面倒くさいわぁ。
OSで32GBってディスク確保したの間違えたっけってazureのコンソール二度見したがな。
azure特有っぽいことするんやったら、見えへんところでやってくれよなぁ。
アカン、こんなもん使うのがデフォルトやったら、メモリいっぱい使てしもて溢れた分をディスクに逃すとき、ディスク性能に引っ張られて応答不良出てまう。
特にクラウドはディスク性能がローカルPCのssdみたいに高くないことが多いから、溢れたメモリをディスクに書かせたら絶対アカン。
linuxやったらswapは作らず、windowsやったらpagefile.sysを、どんだけメモリ積んでても2GBで固定するセットアップを心がけてる自分には、azureのこの仮想マシン状態は受け入れられへん。
仮に物理マシンでもスワップを作りすぎたら過負荷のときディスク書き込みのせいでスローダウン起こすで。
作らん方法もあるみたいやけど、マシンタイプ依存な上、後で削除はでけへんっぽい（できるんかもしれんけど）。
たまたまかもしれんけど、軽い気持ちで選んだVMが性能を圧迫するような設定ではねぇ。
azureのコンソール見たら一時ディスクの費用が勝手に計上されてるようには見えへんかったけど、選んだマシンタイプの費用に乗ってるだけなんやろ。
なんでこういう考え方してるんやろなぁ。
昔は処理時間の短縮のためにプログラムとかSQLのチューニングを必死でやってる場面があった。
今は仮想マシンのリソースを多めに確保して処理時間縮めることもあるから、azureはそういう風潮に乗って性能劣化をすぐに起こそうとしてるようにも見える。
利用初日でazure利用選択のフラグ下がった。
とりあえずpartedで/dev/sdcがあるのは見えた。
root@gvis-jellyfish:~# parted -l
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 34.4GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
14 1049kB 5243kB 4194kB bios_grub
15 5243kB 116MB 111MB fat32 boot, esp
1 116MB 34.4GB 34.2GB ext4
Model: Msft Virtual Disk (scsi)
Disk /dev/sdb: 34.4GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 34.4GB 34.4GB primary ext4
Error: /dev/sdc: unrecognised disk label
Model: Msft Virtual Disk (scsi)
Disk /dev/sdc: 68.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:
root@gvis-jellyfish:~# 最後のほうに/dev/sdcあるやん。
64GBのディスクを仮想マシン作る時にデータディスクとして用意したつもりやけど、partedでは68.7GBってなってるな。
mkfs.xfsとかできるんかな。
確認してからマウントポイントとパーティション作ってみよか。
root@gvis-jellyfish:~# mkdir /docker
root@gvis-jellyfish:~# which mkfs.xfs
/usr/sbin/mkfs.xfs
root@gvis-jellyfish:~# mkfs.xfs -f /dev/sdc
meta-data=/dev/sdc isize=512 agcount=4, agsize=4194304 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0
data = bsize=4096 blocks=16777216, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=8192, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Discarding blocks...Done.
root@gvis-jellyfish:~# 作れたっぽいから手動でマウントしてみよか。
root@gvis-jellyfish:~# mount -t xfs /dev/sdc /docker
root@gvis-jellyfish:~# df -hT | grep -v tmpfs
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 31G 1.7G 30G 6% /
efivarfs efivarfs 128K 32K 92K 27% /sys/firmware/efi/efivars
/dev/sda15 vfat 105M 6.1M 99M 6% /boot/efi
/dev/sdb1 ext4 32G 28K 30G 1% /mnt
/dev/sdc xfs 64G 490M 64G 1% /docker
root@gvis-jellyfish:~# 念の為OS再起動してみたら、/dev/sdcが/dev/sdaになってた。
マウントはできるんやけど、日によってデータディスクが/dev/sdaとか/dev/sdcとか変わってまうんか？
root@gvis-jellyfish:~# parted -l
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 68.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags
1 0.00B 68.7GB 68.7GB xfs
:(中略)OS停止して次の日に続きやってみたら、データディスクが/dev/sdaになってた。
フォーマットしたらデータディスク優先で見えるようになるっぽいから、起動スクリプトは/dev/sdaにして順番に処理させるか。
OS起動した後にデバイス名指定してマウントしようとしてたら、/dev/sdaとsdcに設定コロコロ変わる。
しゃあないから、blkidで確認したuuidをfstabに書いてOS起動のときにマウントさせるように処理させたら、OS再起動１０回やってもちゃんとマウントできるようになった。
azureuser@gvis-jellyfish:~$ cat /etc/fstab
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
UUID=6ad1c370-b98c-4944-86bd-1a0958e820a1 / ext4 discard,errors=remount-ro 0 1
UUID=3C45-1400 /boot/efi vfat umask=0077 0 1
UUID=a1a931c3-b284-44ec-bb84-50cdedd6dee8 /docker xfs defaults,nofail 1 2 ⭐️ここ足した
/dev/disk/cloud/azure_resource-part1 /mnt auto defaults,nofail,x-systemd.requires=cloud-init.service,_netdev,comment=cloudconfig 0 2
azureuser@gvis-jellyfish:~$ んんん？ 最後の行に何か増えとるな。まぁええか。
あとは運用シェルの置き場作って、docker-ce入れてビルドとかやってくかな。
モジュール導入と作業フォルダの準備
いつも使うエイリアスとか、道具類をインストールしながら作業フォルダと運用スクリプトを用意してく。
システム状態の確認のためのnmon
まずはリソースの確認してみようとしたら、nmon使いたいのに入らん。
Unableってなんやねん。Ubuntuで普通にaptできんのか？
クラウドの中やからapt先は普通のリポジトリやなくてazureのなんやろな。
root@gvis-jellyfish:~# apt install nmon
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package nmon
root@gvis-jellyfish:~# awsでもgoogleでも、クラウドの中でubuntuホスト作ったときのapt参照先リポジトリはクラウドの中のを見てるはず。
いったんamazonlinux2023でやったときみたいに直接ダウンロードしてやってみたらできそう。
root@gvis-jellyfish:/home/azureuser# ls
nmon16m_helpsystems.tar.gz
root@gvis-jellyfish:/home/azureuser# tar xzf nmon16m_helpsystems.tar.gz
root@gvis-jellyfish:/home/azureuser# ls
20240429.tar.gz nmon_power_64le_rhel7_gpu nmon_x86_64_debian10 nmon_x86_64_rhel6
nmon16m_helpsystems.tar.gz nmon_power_64le_rhel8 nmon_x86_64_mint18 nmon_x86_64_rhel7
nmon_power_64_centos6 nmon_power_64le_sles12 nmon_x86_64_mint19 nmon_x86_64_rhel8
:(中略)
root@gvis-jellyfish:/home/azureuser# chmod 755 nmon_x86_64_rhel8
root@gvis-jellyfish:/home/azureuser# cp nmon_x86_64_rhel8 /usr/local/bin/nmon
root@gvis-jellyfish:/home/azureuser# which nmon
/usr/local/bin/nmon
root@gvis-jellyfish:/home/azureuser# 実行したら４コアcpu、メモリ16GBが見えてネットワーク通信状態も確認できる。
ついでにロケールを日本にして時刻もJSTにしとく。
# localectl
# apt install language-pack-ja -y
# localectl list-locales
# localectl set-locale LANG=ja_JP.UTF-8
# shutdown -r now
# date
# timedatectl set-timezone Asia/Tokyo
# date ファイル転送はscp使うし、windows側からteraterm使うかな。
teratermでのazure接続
書いたマクロはこんな感じ。変数になってる箇所は1行目のinclude元に書いて準備してるってことで。
これだけやとアカンことあるから注意。
include 'Y:_connect\connect\teraIni\gvis.ini'
; --- 接続 --------------
conSTR = 'xx.xx.xx.xx /ssh /auth=publickey /user=azureuser '
strconcat conSTR ' /keyfile='
strconcat conSTR gvis_KY5
strconcat conSTR ' /F='
strconcat conSTR gvis_iPTH
strconcat conSTR 'blue.INI '
strconcat conSTR '/timeout='
strconcat conSTR gvis_TOUT
; ---debug --------------
; messagebox conSTR 'info'
connect conSTR
if result <> 2 goto end
wait gvis_wS1
sendln "df -hT | grep -v tmpfs"
wait gvis_wS1
sendln "w"
:endteratermの古いアルゴリズムではつながらん
teratermのマクロ書いても、最初は接続に失敗した。
手動でteraterm起動してホスト名(IP)/ユーザ/秘密鍵を指定したらつながる。
ちょっと考えてみたら、amazonlinux2023で古いバージョンのteratermからはつながらず、teraterm5使い始めたこと思い出した。
理由は接続に使うsshのアルゴリズムで新しいのを使う必要があるから。
2023年頃のOSイメージを使うとteraterm4で扱うアルゴリズムでは接続できんし、設定ファイルの中で新しいアルゴリズム使うようにしとかなアカン。
発生した接続不良は、ver4あたりのteraterm使ってる頃の色定義ファイル（上の場合blue.INI）の中に、たぶん古いアルゴリズムのssh設定のことが書いてあるから。
teratermのINIファイルにはウィンドウサイズとかフォントとか、sshフォワーディングとかの設定が入ってて暗号化アルゴリズムの優先順位設定とか入ってるはず(winmergeでINIファイル比べたらすぐわかる)。
自分の場合、blue.INIを新しいバージョンのteratermで設定作りなおして接続したらazureのlinuxにつながった。
マクロ定義の問題やなくて、ttssh設定にあるアルゴリズムの問題。teraterm5で作らなアカン。
扱えるアルゴリズムが古いteratermやと最新のものがないから接続に失敗するのはもちろんやけど、ver5以上にしといて古いINIファイルも更新する必要がある。
ファイルの転送と展開
繋がったらscp転送してdocker本体の設定ファイルとか、dockerfileと永続化領域をまとめて持ってって展開しとく。
/gvis/scriptには普段使いのスクリプトが入ってて、gvis_confにはdocker-ceの設定ファイルとか入ってる。
/dockerにはコンテナの永続化領域(nariDockerDat)とcompose.ymlが入ってる。
ルートディレクトリ逼迫させないようdockerのイメージ置き場はnariDockerSysにする。
root@gvis-jellyfish:~# ls -lh /gvis/
total 12K
drwxr-xr-x 3 azureuser azureuser 4.0K Apr 28 20:50 gvis_conf
drwxr-xr-x 2 azureuser azureuser 4.0K Apr 28 20:50 log
drwxr-xr-x 8 azureuser azureuser 4.0K Apr 29 20:51 script
root@gvis-jellyfish:~# ls -lh /docker/
total 16G
-rw-r--r-- 1 azureuser azureuser 16G Apr 28 20:58 20240429.tar.gz
-rwxr-xr-x 1 azureuser azureuser 865 Jun 17 2023 DB11backup.sh
-rw-r--r-- 1 azureuser azureuser 8.9K Apr 18 21:18 compose-ALL.yml
-rw-r--r-- 1 azureuser azureuser 3.6K Apr 5 18:24 compose-current.yml
-rw-r--r-- 1 azureuser azureuser 3.6K Apr 5 18:24 compose.yml
-rwxr-xr-x 1 azureuser azureuser 936 Mar 22 2023 djangoDB11backup.sh
-rwxr-xr-x 1 azureuser azureuser 1.2K Sep 6 2023 djangoDB11restore.sh
-rw-r--r-- 1 azureuser azureuser 52M Mar 27 2023 docker-compose
-rw-r--r-- 1 azureuser azureuser 1.7K Mar 4 2021 docker.service.20210305.txt
-rw-r--r-- 1 azureuser azureuser 1.8K Feb 3 2023 docker.service.20230204.txt
-rw-r--r-- 1 azureuser azureuser 1.4K Feb 19 00:18 dockerStart.sh
-rwxr-xr-x 1 azureuser azureuser 586 Aug 12 2023 dockerStop.sh
drwxr-xr-x 8 azureuser azureuser 138 Apr 28 20:49 nariDockerDat
drwxr-xr-x 2 azureuser azureuser 6 Apr 28 20:46 nariDockerSys
root@gvis-jellyfish:~# dockerのインストール
コンテナ利用と動作確認に使う材料のインストール。
# apt-get update
# apt-get install \
ca-certificates \
curl \
gnupg \
lsb-release
# mkdir -p /etc/apt/keyrings
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
# echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# apt-get update
# apt-get install docker-ce docker-ce-cli containerd.io docker-compose-pluginこれで使える。
念のためバージョン確認ね。
最近awsのamazonlinux2023でdocker-ce入れたらcomposeが一緒に入らんかったけど、azureのubuntu22には入ってくれるんやな。
root@gvis-jellyfish:~# which docker
/usr/bin/docker
root@gvis-jellyfish:~# docker compose version
Docker Compose version v2.27.0
root@gvis-jellyfish:~# docker version
Client: Docker Engine - Community
Version: 26.1.1
API version: 1.45
Go version: go1.21.9
Git commit: 4cf5afa
Built: Tue Apr 30 11:47:53 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 26.1.1
API version: 1.45 (minimum version 1.24)
Go version: go1.21.9
Git commit: ac2de55
Built: Tue Apr 30 11:47:53 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.31
GitCommit: e377cd56a71523140ca6ae87e30244719194a521
runc:
Version: 1.1.12
GitCommit: v1.1.12-0-g51d5e94
docker-init:
Version: 0.19.0
GitCommit: de40ad0
root@gvis-jellyfish:~# 一般ユーザでdockerコマンド利用
azureのubuntuの初期ユーザはazureuser。
そこからdockerコマンド使えるようにしとく。
# usermod -aG docker azureuserサービス起動設定
サービス起動を順序立てて実施させるための設定をする。
これやっとくと「次のOS起動ではサービス起動せず、コンテナも停止させとく」みたいなことができるから、ディスク交換のための一時的なマウントポイント変更とか、サービス切り替えとかメンテナンスがやりやすい。
root@gvis-jellyfish:/gvis/script# systemctl is-enabled gvis.service
enabled
root@gvis-jellyfish:/gvis/script# cat /gvis/script/000_serviceStart.sh
#! /bin/bash
## -------------------------------------------------------------------------
## Script Name : serviceStart.sh
## Created by : T.Naritomi
## on : 2019.10.11
## Updated by : 2024.05.06
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : for gvis.service before os start (os base process and X11,xrdp,sshd)
## systemd require /etc/systemd/system/gvis.service
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
### exit
LOG=/gvis/log/000_serviceStart.log
echo "" > ${LOG}
## /bin/sh /gvis/script/006_mount_xfs.sh >> ${LOG}
/bin/sh /gvis/script/302_dockerStart.sh
sleep 30
## /bin/sh /docker/dockerStart.sh
root@gvis-jellyfish:/gvis/script# ディスクのマウントはazureの場合はfstabに書いて使うから、マウントのシェル呼び出しはコメント化してる。
最後の行のdockerStart.shはコンテナを起動するdocker composeのことが書いてあるから、ビルドが終わったらコメント化を外す。
コンテナ作成と稼働
mariadbに文字や数字のデータだけでなく、pdf/jpegが入ってるのでdjangoアプリからそれが見えるようにしてく。
dockerはコンテナ間通信が普通にできるので、xrdpのコンテナも作ってそこからブラウザで動作確認する。
docker-ceでhello world
そら動いて当たり前やな。
dockerイメージ取りにいけてるから、インターネットにも出れてる。
azureuser@gvis-jellyfish:~$ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/ここまでゴールデンウィークの前半でやり終わった。
嫁と遊びに行って帰ってきてから後半やろうと思ったら、コスト分析画面こんななってた。
なんやねん、NATがめっちゃ高いやん。
仮想マシンに計算させたりディスク使ってもそれなりの費用やけど、NATが高い！！！
予測のグラフ見たら、このままなんもせんでも７０００円ぐらいまで行っとる。
アカン、完全に利用フラグ下がった。
やっぱgoogle cloud使い続ける。
mariadbコンテナ
まずはdocker compose使って普通にビルドとデータベースの稼働させてみる。
root@gvis-jellyfish:/docker/nariDockerDat# docker compose up sv_mariadb1011
[+] Running 1/1
! sv_mariadb1011 Warning manifest for mariadb:1011 not found: mani... 2.2s
[+] Building 59.2s (9/13) docker:default
=> [sv_mariadb1011 internal] load build definition from sv_mariadb11_Dockerfile 0.0s
=> => transferring dockerfile: 6.38kB 0.0s
=> [sv_mariadb1011 internal] load metadata for docker.io/library/ubuntu:jammy 2.1s
:(中略)
=> [sv_mariadb1011 9/9] RUN chmod +x /usr/local/bin/docker-entrypoint.sh 0.2s
=> [sv_mariadb1011] exporting to image 1.6s
=> => exporting layers 1.6s
=> => writing image sha256:8cd3d8b8922a1b98f0513e5d4f8f1fcdce56cf6bc3ceac9b082ca97de93f3298 0.0s
=> => naming to docker.io/library/mariadb:1011 0.0s
[+] Running 2/2
✔ Network docker_default Created 0.1s
✔ Container docker-sv_mariadb1011-1 Created 0.0s
Attaching to sv_mariadb1011-1
sv_mariadb1011-1 | 2024-05-07 06:23:49+09:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.2+maria~ubu2204 started.
sv_mariadb1011-1 | 2024-05-07 06:23:50+09:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
sv_mariadb1011-1 | 2024-05-07 06:23:50+09:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.2+maria~ubu2204 started.
sv_mariadb1011-1 | 2024-05-07 06:23:50+09:00 [Note] [Entrypoint]: MariaDB upgrade not requiredビルド途中の負荷はこんな感じで特に問題なし。
別窓開いてdockerコンテナの中にログインしてアプリケーションが使うDBアカウントでデータ確認してみると、永続化領域のデータ参照いけてるっぽい。
azureuser@gvis-jellyfish:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8edec9afde4a mariadb:1011 "docker-entrypoint.s…" 59 seconds ago Up 58 seconds 0.0.0.0:13306->3306/tcp, :::13306->3306/tcp docker-sv_mariadb1011-1
azureuser@gvis-jellyfish:~$ docker exec -it docker-sv_mariadb1011-1 bash
root@svmariadb1011:/# mysql -u nari -pXXXXXXXXXXXXXXXX
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases ;
+--------------------+
| Database |
+--------------------+
| information_schema |
| nariDB_1st |
| nariDB_Django |
+--------------------+
3 rows in set (0.001 sec)
MariaDB [(none)]> connect nariDB_1st ;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Connection id: 4
Current database: nariDB_1st
MariaDB [nariDB_1st]> show tables ;
+-----------------------------+
| Tables_in_nariDB_1st |
+-----------------------------+
| GVIS_hwcheckResult |
| GVIS_keihi |
| GVIS_log |
| GVIS_logon |
| GVIS_mst_customer |
| GVIS_mst_kamoku |
| GVIS_mst_keihishubetsu |
| GVIS_mst_kshisanShokyaku |
| GVIS_mst_kshisanShokyakuRit |
| GVIS_mst_nohin |
| GVIS_transaction |
| GVIS_work |
| GVIS_zaiko |
| auth_group |
| auth_group_permissions |
| auth_permission |
| auth_user |
| auth_user_groups |
| auth_user_user_permissions |
| django_admin_log |
| django_content_type |
| django_migrations |
| django_session |
+-----------------------------+
23 rows in set (0.001 sec)
MariaDB [nariDB_1st]>んじゃ、ここからwindowsホストのa5sqlで接続してみる。
たぶん一発OKのはず。
投げるsqlはこんな感じ。
SHOW VARIABLES LIKE 'max_allowed_packet';
SHOW tables ;
SELECT * FROM GVIS_keihi
WHERE year(workPeriod) = 2024 and month(workPeriod) between 4 and 5
order by workPeriod desc , workShubetsu, workPriority ;
select Kamoku,Tax8Kng,Tax10Kng from GVIS_keihi where Tax8Kng > 0 or Tax10Kng > 0 ;
select @@version ;mariadbの永続化領域に置いたパラメータファイルがきいてて、max_allowed_packetが拡がってるやん。
こっからアプリケーションが参照するデータの生確認。
テーブルちゃんとあるでぇ。
額面伏せるけど、あってるあってる。
mariadbへのパラメータも渡ってるし消費税もちゃんと累積計算できてるやん。
そもそものバージョンもちゃんと見えてる。
xrdpのコンテナ
ベースになる実施内容はこのへん。
普通にビルドするだけやなくfirefoxとかvscodeでフォント指定やったり、xfceの時計表示設定を手動で実施する必要があるから、いったんdocker runしてからdocker saveでコンテナイメージを保管する必要がある。
ビルドしてみる。libreofficeとかfirefoxがインストールされた状態のイメージが作れるはず。
あとは応援するだけ。がんばれー。
azureuser@gvis-jellyfish:/docker/nariDockerDat/cl_ubun22/download/container-xrdp$ pwd
/docker/nariDockerDat/cl_ubun22/download/container-xrdp
azureuser@gvis-jellyfish:/docker/nariDockerDat/cl_ubun22/download/container-xrdp$ docker build -f ./ubuntu-xfce/Dockerfile-gvis -t ubu:22gvis .
[+] Building 8.5s (6/52) docker:default
=> [internal] load build definition from Dockerfile-gvis 0.0s
=> => transferring dockerfile: 5.08kB 0.0s
=> [internal] load metadata for docker.io/library/ubuntu:22.04 1.4s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> CACHED [ububase 1/48] FROM docker.io/library/ubuntu:22.04@sha256:a6d2b38300ce017add71440 0.0s
=> [internal] load build context 0.0s
:(中略)
=> [ububase 47/48] RUN echo "PATH=/gvis/script/proc:/usr/local/sbin:/usr/local/bin:/usr/sbin 0.3s
=> [ububase 48/48] RUN echo "export PATH" >> /home/nari/.bashrc 0.3s
=> exporting to image 50.6s
=> => exporting layers 50.5s
=> => writing image sha256:4f525ef5f292177b105cb8b757b83fbc58d9fcc20c48f6484cae59b41d206f68 0.0s
=> => naming to docker.io/library/ubu:22gvis 0.0s
azureuser@gvis-jellyfish:/docker/nariDockerDat/cl_ubun22/download/container-xrdp$
azureuser@gvis-jellyfish:/docker/nariDockerDat/cl_ubun22/download/container-xrdp$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
ubu 22gvis 4f525ef5f292 About a minute ago 3.49GB
mariadb 1011 8cd3d8b8922a 24 hours ago 401MB
azureuser@gvis-jellyfish:/docker/nariDockerDat/cl_ubun22/download/container-xrdp$ １０分ぐらい待つと終わる。docker runでコンテナ起動して手動でしかできない設定してく。
まずはmacからリモートデスクトップ接続ね。
普段ローカルlinuxから使ってる設定をコピーして接続先と設定名を入れとく。
speedtestで1901、インターネットに出る速度はまぁまぁやけど、google cloudのほうがダウンロード速度は速い。
高いnat設定で課金するくせにスピード出えへんのな。
次vscode。
プラグイン入れてgitlabで管理してるdjangoのソースのgitgraph見えるやん。
ここまでで２０００円ほど使っとるな。
ちゃんと起動できて使えるのはわかった。
djangoコンテナ
こっちは普通にcomposeでビルドして動き出すことができる。
azureuser@gvis-jellyfish:/docker$ docker compose up sv_django
[+] Running 1/1
! sv_django Warning pull access denied for sv_django, repository does n... 2.1s
[+] Building 28.0s (7/19) docker:default
=> [sv_django internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.66kB 0.0s
=> [sv_django internal] load metadata for docker.io/library/python:3.12.1-slim-bullseye 2.8s
=> [sv_django internal] load .dockerignore 0.0s
:(中略)
=> [sv_django djangobase 13/15] COPY app/requirements.txt /code/app/ 0.0s
=> [sv_django djangobase 14/15] RUN pip3 install -r /code/app/requirements.txt 16.6s
=> [sv_django djangobase 15/15] COPY . /code/ 0.1s
=> [sv_django] exporting to image 6.0s
=> => exporting layers 6.0s
=> => writing image sha256:79bf1920e8624da25dacfcc4f1897c2df922ea6d8dc7083dccb38824c6fea806 0.0s
=> => naming to docker.io/library/sv_django:5 0.0s
[+] Running 1/1
✔ Container docker-sv_django-1 Created 0.0s
Attaching to sv_django-1
sv_django-1 | /usr/local/lib/python3.12/site-packages/supervisor/options.py:474: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
sv_django-1 | self.warnings.warn(
sv_django-1 | 2024-05-09 04:06:22,900 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
sv_django-1 | 2024-05-09 04:06:22,900 INFO Included extra file "/etc/supervisor/conf.d/supervisor-app.conf" during parsing
sv_django-1 | 2024-05-09 04:06:22,904 INFO RPC interface 'supervisor' initialized
sv_django-1 | 2024-05-09 04:06:22,904 CRIT Server 'unix_http_server' running without any HTTP authentication checking
sv_django-1 | 2024-05-09 04:06:22,904 INFO supervisord started with pid 1
sv_django-1 | 2024-05-09 04:06:23,907 INFO spawned: 'app-uwsgi' with pid 7
sv_django-1 | 2024-05-09 04:06:23,909 INFO spawned: 'nginx-app' with pid 8
sv_django-1 | 2024-05-09 04:06:25,383 INFO success: app-uwsgi entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
sv_django-1 | 2024-05-09 04:06:25,383 INFO success: nginx-app entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)webサービスとして動きそう。
コンテナにbashで入ってpip3でのアップデート確認したらdjango本体のバージョンが上げれそうやった。
5.0.4から5.0.6へ上げましょ、上げましょ。
azureuser@gvis-jellyfish:/docker$ docker exec -it docker-sv_django-1 bash
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@svdjango:/# cd /code/app
root@svdjango:/code/app# ls
gvisDjango3 gvisWebApp manage.py media requirements.txt templates website
root@svdjango:/code/app# pip3 list -o
Package Version Latest Type
------- ------- ------ -----
Django 5.0.4 5.0.6 wheel
root@svdjango:/code/app# pip3 list -o | tail -n +3 | awk '{ print $1 }' | xargs pip3 install --upgrade
Requirement already satisfied: Django in /usr/local/lib/python3.12/site-packages (5.0.4)
Collecting Django
Downloading Django-5.0.6-py3-none-any.whl.metadata (4.1 kB)
Requirement already satisfied: asgiref<4,>=3.7.0 in /usr/local/lib/python3.12/site-packages (from Django) (3.8.1)
Requirement already satisfied: sqlparse>=0.3.1 in /usr/local/lib/python3.12/site-packages (from Django) (0.5.0)
Downloading Django-5.0.6-py3-none-any.whl (8.2 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 8.2/8.2 MB 125.2 MB/s eta 0:00:00
Installing collected packages: Django
Attempting uninstall: Django
Found existing installation: Django 5.0.4
Uninstalling Django-5.0.4:
Successfully uninstalled Django-5.0.4
Successfully installed Django-5.0.6
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
root@svdjango:/code/app# nginxでのhttpsコンテナもやってみよか。
まずはazureで作った仮想ホスト名とついでにhostsファイルの確認。
azureuser@gvis-jellyfish:~$ uname -n
gvis-jellyfish
azureuser@gvis-jellyfish:~$
azureuser@gvis-jellyfish:/docker$ cat /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
azureuser@gvis-jellyfish:/docker$ なるほど、作ったそのままが設定されてんのと、/etc/hostsにはlocalhostとipv6系の設定が少しあるだけ。
dockerはコンテナ間通信するときのコンテナホスト名を定義できる。
httpsのリバースプロキシは環境変数(DOMAINS)に親ホスト名を書いておいて、djangoコンテナのホスト名も書く。
sv_https-portal:
image: steveltn/https-portal:1
ports:
- "30080:80"
- "30443:443"
environment:
DOMAINS: 'gvis-jellyfish -> http://svdjango:8080' ⭐️ここの親ホスト名書き換えた
STAGE: 'local' # or 'production'
CLIENT_MAX_BODY_SIZE: 30M
volumes:
- ./nariDockerDat/sv_django-ssl_certs:/var/lib/https-portal
sv_django:
image: sv_django:5
build: ./nariDockerDat/sv_django-uwsgi-nginx
hostname: svdjango
volumes:
- ./nariDockerDat/sv_django-uwsgi-nginx/app:/code/app
ports:
- "38080:8080"
:(中略)忘れてたけど、djangoの中のsettings.pyにも書いとかなアカンのよね。
やっとかへんかったらdjangoでサイト接続したときエラー表示になる。
:(中略)
GV_CONST_HOST = 'gvis-jellyfish' ⭐️ここ書き換えた
GV_CONST_HOST_LCL_HTTP = "http://" + GV_CONST_HOST ⭐️ここで使うのよ
GV_CONST_HOST_LCL_HTTPS = "https://" + GV_CONST_HOST ⭐️ここで使うのよ
GV_CONST_DOCKER_HTTPS_PORT = "30443"
GV_CONST_DOCKER_HTTP_PORT = "38080"
:(中略)
ALLOWED_HOSTS = [GV_CONST_HOST] ⭐️ここで使うのよ
:(中略)
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': GV_CONST_DBENVNAME, # 実際に作ってあるDB名を設定する
'USER': GV_CONST_DBUSERNAME,
'PASSWORD': GV_CONST_DBPASSWD,
'HOST': GV_CONST_HOST, ⭐️ここで使うのよ
'PORT': GV_CONST_DBPORT,
'OPTIONS': {
'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
},
}
}
:(中略)
CSRF_TRUSTED_ORIGINS = [
GV_CONST_HOST_LCL_HTTPS + ':' + GV_CONST_DOCKER_HTTPS_PORT, ⭐️ここで使うのよ
GV_CONST_HOST_LCL_HTTP + ':' + GV_CONST_DOCKER_HTTP_PORT, ⭐️ここで使うのよ
]
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 60
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_PRELOAD = Trueさぁ、azureのコンテナさん、ローカルのlinux/google cloud/aws ec2/ecs/minikubeでやってくれたみたいにazureでも冪等性見せてくれ。
最後にhttpsのリバプロをビルドさせつつ、全部のコンテナを起動させる。
azureuser@gvis-jellyfish:/docker$ sh ./dockerStart.sh
[+] Running 1/1
✔ Container docker-sv_mariadb1011-1 Started 0.3s
[+] Running 17/17
✔ sv_https-portal Pulled 11.0s
✔ bd159e379b3b Pull complete 2.0s
✔ 8d634ce99fb9 Pull complete 3.8s
✔ 98b0bbcc0ec6 Pull complete 3.9s
✔ 6ab6a6301bde Pull complete 3.9s
✔ f5d8edcd47b1 Pull complete 3.9s
✔ fe24ce36f968 Pull complete 3.9s
✔ bd65f5478131 Pull complete 4.0s
✔ 4f4fb700ef54 Pull complete 4.0s
✔ ae493fe9da38 Pull complete 7.8s
✔ 11b9ec0cda3d Pull complete 7.8s
✔ 0cdee2a52c87 Pull complete 7.9s
✔ c53b86551bfb Pull complete 8.0s
✔ 35358700b609 Pull complete 8.0s
✔ a67f9d5f4c3e Pull complete 8.0s
✔ 58c94666d506 Pull complete 8.1s
✔ c6086c29190c Pull complete 8.1s
[+] Running 4/4
✔ Container docker-sv_mariadb1011-1 Running 0.0s
✔ Container docker-cl_ubu22gvis-1 Started 0.5s
✔ Container docker-sv_django-1 Started 0.5s
✔ Container docker-sv_https-portal-1 Started 0.5s
azureuser@gvis-jellyfish:/docker$ おーし！ 来た！！ 来た！！
azureuser@gvis-jellyfish:/docker$ docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
83358ec57261 docker-cl_ubu22gvis-1 0.00% 11.69MiB / 15.56GiB 0.07% 936B / 0B 11.8MB / 115kB 2
2b34a115bc19 docker-sv_https-portal-1 0.00% 4.859MiB / 15.56GiB 0.03% 936B / 0B 53.2kB / 274kB 14
bbdd92e25b2b docker-sv_django-1 0.02% 58.87MiB / 15.56GiB 0.37% 936B / 0B 0B / 16.4kB 11
8edec9afde4a docker-sv_mariadb1011-1 0.01% 1.498GiB / 15.56GiB 9.63% 1.16kB / 0B 1.4GB / 32.8kB 7オレオレ証明書のhttpsコンテナやから警告出てくる。
ここまで来たら全部OKっぽい。
djangoのライブラリ使って円グラフできてるし、コンテナに日本語フォントをaptしてるから日本語表示もできてるやん。
ログイン認証通してからアプリが使える。
ページネーションできてるし、cssの設定で指定の色合いで表示できてて金額やら日付もあってる。
古いデータやけど、昔使ってたマシンのカタログをmariadbから取ってきてブラウザでpdfをインライン表示もOK。
しっかし懐かしいマシンやな。２世代ぐらい前に使ってたっけ。
ログインしてからdjangoの管理画面も見える。
oracle21動かす
おまけでoracle21cをdockerで動かしてみた。
ローカルlinuxで練習したのはこんな感じ。
oracle21をビルドしてみる
root@gvis-jellyfish:/docker/nariDockerDat/sv_ora21/docker-images/OracleDatabase/SingleInstance/dockerfiles# ./buildContainerImage.sh -v 21.3.0 -e
Checking Docker version.
Dockerfile
Checking if required packages are present and valid...
LINUX.X64_213000_db_home.zip: OK
==========================
Container runtime info:
Client: Docker Engine - Community
Version: 26.1.1
Context: default
Debug Mode: false
:(中略)
==========================
Building image 'oracle/database:21.3.0-ee' ...
[+] Building 277.8s (15/15) FINISHED docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 5.02kB 0.0s
=> [internal] load metadata for docker.io/library/oraclelinux:7-slim 2.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [base 1/4] FROM docker.io/library/oraclelinux:7-slim@sha256:40acb375743853eb51948abbd8dd 15.2s
=> => resolve docker.io/library/oraclelinux:7-slim@sha256:40acb375743853eb51948abbd8dd907f6e 0.0s
=> => sha256:40acb375743853eb51948abbd8dd907f6e47cb368aa8da958cfd2fc5b36f71ce 547B / 547B 0.0s
=> => sha256:3bbaf6342e9f5d6aef40005a8e613535688d8870f3d92e640996bff19ae51b28 529B / 529B 0.0s
=> => sha256:970e50328c70a33ed558068ed168446105a0f9b6d78b8bcff5fa3423723c277 1.48kB / 1.48kB 0.0s
=> => sha256:9ff90099b5a4df32952d1822d472a72c931c53a68c05a3ba7431ea0f85d54 50.39MB / 50.39MB 1.5s
=> => extracting sha256:9ff90099b5a4df32952d1822d472a72c931c53a68c05a3ba7431ea0f85d54135 3.4s
=> [internal] load build context 15.1s
=> => transferring context: 3.11GB 10.3s
=> [base 2/4] COPY setupLinuxEnv.sh checkSpace.sh /opt/install/ 8.7s
=> [base 3/4] COPY runOracle.sh startDB.sh createDB.sh createObserver.sh dbca.rsp.tmpl setPa 0.1s
=> [base 4/4] RUN chmod ug+x /opt/install/*.sh && sync && /opt/install/checkSpace.s 27.3s
=> [builder 1/2] COPY --chown=oracle:dba LINUX.X64_213000_db_home.zip db_inst.rsp installDB 18.7s
=> [builder 2/2] RUN chmod ug+x /opt/install/*.sh && sync && /opt/install/installD 144.5s
=> [stage-2 1/4] COPY --chown=oracle:dba --from=builder /opt/oracle /opt/oracle 2.2s
=> [stage-2 2/4] RUN /opt/oracle/oraInventory/orainstRoot.sh && /opt/oracle/product/21c/ 0.4s
=> [stage-2 3/4] WORKDIR /home/oracle 0.1s
=> [stage-2 4/4] RUN echo 'ORACLE_SID=${ORACLE_SID:-ORCLCDB}; export ORACLE_SID=${ORACLE_SID 0.2s
=> exporting to image 41.2s
=> => exporting layers 41.2s
=> => writing image sha256:a98bed14572cbfa66bc823a8883f418fcc25c7d50507b80f57f4f0dc6d06f67a 0.0s
=> => naming to docker.io/oracle/database:21.3.0-ee 0.0s
Oracle Database container image for 'ee' version 21.3.0 is ready to be extended:
--> oracle/database:21.3.0-ee
Build completed in 278 seconds.
root@gvis-jellyfish:/docker/nariDockerDat/sv_ora21/docker-images/OracleDatabase/SingleInstance/dockerfiles# やってる途中はこんな負荷で、コンテナ停止しておいて５分弱かかった。
oracle21を動かしてみる
そら動くわな。
準備処理とかやってくれて、コーヒー入れて朝飯食ってる間に終わってた。
root@gvis-jellyfish:/docker# docker compose up sv_ora21
[+] Running 1/0
✔ Container docker-sv_ora21-1 Created 0.1s
Attaching to sv_ora21-1
sv_ora21-1 | Relinking oracle binary for edition: 21.3.0
sv_ora21-1 | make -f /opt/oracle/product/21c/dbhome_1/rdbms/lib/ins_rdbms.mk edition_21.3.0 ioracle
sv_ora21-1 | make: *** No rule to make target `edition_21.3.0'. Stop.
sv_ora21-1 | ORACLE EDITION: 21.3.0
sv_ora21-1 |
sv_ora21-1 | LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 12-5月 -2024 02:56:20
sv_ora21-1 |
sv_ora21-1 | Copyright (c) 1991, 2021, Oracle. All rights reserved.
sv_ora21-1 |
sv_ora21-1 | /opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください...
sv_ora21-1 |
sv_ora21-1 | TNSLSNR for Linux: Version 21.0.0.0.0 - Production
sv_ora21-1 | システム・パラメータ・ファイルは/opt/oracle/homes/OraDB21Home1/network/admin/listener.oraです。
sv_ora21-1 | ログ・メッセージを/opt/oracle/diag/tnslsnr/svora21/listener/alert/log.xmlに書き込みました。
sv_ora21-1 | リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
sv_ora21-1 | リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
sv_ora21-1 |
sv_ora21-1 | (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))に接続中
sv_ora21-1 | リスナーのステータス
sv_ora21-1 | ------------------------
sv_ora21-1 | 別名 LISTENER
sv_ora21-1 | バージョン TNSLSNR for Linux: Version 21.0.0.0.0 - Production
sv_ora21-1 | 開始日 12-5月 -2024 02:56:20
sv_ora21-1 | 稼働時間 0 日 0 時間 0 分 0 秒
sv_ora21-1 | トレース・レベル off
sv_ora21-1 | セキュリティ ON: Local OS Authentication
sv_ora21-1 | SNMP OFF
sv_ora21-1 | パラメータ・ファイル /opt/oracle/homes/OraDB21Home1/network/admin/listener.ora
sv_ora21-1 | ログ・ファイル /opt/oracle/diag/tnslsnr/svora21/listener/alert/log.xml
sv_ora21-1 | リスニング・エンドポイントのサマリー...
sv_ora21-1 | (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
sv_ora21-1 | (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
sv_ora21-1 | リスナーはサービスをサポートしていません。
sv_ora21-1 | コマンドは正常に終了しました。
:(中略)
sv_ora21-1 | #########################
sv_ora21-1 | DATABASE IS READY TO USE!
sv_ora21-1 | #########################
sv_ora21-1 | The following output is now a tail of the alert.log:
sv_ora21-1 | GVISORCL(3):CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORCL/GVISORCL/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
sv_ora21-1 | GVISORCL(3):Completed: CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE '/opt/oracle/oradata/ORCL/GVISORCL/users01.dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
sv_ora21-1 | GVISORCL(3):ALTER DATABASE DEFAULT TABLESPACE "USERS"
sv_ora21-1 | GVISORCL(3):Completed: ALTER DATABASE DEFAULT TABLESPACE "USERS"
sv_ora21-1 | 2024-05-12T03:03:22.534370+09:00
sv_ora21-1 | ALTER SYSTEM SET control_files='/opt/oracle/oradata/ORCL/control01.ctl' SCOPE=SPFILE;
sv_ora21-1 | 2024-05-12T03:03:22.548321+09:00
sv_ora21-1 | ALTER SYSTEM SET local_listener='' SCOPE=BOTH;
sv_ora21-1 | ALTER PLUGGABLE DATABASE GVISORCL SAVE STATE
sv_ora21-1 | Completed: ALTER PLUGGABLE DATABASE GVISORCL SAVE STATEoracle21へ接続
ファイアウォール設定をoracle分として31521として書き足す。
コンテナは1521で動いてるつもりでも、外部公開ポートは31521なんでローカルのa5sqlからつなぐときにはこのポートを許可しとく。
許可設定終わったら接続確認。
a5sql使うとローカルora21の接続設定をコピーして使いまわせる。
sql発行してバージョン確認できとるなぁ。
xrdpコンテナへ接続した後に音が出るか
せっかく思い出したし確認画像だけおいとく。
xrdpコンテナはGUI確認にめっちゃ便利。動画見たら音再生できるんか？
結論は動画のみで音声は出んかった。
もう5年以上前にgoogleサポートに英語で問い合わせしたら「音は出ん」って返ってきた。
linuxやからalsaナントカって仕組み入れたら音出るかもしれんけど、そこまでして音声会議とか動画視聴したいわけやないしなぁ。
これはコンテナ全般的に同じはず。
dockerホストでも、minikubeでも、GKEのkubernetesでも音声試したけどアカンかった。
youtube再生してみたら、動画はカクカク動いたのは言わずもがな・・・。
まぁまぁCPUも浪費する。
speedtestの結果
何日かに分けて時間帯も変えて試したけど、ダウンロード速度は1800〜2700ぐらいまでしか出ん。
数年したらまた試してみるけど、やっぱりgoogle cloudをまだしばらく使うわな。
同じことできるんやったら安くて済む方使う。
そらそうやで。
