102 lines
5.4 KiB
Markdown
102 lines
5.4 KiB
Markdown
# Soporte multi-arquitectura (amd64 + arm64) para vscode-server
|
|
|
|
## Contexto
|
|
|
|
La imagen `vscode-server` hoy solo se construye y publica para `linux/amd64` (ver
|
|
`.gitea/workflows/main-workflow.yml:85`). El usuario quiere consumir esta imagen nativamente
|
|
desde una Mac con chip Apple Silicon (arm64), y seguir publicándola en el registry de Gitea
|
|
(`gitea.p-lao.com/aleleba/vscode-server`).
|
|
|
|
La imagen base `gitea.p-lao.com/aleleba/vscode:latest` (repo
|
|
`aleleba/aleleba-vscode-dockerfile-configuration`) ya se publica multi-arch (confirmado: su
|
|
workflow construye con `platforms: linux/amd64,linux/arm64` y su Dockerfile usa
|
|
`$(dpkg --print-architecture)` para resolver rutas dependientes de arquitectura), así que es una
|
|
base válida para extender.
|
|
|
|
Al revisar `Dockerfile` completo se encontraron dos problemas que romperían o degradarían el
|
|
build en arm64, y ambos ya se resolvieron con el usuario:
|
|
|
|
1. **`JAVA_HOME` hardcodeado a `amd64`** (`Dockerfile:106`, y de nuevo en el `~/.bashrc` en
|
|
`Dockerfile:160`) — en Debian/Ubuntu la ruta de `openjdk-17-jdk` es
|
|
`/usr/lib/jvm/java-17-openjdk-<arch>`, así que en arm64 esa ruta no existiría y rompería
|
|
cualquier comando que dependa de `$JAVA_HOME` (Android SDK, Gradle, etc.).
|
|
2. **`docker-compose` v1.21.2 descargado como binario fijo** (`Dockerfile:76-80`) desde
|
|
`https://github.com/docker/compose/releases/download/1.21.2/docker-compose-$(uname -s)-$(uname -m)`
|
|
— se confirmó por búsqueda web que esa versión (2018) nunca publicó binario para
|
|
`aarch64`/`arm64`; el `RUN` fallaría al construir en esa plataforma.
|
|
|
|
Decisiones ya acordadas con el usuario:
|
|
- **docker-compose**: eliminar la descarga manual del binario v1 y confiar en el plugin Compose V2
|
|
(`docker compose`, con espacio) que el script de `get.docker.com` ya instala automáticamente y
|
|
que sí soporta ambas arquitecturas nativamente. Agregar un wrapper `/usr/local/bin/docker-compose`
|
|
que delegue a `docker compose "$@"`, para no romper scripts existentes que usan el nombre con guion.
|
|
- **Android SDK** (`platform-tools`, `build-tools`, `emulator` instalados vía `sdkmanager`,
|
|
`Dockerfile:130-131`): Google solo distribuye binarios nativos oficiales para Linux x86_64. El
|
|
build en sí no falla en arm64 (`sdkmanager` solo descarga/descomprime, no ejecuta los binarios),
|
|
pero en un Mac M corriendo la imagen arm64 nativa, `adb`/`aapt2`/`emulator` probablemente no
|
|
ejecutarán. Se deja la instalación igual en ambas arquitecturas y se documenta la limitación en
|
|
el README (mitigación: correr ese contenedor puntual con `--platform linux/amd64` cuando se
|
|
necesite Android).
|
|
|
|
El resto de las instalaciones del Dockerfile (GitHub CLI, kubectl, Flux CLI, NVM/Node, Emscripten,
|
|
Claude Code, Conan) ya son multi-arch (usan `$(dpkg --print-architecture)`, scripts oficiales que
|
|
autodetectan arquitectura, o son artefactos JVM/Python agnósticos de arquitectura) — no requieren
|
|
cambios.
|
|
|
|
## Cambios
|
|
|
|
### 1. `Dockerfile`
|
|
|
|
- Justo antes de `ENV JAVA_HOME=...` (línea 106), declarar `ARG TARGETARCH` (buildx lo puebla
|
|
automáticamente por plataforma; sus valores `amd64`/`arm64` coinciden con el naming de Debian) y
|
|
cambiar la línea a:
|
|
```
|
|
ENV JAVA_HOME=/usr/lib/jvm/java-17-openjdk-${TARGETARCH}
|
|
```
|
|
- En el bloque de configuración de `~/.bashrc` (línea ~160), reemplazar el valor hardcodeado por la
|
|
variable ya resuelta:
|
|
```
|
|
RUN echo "export JAVA_HOME=$JAVA_HOME" | sudo tee -a ~/.bashrc
|
|
```
|
|
- Eliminar el bloque de instalación manual de `docker-compose` v1 (líneas 76-80).
|
|
- Después de instalar Docker (que ya trae `docker-compose-plugin`), agregar un wrapper de
|
|
compatibilidad:
|
|
```
|
|
RUN sudo printf '#!/bin/sh\nexec docker compose "$@"\n' | sudo tee /usr/local/bin/docker-compose > /dev/null \
|
|
&& sudo chmod +x /usr/local/bin/docker-compose
|
|
```
|
|
|
|
### 2. `.gitea/workflows/main-workflow.yml`
|
|
|
|
- Agregar el paso `docker/setup-qemu-action@v3` (antes de `docker/setup-buildx-action@v3`), para
|
|
garantizar emulación arm64 en el runner de Gitea Actions aunque no traiga QEMU/binfmt
|
|
preregistrado (a diferencia de runners hosteados de GitHub).
|
|
- Cambiar `platforms: linux/amd64` (línea 85) a `platforms: linux/amd64,linux/arm64`.
|
|
|
|
### 3. `README.md`
|
|
|
|
- Bump de versión siguiendo la convención existente del repo (cada commit incrementa la versión):
|
|
`1.1.0` → `1.2.0`.
|
|
- Agregar una nota breve documentando la limitación de Android SDK en arm64 y la mitigación
|
|
(`--platform linux/amd64` cuando se necesite `adb`/`aapt2`/`emulator` funcionales).
|
|
|
|
## Verificación
|
|
|
|
- Build local multi-plataforma sin push, solo para validar que ambos targets compilan:
|
|
```
|
|
docker buildx build --platform linux/amd64,linux/arm64 -t vscode-server:test --output=type=cacheonly .
|
|
```
|
|
- Si hace falta cargar y probar arm64 localmente en una máquina x86 (requiere QEMU registrado,
|
|
p.ej. `docker run --privileged --rm tonistiigi/binfmt --install all`):
|
|
```
|
|
docker buildx build --platform linux/arm64 -t vscode-server:arm64 --load .
|
|
docker run --rm --platform linux/arm64 vscode-server:arm64 bash -lc 'echo $JAVA_HOME && java -version && docker compose version && docker-compose version'
|
|
```
|
|
- Push a `master` (o `workflow_dispatch`) y confirmar en Gitea Actions que el job
|
|
`build-and-push` termina en verde para ambas plataformas.
|
|
- Verificar el manifest multi-arch publicado:
|
|
```
|
|
docker manifest inspect gitea.p-lao.com/aleleba/vscode-server:latest
|
|
```
|
|
y confirmar que aparecen entradas para `linux/amd64` y `linux/arm64`.
|