CrashLoopBackOff when trying to run .Net Applications in AKS cluster accross 2 pods - asp.net

Apologies from the start but please bear with me, I am still rather novice at this so if you see any issues glaringly obvious, please forgive me.
I am working at a company where some devs are trying to have us deploy some .NET Core applications to containers in Azure Kubernetes Service (AKS). From my understanding, they have been written in .NET Core 3.1. The goal is to run this process using a CI/CD Azure Pipeline, using Azure Repos as repository, using a build pipeline to create the docker image, push image to our Azure Container Registry and create an artifact for the release pipeline to then deploy (using helm) contianers into the AKS.
File Structure is as follows:
Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
COPY ["AppFolder1\App.csproj", "."]
RUN dotnet restore "AppFolder1\App.csproj"
COPY . .
RUN dotnet build "AppFolder1\App.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "AppFolder1\App.csproj" -c Release -o /app/publish
FROM base AS final
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DotNet.Docker.dll"]
ERROR
Question: Could there be an issue with 6.0 sdk when trying to deploy app made with .net core 3.1?
running "kubectl get pods -n redacted-namespace"
a) retrieves two pods with CrashLoopBackOff Status showing 9 restarts
running "kubectl define pod -n redacted-namespace" retrieves information on pods
a) both pods show successful pod scheduling - Successfully assigned redacted-namespace/ to aks-nodepool1-02 AND aks-nodepool1-00
b) Both show multiple successful pull of image
c) Both show creation of container and start of container
d) End message:
Warning BackOff 58s (x117 over 26m) kubelet Back-off restarting failed container
--ATTEMPTS TO SOLVE--
It was suggested that the Dockerfile was to blame. Spent time creating and running pipeline with multiple iterations of dockerfile, including changing .net versioning to 3.1 from 6.0. No successful pipelines using these dockerfiles yet.
running kubectl logs <pod-name> -n redacted-namespace:
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'DotNet.Docker.dll' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I had figured that the installation of the .NET SDK should have been handled by the dockerfile line 1, however it doesn't seem to be working properly. In the meantime, adding in pipeline release Agent Task Use .NET Core sdk 6.0 and deleting previous pods to try again.
Re-running pipeline release - No effect. Likely .NET Core SDK install agent task does not work inside of each pod and is therefore not available as an installed resource within pods and replicas.

Apparently there were TWO problems with the Dockerfile. The first and foremost, #Hans Kilian, you're absolutely right. Apparently they were using .NET 3.1. The other issue was the ENDPOINT I had set up was not pointing to the right .dll file. This I found by going to Solutions/App.sln and pulled the name from the Project line (something like Project("################################")= "Project_name"... Its working and running just fine now. Thank you!

Related

How Can I create Dockerfile that install dotnet sdk for existing jenkins container

I'm absolutely new in Docker and Jenkins in addition that I am sophomore at software world. Firstly, I would like to describe our system. We are using Centos 7 and I installed Jenkins on Docker as a container. After that I have tried using the Dotnet commands such as dotnet build on Jenkins, but I faced some errors(" dotnet: not found "). I guess I must install dotnet sdk for jenkins on docker by using Dockerfile. But I could not create Dockerfile properly. I got always some error. Can you share Dockerfile or similar issue for me.
After a quick search i have found this Dockerfile and also this post
This could do for you. I think you should be able to salvage useful bits for yourself.
But if there is an option id recommend your Jenkins agent just run the docker build of the dedicated .net core container through the docker socket? (as an idea of course). For reference

Containerrizing Hosted Blazor WebAssembly for Raspberry Pi Docker Swarm

