【ITニュース解説】The OCI Developer's Workflow: Bridging Your Mac and Local VM with a Shared Folder

システムエンジニアを目指す上では、効率的な開発環境を整えることが非常に重要である。特に、クラウドサービスであるOCI（Oracle Cloud Infrastructure）のような環境で作業を進める際、自分のパソコン（Mac）で開発したコードを、本番に近い環境で即座にテストできる仕組みは必須となる。この記事では、Macとローカルの仮想マシン（VM）であるUbuntuとの間で共有フォルダを設定し、Macでコードを編集し、VMで実行・テストするという、プロフェッショナルなワークフローを構築する方法について解説する。

なぜこのような仕組みが必要なのだろうか。前回の記事で述べられたように、ローカルにUbuntuのVMを準備することは、OCIのプロフェッショナルにとって非常に有効な手段である。VMは、実際にサービスが稼働する本番環境に近い、隔離されたテスト環境を提供してくれる。しかし、この隔離性が問題となることもある。例えば、Mac上で作成したTerraformスクリプトやアプリケーションコード、Ansibleプレイブックといったファイルを、VMへと手動でコピーする作業は、非常に手間がかかり、非効率的である。このような手作業は、開発のスピードを著しく低下させ、誤操作の原因にもなりかねない。

そこで登場するのが「共有フォルダ」である。共有フォルダは、Mac上の特定のディレクトリを、VM内のディレクトリとして認識させ、両者間でファイルをリアルタイムで同期させる仕組みである。これにより、Macで普段使い慣れているエディタ（例えばVS Codeなど）を使ってコードを書き、その変更が即座にVMに反映され、VM内でコンパイルやテストを行うことが可能になる。これは、本番のクラウド環境へのデプロイやテストのワークフローを、ローカル環境で高い精度でシミュレートするための重要な架け橋となる。

具体的な設定は、macOS上で動作する仮想化ソフトウェアであるUTMと、UbuntuのゲストVMを使って進める。まずはMac側に共有したいフォルダを作成する。例えばデスクトップに「UTM_Share」という名前のフォルダを作り、その中にテスト用のファイルを置いておくと、後で共有が成功したかを確認しやすくなる。このフォルダは、VMのファイルを保存する場所として機能する。

次に、UTMの仮想マシンの設定を変更する。重要なのは、この作業を行う前にUbuntu VMを必ずシャットダウンしておくことである。UTMの設定画面から、共有フォルダとして先ほど作成した「UTM_Share」を指定する。この際、「Read Only」（読み取り専用）のチェックボックスが外れていることを確認する。これによって、VM側からもファイルに書き込みができるようになる。UTMの設定で指定されたフォルダは、「マウントタグ」としてVM内で認識される。

UTMの設定が終わったら、Ubuntu VMを起動する。VM内でターミナルを開き、共有フォルダをマウントするための受け皿となるディレクトリ（マウントポイント）を作成する。例えば、「/mnt/utm」というディレクトリを作成するのが一般的である。次に、Linuxのシステム設定ファイルである「/etc/fstab」を編集する。このファイルに、UTMで設定した共有フォルダを、先ほど作成した「/mnt/utm」に自動的にマウントするための情報を追加する。具体的には、仮想環境でよく使われる「9p」というファイルシステムと、「virtio」という高速なデータ転送方式、そして自動マウントやエラー時の動作に関するオプションを設定する。設定ファイルを保存した後、システムに新しい設定を読み込ませ、手動でマウントを試みることで、共有フォルダが正しく見えるかを確認する。ここで、Mac側に置いたテストファイルがVM側から確認できれば、基本的な共有は成功している。

しかし、多くの場合、この段階で一つの課題に直面する。それは「権限の問題」である。Mac上で作成されたファイルの所有者情報（ユーザーID: UID、グループID: GID）は、VM内のUbuntuユーザーのそれとは異なることが多い。例えば、Mac側のUIDが501、GIDが20であるのに対し、Ubuntu側のユーザーは通常UID 1000、GID 1000を持つ。この違いにより、VM内で共有フォルダ内のファイルに書き込みをしようとすると、「Permission denied」（権限がありません）というエラーが発生してしまう。

