Apple M2 での Colima と Docker Desktop を使った仮想化

2023-09-14

Machine-translated — the English original is authoritative.

こんにちは、ピークを持つギーク（Geek with the Peak）です。

この投稿は、自分がどのコンテナエンジンを使っているかにそれほどこだわらないという視点から書かれています。私は単にベンダー製品の評価をしたかっただけで、コンテナが最も効率的に素早く環境を構築できる方法だと知っていました。また、これは個人的なトレーニング演習として行っている活動であり、Docker Desktop のライセンスについては問題ないと考えています。ただし、業務でコンテナを使用しているが Docker Desktop のライセンスを持っていない場合は、コンテナ管理のための実用的なオープンソースソリューションが提供される可能性があるため、この先をお読みください。

また、ここで直面した課題は、Apple の独自 M1/M2 シリコン上で動作する Apple MacOS ユーザーに特有のものでした。高価なマシンで動作させながら、比較的些細なライセンスコストを気にしているという皮肉は、私にもよく分かります 😁。

要約（TLDR）

ライセンスが問題ではなく、エンジニアリング的な好奇心がそれほどなく、コンテナエンジンについて深く知る必要がないが、とにかく仕事を完了させたいという方には、Docker Desktop が最適です！

ただし、Apple の Rosetta 2 ソフトウェアをインストールすることを忘れないでください。このエミュレーター/トランスレーターは、x86/AMD（Intel を想定）のコンテナ、より正確にはそれらのコンテナの低レベル CPU 命令を Apple M2 が認識する命令セットに変換するのに役立ちます。

softwareupdate --install-rosetta

そして、Docker Desktop を Rosetta 2 を使用するように設定します。

その後、Docker コマンドはいつもの通りです。

Colima は、一種のドロップイン置換です！

Colima は、Linux、MacOS、および Nix!?!（聞かないでください、私もまだ Nix は触っていません）上でコンテナを管理する MacOS ユーザーの体験を向上させるのに役立っている、もう一つの素晴らしいコミュニティプロジェクトです。

手順は非常にシンプルです。

# Homebrew
brew install colima
...

その後、

colima start
...

と実行すれば、準備完了でしょうか？ うーん、はい、おそらくその通りです。外部マウントを必要としない、自己完結型（意図的な駄洒落です）のイメージを実行している場合に限りますが。

私が直面した課題は、複数のコンテナと、基盤となる OS 上の物理的なボリュームマウントを必要とする、比較的複雑なベンダーアプリケーションを実行していたことでした。
また、M2 シリコン向けに Colima を最適化していなかったことも要因でした。

まず第一に、M2 シリコン向けに最適化し、デフォルト値を超えていくつかの基本的なリソース設定を増やすために、このエンジンを停止し、以下のようにいくつかの調整を行います。

colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=vz --vz-rosetta --cpu 6 --memory 12 --disk 64

同程度のリソースが利用可能であれば、これが最適なセットアップになるはずです。そうでない場合は、好みに合わせて調整してください。

しかし、それでもベンダーアプリケーションを正常に実行することはできませんでした。覚えておいてください、Docker Desktop では初回で成功しました。
Docker コンテナのログを調べると、メインコンテナが初期化ブートループに陥っていることが分かりました。マウントされたドライブのファイル権限について文句を言っていました。

Colima の Issues を検索したところ、課題とその回避策が見つかりました。少なくとも私にはこれで機能しました。

したがって、私の M2 MBP 用の最終的な Colima 設定は以下の通りです：

• /Users/(username)/.lima/_config/override.yaml に以下を作成するか、追記します

mountType: 9p
mounts:
  - location: "/Users/(username)"
    writable: true
    9p:
      securityModel: mapped-xattr
      cache: mmap
  - location: "~"
    writable: true
    9p:
      securityModel: mapped-xattr
      cache: mmap
  - location: /tmp/colima
    writable: true
    9p:
      securityModel: mapped-xattr
      cache: mmap

上記の (username) を自分のユーザー名に置き換えることを忘れないでください（もしそうしなかったら、あなたと同じ仲間に入りますが、私にとっては夜遅くだったので、あなたの言い訳は何ですか？）。

• 既存のエンジンを削除して、再度開始します。今回は QEMU エミュレーションと古い mountType に戻します。

colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=qemu --vz-rosetta --cpu 6 --memory 12 --disk 64 --mount-type 9p

