azure 仮想マシンの試験利用(dockerコンテナ利用をgoogle cloudと比較)

今年の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/メモリの課金具合やその性能は問題ないけど、ディスクの費用が5倍ぐらい高い(azureで60GB確保したとき、googleの300GBのディスクと同じっぽい)
  • セキュリティグループの設定が不慣れでうまくつながらないことがあると、接続設定を補助してくれる仕組みがあって好感が持てる

日常的にgoogle cloud/awsでwindows/linuxのサーバ作ったりサービス構成して接続設定してるので、用語とか概念をトランスファする何かがあったらazureにもスンナリ理解が進んで、1日目で使えるようにはなるかも。

安全に使えるかとか、費用をつきつめて使うにはまだまだやけど。
課金ではnatあたりが高い。

左がazureで右がgoogle cloud。

gvis-azure-try2024

azure仮想マシン停止してるのに固定IP確保してインターネットに出るときの設定維持費用が高かった。

google cloudで同じようなことして月2500円未満なのに、azureの予測グラフは7000円以上かかる。

左下の円グラフではNATが食い過ぎ。仮想マシン停止しててもネットワーク系の費用は計上するらしい。

どうにかして見える方法あるんかもしれんけど、azureは何時間ほど使ったのかが表示されないから、料金が不明確。ここは右がazureで左がgoogle cloud。

gvis-azure-try2024

自分の設定とか扱い方が悪いんかもしれんけど、やっぱり自分にはgoogle cloudが一番あってる。

無料枠とかあるのか

googleは300ドルの無料枠があった。しかも3ヶ月ほど使える。
去年に業務用のgoogleアカウントでkubernetesの練習させてもらった。

今とは為替レートが50円ぐらい違うけど、10年ぐらい前に使い始めたときもgoogleに無料枠あって最初は費用感を掴んだ。

誰でも最初は初心者なんやから使い始めの価格って大事で、敷居が低いってことはエエこと。それだけで印象変わる。

2024年のazureどうなんやろ。

ググったらすぐ出てくる。30日 or 200ドル無料なんやな。
今は1ドルが150円以上やから3万円分ぐらいか。

クラウド コンピューティング サービス | Microsoft Azure
Microsoft Azure のオープンで柔軟なクラウド コンピューティング プラットフォームを使用すれば、目的を持って創造し、コストを節約し、組織の効率を向上させることができます。

1ヶ月じゃ、時間的に仮想ホスト作れてもkubernetesまでは踏み込めん。

linuxホスト作ってdockerでコンテナ動かして、windowsホストから利用確認するみたいなところまで行けたらええか。

windowsホストはライセンス料かかるんやろし、dockerも動かんやろからやっぱubuntuを動かすとこまでを目指す。

msアカウントはあるから、普通にスマホの番号入力して確認コード受け取りして契約に同意してサインアップしてった。

クレジットの情報とか必要やけど、同意せん限りは請求来ることないっぽい。
一般的な手順やから割愛。

多重要素認証でgmailにログインの確認コードがきたら入力したら使い始められるようになる。

使い始めと参考記事

azureのポータルに入るとクイックスタートがある。

gvis-azure-try2024

チュートリアルもあるんやけど、Eric Boydさんが英語でフツーに解説してくれるだけでなんとなくしか聞き取れず。

gvis-azure-try2024

字幕入れといてくれよー。リスニング苦手や。

ちょっとだけ見てわかったのはクラウドシェルがあって、bashだけじゃなくてpowershellが使える。

gvis-azure-try2024

やってみたら選べるんやけど、powershell使う人いるんかなぁ。

自称「windowsバカ」な人やったらええんやろけど、自分は「unixバカ」を目指してるし、powershell苦手やからbash選ぶわな。

gvis-azure-try2024

無料枠やし今は放っとくけど、お金払ってディスク使わな始められへんらしい。あ、ハードコピー忘れた。

クラウドシェルは、awsやったらaws xxx、gcpやったらgcloud xxxとかやる。
azureはaz xxxってやるらしい。

最初やしqiitaとか頼ることにする。

なるほど、基本的なことはこんな感じなんや。
作者さんありがとう。

AzureでUbuntu仮想マシンをデプロイする(Webサーバ用途) - Qiita
船井総研デジタルのよもぎたです。今回は、AzureにUbuntu仮想マシンをデプロイして、そこにWebサーバを構築してみたいと思います。WebサーバはApacheとNginxの2パターンを考えてい…

さっと読んでだいたいの設定どころを理解しとく。
最初はsshできるようにして、あとはコンテナへの接続を目指す。

実際に設定しはじめると、案内がちょくちょく見える。
踏み台が有料で使えるそうな。

価格 - Azure Bastion | Microsoft Azure
Azure Bastion サービスは、Azure 仮想ネットワーク内の Azure VM への安全でシームレスな RDP および SSH 接続を提供します。VM 上のパブリック IP は必要ありません。

