インフラ作業してSSL接続によるロケット画面が表示できるようになったので続きを勉強して試しながら実施。 dockerコンテナ内のコマンドライン python3とpip3を使っていく。 コンテナのbashに入る。 1 2 3 4 5 $ docker ps | grep django 8b95c47cd3b0 sv_django:3.1.5 "supervisord -n" 12 days ago Up 40 minutes 0.0.0.0:38080->8080/tcp, :::38080->8080/tcp docker_sv_django_1 f7530c88c5ab mysql:5.7 "docker-entrypoint.s…" 2 weeks ago Up 39 minutes 33060/tcp, 0.0.0.0:23306->3306/tcp, :::23306->3306/tcp docker_sv_django-DBServer_1 $ docker exec -it docker_sv_django_1 bash root@svdjango:/# コンテナの中ではviすら使えないこともあるので、必要ならaptとかyumとかでインストールしておく。 requirement.txtに書いて管理 パッケージを一括で管理する。 他に依存するものは勝手に取ってきてくれるらしい。 upgradeした後で、バージョンNo書き換えれば最新を維持できる。 phpは5から7に上げるとき苦しんがけど、djangoは楽にバージョン上げていける運用になったらいいなぁ。 ...

きっかけ そもそも、phpで自前のwebアプリを作って帳簿を管理している。 後学のためでもあるし、確定申告のためでもある。 webアプリはlarabelとかじゃなくて、ベタのphp。 動かし始めて７年、毎月帳簿をつけ年末になるとせっせと申告準備してる。 phpは賞味期限が長くないので、バージョンを上げていく頻度はけっこう短い。 jpeg/pdf保管にimagickを使っているので、この扱いがけっこう面倒。 グラフ表示もやってるし。 そこで、機能移行が全部できるか調べながらだけど、phpからdjangoに引っ越すことに。 既存DBの帳簿データや、グラフ表示を１円も誤差なく表示させられるのか？ イントラでssl接続も実現させた。 そこでやってみた。 https化したdjango環境を作る あっちこっちで書かれているdjangoのロケット表示画面とadmin画面を自分でもdockerコンテナ使って作成してみた。 ロケット表示画面はSSLで提供できないかって考えてたら、やっておられる方がおられたので参考にさせてもらった。 （自分にとってはとてもいいヒントと問題提起になった） ただし、admin画面はcsrf検証エラーになってしまうので、そこだけはdjangoのコンテナ直つなぎ。 もう少し勉強して解決できたらいいな。 ※別の日にこの文章作るためにコンテナ作り直したら、admin画面のcsrf検証エラーがなくなった。その代わりdjangoコンテナに直接つなぐとcsrf検証エラーが発生するようになった。目的は達成できたけど、エラーになる原因は？？？　まだわからん。 【参考URL】 [Docker]Djangoを無料でHTTPS化して簡単にデプロイする方法 | エンジニアの眠れない夜 sleepless-se.net GitHub - SteveLTN/https-portal: A fully automated HTTPS server powered by Nginx, Let's Encrypt and … github.com uWSGI入門 | Python学習講座 www.python.ambitious-engineer.com Django + uWSGI + nginx (uWSGIチュートリアルの和訳) #Python3 - Qiita qiita.com Djangoサイトのセキュリティ見直しメモ - ikura1's log ikura-lab.hatenablog.com dockerでビルドしてコンテナ動かすときは、自分の環境にフィットさせるために考えてdocker-compose.ymlとDockerfileを書き換える必要がある。 これがけっこう考えさせられるし、いい勉強になる。 あれこれ試しているときに、記事の内容で「docker-compose down」なんてそのまま動かすと、 自分の消したくないコンテナまで消えて「あー、手がスベった」ってなることもあった。 たまたまoracleのコンテナ動かしてたときは、docker-composeでdownを指定しちゃうと「あーsql動かしなおしかー」みたいなことになって時間がないときツラい。 以下、自分のdocker-compose.ymlの記述の一部。 djangoはデータベース利用に制限があるらしく、単一カラムに主キーがついたテーブルでないと扱えないらしい。 既存mariadbが自分のデータベースとして別で存在するけど、ちゃんと扱えるようになるまで別コンテナのmysqlを１つ用意しておく。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 sv_https-portal: image: steveltn/https-portal:1 ports: - '30080:80' - '30443:443' environment: DOMAINS: 'nafslinux.intra.gavann-it.com -> http://svdjango:8080' STAGE: 'local' # or 'production' volumes: - ./nariDockerDat/sv_django-ssl_certs:/var/lib/https-portal sv_django: image: sv_django:3.1.5 build: ./nariDockerDat/sv_django-uwsgi-nginx hostname: svdjango volumes: - ./nariDockerDat/sv_django-uwsgi-nginx/app:/code/app ports: - '38080:8080' sv_django-DBServer: image: mysql:5.7 hostname: 'svdjangoDBServer' command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci ports: - "23306:3306" environment: MYSQL_ROOT_PASSWORD: hogehoge MYSQL_DATABASE: djangodb MYSQL_USER: gvis MYSQL_PASSWORD: mogemoge TZ: 'Asia/Tokyo' volumes: - ./nariDockerDat/sv_django-db/lib:/var/lib/mysql - ./nariDockerDat/sv_django-db/etc:/etc/mysql - ./nariDockerDat/sv_django-dbconf:/docker-entrypoint-initdb.d ：(中略) フォルダの準備 /dockerをベースディレクトリにしている。 sambaで丸ごと共有し、windows/mac/linuxのvscodeから編集できるようにしてある。 ...

