Closed milkyware closed 2 years ago
Hi, docker build was failing when not explicitly mentioning amd64 due to an error in the dotnet tooling. That's why it was reverted to amd64. However, both arm images should be generated I think. However I have not tested either. Please check if you are getting the right image. Will try to find if docker build works now and update you.
Hi, well when you compare the current docker files e.g. Dockerfile-elsa-dashboard-and-server to the ones in 0dd7575a75, prior to the upgrade to .NET 6, the final stage had a base image of mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim, without the amd64 specific tag. In terms of using the right image, I'm using elsaworkflows/elsa-dashboard-and-server:latest which docker should then work out which platform to download and run. I'll rebuild an image without the amd64 in the final tag and test.
If need be, we could copy the Dockerfile and change the base image and push both of them. But let's see what @mohdali comes up with.
@MilkyWare when trying to build using sdk:6.0-bullseye-slim
I get the below error. This is the same error I was facing earlier and couldn't figure out the reason as it looks like a problem with the dotnet image itself.
Do you know any solution for this? I don't use arm myself so couldn't test further.
=> ERROR [linux/arm/v7 build 7/10] RUN dotnet restore "./src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith/ElsaDashboard.Samples.AspNetCore.Monolith.csproj" --configfile ./Nuget.Config 2.3s
------
> [linux/arm/v7 build 7/10] RUN dotnet restore "./src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith/ElsaDashboard.Samples.AspNetCore.Monolith.csproj" --configfile ./Nuget.Config:
#0 1.585 A fatal error occurred, the folder [/usr/share/dotnet/host/fxr] does not contain any version-numbered child folders
------
Dockerfile-elsa-dashboard-and-server:22
--------------------
20 | COPY --from=client-build /app/designer/bindings/aspnet/Elsa.Designer.Components.Web ./src/designer/bindings/aspnet/Elsa.Designer.Components.Web
21 | COPY *.props ./
22 | >>> RUN dotnet restore "./src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith/ElsaDashboard.Samples.AspNetCore.Monolith.csproj" --configfile ./Nuget.Config
23 |
24 | # build and publish (UseAppHost=false creates platform independent binaries)
--------------------
error: failed to solve: process "/bin/sh -c dotnet restore \"./src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith/ElsaDashboard.Samples.AspNetCore.Monolith.csproj\" --configfile ./Nuget.Config" did not complete successfully: exit code: 131
For reference, below is the dockerfile and build command. I believe this is the same command used by the the github action. It takes around one hour to build as it is building all three images.
FROM node:17-alpine as client-build
WORKDIR /app
COPY /src .
WORKDIR /app/designer/elsa-workflows-studio
RUN npm install --force
RUN npm run build
WORKDIR /app/designer/bindings/aspnet/Elsa.Designer.Components.Web
RUN npm install --force
RUN npm run build
FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim AS build
WORKDIR /source
# restore packages
COPY ./Nuget.Config ./
COPY src/. ./src
COPY --from=client-build /app/designer/bindings/aspnet/Elsa.Designer.Components.Web ./src/designer/bindings/aspnet/Elsa.Designer.Components.Web
COPY *.props ./
RUN dotnet restore "./src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith/ElsaDashboard.Samples.AspNetCore.Monolith.csproj" --configfile ./Nuget.Config
# build and publish (UseAppHost=false creates platform independent binaries)
WORKDIR /source/src/samples/dashboard/aspnetcore/ElsaDashboard.Samples.AspNetCore.Monolith
RUN dotnet build "ElsaDashboard.Samples.AspNetCore.Monolith.csproj" -c Release -o /app/build
RUN dotnet publish "ElsaDashboard.Samples.AspNetCore.Monolith.csproj" -c Release -o /app/publish /p:UseAppHost=false --no-restore -f net6.0
# move binaries into smaller base image
FROM mcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slim AS base
WORKDIR /app
COPY --from=build /app/publish ./
EXPOSE 80/tcp
EXPOSE 443/tcp
ENTRYPOINT ["dotnet", "ElsaDashboard.Samples.AspNetCore.Monolith.dll"]
docker buildx build -t elsa-dashboard-and-server:local -f ./docker/Dockerfile-elsa-dashboard-and-server --platform linux/amd64,linux/arm64,linux/arm/v7 .
Hi, I suggest the first bullseye image is left as mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim-amd64 as that stage is only used for building libraries and then thrown away once the libraries are copied to the mcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slim stage. The result is that the actual image that runs supports all the platforms. The image below is from 0dd7575, line 14 uses amd64, whereas the last image, line 30, uses the generic version. I've tweaked these tags in a branch and built and published an image to milkyware/elsa-dashboard-and-server which seems to work on my Pi and my laptop. I'll raise a PR so you can see the changes
Hi @mohdali, just around your question of the ARM error, I've seen it a couple of times but I've not come across why it does it. However, the workaround/solution I've suggested is the same as suggested here where the build stage uses an amd64 specific image, but the final/running stage uses the generic version
Hi @mohdali, just around your question of the ARM error, I've seen it a couple of times but I've not come across why it does it. However, the workaround/solution I've suggested is the same as suggested here where the build stage uses an amd64 specific image, but the final/running stage uses the generic version
Thanks! I checked with your fix and it builds fine. Good to hear you are able to run it on arm as well. I was wondering for a while if anyone is using Elsa on Arm and I'm interested to know more of the use cases.
No worries @mohdali. Personally I use it mainly for a bit a of a personal cloud at home, hosting my projects on a clustered docker swarm (same would be possible with kubernetes) which is quite cheap to run and scale. However, the area that would be interesting is that AWS have very competitive pricing for their ARM based graviton EC2s compared to traditional x86 servers.
Thanks @sfmskywalker @mohdali for your assistance
Hi,
Just updating my docker containers to latest and noticed they don't start up on my RPi with an error of
exec /usr/bin/dotnet: exec format error
. I noticed in commit aad15cb the base image was updated to point directly at the amd64 image. Just wondering if there was a reason, and if not if I could raise a PR to revert?Many Thanks Cameron