Multiple Architekturen erzeugen about fhempy-docker HOT 7 CLOSED

bei mir läuft lokal der build für aarch64, amd64 und arm/v7. Dazu gibt's diese Dateien:

build-release.sh

#!/bin/bash
#
export BUILD_VERSION=$(curl -Ls https://api.github.com/repos/fhem/fhempy-docker/releases/latest | grep -oP '"tag_name": "V\K(.*)(?=")')
export FHEMPY_V=$(curl -Ls https://api.github.com/repos/fhempy/fhempy/releases/latest | grep -oP '"tag_name": "v\K(.*)(?=")')
echo -ne "\033]0;Baue fhempy-docker/${BUILD_VERSION} auf Basis von fhempy/${FHEMPY_V}\007"
docker buildx build --rm \
    --build-arg BUILD_VERSION="${BUILD_VERSION}" \
    --build-arg FHEMPY_V="${FHEMPY_V}" \
    --build-arg BUILD_DATE="$(date +"%Y-%m-%dT%H:%M:%SZ")" \
    --tag <lokale Registry>:5000/fhempy-docker:latest --tag <lokale Registry>:5000/fhempy-docker:${BUILD_VERSION} \
    --platform linux/amd64,linux/aarch64,linux/arm/v7 \
    --push .
echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"

Dockerfile

## base (used only during build)
FROM python:latest as base
RUN apt update && \
        apt install dbus python-dbus-dev rustc build-essential libssl-dev libffi-dev python3-dev cargo -y --no-install-recommends \
        && rm -rf /var/lib/apt/lists/*

ARG FHEMPY_V
ARG BUILD_VERSION

RUN curl https://raw.githubusercontent.com/fhempy/fhempy/v${FHEMPY_V}/requirements.txt --silent --output requirements.txt &&\
    pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt &&\
    rm requirements.txt

### fhempy-container
FROM python:slim as runtime

WORKDIR /usr/src/app

ARG FHEMPY_V
ARG BUILD_VERSION

LABEL org.opencontainers.image.created=$BUILD_DATE \
      org.opencontainers.image.version=$BUILD_VERSION \
      org.opencontainers.image.title="fhempy-docker" \
      org.opencontainers.image.description="Docker implementation of fhempy, based on fhempy/v${FHEMPY_V}"

COPY --from=base /wheels /wheels
RUN pip install --no-cache --find-links=/wheels fhempy==${FHEMPY_V}

RUN apt update && \
        apt install curl -y --no-install-recommends \
        && rm -rf /var/lib/apt/lists/*

COPY src/health-check.sh /health-check.sh
RUN chmod +x /health-check.sh

HEALTHCHECK --interval=50s --timeout=15s --start-period=10s --retries=3 CMD /health-check.sh

CMD [ "fhempy" ]

Das Dockerfile ist hier aus Deinem Repo, ich hab es nur ein bissl für mich abgewandelt.
Deine requirements.txt enthält ja nur fhempy.
Wenn da noch mehr reinkommt, dann das vorletzte RUN (RUN pip install --no-cache --find-links=/wheels fhempy==${FHEMPY_V}) ersetzen mit: RUN curl https://raw.githubusercontent.com/fhem/fhempy-docker/v${BUILD_VERSION}/requirements.txt --silent --output requirements.txt && pip install --no-cache --find-links=/wheels -r requirements.txt && rm requirements.txt.

Vielleicht hilfts Dir weiter...

from fhempy-docker.

Das Problem ist, es sind etliche Abhängigkeiten die in der requirements.txt von FHEMPY fehlen nötig, damit die Module (z.B. google weather) funktionieren, da diese dynamisch nachgeladen werden.

Ich habe versucht die wheels für arm zu bauen, nach 5h Laufzeit kam es zu einem Fehler.
Installieren lassen sich die wheels dann aber auch nicht alle, da es unterschiedliche Versions Anforderungen gibt.

Bin da gerade etwas ratlos, was die Anpassungen im Dockerfile von dir angeht kann ich denen leider nicht ganz folgen:

• Requirements wird mittels ADD in den build container namens "base" geladen | RUN curl ist nicht nötig
• das Requirements.txt im Repo dient dazu, dass Dependabot einen PR erstellt, sobald eine neue Version bereitliegt. Da dann auch genau diese Version installiert werden soll, kann es beim Installieren von fhempy ja angegeben werden. Ist vom Prinzip auch nichts anderes als fhempy==${FHEMPY_V}

from fhempy-docker.

...kann ich denen leider nicht ganz folgen

Beide Requirements.txt lade ich nur in die Ausführungsschicht, um dann pip darüber laufen zu lassen.
Ich habe absichtlich ADD/COPY rausgenommen, damit ich in der gleichen Schicht bleibe.

RUN curl https://raw.githubusercontent.com/fhempy/fhempy/v${FHEMPY_V}/requirements.txt --silent --output requirements.txt &&\
    pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt &&\
    rm requirements.txt

es ist alles im gleichen RUN-Abschnitt. Sowie der Abschnitt verlassen wird, landet das Ergebnis im Image. Deswegen lade ich die Requirement-Datei (dafür das curl), führe pip aus und lösche die Datei gleich wieder. Sind nur ein paar kB, aber so ist es dann später keine requirements.txt im Image ;-) Und ich spare mir, die Datei vorher lokal runter zu laden.
Man kann die Datei auch mit COPY oder ADD reinschieben und dann später mit RUN rm requirements.txt wieder rausnehmen. Ist eigentlich nur ein optisches Ding. Ich versuche immer, Dockerfiles auf so wenig Befehle wie möglich zu reduzieren.

Ich habe versucht die wheels für arm zu bauen, nach 5h Laufzeit kam es zu einem Fehler.

5h Laufzeit? Wow, ich dachte schon, bei mir läuft was schief, weil der so lange braucht...
Die Emulatoren sind echt langsam. Gebaut wird bei mir auf einem amd64. Der build dauert da für amd64 keine 5 Minuten. Sowie ich die anderen Architekturen zuschalte, brauchen die emulierten Umgebungen fast 2 Stunden nur um crypto mit pip zu bauen. Am längsten braucht arm/v7. Der Rest des builds geht dann wieder recht schnell.

Das Problem ist, es sind etliche Abhängigkeiten die in der requirements.txt von FHEMPY fehlen nötig, ...

Dann sollte ich wohl besser auf die requirements.txt umstellen, falls da Anpassungen kommen. ;-)

from fhempy-docker.

es ist alles im gleichen RUN-Abschnitt. Sowie der Abschnitt verlassen wird, landet das Ergebnis im Image. Deswegen lade ich die Requirement-Datei (dafür das curl), führe pip aus und lösche die Datei gleich wieder. Sind nur ein paar kB, aber so ist es dann später keine requirements.txt im Image ;-) Und ich spare mir, die Datei vorher lokal runter zu laden.
Man kann die Datei auch mit COPY oder ADD reinschieben und dann später mit RUN rm requirements.txt wieder rausnehmen. Ist eigentlich nur ein optisches Ding. Ich versuche immer, Dockerfiles auf so wenig Befehle wie möglich zu reduzieren.

Du brauchst das vorher nicht lokal laden, das macht doch der ADD Befehl schon: :-)
ADD https://raw.githubusercontent.com/fhempy/fhempy/v${FHEMPY_V}/requirements.txt /

Und die Datei landet auch nicht im runtime image, sondern nur im base image. Beide Varianten sind aber natürlich möglich. Das gibt sich vom Prinzip her nichts. Ist halt so nur ein Befehl gewesen um an die Datei zu kommen.

Ich habe versucht die wheels für arm zu bauen, nach 5h Laufzeit kam es zu einem Fehler.

5h Laufzeit? Wow, ich dachte schon, bei mir läuft was schief, weil der so lange braucht... Die Emulatoren sind echt langsam. Gebaut wird bei mir auf einem amd64. Der build dauert da für amd64 keine 5 Minuten. Sowie ich die anderen Architekturen zuschalte, brauchen die emulierten Umgebungen fast 2 Stunden nur um crypto mit pip zu bauen. Am längsten braucht arm/v7. Der Rest des builds geht dann wieder recht schnell.

Ja, nach 5h gab es irgend einen Fehler. Keine Ahnung bei welchem Paket. Vielleicht war auch die Laufzeit zu lange.
Hier ist er ausgestiegen:
https://github.com/fhem/fhempy-docker/actions/runs/3258804011/jobs/5351166357#step:14:3681

Ich habe schon überlegt, ob sich das parallelisieren lässt um dann jedes wheel einzeln als artifact oder in einem Release abspeichern. Bei 5h Wartezeit bis zu einem Fehler vergeht mir leider die Lust ein wenig und im Moment weiss ich nicht, welches Paket das problembehaftete ist.

from fhempy-docker.

Ich habe mich durchgerungen und eine Matrix aufgebaut:
https://github.com/fhem/fhempy-docker/actions/runs/3298772875

Das war schon ein frickeln schlechthin, nur um noch zu lernen dass es auch noch in Unterverzeichnissen weitere Abhängigkeiten geben kann. In der Theorie brauchts ja für jeden Job der generiert wird nur das das passende build kommando.. naja sollte sich kopieren lassen.

from fhempy-docker.

@OiledAmoeba

Sodele, für das Modul google_weather habe ich einen lauffähigen Container (für zwei AMD64 und ARM) erstellt:
https://github.com/fhem/fhempy-docker/actions/runs/3304324934/jobs/5453563233

• Zuerst werden die requirements von fhempy als wheel gebaut. Natürlich für beide Architekturen. Das erschien mir vorteilhaft, damit anzufangen, da dann schon das cryptography teil gebaut ist, was sonst später mehrfach passieren würde.
• Dann werden die nötigen requirements aus dem fhempy_modulen eruiert.
• Für jedes Modul gibt es dann einen eigenen job um diese als wheel zu bauen. (das geht teilweise parallel) ist aber trotzdem aufreibend. Mit allen habe ich es auch noch nicht durchlaufen lassen. Irgendwo hat aber mal cmake gefehlt ;)
• Wenn dann alle wheels durch sind und noch ein paar Zaubertricks angewendet wurden, wird endlich das image gebaut indem fhempy installiert wird. Dort liegen dann alle gebauten wheels für die jeweilige Architektur mit drinnen, sind aber nicht installiert.
  Was mich hier gewundert hat, es gibt scheinbar wheels, die lassen sich trotzdem nicht ohne compiler installieren. Also brauchts im fhempy image am Ende doch gewisse build-tools.

Alles was in dem im image integrierten wheel repository liegt, kann durch fhempy nun zur Laufzeit installiert werden. Andere wheels funktionieren nicht.
Prinzipiell könnte auch schon im build des Images wheels vorinstallieren. Mit allen wird das aber nicht klappen. Ein Ansatz könnte sein, die zu installieren, die von mehr als einem Modul verwendet werden. Das erspart einem dann halt das installieren zur Laufzeit, nachdem ein container neu generiert wurde.

Alternativ, könnte man auch für jedes Modul ein eigenes Image machen. Allerdings müssten dann für jedes Modul auch ein eigener fhempy container laufen. Keine Ahnung, wie viel Module da so im Schnitt zum Einsatz kommen :)
Über builds zur Laufzeit, die das passende an Module zusammen konfektionieren habe ich noch nicht nachgedacht. Auch wären natürlich Gruppen an Modulen denkbar.

from fhempy-docker.

mit https://github.com/fhem/fhempy-docker/releases/tag/v1.4.0-beta.1 wird armv7 und amd64 gebaut.

from fhempy-docker.