IBMがredhatを含めちゃった数年前、なんか嫌～な感じがしてた。 やっぱりというか、centosの役割が変わってdockerhubからcentos8のイメージがなくなってた。 前に作ったldaps接続を、イメージからコンテナ作り直すことができない。 そこに、redhat9が リリース されてた。 業務ではほとんどがredhatとかamazonlinuxを使う。 今はたまたまredhatがほとんど。 十分なテスト環境をいつも使えるわけじゃないから、研究・検証・勉強のためにはdockerを使って環境作って知見を得る。 centosが使えないなら、redhatのクローン探しからやりなおしてldap認証やったろやんけ。 コンテナで ldapsサーバ作る箇所 はそのままで、接続元をredhat8/9のクローンOSで置き換えてみた。 redhatクローンOSの選択 いくつかある。 ただし、dockerイメージがないと自分には使えない。 ubuntu22にベースOSを変えたときusb3のディスクを高速なssdに変えたから、ディスクのI/O性能が数倍よくなって、めっちゃコンテナ作成速度も上がった。 結論 redhat8/9のイメージがdockerhubにあったけど、結局は使えなかった。 理由はパッケージの制限があってsssd/oddjobdがインストールできなかったから。 redhat面倒くさー。 やっぱりクローン使おう。 結局は、openldapのLDAPを使い、クライアント側はredhatクローンとしてalmalinuxの8.6/9.0を使い、OSへのログインをLDAP認証させた。 dockerの作業フォルダ こんな感じ。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 /docker |--docker-compose.yml |--nariDockerDat | |--cl_red8_Dockerfile | |--cl_red8　⭐️１ | | |--download | | |--script | |--cl_red9_Dockerfile | |--cl_red9　⭐️２ | | |--download | | |--script | |--sv_ldap | | |--gvisExport.ldif |--nariDockerSys　⭐️３ ⭐️１と⭐️２のcl_red8/cl_red9はクローンOSのための永続化領域。 ...

unix/linuxで定期的に処理を動かしたいときはcrontab使う。 たとえばcrontab.txtとか適当なファイルを作っておく。 左から、「分」「時」「日」「月」「曜日」「コマンド」を書く。 1 2 3 4 5 #daily rm 00 7 * * * /bin/find /gvis/ -name ".*DS_Store" -print -exec rm {} ";" 01 7 * * * /bin/find /gvis/ -name "Thumbs.db" -print -exec rm {} ";" 02 7 * * * /bin/find /nari/ -name ".*DS_Store" -print -exec rm {} ";" 03 7 * * * /bin/find /nari/ -name "Thumbs.db" -print -exec rm {} ";" この定義使うと、Thumbs.db(windowsが勝手に作るファイルね)とDS_Store(macが勝手に作るファイルね)を/nariのディレクトリ以下から探し出して抹消してくれる。 ...

mariadbにもLTSってのがある。 11.2が2023年2月に出てた。 MariaDB | endoflife.date endoflife.date 去年の暮れから、そろそろやらなアカンなぁって考えてた。 自分が使ってるのは10.5.7やったのを10.11に上げてく。 結果的にはバージョンアップするけど、動作確認しながらなので一時的に２つのバージョンのmariadbを共存させる。 去年まではphpから参照してたのを、djangoから参照するように変えたから、django内のモジュールもついでにバージョン上げてく。 詳細は長いリストになるものもあるから、分割で書いてリンク入れといた。 local-linuxとgoogle cloudの環境 local-linuxが練習環境、google cloudにあるのが本番環境。 djangoのアプリケーション作成と同じやり方。 local-linuxでまずは引越しの練習してからgoogle cloudで同じことやって、google cloudのデータをときどきlocal-linuxにもコピー反映する。 google cloudは本番環境として伝票入力とかドキュメント管理に使ってる。 データの入力や保管に「使う」ことに重点を置いてる。 できるだけ計算時間やディスク利用やダウンロードパケットは抑えながら使う方針。 そのためにlocal-linuxで練習してから実施。 実施のイメージ local-linuxでmariadb10.11のコンテナを作る docker-composeからビルドと起動できるようにする。 前はDockerfileとかconfフォルダ内の整理ができてなかったから、これもあわせて整理した。 ここでdocker-compose.ymlとdjangoのsettigs.pyに何て書けばいいかが確定する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +------------------------------------+ |local-linux(ubuntu22) | | +--------------------------------+ | | |docker23 | | | | +--------------+ +-------+ | | | | |mariadb10.5 | |django4| | | | | | nari_1st | <-- | | | | | | | nariDB_Django| | | | | | | +--------------+ +-------+ | | | | | | | | +------------+ | | | | |mariadb10.11| | | | | +------------+ | | | +--------------------------------+ | +------------------------------------+ nari_1stってのが本利用のスキーマでgoogle cloudと同じ内容を維持する。 永続化領域をgoogle cloudから丸々コピーして使ってる。 ...