PCサーバを作るとき、CPU/メモリ/ディスクのサイズや規模を決めて購入したり、仮想マシンとして作成する。 CPUとメモリは扱いたいソフトウェアの規模によって決める。 excelやwordだけなら４コア程度、DBサーバなら16GBぐらいを目安に設定。 ディスク作成するとき、バックアップの取り方やリカバリポイントも考慮に入れる。 今はほとんどssdで動かすから、バックアップ先はhddにしてる。 自分はhddにもいったん入れるけど、クラウドのディスクに入れるから暗号化zipして１つのファイルにして月に1回保管してる。 パーティション操作が発生するのは、当初の予定と違うソフトウェアを入れることになったとか、保管データの容量が大きくなりすぎたとか。 そもそもフラグメント発生するwindowsのntfsを使うことも減ったし、ext4/xfsでlinuxのsamba動かしてたらほとんどデータをntfsに置くことがなくなったからパーティション操作することがほとんどなくなった。 ただ、昔やってたPC管理の考え方は以下のとおり。 パーティションを変更するのは何のため サーバを選んだり、ＰＣを用意するとき、用途に応じてディスクのサイズを考える。 スタンドアロンで持ち運び重視のノートＰＣだったらこんな感じでシステムドライブのこと考えてた。 用途 windows linux solaris(unix) システムパーティション Cドライブ:140GB ルート(/):30GB ルート(/):100GB 長期間使ってwindows updateするとだんだんディスク利用率が上がっていくし、レジストリも汚れていく。 linuxとsolarisは今は置いといて、windows10だけで考えると、OS以外に業務利用のソフトウェア(office365とか)入れて、40GB程度は必要。 windows updateすると、半期に１回のOS更新で5GBぐらいは増えてた。 ５年使うとして、システムパーティションに必要な量の予測は、 初期容量40GB + ((半期windows update 5GB x 2) x ５年) ≒　90GB 途中でアプリ増やしたくなることもあるので、１．５倍で考えると135GBぐらいあればいいことになる。 ５年経過しても利用率70%程度におさえることを目指すと、 135GB / 0.7 ≒ 192GB そういうわけで、windowsでは200GBあればシステムパーティションは足りるはず。 予測が不安な時は１．５倍じゃなく２倍とかそれ以上で掛け算しておけばいい。 さらにMyDocumentにデータを保存する癖があるなら、その保管量を上乗せすればいい。 この予測が外れたり、利用用途変更があったときにパーティションを変更したくなる。 windowsでパーティションを変更しなくてすむ方法 たとえばexcelやpower pointで資料作るために使ってたPCを、画像処理やsteamみたいなゲーム利用に用途変更したら、ディスクの使われ方が変わってくる。 画像処理はテンポラリファイルも書き出しがあるし、ゲームは数十GB単位で本体の容量を食う。 音楽や動画、画像なんかはすぐにMyDocumentのフォルダあたりがパンパンになるから、ドライブ接続した場所に保管する癖をつければいい。 長期間使ってwindows updateしていったり、ソフトウェアをインストール・アンインストールするとレジストリは汚れていくし、不要なフォルダがたくさんできる。 やっかいなのはAppdataあたりに残る残骸。 いつ何のために作られたフォルダなのかすごくわかりにくいから、手動削除やりにくいフォルダやデータがけっこう入ってる。 windows updateでソフトウェアが動くなるのが怖い場合は仕方ないけど、windows updateをアンインストールしないでおくとディスク消費が大きい。インストールのときのログも含めて、以前のwindows状態に戻す必要が少ないなら、バックワードするためのデータは削除したほうがいい。 これでも対処できないときのために、自分の仮想マシンは２世代のバックアップを取ってる。１つはメジャーアップデートの直後のバックアップ。もう１つは毎月のバックアップ。ほぼこれで問題は出ない。 Cドライブを右クリックしてプロパティを開き、全般タブからディスクのクリーンアップを選んで、システムファイルのクリーンアップをやると、削除の目安が出てくる。 システムファイルのクリーンアップに加えて、月に１回ぐらいはglary utilitiesみたいなクリーナーを使うと肥大したドライブをある程度はダイエットしてくれるしレジストリもきれいにしてくれる。 ディスク操作の今まで hdd使い始めの頃でフロッピーディスクがまだ現役のとき、プログラムを書いてビルドするときにhdd使うとメチャ速くて感動した。 たしかscsiの外付けディスクのサイズは40MBぐらいだったと思う。 今手元で使うファイルサーバは6TB。 容量は格段に大きくなった。 ディスクの管理領域の取り扱いビット数の都合だったと思うけど、それから何年かおきに、 容量の壁 に出会う。 ...

