「Windows11 24H2」へのアップデートを避けていたユーザーも、ついに受け入れざるを得ない状況となっている。Microsoftは米国時間5月2日、Windows11 24H2が段階的ロールアウトの最後のフェーズに入ったことを明らかにした。これは、同バージョンが全てのユーザーに広く提供される段階になったことを意味する。
「Windows 11 24H2」を全ての個人ユーザーに自動配信--段階的ロールアウトが最終段階に - ZDNET Japan
問題の修正が進むまでバージョン24H2へのアップデートを保留するよう助言する声も一部にあった。しかし、自動インストールが本格化する今、その選択肢は難しくなった。確かに継続的な問題は残るが、PC構成や利用環境はユーザーごとに大きく異なるため、実際に問題に遭遇するかどうかはユーザー次第であり、運に左右される側面がある。
「Windows 11 24H2」を全ての個人ユーザーに自動配信--段階的ロールアウトが最終段階に - ZDNET Japan
⇧ もう滅茶苦茶ですな...
大企業の横暴もここまで来ると、犯罪と言っても過言ではない気がして来ますな...
そもそも、
Microsoftが開発するOS「Windows」は、1985年に誕生したWindows 1.0からスタートして2012年にWindows 8が登場するまでたくさんのバージョン改訂を行い、それに伴ってOSとしての機能も大きく変化させてきました。
そんなWindowsシリーズの最新バージョンとなるのが「Windows 10」ですが、Microsoftのジェリー・ニクソン氏が「Windows 10はWindowsの最後のバージョンとなる」と発言して話題になっています。
⇧ と言っていたのに、平気で反故にするのは、組織的な偽証罪に該当する気がするんだが...
ハードウェアの要件が、「Windows 11」にアップデートを満たせないPCを使っている私のような人間は、裏切られた気持ちでいっぱいなわけだが...
そんな人間から見ると、「Microsoft」への信用は地に落ちているのよね...
Azure Data Lake Storageがサポートしているのは、NFS 3.0
前に、
⇧ 上記の記事の時に触れたのだが、相も変わらず、「Microsoft」のドキュメントが整備されておらず、「ファインダビリティ（Findability）」が皆無なのだが、
NFS 3.0 プロトコルのサポートでは、BLOB を階層型名前空間に編成する必要があります。 ストレージ アカウントを作成するときに、階層型名前空間を有効にできます。 階層型名前空間を使用する機能は、Azure Data Lake Storage によって導入されました。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support
この表の使用方法
機能に悪影響はありませんが、特定の機能と使用する場合に互換性がない可能性があります。 たとえば、NFS 3.0 を有効にしても、Microsoft Entra 認可には影響ありません。 ただし、Microsoft Entra ID を使用して NFS 3.0 要求を承認することはできません。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-feature-support-in-storage-accounts
⇧ とあることから、「Azure Data Lake Storage」がサポートしているのは、「NFS 3.0」となりますと。
で、ややこしいのが、
Azure Storage 機能のサポート
次の表は、NFS 4.1 機能が有効になっているアカウントにおける Azure Storage 機能の現在のサポート レベルを示しています。
https://learn.microsoft.com/ja-jp/azure/storage/files/files-nfs-protocol
⇧「Azure Storage サービス」の1つである「Azure Files」がサポートしているのは、「NFS 4.1」というね...
兎にも角にも、「Microsoft Azure」の「サービス」の分類と「プロトコル」の分類をドキュメントに集約して記載して欲しいのだが...
散逸した情報を探すために、手あたり次第にドキュメントを確認して回らなければならないのは、本当に苦行なんよね...
Docker ComposeでAzure Data Lake StorageとNFSを実現する設定が分かり辛い...
で、「Docker」の公式のドキュメントもイケてないのですが、ドキュメントによると「NFS（Network File System）」が実現できるらしいのだが、
⇧ この説明の杜撰さは酷い...
『オプションの詳細については、各ドライバのドキュメントをご確認ください。』とあるのだが、どこで「各ドライバ」のドキュメントが確認できるのかの説明が無いのが腹立たしいのだが...
ちなみに、
⇧ 英語版のドキュメントも酷さは変わらない感じですかね...
で、
The Docker Engine provides the following storage drivers on Linux:
https://docs.docker.com/engine/storage/drivers/select-storage-driver/
⇧ 上記の「Select a storage driver」というページに掲載の「driver」のことだと思われるのだが、「Linux」環境においては、
の5つの「driver」が「volume driver」の全量ってことになるらしい。
と思ったら、
- volume driver
- storage driver
は別物らしい（後述）...
「logging driver」とかもあるから、単に「driver」と言われても訳が分からなくなるのよね...
そもそも、「storage driver」と「volume driver」って別物なのかが分からないんだが...
⇧ stackoverflowが正しいとすると、以下の「Use Docker Engine plugins」のドキュメントに記載の「Volume plugins」が「volume driver」ということらしいのだが...
いや、本当に公式のドキュメントが酷過ぎるのだが...
で、ネットの情報を漁っていたところ、
■Docker Swarm
■Docker Compose
The
devicefield is the path on the remote NFS server. The leading colon is required. This is an artifact of how the mount command moves the IP address to theaddrfield for the syscall. This directory must exist on the remote host prior to the volume being mounted into a container.
⇧ 上記のstackoverflowによると、「volume driver」の指定は、「Docker Compose」を利用する時だけ必要っぽいのだが、
# inside a docker-compose file
...
services:
example-app:
volumes:
- "nfs-data:/data"
...
volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: nfsvers=4,addr=nfs.example.com,rw
device: ":/path/to/dir"
⇧「リモート」の「ストレージ」をマウントする際も、「volume driver」は「local」を指定するらしい...
分かり辛いことこの上ないのだが...
「Azure Data Lake Storage」の場合は、サポートしているのが「NFS 3.0」になるので、
a. 次の行を追加して、/etc/fstab ファイルにエントリを作成します。
<storage-account-name>.blob.core.windows.net:/<storage-account-name>/<container-name> /nfsdata aznfs defaults,sec=sys,vers=3,nolock,proto=tcp,nofail,_netdev 0 0
⇧ を参考に、「docker-compose.yaml」の「volumes:」の「o:」の部分を変更する必要がありますと。
勿論、「Azure Portal」側で、「Azure Storage アカウント」作ったり、作成した「Azure Storage アカウント」に対して「NFS 3.0」を有効にしたり（一度「NFS 3.0」を有効にすると「NFS 3.0」は無効にできないという鬼畜仕様だが...）を事前にしてく必要があるのだが...
「Azure Data Lake Storage」と「NFS（Network File System）」でマウントできると、マウントされている「Dockerコンテナ」のディレクトリに追加されたファイルは、「Azure Data Lake Storage」のディレクトリに保存されることになりますと。
つまり、「Dockerコンテナ」が稼働しているホストが障害でダウンしたとて、「Azure Data Lake Storage」がダウンしない限り、データが失われることは無いと。
外部でデータを永続化できることになると。
とりあえず、一次情報たる公式のドキュメントが役に立たな過ぎる...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