概要編から参照されるための詳細編１。 local-linuxでmariadb10.11のコンテナを作る docker-composeからビルドと起動できるようにする。 設定ファイルの準備とdocker-compose.ymlの追記 設定ファイルや置き場を用意しながら、mariadb10と11を共存させる。 最近知ったけど、redhat8のアプリケーション管理にはストリームってのがあって、同じアプリでも違うバージョンを共存させられない。 昔はポート番号変えて新旧データベースを共存させられたような気がする。 dockerありがたや。 mariadb本体の設定ファイルの用意 docker単体なら一発起動でええけど、docker-composeでオーケストレーションしてるから、永続化領域にmariadbの設定ファイルとか置いて準備してく。 まずは永続化領域に設定ファイル置き場の作成。 sv_mariadbconfには設定ファイル以外にも、コンテナ内でバックアップとリストアを動かすためのスクリプトが入ってる秘伝のタレみたいなもん。 1 2 cd nariDockerDat cp -pR sv_mariadbconf sv_mariadb11conf djangoからモデル経由でテーブルを扱うとき、pdfとjpegをblob列に保管してる。 設定で必要なのは、この保管ができるようにmax_allowed_packetを書いとく必要がある。 phpで使ってた頃からほぼ内容そのまま。 さっきコピーした内容でそのまま使えるはず。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [mysqld] max_allowed_packet=1024M log_warnings=1 query_cache_size=640M query_cache_type=1 query_cache_limit=1280M innodb_buffer_pool_size=5120M innodb_log_file_size=128M read_buffer_size=320M log-error=/var/log/mariadb.log slow_query_log slow_query_log_file=/var/log/mariadb_slow.log long_query_time=30 innodb_data_file_path=ibdata1:1G innodb_file_per_table=ON [mysqldump] max_allowed_packet=1024M データ置き場と環境変数の用意 dockerで動かすときにはdocker-entrypoint.shとかhealthcheck.shが必要。 ...

概要編から参照されるための詳細編２。 maridb10.11にデータベースコピーする データベースとテーブルを作ってデータを流し込み、django4からの向き先を10.11へ変更する。 django4では集計やグラフ作成させてるから１円単位、１時間単位で数字があってるかを確認してく。 テーブルの作成 空のテーブルを作る。 djangoが管理するテーブルが１０個ある。 前にテーブルの関連性調べた。 管理テーブルにはdjangoアプリケーションへのログイン管理とかが入ってる。 djangoが提供するログインの仕組みを使ってるので自分には必須。 管理テーブルは外部キーを使ってるから、作成順序とデータ投入順位に気を付ける。 その後で自分が設計して利用してる業務テーブル１３個を一括で流す。 10.5で定義を定期的に取ってるので、そのまま流用してcreate tableしてく。 a5sqlで接続してテーブル作成一発OK。 10.5からのコピー djangoが管理するテーブルが１０個あって、さっきcreate tableした順序で１つずつテーブルへデータを流し込む。 a5sqlで最初は全部選択された状態になるけど、いったん「全解除」してから１つずつ管理テーブル選んでコピーする。１つ１分もかからない。 管理テーブルのコピーが終わったら、業務テーブル１３個を一括でコピー。 blob列あるから、複数行インサートは１００行ぐらいを設定しとく。 業務テーブルは5分以内でコピー終わった。 コピーしてるときのdocker statsはこんな感じ。 一番上と一番下が新旧mariadb。 メモリけっこう食う。 1 2 3 4 5 6 7 8 9 10 11 CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS f2e33178380c docker-sv_mariadb1011-1 0.02% 1.67GiB / 19.51GiB 8.56% 1.33GB / 1.13MB 49MB / 2.63GB 11 273c6892b62e docker-cl_red9-1 0.00% 81.16MiB / 19.51GiB 0.41% 31.4kB / 4.98kB 53MB / 34.9MB 15 3c6bdd6634f6 docker-cl_ubu22-1 0.00% 10.43MiB / 19.51GiB 0.05% 23.5kB / 0B 20.8MB / 28.7kB 2 d31718d81aa9 docker-cl_red8-1 0.00% 91.45MiB / 19.51GiB 0.46% 30.4kB / 4.92kB 51.7MB / 35.4MB 12 4fb021b38fcf svldap-admin 0.00% 63.84MiB / 19.51GiB 0.32% 25.9kB / 0B 57MB / 279kB 139 85eb8c870d18 docker-sv_https-portal-1 0.00% 17.96MiB / 19.51GiB 0.09% 27.5kB / 0B 20.6MB / 180kB 14 216fb2fa939a svldap-server 0.00% 20.93MiB / 19.51GiB 0.10% 36.4kB / 14.7kB 26.7MB / 119kB 5 f1ab77ea1fcd docker-sv_jupyter-1 0.22% 98.49MiB / 19.51GiB 0.49% 154kB / 73.2kB 60.9MB / 135kB 1 a1207001c3c1 docker-sv_django-1 0.02% 71.59MiB / 19.51GiB 0.36% 17.5MB / 15.6kB 45.1MB / 16.4kB 11 4a104c3c6ece docker-sv_mariadb-1 0.03% 3.474GiB / 19.51GiB 17.81% 2.64MB / 1.33GB 2.73GB / 2.16MB 12 コピー終わった後の永続化領域の利用サイズ。 sv_mariadbとsv_mariadb11のサイズが倍ぐらい違うのは、アプリケーションテスト用のスキーマをsv_mariadb11に作ってないから。 あとで作らなあかんなぁ。 ...