I want to host aspnet 6.0 application in docker container on AlmaLinux (or any centos compatible destro). The application also needs to have maprdrill odbc client that is available only in rpm package. Problem is the base images Microsoft provides are based on debian, alpine and ubuntu only (see here) and none of them let me install rpm package.
I also tried to convert the rpm to deb using alien, conversion was success and package was installed but due to some unknown reason the installation created a layer of 400mb that takes only 80mb on centos and the client appears to not work as well.
What other options I've to install rpm package in aspnet 6 app docker image?
Here is my docker file that understandably fails on line 29:
# base
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# build
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["HelloWorld/HelloWorld.csproj", "HelloWorld/"]
RUN dotnet restore "HelloWorld/HelloWorld.csproj"
COPY . .
WORKDIR "/src/HelloWorld"
RUN dotnet build "HelloWorld.csproj" -c Release -r rhel-x64 --self-contained false -o /app/build
# publish
FROM build AS publish
RUN dotnet publish "HelloWorld.csproj" -c Release -r rhel-x64 --self-contained false -o /app/publish
FROM base AS final
RUN apt update
WORKDIR /app
COPY --from=publish /app/publish .
WORKDIR /mapr
RUN apt-get -yq install wget
RUN wget http://package.mapr.com/tools/MapR-ODBC/MapR_Drill/MapRDrill_odbc_v1.5.1.1002/maprdrill-1.5.1.1002-1.el7.x86_64.rpm
RUN rpm -i maprdrill-1.5.1.1002-1.el7.x86_64.rpm
ENTRYPOINT ["dotnet", "HelloWorld.dll"]
Related
Since container is not building with the full project I commented docker file as bellow . then I executed manually dotnet build command inside container. it failed like below. But when I build the container from outside from the visual studio it is building fine.
Determining projects to restore...
All projects are up-to-date for restore.
myapp -> /app/build/myapp.dll
myapp -> /app/build/myapp.Views.dll
/bin/sh: 2: /tmp/tmped91456469694a38bc5ed8e7d4b423b1.exec.cmd: docker: not found
/root/.nuget/packages/microsoft.visualstudio.azure.containers.tools.targets/1.11.1/build/Container.targets(97,5): error : Docker is not installed or is not in the current PATH. [/src/myapp/myapp.csproj]
Build FAILED.
/root/.nuget/packages/microsoft.visualstudio.azure.containers.tools.targets/1.11.1/build/Container.targets(97,5): error : Docker is not installed or is not in the current PATH. [/src/myapp/myapp.csproj]
0 Warning(s)
1 Error(s)
Here is the my Dockerfile
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
RUN apt-get update && \
apt-get install -y wget && \
apt-get install -y gnupg2 && \
wget -qO- https://deb.nodesource.com/setup_16.x | bash - && \
apt-get install -y build-essential nodejs
COPY ["myapp/myapp.csproj", "myapp/"]
COPY ["myapp/NuGet.Config", "myapp/"]
RUN dotnet restore "myapp/myapp.csproj" --configfile myapp/NuGet.Config
COPY . .
WORKDIR "/src/myapp"
#RUN dotnet build "myapp.csproj" -c Release -o /app/build
#FROM build AS publish
#RUN dotnet publish "myapp.csproj" -c Release -o /app/publish
#FROM base AS final
#WORKDIR /app
#COPY --from=publish /app/publish .
#ENTRYPOINT ["dotnet", "myapp.dll"]
ENTRYPOINT ["tail", "-f", "/dev/null"]
Here is a Dockerfile and I wonder why with a slight change in C# code rebuilding the image takes a lot of time compared to Python. I read all tips and still no chance. Is there a way to improve it?
Dockerfile:
FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base
RUN apt-get update && apt-get install -y libldap-2.4-2
RUN apt-get install curl -y
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build
WORKDIR /src
COPY ["test/testAdmin.csproj", "test/"]
COPY ["testDal/testDal.csproj", "testDal/"]
COPY ["testCore/testCore.csproj", "testCore/"]
RUN dotnet restore "test/testAdmin.csproj"
COPY . .
WORKDIR "/src/testAdmin"
RUN pwd
RUN ls
RUN mv appsettings.json appsettings.json
RUN dotnet build "testAdmin.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "testAdmin.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "testAdmin.dll"]
For production environment this is OK but for testing we need faster builds for every pull.
I am working on implementing a solution for a sonar scanner inside a docker container for the .net core application in azure DevOps.
Currently, the sonarqube installed was on a sonarqube namespace in the AKS cluster and our dot net application is containerized in a different namespace in the same cluster. I'm struggling with the following error: The temporary analysis directory (usually .sonarqube) doesn't exist. The "begin" step was probably not executed. Is there any sample or working Docker file which implements this type of logic? I tried to follow the steps described in this blog post but the result is the same.
Here is my Dockerfile:
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
RUN apt-get update && apt-get install -y openjdk-11-jdk
RUN dotnet tool install --global dotnet-sonarscanner
RUN dotnet tool install --global dotnet-reportgenerator-globaltool
RUN dotnet tool install --global coverlet.console
## Set the dotnet tools folder in the PATH env variable
ENV PATH="$PATH:/root/.dotnet/tools"
## Start scanner
RUN dotnet sonarscanner begin \
/k:"my-token" \
/o:"my-org" \
/d:sonar.host.url="sonar-host" \
/d:sonar.login="sonar-token" \
/d:sonar.cs.opencover.reportsPaths=/coverage.opencover.xml
COPY my-project/*.csproj ./my-project/
COPY . .
WORKDIR /src/my-project
RUN dotnet restore
RUN dotnet build -c Release -o /app/build --no-restore
RUN dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput="/coverage"
## Stop scanner
RUN dotnet sonarscanner end /d:sonar.login="sonar-token"
FROM build AS publish
WORKDIR /src/my-project
RUN dotnet publish -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "my-project.dll"]
I believe your issue may be running dotnet restore after the sonarscanner begin. If you re-arrange those steps, you should be OK.
I'm trying to connect my .net core application, hosted on a unix docker container to an external Vertica database.
It works fine when it's a windows client because there are Vertica Drivers for Windows. But there isn't a unix driver for Vertica under unix.
When I try to run a Query against Vertica I get the following error:
Dependency unixODBC with minimum version 2.3.1 is required. Unable to
load shared library 'libodbc.so.2' or one of its dependencies. In
order to help diagnose loading problems, consider setting the LD_DEBUG
environment variable: liblibodbc.so.2.so:
My docker file looks like this
FROM microsoft/dotnet:sdk AS build-env
WORKDIR /app
ARG DEBIAN_FRONTEND=noninteractive
# Copy csproj and restore as distinct layers
COPY ./*.sln ./
COPY ./MyApp/*.csproj ./MyApp/
RUN dotnet restore MyApp.sln
COPY . ./
RUN dotnet publish MyApp.sln -c Release -f=netcoreapp2.1 -o out
RUN cp /app/MyApp/*.yml /app/MyApp/out
RUN cp /app/*.ini /app/VMyApp/out
#ODBC
FROM microsoft/dotnet:aspnetcore-runtime
RUN apt-get update
RUN apt-get install -y apt-utils
RUN curl -O -k https://www.vertica.com/client_drivers/9.1.x/9.1.1-0/vertica-client-9.1.1-0.x86_64.tar.gz
RUN tar vzxf vertica-client-9.1.1-0.x86_64.tar.gz && rm vertica-client-9.1.1-0.x86_64.tar.gz
RUN apt-get install -y unixodbc-dev
ADD odbc.ini /root/odbc.ini
ADD odbcinst.ini /root/odbcinst.ini
ADD vertica.ini /root/vertica.ini
ENV VERTICAINI=/root/vertica.ini
ENV ODBCINI=/root/odbc.ini
RUN echo "$VERTICAINI $ODBCINI"
WORKDIR /app
COPY --from=build-env /app/MyApp/out .
ENTRYPOINT ["dotnet", "MyApp.dll"]
I'm using a containerized ASP.Net Core (2.1) app. The container is running Debian Stretch. Everything is working fine except this one small detail - whenever I want to use Rotativa I get this message:
Unable to find view '/app/wwwroot/templates/IssuedInvoice.cshtml'. The following locations were searched:\n/app/wwwroot/templates/IssuedInvoice.cshtml
That would very probably mean that file does not exist. Fair enough, I go into the docker container and issue cat /app/wwwroot/templates/IssuedInvoice.cshtml and what do I find? The file is listed without any errors.
Have anyone encountered such problem? I don't think that's a permission issue since the app runs inside the container as root anyway.
I have tested this outside of the container and everything works fine, same on Debug and Release configurations.
Dockerfile
FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["JTEPanel.Api/JTEPanel.Api.csproj", "JTEPanel.Api/"]
COPY ["JTEPanel.Infrastructure/JTEPanel.Infrastructure.csproj", "JTEPanel.Infrastructure/"]
COPY ["JTEPanel.SmsApi/JTEPanel.SmsApi.csproj", "JTEPanel.SmsApi/"]
COPY ["JTEPanel.Domain/JTEPanel.Domain.csproj", "JTEPanel.Domain/"]
COPY ["JTEPanel.Common/JTEPanel.Common.csproj", "JTEPanel.Common/"]
RUN dotnet restore "JTEPanel.Api/JTEPanel.Api.csproj"
COPY . .
WORKDIR "/src/JTEPanel.Api"
RUN dotnet build "JTEPanel.Api.csproj" -c Release -o /app
FROM build AS publish
RUN dotnet publish "JTEPanel.Api.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
VOLUME /app/wwwroot
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y locales libgdiplus wkhtmltopdf
RUN ln -s /usr/bin/wkhtmltopdf /app/wwwroot/Rotativa/wkhtmltopdf
RUN sed -i -e 's/# pl_PL.UTF-8 UTF-8/pl_PL.UTF-8 UTF-8/' /etc/locale.gen && \
dpkg-reconfigure --frontend=noninteractive locales && \
update-locale LANG=pl_PL.UTF-8
ENV LANG pl_PL.UTF-8
ENTRYPOINT ["dotnet", "JTEPanel.Api.dll"]