I’m developing a DotNet Core hosted Blazor WebAssembly, as a frontend to my backend ASPNet Core API, running on Raspberry Pi’s, containerised in a Docker Swarm.
I’m developing on a MacBook Pro, using VSCode for Mac, and it’s really a great tool. I created the solution as “dotnet new blazorwasm —hosted” and got the solution created and build.
I have installed Docker Desktop, and created a Buildx builder for arm, which works great with all my other solutions (DotNet Core API, DotNet Background solutions), but with the hosted blazorwasm solution, I run into several problems, probably caused by my lacking knowledge on setting up build options.
So I installed Visual Studio 2019 (I have used VS on Windows for 20 years) and was actually surprised over the look and feel, a really great tool.
I created the hosted Blazor WebAssembly solution, which works great om Mac, and even the Docker desktop integration work without problems.
Building the Docker Image was easy, I just used my Buildx builder, and executed below command from the command line:
“docker buildx build --file ./SnakeConsole/Server/Dockerfile --platform linux/arm/v7 -t jagdriver/wavesnake:SnakeConsole3 --push .”
On the Raspberry Swarm, I then created the Stack/Container. The Stack installed but the container refused to start, and the log was:
standard_init_linux.go:211: exec user process caused “exec format error”.
I have seen this error before, and as far as I remember I added “-r ubuntu.19.10-arm” to the dotnet publish command to ensure that the code is generated for linux-arm.
So I tried to add “-r ubuntu.19.10-arm” to the dotnet publish command in below dockerfile, and execute the Docker buildx build command again, but then the Build Engine run into below error.
project.assets.json' doesn't have a target for '.NETCoreApp,Version=v5.0/browser-wasm'. Ensure that restore has run and that you have included 'net5.0' in the TargetFrameworks for your project. You may also need to include 'browser-wasm' in your project's RuntimeIdentifiers
Can anyone out the give me a helping hand on this, thanks in advance.
FACTS:
The solution I’m mentioning is the standard Hosted Blazor
WebAssembly template without any changes.
The target framework is .Net 5.0
Visual Studio for Mac community is version 8.7.2 (build 4)
Docker file from the default hosted Blazor WebAssembly template.
FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build
WORKDIR /src
COPY SnakeConsole/Server/SnakeConsole.Server.csproj SnakeConsole/Server/
COPY SnakeConsole/Client/SnakeConsole.Client.csproj SnakeConsole/Client/
COPY SnakeConsole/Shared/SnakeConsole.Shared.csproj SnakeConsole/Shared/
RUN dotnet restore "SnakeConsole/Server/SnakeConsole.Server.csproj"
COPY . .
WORKDIR "/src/SnakeConsole/Server"
RUN dotnet build "SnakeConsole.Server.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "SnakeConsole.Server.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "SnakeConsole.Server.dll"]
Have faced similar issue, documentation says:
Deploying a standalone Blazor WebAssembly app to Azure App Service for Linux isn't currently supported. A Linux server image to host the app isn't available at this time. Work is in progress to enable this scenario.
https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0#standalone-deployment
Looks like this is a Docker OS compatibility and framework functionality issue. I would suggest to target your app to Server (Blazor Server Hosting model scenario).

Access linux-hosted ASP.NET Core 2.x webapp (without nginx)

My ASP.NET Core 2.1 webapp works perfectly on my dev setup. Now I want to test it in production.
The production server is Ubuntu 18. I followed the instructions. I don't want to setup nginx yet, just do some quick tests, and the instructions say:
"Either configuration—with or without a reverse proxy server—is a valid and supported hosting configuration for ASP.NET Core 2.0 or later apps".
So I built and published my project: dotnet publish --configuration Release.
Then on the server:
install the dotnet runtime
copied files to server (/var/www/myapp)
opened ports: sudo uwf allow 5000/tcp 80/tcp
run dotnet MyApp.dll (also tried sudo dotnet MyApp.dll)
It runs without errors/warnings, and says it's listening on http://localhost:5000.
On my local machine I tried http://serveripaddress (and http://serveripaddress:5000) but get nothing ("can't connect"). I can access that server with ssh, sftp, etc - only http isn't working.
What am I doing wrong?
the host default bind is 127.0.0.1 , so you can only access the app locally. if you want to access it from Network, please add --urls parameter. for example :
for development, you can run:
dotnet run --urls http://0.0.0.0:5000
and for deployed project, you can run:
dotnet MyApp.dll --urls http://0.0.0.0:5000
The dotnet core sdk I use is version 2.1.400.
Found the problem. I needed to use:
ASPNETCORE_URLS="http://0.0.0.0:5000" sudo dotnet MyApp.dll
Then it logs Now listening on: http://0.0.0.0:5000. And I can access that from a remote client.

ASP.NET Core 2.1 Preview 2 App Not working on Azure App Service

