Virtualizzazione Apple M2 con Colima e Docker Desktop
2023-09-14
Machine-translated — the English original is authoritative.
Questo articolo è scritto dalla prospettiva di qualcuno che non si preoccupa troppo del motore di container che sta utilizzando. Volevo semplicemente valutare un prodotto di un fornitore e sapevo che i container sarebbero stati il modo più efficiente per iniziare rapidamente. Sto inoltre svolgendo questa attività come esercizio di formazione personale, il che significa che la licenza di Docker Desktop non dovrebbe essere un problema. Tuttavia, se stai utilizzando i container per lavoro ma non sei in possesso di una licenza per Docker Desktop, continua a leggere poiché questo potrebbe fornirti una valida soluzione open source per la gestione dei container.
Tieni presente inoltre che le sfide che ho affrontato qui erano specifiche per gli utenti Apple MacOS che utilizzano il silicio proprietario M1/M2 di Apple: l'ironia non mi è sfuggita, dato che sto utilizzando un hardware così costoso e mi preoccupo di costi di licenza relativamente irrilevanti 😁.
TLDR
Se la licenza non è un problema e ti manca quella curiosità ingegneristica riguardo ai vari motori di container, ma vuoi semplicemente sbrigare la commissione, Docker Desktop fa per te!
Non dimenticare di installare il software Rosetta 2 di Apple. Questo emulatore/traduttore aiuterà a tradurre in modo trasparente i container x86/AMD (pensa a Intel) o, più correttamente, le istruzioni CPU di basso livello di quei container in un set di istruzioni riconosciuto da Apple M2.
softwareupdate --install-rosetta
E configura Docker Desktop per utilizzare Rosetta 2.
Poi è solo business as usual con i tuoi comandi Docker.
Colima è un sostituto plug-in, quasi!
Colima è un altro eccellente progetto della community che sta aiutando a migliorare l'esperienza degli utenti MacOS nella gestione dei container su Linux, MacOS e Nix!?! (non chiedere, non ho ancora giocato con Nix).
È semplice come
# Homebrew
brew install colima
...
seguito da
colima start
...
e poi sei pronto a partire, vero? Hmmm, sì, suppongo di sì, purché tu stia eseguendo immagini autonome (gioco di parole voluto) che non richiedono mount esterni.
La sfida che ho avuto è che stavo eseguendo un'applicazione vendor relativamente complessa che richiedeva più container e mount di volumi fisici sul sistema operativo sottostante.
Inoltre, non avevo ancora ottimizzato colima per il silicio M2.
Prima di tutto, per ottimizzare per il silicio M2 e aumentare alcune delle configurazioni di base oltre i valori predefiniti, uccidiamo questo motore e apportiamo alcune modifiche come segue.
colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=vz --vz-rosetta --cpu 6 --memory 12 --disk 64
Questo dovrebbe darti una configurazione ottimale, purché tu abbia risorse simili disponibili; in caso contrario, regola a tuo piacimento.
Tuttavia, non sono ancora riuscito a far funzionare con successo l'applicazione vendor. Ricorda, ha funzionato al primo tentativo su Docker Desktop.
Cercando nei log dei container docker, ho visto che il container principale era bloccato in un ciclo di avvio di inizializzazione: si lamentava dei permessi dei file sui dischi montati.
Una rapida ricerca nei Problemi di Colima ha rivelato la sfida insieme alla soluzione alternativa – almeno per me ha funzionato.
Quindi la configurazione finale funzionante di Colima per il mio M2 MBP:
- Crea o inserisci quanto segue in
/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
Per favore, non dimenticare di sostituire (username) con il tuo nome utente sopra (se lo fai sei in buona compagnia, ma era tardi la sera per me, qual è la tua scusa?)
- Elimina il motore esistente e ricomincia questa volta passando all'emulazione qemu e al vecchio mountType
colima stop
...
colima delete
...
colima start --arch aarch64 --vm-type=qemu --vz-rosetta --cpu 6 --memory 12 --disk 64 --mount-type 9p
Infine, possiamo lanciare con successo la stessa applicazione vendor sul silicio M2 utilizzando Colima! I tuoi comandi Docker standard e i file docker-compose.yml dovrebbero funzionare come al solito.
Il cambio di contesto di Docker è utile se decidi di eseguire più motori di container. Dice al binario docker a quale motore di container parlare. Nota inoltre che, quando avvii Docker Desktop, il contesto viene scambiato automaticamente (sì, ha senso, immagino).
# 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
#
Conclusione
In teoria, le prestazioni di Colima dovrebbero essere ridotte poiché non stiamo più utilizzando la virtualizzazione nativa di Apple passando di nuovo a QEMU in questo caso.
Ho sentito che c'era una leggera riduzione delle prestazioni rispetto a Docker Desktop.
Analisi scientifica: è un'applicazione robusta (termine tecnico) e ha impiegato costantemente 2 minuti da docker compose up -d all'accesso quando era in esecuzione su Docker Desktop, mentre ci volevano più di 3 minuti per ottenere il prompt di accesso quando era in esecuzione su Colima.
Se hai fretta, sei un'azienda e puoi permetterti la licenza, Docker Desktop è probabilmente l'opzione migliore focalizzata sul business.
Tuttavia, gli Ingegneri e gli Sviluppatori giocheranno sicuramente con Colima e ti preghiamo di contribuire al progetto: funziona e sta migliorando continuamente.
Dettagli MBP -> Apple M2 Max, 32GB, OS 13.5.2
Docker Desktop -> versione 4.22.0
Colima -> versione 0.5.5
Happy Shipping!
Di seguito è riportato il file docker-compose.yml utilizzato per il deployment.
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).