この権限問題を解決するために、「bindfs」というツールを使用する。bindfsは、ファイルシステムを再マウントする際に、ファイルの所有者情報（UID/GID）を別の値にマッピングし直すことができる便利なツールである。まず、Ubuntu VM内でbindfsをインストールする。次に、現在のUbuntuユーザーのUIDとGID（通常は1000である）を確認する。そして、共有フォルダ「/mnt/utm」の現在のファイルのUID/GIDを確認する。例えば、Mac側の501と20という値が見つかるはずである。

解決策として、Ubuntuのホームディレクトリ内（例: 「/utm」）に新しいマウントポイントを作成する。そして、再度「/etc/fstab」を編集し、今度は「/mnt/utm」を「/utm」にbindfsを使ってマウントする設定を追加する。この際、「map=501/1000:@20/@1000」のようなオプションを指定することで、Mac側のUID 501をUbuntu側のUID 1000に、GID 20をGID 1000にそれぞれマッピングし直す指示を与えるのである。この設定には、先に「/mnt/utm」がマウントされていることを保証するためのオプションや、ネットワーク経由のマウントであることを示すオプションも含まれる。設定を保存し、システムをリロードして、新しいbindfsによるマウントを適用する。

この最終的な設定が完了すれば、Macの「UTM_Share」フォルダにファイルを置くと、それがUbuntu VMの「~/utm」ディレクトリに表示され、かつVM側から自由に読み書きできるようになる。VM内で「echo "Synced via bindfs!" > ~/utm/test_from_linux.txt」のようなコマンドでファイルを作成すれば、それが即座にMac側の「UTM_Share」フォルダに現れることを確認できるだろう。

このMacとLinux VM間のシームレスな共有フォルダワークフローは、OCI開発において多大なメリットをもたらす。まず、クラウドでのコードデプロイメントを効果的にシミュレートできる。Macは開発者のワークステーションであり、VM内の「~/utm」ディレクトリは、まるでOCIインスタンスにデプロイされたかのように扱えるため、実際のデプロイ前に動作確認が行える。

また、「Infrastructure as Code (IaC)」のテストにおいて非常に強力なツールとなる。例えば、OCIのネットワーク設定をTerraformスクリプトで記述する場合、MacのVS Codeで.tfファイルを編集し、保存すればすぐにVM内のファイルに反映される。VMはOCI CLIやLinux環境を備えているため、VM内で「terraform plan」などのコマンドを即座に実行し、スクリプトが意図通りに動作するかを確認できる。これは、CI/CDパイプラインや本番の踏み台サーバーで行われるテストと全く同じ感覚で実施可能である。

さらに、Python、Go、Node.jsなどのアプリケーション開発とテストにも役立つ。Mac上でアプリケーションのコードを書き、そのコードがVMに同期されることで、VM内でLinux固有の依存関係を解決しながら、アプリケーションのコンパイル、実行、テストをスムーズに行うことができる。

まとめると、この共有フォルダ設定は、macOSの洗練されたユーザーインターフェースと、本番環境に限りなく近いLinux VMの環境という、両者の利点を組み合わせた効率的な開発ワークフローを構築するものである。単なる共有フォルダではなく、プロフェッショナルな開発のための強力なツールを手に入れたことになる。この設定によって、コードの編集からテストまでのフィードバックループが劇的に短縮され、OCIソリューションの開発とテストがより迅速かつ確実に行えるようになるだろう。また、このシリーズの次のステップでは、VM内で動くウェブサーバーなどのサービスにMacから直接アクセスするための「ポートフォワーディング」について解説される予定であり、それによってローカルのOCIラボ環境はさらに完成度を高めることになる。