ファイルシステム の違いはwikipediaに書いてある。 今のNTFS 3.0 (5.0) は２０００年頃から使ってるけど、もう２０年経ってるなぁ。 それでもアクセス権操作は慣れない。 使う側の選び方 ファイルサイズやディレクトリ数の上限 大きいに越したことない。 ファイルサーバの管理をしていて以下のようなときjavaで開発しているメンバがいると「限界までやるなよ」って悲しくなる。 ファイル名が長すぎ フォルダ階層が深すぎ フォルダの名前が長すぎて絶対階層名が処理できず削除すらできない そんなときは fastcopy に頼るぐらいしか手が浮かばない。 もしかするとフォルダ同期をする発送で、windows純正品ならrobocopy、unix/linuxならrsyncで何とかしてくれるかもしれないけど、それはまた今度。 タイムスタンプがいつまでのを保管できるか B.CとA.Dまでは要らないけど、せめて自分の生まれた頃ぐらいまでは表現できればいいんじゃないかと思う。unix時間は1970年１月１日00:00:00から計算してくれるから、linuxゆかりのファイルシステムでいいかなって。 いきなり停電したときデータが吹っ飛びやすいんじゃないか 線状降雨帯のおかげなのか、雷におびえることが増えた。 ジャーナルがファイルシステムにあると少しは安心できるかも。 windowsにはなさそうだけど、unix/linuxではsyncを打ってからコマンドを打つようにしてる。 gitを使ったときの.gitフォルダ内のような、数KBの小さなファイルがたくさんあっても保管効率が悪くならないか。 ブランチがやたら多いときには無視できないことがある。ちゃんとmasterへマージして、マージ後にブランチ消去するとかしてたら肥大化は防げる。 OSを複数扱うとき便利だったfat fat を思い出せなくなることもあるけど、wikipediaにも説明があった。 fat12とfat16とfat32ってのがある。 File Allocation Tableのことで、管理テーブルのビット数が12/16/32の違い。 あとはexFATっていうのもあるらしいけど、それぞれ扱えるファイルサイズやパーティションサイズの違いだったはず。 ms-dos/windows95/98あたりで使ってた。 8.3文字形式って制限が有名で、OSをまたいでデータをやりとりするには便利なこともあった。 古い方式で読み書きできるOSが多く、solaris8でも扱えた。 結論 ファイル名長はどれも255バイト。 ntfsは最大パス名長が32767文字って制限がある。 自分は１つのファイルで最も大きいものでも、10GB程度のisoイメージ。 身近に使えるファイルシステムで手軽そうなのはxfs/ext4かな。

