Virtualisation Apple M2 avec Colima et Docker Desktop
2023-09-14
Machine-translated from English. Read the English original
Cet article est rédigé du point de vue de quelqu’un qui ne se soucie pas vraiment du moteur de conteneurs qu’il utilise. Je voulais simplement évaluer le produit d’un éditeur et je savais que les conteneurs seraient le moyen le plus efficace pour démarrer rapidement. J’entreprends également cette activité dans le cadre d’un exercice de formation personnelle, ce qui signifie que la licence de Docker Desktop ne devrait pas poser de problème. Cependant, si vous utilisez des conteneurs dans un cadre professionnel mais que vous n’êtes pas licencié pour Docker Desktop, poursuivez votre lecture, car cela pourrait vous fournir une solution open source viable pour la gestion des conteneurs.
Notez également que les défis auxquels j’ai été confronté ici étaient spécifiques aux utilisateurs d’Apple MacOS fonctionnant sur les puces propriétaires M1/M2 d’Apple – l’ironie n’est pas perdue pour moi ici, utilisant un matériel aussi coûteux et m’inquiétant de coûts de licence relativement triviaux 😁.
TLDR
Si la licence n’est pas un problème et que vous manquez de engineering curiousity sur les différents moteurs de conteneurs mais que vous voulez simplement faire le travail, Docker Desktop est celui qu’il vous faut !
N’oubliez pas d’installer le logiciel Rosetta 2 d’Apple. Cet émulateur/traducteur aidera à traduire de manière transparente les conteneurs x86/AMD (pensez Intel) ou, plus précisément, les instructions CPU de bas niveau de ces conteneurs vers un jeu d’instructions reconnu par Apple M2.
softwareupdate --install-rosetta
Et configurez Docker Desktop pour utiliser Rosetta 2.
Ensuite, c’est juste business as usual avec vos commandes Docker.
Colima est un remplacement direct, un peu !
Colima est un autre excellent projet communautaire qui aide à améliorer l’expérience des utilisateurs MacOS dans la gestion des conteneurs sur Linux, MacOS et Nix!?! (ne me demandez pas, je n’ai pas encore joué avec Nix non plus).
C’est aussi simple que
# Homebrew
brew install colima
...
suis de
colima start
...
et ensuite vous êtes prêt à partir, non ? Hmmm, oui, je suppose, à condition que vous utilisiez des images autonomes (jeu de mots voulu) qui ne nécessitent pas de montages externes.
Le défi auquel j’ai été confronté était que j’exécutais une application vendor relativement complexe qui nécessitait plusieurs conteneurs et des montages de volumes physiques sur le système d’exploitation sous-jacent.
De plus, je n’avais pas encore optimisé colima pour la puce M2.
Premièrement, pour optimiser pour la puce M2 et augmenter certaines des configurations de ressources de base au-delà de leurs valeurs par défaut, tuons ce moteur et apportons quelques modifications comme suit.
colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=vz --vz-rosetta --cpu 6 --memory 12 --disk 64
Cela devrait vous donner une configuration optimale à condition que vous disposiez de ressources similaires, sinon ajustez selon vos goûts.
Cependant, je n’ai toujours pas pu faire fonctionner l’application vendor avec succès. Rappelez-vous, cela a fonctionné du premier coup sur Docker Desktop.
En parcourant les journaux des conteneurs docker, j’ai pu voir que le conteneur principal était bloqué dans une boucle de démarrage d’initialisation – il se plaignait des autorisations de fichiers sur les lecteurs montés.
Une recherche rapide dans les problèmes de Colima a révélé le défi ainsi que la solution de contournement – au moins cela a fonctionné pour moi.
Donc la configuration Colima finale fonctionnelle pour mon M2 MBP :
- Créez ou placez ce qui suit dans
/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
Veuillez ne pas oublier de remplacer (username) par votre propre nom d’utilisateur ci-dessus (si vous le faites, vous êtes en bonne compagnie mais il était tard pour moi, quelle est votre excuse ?)
- Supprimez le moteur existant et recommencez – cette fois en revenant à l’émulation qemu et au type de montage plus ancien
colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=qemu --vz-rosetta --cpu 6 --memory 12 --disk 64 --mount-type 9p
Enfin, nous pouvons lancer avec succès la même application vendor sur la puce M2 en utilisant Colima ! Vos commandes Docker standard et les fichiers docker-compose.yml devraient tous fonctionner normalement.
Le changement de contexte de Docker est utile si vous décidez d’exécuter plusieurs moteurs de conteneurs. Il indique au binaire docker à quel moteur de conteneurs parler. Notez également que lorsque vous démarrez Docker Desktop, il change le contexte automatiquement (oui, cela a du sens, je suppose).
# 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
#
Conclusion
En théorie, les performances de Colima devraient être réduites car nous n’utilisons plus la virtualisation native d’Apple en revenant à QEMU dans ce cas.
J’ai senti qu’il y avait une légère réduction des performances par rapport à Docker Desktop.
Analyse scientifique – C’est une application robuste (terme technique) et elle a pris constamment 2 minutes de docker compose up -d à la connexion lors de l’exécution sur Docker Desktop, tandis qu’il fallait plus de 3 minutes pour obtenir l’invite de connexion lors de l’exécution sur Colima.
Si vous êtes pressé, êtes une entreprise et pouvez vous permettre la licence, alors Docker Desktop est probablement la meilleure option axée sur les entreprises.
Cependant, les ingénieurs et les développeurs joueront certainement avec Colima et veuillez contribuer au projet – cela fonctionne et s’améliore continuellement.
Détails MBP -> Apple M2 Max, 32 Go, OS 13.5.2
Docker Desktop -> version 4.22.0
Colima -> version 0.5.5
Bon Shipping !
Voici le fichier docker-compose.yml utilisé pour le déploiement.
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).