HarmenandClaude Opus 5
627c8306b1
Alleen documentatie. Op aanwijzing van de gebruiker bij het afsluiten: de suite meldt bij elke ronde dat python:3-alpine en nginx:alpine niet gepind zijn, en de verleiding is dat even te doen. Dat is de verkeerde volgorde. Pinnen is een eis van Publicatie, maar daarvoor gaat de app-inhoud eerst een eigen image in, en dan bestaan die twee niet meer als de plek waar onze code draait. De regel staat nu in KNOWLEDGE.md, want vier plannen raken hem en geen van de vier bezit hem: de eis komt uit Publicatie, de oorzaak zit in Eigenimage, en de taak stond in Umbrelapp en Appstore. Met twee grenzen erbij, anders slaat het de andere kant op door: de eigen image pin je wel meteen bij elke verhoging, en de melding in de suite blijft een afdruk en geen toets, zodat de suite niet rood staat tot Eigenimage klaar is. Onderweg bleek Eigenimage PLAN.md 8 achterhaald en misleidend. Daar stond dat het bouwrecept van Evolu Relay misschien zou vervallen zodra de kale relay de weg werd, en dat je er daarom niets aan moest verbeteren. Wij bouwen juist een eigen image, want de twee terugroepfuncties zitten niet in de gepubliceerde. En de paragraaf onderschatte wat er nog te doen is: ook bij die app staan de agent en de pagina nog op vreemde images, alleen de relay zelf is klaar. Herschreven, en de kolom App van dat plan in CONTINUE_HERE staat daarom op "beide" in plaats van op Gate. Verder de taak in Umbrelapp gemarkeerd als wachtend op Eigenimage in plaats van open, een verwijzing bovenaan Images-pinnen.md, en de regel voor Umbrelapp in CONTINUE_HERE ingekort en bijgewerkt naar 0.5.1. Geen tests gedraaid: er is niets buiten Docs/ geraakt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
104 lines
4.2 KiB
Markdown
104 lines
4.2 KiB
Markdown
# Images pinnen: de commando's
|
|
|
|
Naslag, geen plan. Wanneer dit gedaan wordt en waarom staat in het masterplan **Publicatie**; hier staan
|
|
alleen de commando's en wat je uit de uitvoer moet halen.
|
|
|
|
> **Lees eerst de volgorde-regel in [KNOWLEDGE.md](../KNOWLEDGE.md), voordat je `python:3-alpine` en
|
|
> `nginx:alpine` gaat pinnen.** Vastgelegd 30-08-2026 op aanwijzing van de gebruiker: die twee verdwijnen
|
|
> waarschijnlijk als het plan **Eigenimage** klaar is, en dan is dit werk weggegooid. Voor een image die je
|
|
> zelf uitgeeft blijft alles hieronder wél gelden, en dat is dan het enige dat er te pinnen valt.
|
|
|
|
Alles hieronder draait **op de Umbrel**, want daar staat Docker. Lukt een commando niet, zet er dan `sudo`
|
|
voor.
|
|
|
|
## Waarom het niet één commando is
|
|
|
|
De eis is `repo:versie@sha256:<digest>`, en daar zitten drie dingen in die elk apart mis kunnen gaan:
|
|
|
|
- **de tag moet specifiek zijn.** `python:3-alpine` beweegt mee met elke nieuwe 3.x en is ook mét digest
|
|
niet toegestaan. Stap 1 zoekt uit welke versie er nu achter zit;
|
|
- **de digest moet die van de index zijn**, niet die van één architectuur. Een platform-digest werkt op de
|
|
machine waar je hem ophaalt en breekt op de andere; een Umbrel Home is arm64 en een zelfbouw meestal
|
|
amd64;
|
|
- **beide architecturen moeten erin zitten.** Dat lees je in dezelfde uitvoer af.
|
|
|
|
## Stap 1: welke versie zit er achter de bewegende tag
|
|
|
|
```bash
|
|
docker run --rm python:3-alpine python -V
|
|
```
|
|
|
|
```bash
|
|
docker run --rm nginx:alpine nginx -v
|
|
```
|
|
|
|
De uitvoer noemt bijvoorbeeld `Python 3.13.7` en `nginx version: nginx/1.27.4`. Gebruik daarvan alleen het
|
|
eerste deel in de tag, dus `python:3.13-alpine` en `nginx:1.27-alpine`, en niet de derde cijfergroep: een
|
|
patchversie-tag bestaat niet altijd, en de tweede cijfergroep is specifiek genoeg om niet mee te bewegen
|
|
met een nieuwe hoofdversie.
|
|
|
|
## Stap 2: de index-digest van die tag
|
|
|
|
```bash
|
|
docker buildx imagetools inspect python:3.13-alpine
|
|
```
|
|
|
|
```bash
|
|
docker buildx imagetools inspect nginx:1.27-alpine
|
|
```
|
|
|
|
Twee dingen uit die uitvoer, en let op welke digest je pakt:
|
|
|
|
```
|
|
Name: docker.io/library/python:3.13-alpine
|
|
MediaType: application/vnd.oci.image.index.v1+json
|
|
Digest: sha256:AAAA... <- deze, de bovenste
|
|
Manifests:
|
|
Name: docker.io/library/python:3.13-alpine@sha256:BBBB...
|
|
Platform: linux/amd64 <- deze moet erin staan
|
|
Name: docker.io/library/python:3.13-alpine@sha256:CCCC...
|
|
Platform: linux/arm64 <- en deze ook
|
|
```
|
|
|
|
De bovenste `Digest:` is de manifest-lijst en die hoort in de compose. De digests bij `Manifests:` zijn per
|
|
platform; dat is precies de verwisseling die pas op de andere architectuur opvalt.
|
|
|
|
## Stap 2b: als `buildx` er niet is
|
|
|
|
```bash
|
|
docker pull python:3.13-alpine
|
|
```
|
|
|
|
```bash
|
|
docker image inspect --format '{{index .RepoDigests 0}}' python:3.13-alpine
|
|
```
|
|
|
|
Een `docker pull` van een tag met meerdere architecturen zet de index-digest in `RepoDigests`, dus dit
|
|
levert dezelfde waarde op als stap 2.
|
|
|
|
**Maar het bewijst niets over de architecturen, en dat is hier geen theoretisch punt.** De Umbrel van de
|
|
gebruiker is amd64 (`OS: Linux 6.12.85+deb13-amd64`, uit de nginx-startlog van 20-08-2026). Een `docker pull`
|
|
daar haalt de amd64-variant en zegt niets over arm64, terwijl arm64 wel een eis is en de helft van de
|
|
Umbrels erop draait. Gebruik dus stap 2 als het kan, en zie deze terugval als "de digest opzoeken", niet als
|
|
"de eis controleren".
|
|
|
|
Terzijde, uit diezelfde log: achter `nginx:alpine` zat op 20-08-2026 **nginx 1.31.4**. Stap 1 hoeft daarvoor
|
|
dus niet eens gedraaid te worden zolang de app draait; `docker logs` van de server-container noemt de versie
|
|
bij elke start.
|
|
|
|
## Stap 3: de pin in de repo
|
|
|
|
Plak de uitvoer van stap 2 in de sessie. De pin gaat dan in `docker-compose.yml`:
|
|
|
|
```yaml
|
|
image: python:3.13-alpine@sha256:AAAA...
|
|
```
|
|
|
|
Dat is een gewone commit **met een versieverhoging** in `umbrel-app.yml`, want de compose staat in de
|
|
update-whitelist en wordt dus daadwerkelijk uitgerold.
|
|
|
|
## Stap 4: het is onderhoud, geen eenmalige handeling
|
|
|
|
Een gepinde image krijgt geen beveiligingsupdates meer tot iemand de pin verhoogt. Deze vier stappen horen
|
|
daarom bij elke release opnieuw gedaan te worden, niet één keer bij de inlevering.
|