アメリカのカンザス州立大学（KSU）で行われた研究によって、NASAが誇るジェイムズ・ウェッブ宇宙望遠鏡（JWST）の最新観測データから、にわかには信じがたい――しかし非常に魅力的な仮説が再び浮上しています。
それは「私たち自身の宇宙が、実はブラックホールの内部にあるのではないか」というものです。
まぁ、現状の人類の科学力では証明できそうにない仮説だから、何とでも言えそうな感はありますな...
Vagrantfileから他のVagrantfileを読み込む形にしたいが...
「Vagrant」のプロバイダーとして「VirtualBox」を指定して利用していて、「仮想ディスク（VMDK形式）」のサイズの肥大化が止まることを知らない状態になることあるあるだと思います。
そもそも、
『何故、青天井で「仮想ディスク（VMDK形式）」のサイズが肥大し続けていくのか？』
という部分についての仕組みが完全に「ブラックボックス」であると...
同じような疑問を抱えていらっしゃる方がおられたのですが、
⇧ 結局のところ、「仮想ディスク（VMDK形式）」のサイズが膨れ上がっていくことについては原因が分からないということで、「ブラックボックス」は解明されていないとなっている...
そもそも、回答が「空き容量を確保する方法についての紹介」になっていて、「サイズが増大していく理由は何ですか？」という質問に対する回答になっていないのよね...
つまり、
- 事前対応
- 事後対応
の内、「1. 事前対応」のアプローチが取れない...
何故なら、『「仮想ディスク（VMDK形式）」のサイズが肥大し続けていく』事象については発生する原因が分からないことから、事象自体を抑制する対応が取れないので...
故に、不本意であろうと、『「仮想ディスク（VMDK形式）」のサイズが肥大し続けていく』が起きることが必然であると考えて、「2. 事後対応」のアプローチで検討するしかない...
ちなみに、
■Vagrantで仮想マシンを生成した場合の仮想ディスク（VMDK形式）
■VirtualBoxで仮想マシンを生成した場合の仮想ディスク（VDI形式）
⇧ 仮想ディスクのフォーマットが異なるので、結構な頻度で「空き容量の確保」の作業を行うとなると面倒ではある...
「仮想ディスク（VMDK形式）」のサイズの肥大化は避けられないものと考えて、
のどちらかの対応になってくる気はする。
毎回、リセットする形になる「2. 都度、vagrant destoryして真っ新な状態にしてvagrant upする」の方式は、「データベース」などを「仮想マシン」上に構築している場合は、データが引き継がれないという難はあるのだが、「データベース」などを利用しておらずデータが処理に影響を与えないのであれば、アプローチとして選択しても良いとは思われる。
「1. 定期的に「空き容量」を確保する対応をする」もスクリプト化しておけば良いのだが、
- 余分なファイルを削除する
- ディスクのサイズを拡張する
のいずれの方式にしても、リソースは有限なので、いつか限界を迎えることになる気はする。
今回は、「2. 都度、vagrant destoryして真っ新な状態にしてvagrant upする」の方式を採用する方向で考えてみる。
そうなってくると、まずは、ザックリ
- 1つのVagrantfileに全て記載する
- 複数のVagrantfileに分割する
の2パターンの方式に分かれる気がしている。
可能であれば、「2. 複数のVagrantfileに分割する」方式を採用したいので、実現できるのか調べてみる。
公式のドキュメントを見た感じでは、
⇧ 複数のファイルあった場合に、マージされるとはある。
ちなみに、
⇧ 設定を別ファイルに定義しておいて、読み込ませるというようなこともできるらしい。
となってくると、
■複数のVagrantfileに分割するパターン
.
└─ansible
│ Vagrantfile
│
└─vms
├─app_server
│ │ config.yml
│ │ Vagrantfile
│ │
│ └─scripts
│ setup.sh
│
├─jump_server
│ │ config.yml
│ │ Vagrantfile
│ │
│ └─scripts
│ setup.sh
│
└─proxy_server
│ config.yml
│ Vagrantfile
│
└─scripts
setup.sh
■~/ansible/Vagranfile
# 共通の設定
Vagrant.configure("2") do |config|
# 仮想マシンのIOSイメージ
config.vm.box = 'your_box_name'
end
# サーバー名のリスト
vm_names = ['app_server', 'jump_server', 'proxy_server']
# 各VMのVagrantfileをロード
vm_names.each do |vm_name|
vm_vagrantfile = "vms/#{vm_name}/Vagrantfile"
load vm_vagrantfile if File.exists?(vm_vagrantfile)
end
⇧ というような構成になるんかな？
各々のスクリプト（setup.sh）で、
- ライブラリのインストール
- ライブラリの設定
など、各々の「仮想マシン」のに必要な諸々の情報を全て準備するようにしておけば、「冪等性」も担保されるであろうと。
ただ、「Vagrant」の公式のドキュメントでは、「Vagrantfile」の分割については、言及されていない感じなのよね...
とは言え、開発環境に限らず「環境構築」系は、「AI」に良しなにお任せしたいところですな...
ザックリと作業を洗い出してみると、
- 環境構築
- 実現方法調査・検討
- 方針決定・レビュー
- 外部設計書作成・レビュー
- 概念実証（PoC：Proof of Concept）
- 詳細設計書（構築手順）作成
- コマンド定義
- 検証
- フィードバック（コマンド定義、設計書への反映など）
- 構築作業
- 開発
- 実現方法調査・検討
- 方針決定・レビュー
- 外部設計書作成・レビュー
- 概念実証（PoC：Proof of Concept）
- 詳細設計書作成
- 実装（ソースコード）
- 検証
- フィードバック（実装、設計書への反映など）
- 開発作業
といった感じで、何だかだんだで、やること多いので、即時に開発に着手できるように「環境構築」系が済んでいると嬉しいんですけどね...
「オレオレ環境」の乱立も防止できて、問題が起きた時の切り分けも楽になりますし...
で、
⇧ 上記サイト様にありますように、「Vagrant」が有力な候補になって気そうなのだが、PCのスペックがある程度は必要にはなってきますと。
まぁ、「Dockerコンテナ」で完結している環境で、且つ、コストかかっても良いのであれば、「Docker Desktop」を利用するという手もあるとは思いますが...
とりあえず、自分は「開発環境」は統一したい派なのだが、「社会的少数者（マイノリティ：minority）」なんかな？
「環境構築」系こそ「誰が行っても同じ結果になる」という仕組みを構築しておいて、「冪等性」を重視しておくのが合理的な気がするのだが...
せめて、手順を用意しておいて「開発環境」が統一されるような仕組みにしておくぐらいはMUSTにしておいて欲しい気はする...
プロジェクト特有のアプリケーションが動作する「環境構築」に必要な情報の調査からしないといけないのは辛過ぎるので...
欲を言えば、
- DEV環境（DEVELOPMENT、開発環境）
- STG環境（STAGING、ステージング環境）
- PRD環境（PRODUCTION、商用環境、本番環境）
で環境差分が限りなく0になるのが良い気はしますが...
ただ、
のどちらの問題なのかが分からないのですが、「Vagrant」の「box」での不具合が多過ぎて、安定しないのよね...
Boxes are the package format for Vagrant environments. You specify a box environment and operating configurations in your Vagrantfile. You can use a box on any supported platform to bring up identical working environments. To enable teams to use and manage the same boxes, versions are supported.
⇧ とあって、仮に、
- Vagrant
- Provider（Vagrantで使用する仮想化ソフトウェア）
- VirtualBox
- Hyper-V
- Docker
- VMware
- ...etc
の組み合わせや相互のバージョンなどに依存してしまっているのでれば、それって、『俺の環境だと動くけど？』の問題が解決できないってことになってしまう...
と言うか、現状、そうなってしまっている...
一応、
⇧『Rocky Linux is a community enterprise operating system designed to be 100% bug-for-bug compatible with America's top enterprise Linux distribution.』とあるので、バグまで100%完全互換と言っているのだが、動かないことが多過ぎるのよ...
何やら、issueとか見てると、
⇧「Vagrant」の中の人なのか分からないのですが「box」のメンテナンス諦めてるっぽいのよね...
2025年3月23日（日）追記：↓ ここから
何やら、
⇧ Windows以外でもバグってるところを見るに、「Vagrant」側の「box」のバグというような気がするが...
「Windows 10 Home」でも同様の事象が起こるので...
う～む、「Vagrant」はバグのある「box」を公開しないで欲しいのよね...
2025年3月23日（日）追記：↑ ここまで
コマンド一発で「環境構築」が完了する世界線が理想なのだが、残念ながら、現実的には実現不可能といった趣なのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
