Hyper-V 仮想マシン内で Git システム Forgejo を利用 – Intel N100 ミニ PC で構築する開発環境(10日目)

NiPoGi ミニPC (CPU: Intel n100) を購入しました。Windows でも Ubuntu でも使えるようにして、「Intel N100 ミニ PC で構築する開発環境(2日目) | hiro345」で紹介した環境を用意していくつもりです。

最初から読むこともできます。目次もあります。)

 今回は、Hyper-V 仮想マシン内で Git システム Forgejo を利用してみました。最初、Forgejo を単体で動作させることを考えていたのですが、なんと Forgejo の公式サイトでは Windows 用のバイナリーが提供されていないようでした。Gitea の方は、Windows 版があるので、Forgejo もてっきりあるものだと勘違いしていました。

 しかし、Docker Desktop があれば問題ありません。Hyper-V 仮想マシン内の Docker コンテナで Forgejo を動かしてみました。

Docker Desktop の自動起動

 今回の利用方法は、ローカルマシンで Git システムを手軽に使えるようにするということなので、ユーザーがサインインしているときに使えれば良いということになります。ということで、Hyper-V Windows 仮想マシンで Forgejo を使うにあたっては、ユーザがサインインしたら、Docker Desktop を自動で起動するように設定をするということで、これについては対応ができます。

 今回、想定している開発環境では基本的に Docker は使うので、サインインしたら、Docker Desktop が自動起動することについて問題はありません。Docker を使わないときは、停止しておいたほうがマシン負荷が減るので、この自動起動をさせたくない場合は、それでもかまいません。その場合は自分で手動で Docker Desktop を起動すれば良いだけです。ただし、当然のことながら、Docker Desktop が起動していないと、その間は Forgejo が使えないということになります。

 Docker Desktop を自動で起動するように設定をするのは、Docker Desktop の設定画面の General メニューで開く画面で、Start Docker Desktop when you sign in to your computer にチェックをいれて「Apply & restart」をクリックするだけです。

Forgejo 用 docker-compose.yml

 次に、Forgejo 用の docker-compose.yml ファイルを用意しました。基本的にユーザーがサインインしている間は稼働している必要があるので、restart に always を指定するなどして、調査時のものより運用に適した設定をするようにしてみました。

 アクセスはローカルマシンからしか使わない想定なので、Docker の docker0 ネットワークで使われる 172.17.0.0/16 のネットワークからのみポート転送をするようにしました。

 あとは、調査時はホスト名の名前解決まわりの設定で手間をかけたくなかったので、Forgejo へのアクセスには IP を使っていたのですが、普段使うということを考えるとホスト名を固定した方が何かとやりやすいので、forgejo.example.jp といったホスト名をつけてアクセスできるようにしました。

 こうした場合、Windows からアクセスできるようにするには hosts ファイルを編集する必要がでてくるのが、若干の手間となります。hosts ファイルの編集をすると Docker ホストマシンの環境ファイルに影響が出るので、できるだけ少ない影響で済むようにしたいところです。

 実は Docker ホストマシンの hosts ファイルを編集しなくても Dev Container の desktop-lite のようなものを使えば Docker 環境内に全部閉じることができるので、開発時は Docker 環境内を使うと割り切ることもできます。Docker ホストマシンの Windows での作業が必要な場合もありますが、何らかの方法で Docker 環境と Windows 間とでファイル共有ができさえすれば、何とかなります。

Docker 環境での Git システムの利用

 Docker 環境で Forgejo を動作させることができるようになったので、これを使いたいときは git コマンドが使える Docker コンテナを用意してアクセスすれば良いということになります。開発コンテナー系であれば、基本的に git や ssh コマンドは使えるので、問題なく利用ができます。

 git コマンドがついていないコンテナーで利用することはできませんが、カスタムイメージを使わなくても、git コマンドが使える Docker コンテナを組み合わせて、利用することはできます。その場合は Docker ボリュームを共有するのが手軽です。

 ちなみに Windows からもアクセスしたい場合は、hosts ファイルを編集すれば良いだけです。ここまで書いて思い出しましたが、Docker Desktop で *.docker.internal を有効にしてあるなら、Forgejo で指定するドメイン名を host.docker.internal にしておけば Windows の hosts ファイルを改めて編集することなく、Forgejo を利用することができます。

外部の Git システムの利用

 今回は、Intel N100 ミニ PC で作業をするときもあれば、Hyper-V 仮想マシンで作業をするときもあれば、普段使っている Linux マシンで作業をすることもありました。こういったときは、各マシン間でファイルの同期をしたくなるのですが、そういう場合は、普段使っている Linux マシンで Docker を使って一時的に Forgejo の Git システムを稼働させることで、簡単に同期ができました。

 Hyper-V 仮想マシン内の Docker で動作している Docker コンテナは、他のマシンからはアクセスできないようにしていたので、ファイル転送などをするにしても、基本は Hyper-V 仮想マシン内から他のマシンへアクセスする必要がありました。scp コマンドでファイル転送をするとか、Samba を使ってファイル共有をするとか、いろいろな方法でファイルを共有することはできます。

 でも、Git で出来ることを、わざわざ他の環境を用意して実現する必要もありません。Git システムを動かすための調査をして運用できるように検討をしていたところなので、すでに Forgejo 用の docker-compose.yml もあります。これを使うことで、Hyper-V 仮想マシンへ転送したいファイルがある他のマシンですぐに Git システムの環境が用意できました。これで、バージョン管理をしつつファイル転送もできました。

 ということで、大体のところは目処がたってきました。後は、HTTP での利用はやっぱり抵抗があるので HTTPS 対応にしたいというところでしょうか。これは、どの程度まで対応するかで作業量に大きな差がでてきます。自分の場合は自由に使えるドメインもあり、Let’s Encrypt の証明書も利用できる環境があるので、それほど苦労しなくても用意できるのですが、そういった環境がない場合でも何とかする方法はあります。さて、どうしましょうかね。

 ということで、本日はここまで。

同じタグの記事: Docker Desktop
同じタグの記事: Forgejo
同じタグの記事: Intel N100
同じタグの記事: NiPoGi
同じタグの記事: Ubuntu
同じカテゴリの記事: Linux
同じカテゴリの記事: Win