I've been running my ASP.NET Core 2.1 Preview-1 app on Azure since this release became available. I had installed the ASP.NET Core runtime extensions through the portal and it's been working fine.
Now that Microsoft released ASP.NET Core 2.1 Preview-2, I installed the upgrade to the SDK. Updated my Nuget packages so that I have the preview-2 versions of everything. See my csproj file below:
I also removed the ASP.NET Core Runtime extensions from Azure App Service for my app which was showing 2.1 Preview-1. Instead installed ASP.NET Core 2.1 run times for x86 and x64 separately -- see below:
Compiled the app and published it to my Azure App service but I'm getting errors. First I got the 502.5 error. Now, I'm getting:
The specified CGI application encountered an error and the server
terminated the process.
What am I missing here?
UPDATE:
As the answer suggested, I set my target to x86 (to play it safe) -- see below:
I removed the extension and the individual x86 and x64 run times and installed only the x86 with support for ASP.NET Core 2.1 preview-2 -- see below:
I restarted the app several times and I'm still getting 502.5.
I then tried to do a self deploy through CLI command line by issuing the following command:
dotnet publish -c Release -r win10-x64
And I get the following error:
C:\Program
Files\dotnet\sdk\2.1.300-preview2-008530\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(125,5):
error : The RuntimeIdentifier platform 'win10-x64' and the
PlatformTarget 'x86' must be compatible.
Does this mean I have the x86 version of the SDK installed and I must target x86?
I didn't have half the trouble that I'm going through now going from ASP.NET Core 2.0 to 2.1!!!!
UPDATE 2:
Just ran dotnet --info in Kudu console. If I'm reading this correctly, I don't have the correct runtime.
Update 3:
I think this screen shot confirms what I was saying.
Update 4:
I installed x86 version of ASP.NET Core 2.1 Runtime -- see below:
When I run dotnet --info in Kudu console, I get the following which confuses me. I'm still not seeing the version I was expecting to see:
And when I hit the URL, I'm still getting 502.5 and the same message in Kudu console when I run dotnet MyApp.dll telling me that the correct version of the runtime is not found.
How will I get the correct version in there? I thought installing it through the portal would do it.
We've managed to publish ASP.NET Core 2.1 RC1 webapp to Azure app-service using "self-contained" deployment mode.
Platform target: Any CPU
Here are the package references from our .csproj:
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="2.1.0-rc1-final" PrivateAssets="All" />
<PackageReference Include="Microsoft.AspNetCore.AzureAppServicesIntegration" Version="2.1.0-rc1-final" />
The steps I took to get this working:
Remove the 2.1-preview1 ASP.NET Core Runtime Extension.
Check the application settings to see if you're running under 32-bit or 64-bit.
Install only the matching (32- or 64-bit) ASP.NET Core 2.1 Runtime.
Restart the web app.
Restarting is important - before restarting the .NET Core tools were the wrong version and I would also get 502.5 errors.
As you've installed both 32- and 64-bit runtimes I'd try removing the one that your application doesn't need and restart the web app.
I had the same problem. Finally after 2 hours I fixed it.
Here is my configuration:
Extensions:
Console dotnet --info command:
Console kudu dotnet --version command:
a) Remember to restart your app after install extension.
b) Clear your wwwroot folder from old files and publish again.
I got my project working on asp.net core 2.1 Preview 2 on Azure.
I did the following steps;
Deleted the old asp.net core extension from Azure app service Extension
Using kudus deleted all the files in wwwroot folder of the site.
Installed asp.net core site extension from Azure as shown in the picture below and restarted the app service
Before deploying to Azure, the publish configuration option used is as depicted in the picture below,
That's it.
Try adding a global.json file in your project folder with this content:
{
"sdk": {
"version": "2.1.300-preview2-008530"
}
}
Restart your app after that to be on the safe side.
Here's the only thing that seems to have worked for me.
I did a self-contained deployment using
dotnet publish --self-contained -r win10-x64 -c Release
I then had to do a manual deployment -- in my case using FTP.
I really would like this issue to be resolved but if it's not resolved by my next deployment, I'll do the zip deploy. Because my app has a ReactJs frontend, there were thousands of files to deploy and FTP was not a lot of fun!
Because this approach doesn't depend on what's installed or not installed on Azure App Service, it's a much more straight forward solution.
I still want to be able to simply click Publish in Visual Studio though!
UPDATE:
I just did a zip deployment and I'm still getting the errors I was getting before even though zip deployment was successful. So, something is still not right!
I had a problem with a complex website, so I created a simple one with just the App file set at the same version:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />
</ItemGroup>
and then, taken from Tim Diekmann's example, I did nothing apart from changing the Deployment Mode in the Azure publishing configuration Settings to Self-Contained - and that worked.

How do I git deploy an .fsproj based f# project to azure?

I have an ASP.NET core application that I've been auto-deploying to an azure app service on commit to a git repo. It worked fine as a project.json type project.
I've converted my project.json to myproject.fsproj and it builds and runs locally. On comitting the .fsproj to git, the deployment was triggered, but it failed with the activity log containing one line: 'D:\home\site\repository\myproject.fsproj' is not a deployable project.
I guess it's an issue with the default kudu deployment script? Does anyone know how to sort this out, or do I need to submit an issue/RFC to the kudu guys?
UPDATE
I generated the original .fsproj using:
dotnet new mvc --language f# --framework netcoreapp1.0
I've since made changes to it, so I will try to do a minimal case later tonight.
Turns out that the default deployment in azure wouldn't deal with this.
Following the answer on Kudu Deployment Script for ASP.NET Core 1.0, I generated a custom deployment script using:
npm install -g kuduscript
kuduscript -y --aspNetCore myproject.fsproj
Added the resulting deploy.cmd along with a .deployment:
[config]
command = deploy.cmd
A deployment triggered by a push to git works as expected now.

Resources