On previous articles I have explained how you can install an azure devops agent on the operating system in order to create your self hosted agent pools for your projects.
Windows installation example:
Mac OS X installation example:
But what if you need to create multiple agents inside a virtual machine? The best solution would be to use docker virtualization and separate those agents from each other. We will now examine how we can host our azure devops agents on containers.
The first thing that you will need is a virtual machine that runs docker. When this requirement is fulfilled you can jump on the image building. In order to build your image you will need your Dockerfile and the instructions for the agent.
You can read the rest of the article on Medium using the link below:
A detailed deployment video can be found on my Udemy course:
When you build your application with cloud native technologies you will build microservices on containers instead of monolithic applications. We will now examine how easy is to build a .NET application in a container and run this application on your local machine.
First we will need to create the visual studio solution. I will go through that with visual studio IDE and then I will use vs code. For my microservice I am using a ASP .NET Core web api with default code.
The target framework for the solution will be the latest .NET framework which is version 7. All other settings will be set to defaults.
When you run the app locally with IIsExpress you will be able to access the swagger interface through the port which you defined in the launchSettings.json.
This file can be located under Properties and there you can configure on which port the application will run. In the profiles section under https settings, you can find the default application URL and port. This will be needed in later steps.
Microsoft provides the below documentation in order to create a containerized application that runs on .NET
In order to create a microservice based on our vs solution we will need a dockerfile. This can be created automatically with vs code.
In vs code command dialog search for docker add and select docker compose files to workspace.
Then select asp net core.
and after that your operating system. The next step will be to select the exposed port, or otherwise under which port your application will run. There we should provide the port that we found under our launchSettings.json or the one that we configured manually. In my case I will select the default one for the solution which was 7057.
When a popup window appears on the screen you should select add Dockerfile and automatically the build files will be generated.
Dockerfile
Based on my setup I altered two things in the generated Dockerfile. The first thing will be to change configuration to Debug instead of Release. For production environments you will consider using the release build directive. The second thing will be to add an environmental variable ASPNETCORE_ENVIRONMENT inside the container with the value Development.
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base WORKDIR /app EXPOSE 7057
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build WORKDIR /src COPY ["AspNetWebApi.csproj", "./"] RUN dotnet restore "AspNetWebApi.csproj" COPY . . WORKDIR "/src/." RUN dotnet build "AspNetWebApi.csproj" -c Debug -o /app/build
FROM build AS publish RUN dotnet publish "AspNetWebApi.csproj" -c Debug -o /app/publish /p:UseAppHost=false
FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "AspNetWebApi.dll"]
docker build command
after the build is completed and the image is created you can run a new container locally.
Keep in mind that in order to test your container you should create a port forward from the container to your host. I used the same port for the host so I added the -p 7057:7057
The logs of the container indicate a successful run of the application.
Our application now runs as a microservice container inside the host machine (my laptop).
We can verify the access to our application using the URL with the swagger.
PowerShell 7.3 installs to a new directory and runs side-by-side with Windows PowerShell 5.1. PowerShell 7.3 is an in-place upgrade that replaces PowerShell 7.0 and lower.
Error:
error NU1202: Package PowerShell 7.3.0 is not compatible with net6.0 (.NETCoreApp,Version=v6.0) / any. Package PowerShell 7.3.0 supports: net7.0 (.NETCoreApp,Version=v7.0) / any The tool package could not be restored. Tool ‘powershell’ failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the –version option to specify the version. * A package by this name was found, but it was not a .NET tool. * The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem. * You mistyped the name of the tool.
Solution:
In order to resolve the error you should install .NET 7.
In a previous article I explained how you can add python on PATH when you install it on a windows container image.
However if you try to use the python verb immediately you may face a problem that variable is not recognized.
In order to resolve this issue you will have to reload the environmental variables so that change reflects the current powershell session that you use.
By performing the below powershell command you can reload env variables and continue the execution of your scripts with variables reloaded.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy