🐳

M1 mac で x86_64 の Docker コンテナイメージ(gitbucket)を動かしてみたよ(ただし、動作がもたついている状態)

2022/03/18に公開約9,500字3件のコメント

はじめに

Docker、Linuxコマンドなどをあまり使い慣れていません。用語の違いや解釈の違いなどがあったら、ご指摘もらえるとうれしいです・・。

今回の内容を確認したかった動機

現在、自宅のメインPCは、Mac mini(M1 2020)で、CPUが Apple シリコン となりました。
10万円以下で購入できるPCとしては、とにかく基本性能の高い!(少なくとも自分には満足な性能!)で、
ものすごくコストパフォーマンスが良く、PCの性能ってまだまだ向上するものなんだなと感心しています。

が、arm系CPUは、2022年03月現在、ハードウェアとの接続を管理するデバイスドライバなどがまだ十分にそろっておらず、たとえばドキュメントスキャナに関しては、先日、Canonのドキュメントスキャナ(DR-C230)のデバイスドライバがようやくメーカーにて正式対応し、ダウンロードできるようになりました。(半年くらい対応を待っておりました。ありがとうCanon。信じて待ってたおかげで、他のメーカーのドキュメントスキャナを買わずに済んだよ。)

次に、作成したソースコードの管理方法として、Gitを使う上でのリモートリポジトリ保存先として、私は竹添直樹さんが公開している gitbucket を愛用しています。
(余談ですが、竹添さんといえば、

https://www.shoeisha.co.jp/book/detail/9784798121505
Seasar2徹底入門。この本でWebアプリケーション開発のことを学びました。(当時は非常に助けられました。ありがとうございます。))
肝心の gitbucket ですが、OSSでここまでのものが作れてしまうことがすごいですね。見習わなければ・・。

話を戻して、
以前は手組みでCentOSサーバーを用意し、gitbucketを入れておりましたが、Javaの設定などを簡略することを考えて、今回、Dockerでのgitbucketを構築してみようと思いました。コンテナ技術って便利ですね。

が、gitbucketの正式Dockerコンテナイメージは、x86関連のものしか見当たらない

https://hub.docker.com/r/gitbucket/gitbucket/tags
ため、「どうしようか?」と、いつものようにネットを彷徨っていたところ、
・qemu
・lima
というキーワードにたどり着きました。
つまり、
 Mac上での 「Windows における WSL みたいなもの」 で、かつ、「m1 mac 上で x86 エミュレーション動作する」 ものの様子。こりゃすごい!! ということで、早速試してみることにします。

ちなみに私、VisualBasicの思い出Blog

https://zenn.dev/okojyo21/articles/891647a35d52f3
を書いているように、基本的に、Windows野郎(今でも Mac も Windows も両方好きです)でしたので、bashや、zshより、PowerShell や MS-DOSコマンド の方が詳しいのですが、逐次頭を置き換えながら作業をしていってみます。

目指すべきゴール

・m1 mac 上で x86_64 プラットフォームの gitbucket の Dockerコンテナイメージ が動作し Gitリモートリポジトリ管理できる

構成要素の把握

まず、limaですが、

https://github.com/lima-vm/lima

うん、Windowsにおける WSLのようなもの、ですね。早速、インストールしてみましょう。

環境整備

まず、homebrew は 入っている前提です。

https://brew.sh/index_ja

まず、 lima を入れてみます。ちなみに、自室ではなくリビングでいろいろと試してみたかったので、m1 mac miniではなく、アラフィフ(表現が古い?)モバイル野郎として利用しようと購入した m1 MacbookAir(2020) で試してみます。このマシンは先日購入したばかりで、ほとんどアプリケーションを入れていない状態です(こいつもバッテリーは長持ちするし、Rethinaディスプレイは老眼気味になってきた目にもみやすい。TouchIDも便利ですね)。

brew install lima

不安になるくらい、いろんなものが追加インストールされた様子ですが、最終的に
以下のバージョンがインストールされました。

/opt/homebrew/Cellar/lima/0.9.1: 45 files, 26.5MB

現在のプラットフォーム環境を確認します

uname -a
Darwin xxxx.local 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T8101 arm64

開始してみます。

limactl start

確認プロンプト状態になるので、デフォルトのまま進めてみます。

? Creating an instance "default"  [Use arrows to move, type to filter]
> Proceed with the current configuration
  Open an editor to review or modify the current configuration
  Choose another example (docker, podman, archlinux, fedora, ...)
  Exit!

インストールが終わりました。
コンテナの動作状態をチェックしてみます。

lima uname -a
Linux lima-default 5.13.0-28-generic #31-Ubuntu SMP Thu Jan 13 17:44:32 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

arm64 の Ubuntu がインストールされていることがわかります。ちゃんとできてますね(あたりまえ)。

limactl listコマンドで、イメージのリストが表示されます。

limactl list
NAME       STATUS     SSH                ARCH       CPUS    MEMORY    DISK      DIR
default    Running    127.0.0.1:60022    aarch64    4       4GiB      100GiB    /Users/xxxxxxx/.lima/default

なにも指定していない状態なので、default という名前でコンテナイメージが作成されていることがわかります。

このイメージは、以下の設定ファイル内容で、仮装コンテナ内OSの設定が決まっているようです。

10行目、arch の 部分が null なので、
m1 mac としては、arm64(aarch64) の ubuntuが自動選択されて、作成されているということですね。

ということは、同じように設定ファイル(.yaml)を用意して、arch の部分を x86_64 を指定して、limaを起動すれば、 x86_64版のコンテナイメージが作成できるのでは? という風に想像できますね。早速やってみます。

x86_64版の lima 環境整備

デフォルトで作成したコンテナの.yamlファイルは、以下のフォルダに保存されていました。このファイルをコピーします。

先ほどはホームディレクトリから直接 limactrlコマンドを実行していましたが、挙動を確認するため、任意のフォルダ(ディレクトリか)を作成し、先ほどのファイルを持ってきて、lima_x86.yaml にリネームします。

適当なエディタで中を開いて、 arch を "x86_64" に修正して保存します。

今度は、カレントディレクトリを上記のディレクトリに移動させて、limactl start コマンドで .yamlファイルを指定して実行してみます。

cd lima
limactl start lima_x86.yaml

またまた不安になるくらい時間がかかるのですが、ターミナル内で進捗がみられます。先ほどは意識していませんでしたが、途中のセットアップ情報のなかで、 QEMU なるキーワードが出てきます。

https://www.qemu.org/
https://ascii.jp/elem/000/004/039/4039729/2/

lima 上において、 QEMUが 各コンテナの指定条件のCPUアーキテクチャに合わせてエミュレーションを行う形になって、CPUの違いを吸収している、という解釈をしていますが、合ってるかな?

そうこうしている間に、不安をよそに、コマンドの実行が終わりました。動作状況を確認してみます。

limactl list               
NAME        STATUS     SSH                ARCH       CPUS    MEMORY    DISK      DIR
default     Running    127.0.0.1:60022    aarch64    4       4GiB      100GiB    /Users/xxxxxxxxx/.lima/default
lima_x86    Running    127.0.0.1:57944    x86_64     4       4GiB      100GiB    /Users/xxxxxxxxx/.lima/lima_x86

先ほどの default 以外に lima_x86 が増えました。動作している様子です。早速、作成したコンテナイメージを limactl コマンドにて 利用してみましょう。

limactl shell lima_x86
xxxxxxxxx@ubuntu:/Users/xxxxxxxxx/lima$ 

無事に 対象コンテナイメージの shell としてターミナルが切り替わりました。
CPUが x86 環境で動作していることを確認してみます。

uname -a
Linux ubuntu 5.13.0-28-generic #31-Ubuntu SMP Thu Jan 13 17:41:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

x86_64 の文字が確認できます。おおー! arm64 系のCPU上で、x86をエミュレーションしながら仮装コンテナイメージ内で ubuntu が動作しているのですね。すごいすごい!
(確認できたので、shellは exit にて終了させておきます。)

ここで、不要なトラブル発生を抑止するため、先に動作させている arm64 default コンテナイメージ動作を停止させておきます。

limactl stop default

現在の状態を確認します。

limactl list        
NAME        STATUS     SSH                ARCH       CPUS    MEMORY    DISK      DIR
default     Stopped    127.0.0.1:0        aarch64    4       4GiB      100GiB    /Users/xxxxxxxx/.lima/default
lima_x86    Running    127.0.0.1:57944    x86_64     4       4GiB      100GiB    /Users/xxxxxxxx/.lima/lima_x86

defalutコンテナ は Stopped で、止まってますね。
では、ここから x86_64 で動作している lima ubuntu内の 仮想マシン上にて、Docker を動作させて、最終目標である、Gitbucket の 正式コンテナイメージ を動作させてみましょう。

x86_64版の lima 内 ubuntu にて Docker を動作させる

m1 arm64 を x86 環境でエミュレーションした、lima ubuntu 内にて、さらに Docker を動作させます。(何重のエミュレーションが走っているのでしょうか、すごいことだ・・)
作成した 名称、lima_x86 の shellを起動します。(プロンプト表示が username@ubuntu:にかわります)

limactl lima_x86 shell

起動したshell内に ベタ ですが、そのまま Docker(Docker-ce) を入れてみます。
Dockerのインストールについては

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-20-04-ja
上記URLの情報を参考にさせていただきました。Step01部分を参考に、インストールを実行。
sudo systemctl status docker

で、Dockerが常駐していることを確認できました。

x86_64版の オフィシャルDockerイメージ gitbucketの起動

では、いよいよメインの目的 オフィシャルDockerイメージのgitbucket を動かしてみます。
利用するイメージを特定します。

https://takezoe.hatenablog.com/entry/2018/09/29/153413
竹添さんの本家Blogの情報をもとに、公式イメージを取り込みます。

DockerHubの対象ページも参照します。