ファイアウォールも有料のがあるらしい。外部公開のサイトとか利用制限させたいときに使うんかな。

セキュリティグループ使えばエエから今は設定せん。

価格 - Azure Firewall | Microsoft Azure
ネットワーク セキュリティと分析のためのクラウドネイティブのサービスである Azure Firewall の価格について詳しく説明します。

仮想マシン作る

普通に作る。

まずはサブスクリプションってのを作る。
google cloudではプロジェクトのことで枠のことっぽい。

gvis-azure-try2024

適当に自分が連想しやすい名前つけといた。
次は踏み台とファイアウォールの設定。
使わん。

gvis-azure-try2024

IPアドレスの利用範囲の設定。
今は1つしかIPアドレスいらんけど、これも適当。

gvis-azure-try2024

ローカルマシンからazureの仮想マシンへ接続する外部IPがいるから、パブリックIPを使う。

gvis-azure-try2024

タグもいらん。

gvis-azure-try2024

確認画面で作成概要をチェック。

gvis-azure-try2024

はいできた。

gvis-azure-try2024

自分は固定IP使ってるので、そこからだけ接続を許可するように設定を作る。

gvis-azure-try2024

先に作ったサブスクリプションとリソース指定で検証OKらしい。

gvis-azure-try2024

優先順位上のほうにしていったんsshだけ許可設定作る。
デフォルトで設定されてる拒否設定はそのままにしとく。
と、思ったらソースポートは「*」にしとかなアカンらしい。

gvis-azure-try2024

ネットワーク作る。

gvis-azure-try2024

パブリックIP作る。

gvis-azure-try2024

設定はデフォルトのまま。

gvis-azure-try2024

保護設定もデフォルトのまま。

gvis-azure-try2024

タグいらん。

gvis-azure-try2024

検証結果OKみたいなんで作ってもらいましょ。

gvis-azure-try2024

仮想マシンを作る。

gvis-azure-try2024

google cloudの仮想マシンと同じ条件で4コア16GBを選ぶ。
後でハマったんやけど、ここでマシンタイプしっかり精査せんかった。
このマシンタイプは勝手に一時ディスク作りよる。

gvis-azure-try2024

OSユーザはデフォルトのまま、鍵ファイルの名前を指定しとく。

gvis-azure-try2024

OSが使うディスクを用意。

gvis-azure-try2024

データ用ディスクを用意する。
ここにdockerのフォルダ作って永続化領域とかも設置してくのに使う。

gvis-azure-try2024

さっき作ったネットワークとか選ぶ。

gvis-azure-try2024

削除設定とかロードバランスみたいな箇所も選べるんやな。
いったんデフォルト設定のままにしとく。

gvis-azure-try2024

ここはようわからんかった。
いったんデフォルト設定のままにしとく。

gvis-azure-try2024

自動停止の設定できるらしい。
crontab使うからいらんけど、ちょっと試しにやっといたら普通に停止してくれてた。

gvis-azure-try2024

ここもようわからんかった。
いったんデフォルト設定のままにしとく。

gvis-azure-try2024

拡張機能って何やろ?

gvis-azure-try2024

アンチウィルスとか入れてくれるんや。
親切やね。

gvis-azure-try2024

GPUのドライバとかもあるんや。

gvis-azure-try2024

ようわからんからそのまま。

gvis-azure-try2024
gvis-azure-try2024

やっと確認画面。

gvis-azure-try2024

取りこぼさんように鍵ファイルをダウンロードしとく。

gvis-azure-try2024

やっとできた。

gvis-azure-try2024

ここまで来ても初日やから費用はゼロ円。明日になったら前日のが見えるかな。

gvis-azure-try2024

次の日に見たらこうなってた。まぁ300円行かんぐらいやわな。

gvis-azure-try2024

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
gvis-azure-try2024

macからteraterm使えるわけやないから、spawnをからめたssh接続するスクリプト使ってるので、ターミナルの設定で色とかサイズ定義した後でスクリプト呼び出しを書いとく。

gvis-azure-try2024

んで、ターミナルで指定したシェルスクリプトを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させとく。
つないだらこうなる。

gvis-azure-try2024

はい開通完了。
データディスクっぽいの見えてへんけど、次はマウントさせたいフォルダ箇所にマウントさせよっか。

データディスクのマウントで困惑した

ディスクは最初こう見えてるなぁ。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の中見てみたら、テキストファイルが1個入ってて「テンポラリディスクやから使ってくれるな」みたいなことが書いてある。

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ドライブ使うんやて!!!
勝手にディスク利用の底上げしてんのかいな!!! そんな設定したつもりないで!!!