久しぶりにwindows10でパーティションサイズ変更したくなった。 普段使いのPCとしては仮想マシンしか扱わないので、vmware上のwindowsで利用。 深く考えず、使えるものを探してみると、カナダの会社の製品を発見。 他にもドイツ製、中国製の製品あるけど、サーバ構築や運用変更のために使ったことが既にあったので、気軽にPCで使えそうな初見のソフトウェアを探してみた。 MiniTool Partition Wizard がそれ。 前提 実際にやるのはテスト用のVMを準備。OSだけインストールした状態のひな形になる仮想マシンを利用。 物理マシンのリソースにあわせてCPUとメモリとディスクを割り当てて作成する。 ひな形にしてるvmイメージをzipから解凍して展開 メモリ8GB、CPU4コア、Cドライブはもともとgptで100GBのを作ってるので、Dドライブはmbrで500GB追加作成しておく。 基本的なソフトウェアのインストール 普段使いに近づけるので、ブラウザ(firefox)とアンチウィルス(kaspersky)も入れておき、バージョンや定義も更新してたら、裏で勝手にwindows updateが動いて最新になってくれる。 OS再起動は４回ぐらい実施。windowsは最新になった。ここまで４０分ぐらい。 データドライブ作成 Dドライブを普通のNTFSドライブとして、500GBでパーティション作っておく。 ディスク性能 システムドライブ(cドライブ)とデータドライブ(dドライブ)のディスク性能は以下のとおり。 何回かやってみたけど、同じ物理ディスクにvmdk作ってるのに性能差が出るのが意味わからん。 Partition Wizardをインストール １分以内で終わる。軽い。 Partition Wizardを起動 ディスク操作は管理権限必要だから、アカウント制御の確認画面表示された後に起動できる。 ディスクサイズを変える（システムドライブ） 広げたり縮めたり Ｃドライブを広げたり縮めたり移動させたりが、矢印アイコンとドラッグでできる。めっちゃ軽快。 もちろん自分で数字を入力して細かく設定もできる。濃い青の箇所は使ってるディスク領域で、これより小さく縮めることはできない。 反映 もちろんその場で即反映ではなく、画面左下の適用ボタンを押すと初めて構成変更される。取り消したら操作は無効になってくれる。 ＯＳ再起動 Ｃドライブはシステムドライブだから、サイズ変更を適用するにはＯＳ再起動が必要。 サイズ変更の適用処理 ＯＳ再起動すると、続きの処理が実行されて適用した内容を反映してくれる。 パーティション移動と縮小には終わるのに４分３５秒かかって、もう１回OS再起動があった。元のサイズと位置に戻すには２分５秒。 ssd使ってるのもあるけど、けっこう速いかも。 サイズ変更の適用完了 OS再起動終わると確かにパーティション移動とサイズ変更できてる。 あれ？　gpt扱えないってあった気がしたけど、2TBになってないgptだったら普通に操作できるみたい。 ディスクサイズを変える（データトライブ） データの入った状態を用意 大粒で数が少ないファイルと、小粒で数が多いファイルを用意してみる。 OSインストールで使うisoイメージと、gitに登録しているファイルをデータとして入れておき、そのあとでサイズ変更。 winフォルダにはisoイメージで4GB程度の大き目ファイルが何個か入ってる。 memosフォルダには、ローカルgitからクローンしたブランチが入っていて、数KB程度の小さめのファイルがたくさん入ってる。 500GBのうち、20GB程度のデータをコピーして設置するのに約１０分。 広げたり縮めたり 500GBのパーティションの中で移動してサイズ変更もしてみる。 反映 適用して反映してみるため「はい」を押す。必要時間はおよそ２分。 ...