https://hub.docker.com/r/gitbucket/gitbucket/

では、取り込み開始。

docker pull gitbucket/gitbucket

あれ、エラーになりました。実行権限が弱いようです。sudo を 付加します。

sudo docker pull gitbucket/gitbucket

今度は成功しました。

Using default tag: latest
latest: Pulling from gitbucket/gitbucket
0e29546d541c: Pull complete 
9b829c73b52b: Pull complete 
cb5b7ae36172: Pull complete 
99ce012bef04: Pull complete 
22dc2a72d098: Pull complete 
9c69a57e10d9: Pull complete 
f249eb2068a0: Pull complete 
f4460442282c: Pull complete 
Digest: sha256:eafcdaf0e9b7c775f34b068b1360f221674fd896321920a49d536ac678afceb1
Status: Downloaded newer image for gitbucket/gitbucket:latest
docker.io/gitbucket/gitbucket:latest

では、gitbucketを docker run で起動してみます。

sudo docker run -d -p 8080:8080 gitbucket/gitbucket

dockerプロセスの状態を確認してみます。

sudo docker ps
CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS         PORTS                                                  NAMES
3eefc1eeb2a7   gitbucket/gitbucket   "sh -c 'java -jar /o…"   2 minutes ago   Up 2 minutes   0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 29418/tcp   priceless_shirley

では、gitbucketに GoogleChromeでアクセスしてみますが、
ぐ、ぐむー(キン肉マンを見ているとよく出てくる困った時に出るセリフ)。

管理画面ページが表示されないですね。
homeディレクトリ配下の、隠しフォルダ(.lima)内にある lima の実行ログを確認してみます。
ha.stderr.log
というログが出力されていました。

内容を確認すると、

{"error":"failed to run [ssh -F /dev/null -o 
以下略

SSH関連のエラーが発生している様子です。竹添さんのサイト情報の「SSH経由での接続」を考慮して、実行コマンドを変更してみます。

まずは、起動中のDocker gitbucket を停止します。

sudo docker stop 3eefc1eeb2a7

コマンドを変更して、再トライ。

sudo docker run -d -p 8080:8080 -p 29418:29418 gitbucket/gitbucket

さあ、動くかな?と思い、 gitbucket への urlに再アクセスするも、 あれ、やっぱり同じ状態・・。

こんなときはちょっと一呼吸入れて、頭を切り替えてみよう、と思い、3時間ほど放置。戻ってきてmacbook air を見てみると・・・


gitbucket の画面が表示されています!!!
とりあえず、内部でメイン画面を起動できるところまでは成功しているようです。

初期設定を行うため、サインインしてみます。

サインインできましたが、

GoogleChromeのタブバーの「読み込み中」部分が動いたままの状態で 「localhost を 待機しています...」が連続していますね。
現時点のままでは、動作として、Gitbucketとしては実用に耐えられる状態ではないかも、です。

しかしながら、m1 mac上で x86_64 イメージの仮装コンテナが動作する ということは確認できました。もう少し調査を進めて、現状の動作のもたつきの原因を解消してみようと思います。

まとめ

いやー、しかし素晴らしい!!
Docker というか、コンテナ技術を使いこなせると、PC98のConfig.sysの記述内容と戦っていた MS-DOS時代とは考えられないくらい、各種環境を迅速に用意できますね(例えが古すぎるかも・・)。

ただ、逆に、結局 Config.sys をいじるのと同じように、「各構成要素を正しく理解して使う」必要もありますね。便利であるが故に、何が使われて動作しているのだろう、という、何がの部分が隠蔽されてしまうため、構成要素を分解し理解できるようにしていこうと思います。

今回はプライベートで確認している限りですので、まずはやってみようの意識で取り組んでみました。
次は、gitbucket を 実用に耐えられるようにしてみたいなあ・・。

参考にさせていただいたサイト

https://zenn.dev/takasp/articles/3cf03da87d894e
https://zenn.dev/matsukaz/articles/31bc31ff1c54b4
https://qiita.com/chibiegg/items/eede37345f7058ce604d
https://zenn.dev/ciloholic/articles/bbc6927ecfbdb4
https://zenn.dev/ioridev/articles/9f6d925cac150c
https://zenn.dev/sasasin/articles/46540925aecc4e
https://qiita.com/s-suefusa/items/cb3c4044da3b3657dbd0
GitHubで編集を提案

Discussion

そんな難しいことをしなくても、GitBucketはJREが動けば良いので、下記Dockerfileを手元の環境でビルドすればarm64なopenjdk:8-jreを使って動作するはずです。

https://github.com/gitbucket/gitbucket-docker/blob/master/Dockerfile

コメントありがとうございます。確かに、arm64で動作するJREの環境を作ってあげれば良いですねー。こういう点に気がつくということが大事ですね。ありがとうございます。

ビルドして試してみました。mac単体でDockerが動作するという、検証目的とは違うところでの確認になりますが・・・。なお、コマンドに --platform linux/x86_64 を追加することで、正常動作が確認できました。

ログインするとコメントできます