Azure Linux VM のディスク識別 - Qiita
はじめにこんにちは。この記事は、Microsoft Azure Tech Advent Calendar 2022 22日目の記事です。Azure Linux VM にデータディスクを複数接続…
一時ディスクって何? Azure仮想マシン独自のストレージ構成を理解しよう
仮想マシンを作るとC:とD:の2つのドライブが作られますが、これはなぜ? 今回はAzure仮想マシンにおけるストレージ(ディスク)の扱いについて見てみましょう。

なんやねん、面倒くさいわぁ。

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再起動10回やってもちゃんとマウントできるようになった。

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# 

実行したら4コアcpu、メモリ16GBが見えてネットワーク通信状態も確認できる。

gvis-azure-try2024

ついでにロケールを日本にして時刻も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"

:end

teratermの古いアルゴリズムではつながらん

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が高い!!!

gvis-azure-try2024

予測のグラフ見たら、このままなんもせんでも7000円ぐらいまで行っとる。

アカン、完全に利用フラグ下がった。
やっぱ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

ビルド途中の負荷はこんな感じで特に問題なし。

gvis-azure-try2024

別窓開いて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のはず。

gvis-azure-try2024

投げる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が拡がってるやん。

gvis-azure-try2024

こっからアプリケーションが参照するデータの生確認。
テーブルちゃんとあるでぇ。

gvis-azure-try2024

額面伏せるけど、あってるあってる。

gvis-azure-try2024

mariadbへのパラメータも渡ってるし消費税もちゃんと累積計算できてるやん。

gvis-azure-try2024

そもそものバージョンもちゃんと見えてる。

gvis-azure-try2024

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$ 

10分ぐらい待つと終わる。docker runでコンテナ起動して手動でしかできない設定してく。

まずはmacからリモートデスクトップ接続ね。
普段ローカルlinuxから使ってる設定をコピーして接続先と設定名を入れとく。

gvis-azure-try2024

speedtestで1901、インターネットに出る速度はまぁまぁやけど、google cloudのほうがダウンロード速度は速い。

gvis-azure-try2024

高いnat設定で課金するくせにスピード出えへんのな。

次vscode。
プラグイン入れてgitlabで管理してるdjangoのソースのgitgraph見えるやん。

gvis-azure-try2024

ここまでで2000円ほど使っとるな。

gvis-azure-try2024

ちゃんと起動できて使えるのはわかった。

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コンテナやから警告出てくる。

gvis-azure-try2024

ここまで来たら全部OKっぽい。

gvis-azure-try2024

djangoのライブラリ使って円グラフできてるし、コンテナに日本語フォントをaptしてるから日本語表示もできてるやん。

gvis-azure-try2024

ログイン認証通してからアプリが使える。

gvis-azure-try2024

ページネーションできてるし、cssの設定で指定の色合いで表示できてて金額やら日付もあってる。

gvis-azure-try2024

古いデータやけど、昔使ってたマシンのカタログをmariadbから取ってきてブラウザでpdfをインライン表示もOK。
しっかし懐かしいマシンやな。2世代ぐらい前に使ってたっけ。

gvis-azure-try2024

ログインしてからdjangoの管理画面も見える。

gvis-azure-try2024

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# 

やってる途中はこんな負荷で、コンテナ停止しておいて5分弱かかった。

gvis-azure-try2024

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 STATE

oracle21へ接続

ファイアウォール設定をoracle分として31521として書き足す。
コンテナは1521で動いてるつもりでも、外部公開ポートは31521なんでローカルのa5sqlからつなぐときにはこのポートを許可しとく。

gvis-azure-try2024

許可設定終わったら接続確認。
a5sql使うとローカルora21の接続設定をコピーして使いまわせる。

gvis-azure-try2024

sql発行してバージョン確認できとるなぁ。

gvis-azure-try2024

xrdpコンテナへ接続した後に音が出るか

せっかく思い出したし確認画像だけおいとく。

xrdpコンテナはGUI確認にめっちゃ便利。動画見たら音再生できるんか?

結論は動画のみで音声は出んかった。

gvis-azure-try2024

もう5年以上前にgoogleサポートに英語で問い合わせしたら「音は出ん」って返ってきた。

linuxやからalsaナントカって仕組み入れたら音出るかもしれんけど、そこまでして音声会議とか動画視聴したいわけやないしなぁ。

これはコンテナ全般的に同じはず。
dockerホストでも、minikubeでも、GKEのkubernetesでも音声試したけどアカンかった。

youtube再生してみたら、動画はカクカク動いたのは言わずもがな・・・。

まぁまぁCPUも浪費する。

speedtestの結果

何日かに分けて時間帯も変えて試したけど、ダウンロード速度は1800〜2700ぐらいまでしか出ん。

gvis-azure-try2024

数年したらまた試してみるけど、やっぱりgoogle cloudをまだしばらく使うわな。

同じことできるんやったら安くて済む方使う。
そらそうやで。

タイトルとURLをコピーしました