ついに、Colima を使用して M2 シリコン上で同じベンダーアプリケーションを正常に起動できるようになりました！ 標準的な Docker コマンドと docker-compose.yml ファイルは、通常どおり機能するはずです。

複数のコンテナエンジンを実行する予定がある場合、Docker のコンテキスト切り替えは便利です。これは、docker バイナリがどのコンテナエンジンと通信すべきかを指定します。また、Docker Desktop を起動すると、コンテキストが自動的に切り替わることに注意してください（うーん、確かに理にかなっていると思います）。

# docker context ls
NAME              DESCRIPTION                               DOCKER ENDPOINT                                  ERROR
colima            colima                                    unix:///Users/graz/.colima/default/docker.sock   
default           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock                      
desktop-linux *   Docker Desktop                            unix:///Users/graz/.docker/run/docker.sock
#

結論

理論的には、このインスタンスで QEMU に戻すことで Apple のネイティブ仮想化を使用しなくなったため、Colima のパフォーマンスは低下するはずです。
実際、Docker Desktop と比較してパフォーマンスがわずかに低下したように感じました。

科学的分析 – これは「パワフルな」（技術用語）アプリケーションであり、Docker Desktop で実行している場合、docker compose up -d からログインまで一貫して 2 分かかっていましたが、Colima で実行している場合はログインプロンプトが表示されるまでに 3 分以上かかりました。

急いでいる場合、企業であり、ライセンス料を支払える余裕がある場合は、Docker Desktop が最もビジネス指向の優れたオプションかもしれません。
しかし、エンジニアや開発者は間違いなく Colima を試すでしょうし、プロジェクトへの貢献もお願いします。機能しており、継続的に改善されています。

MBP 詳細 -> Apple M2 Max, 32GB, OS 13.5.2
Docker Desktop -> バージョン 4.22.0
Colima -> バージョン 0.5.5

Happy Shipping!

Graz

以下は、デプロイメントに使用された docker-compose.yml ファイルです。

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ce:16.2.6-ce.0'
    depends_on:
       - redis
       - postgresql
    hostname: 'gitlab.demo'
    networks:
      vpcbr:
        ipv4_address: 10.5.0.4
    environment:
       GITLAB_OMNIBUS_CONFIG: |
         postgresql['enable'] = false
         gitlab_rails['db_username'] = "gitlab"
         gitlab_rails['db_password'] = "gitlab"
         gitlab_rails['db_host'] = "postgresql"
         gitlab_rails['db_database'] = "gitlabDB"
         gitlab_rails['db_adapter'] = 'postgresql'
         gitlab_rails['db_encoding'] = 'utf8'
         redis['enable'] = false
         gitlab_rails['redis_host'] = 'redis'
         gitlab_rails['redis_port'] = '6379'
         prometheus['enable'] = false
         external_url "http://gitlab.demo"
         gitlab_rails['gitlab_shell_ssh_port'] = 23
    container_name: gitlabce
    extra_hosts:
      - "gitlab.demo:127.0.0.1"
    restart:  always
    ports:
      - '80:80'
      - '443:443'
      - '23:22'
    volumes:
      - '$GITLAB_HOME/config:/etc/gitlab'
      - '$GITLAB_HOME/logs:/var/log/gitlab'
      - '$GITLAB_HOME/data:/var/opt/gitlab'
    shm_size: '4GB'
  postgresql:
     container_name: postgress
     image: postgres:15.4
     networks:
      vpcbr:
        ipv4_address: 10.5.0.5
     environment:
       - POSTGRES_USER=gitlab
       - POSTGRES_PASSWORD=gitlab
       - POSTGRES_DB=gitlabDB
  redis:
     image: redis:7.2.1
     container_name: redis
     networks:
      vpcbr:
        ipv4_address: 10.5.0.6

  runner:
    image: gitlab/gitlab-runner:v16.3.0
    container_name: gitlab-runner
    restart: always
    extra_hosts:
      - "gitlab.demo:10.5.0.4"
    volumes:
     - '$GITLAB_HOME/gitlab-runner/config:/etc/gitlab-runner'
     - '/var/run/docker.sock:/var/run/docker.sock'
    networks:
      vpcbr:
        ipv4_address: 10.5.0.7

networks:
  vpcbr:
    driver: bridge
    ipam:
     config:
       - subnet: 10.5.0.0/24
         gateway: 10.5.0.1

Originally published on allthingscloud.eu (2023-09-14).