The .NET application was containerized using Docker to ensure consistency across development and production environments.

A Dockerfile was created at the root of the project directory. This Dockerfile defined a multi-stage build, where the application was built and run in a minimal environment. The build stage involved using the .NET SDK to restore dependencies and publish the application, while the runtime stage used the ASP.NET Core image to run the application.

An example of the Dockerfile is shown below:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build-env
WORKDIR /app

# Copy project files and restore dependencies
COPY *.csproj ./
RUN dotnet restore

# Copy remaining application files and build
COPY . ./
RUN dotnet publish -c Release -o out

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:7.0
WORKDIR /app
COPY --from=build-env /app/out .

# Expose port 80 and run the application
EXPOSE 80
ENTRYPOINT ["dotnet", "MyDotnetApp.dll"]

The image was then built using Docker with the following command:

bashCopy codedocker build -t <MyRegistryURL>:<Port>:latest .

This command created a Docker image tagged as my-dotnet-app:latest, ready to be pushed to a registry.

Setting Up a Private Docker Registry

A private Docker registry was set up to store and manage Docker images, enabling secure access across different servers. Docker’s official Registry 2 image was used to achieve this.

The registry was started with the following command:

bashCopy codedocker run -d -p 5000:5000 --name registry --restart=always registry:2

This command deployed a registry container that listens on port 5000. The --restart=always flag ensured that the registry would restart automatically in case of server restarts or failures.

Afterward, the Docker image created earlier was tagged for the private registry and pushed:

# Tagging the image
docker tag my-dotnet-app:latest localhost:5000/my-dotnet-app:latest

# Pushing the image to the private registry
docker push localhost:5000/my-dotnet-app:latest

The image was successfully stored in the private registry, making it accessible to other servers in the Docker Swarm cluster.

Configuring a Docker Swarm Cluster

A Docker Swarm cluster configuration is essential for deploying the application across multiple servers. Docker Swarm simplifies the orchestration and management of containerized applications by enabling clustering, load balancing, and service discovery.

Step 1: Initialize Docker Swarm

First, one of the servers was chosen as the Swarm Manager, who was responsible for managing the entire cluster. The Swarm was initialized using the following command:

docker swarm init --advertise-addr <manager-ip>

• --advertise-addr specifies the IP address of the manager node so that other nodes can discover and join the swarm.

After running this command, Docker outputs a unique token, which is used to add worker nodes to the swarm.

Step 2: Add Worker Nodes to the Swarm

The remaining two servers were designated as Worker Nodes, which will host the application containers. To join these worker nodes to the swarm, the token from the previous step was used:

docker swarm join --token <swarm-join-token> <manager-ip>:2377

• <swarm-join-token>: The token provided when initializing the swarm on the manager.

• <manager-ip>: The IP address of the swarm manager.

This command connects the worker nodes to the swarm, allowing them to be managed by the Swarm Manager.

To confirm that the nodes had successfully joined the swarm, the following command was run on the manager node:

Copy codedocker node ls

This command lists all the nodes in the swarm and shows their status. The manager node is marked as the leader, and the worker nodes are shown as active members of the swarm.

Installing Git

You can use sudo apt install git it in Debian servers.

Installing Gitlab Task Runner

To run GitLab CI pipelines, GitLab Runner must be installed. GitLab Runner is an application used to run jobs in the GitLab CI/CD pipeline.

1. Add the GitLab Runner Repository
   Add the official GitLab Runner repository to your system:

    curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
   

2. Install GitLab Runner
   After downloading the binary, you need to install the GitLab Runner using the following command:

    sudo apt install gitlab-runner
   

   Verify that GitLab Runner has been installed successfully by checking its version:

    gitlab-runner --version
   

Step 3: Register GitLab Runner

To make GitLab Runner work with GitLab CI pipelines, it needs to be registered with the GitLab instance.

1. Get the GitLab Runner Token
   Go to your GitLab project and navigate to:
   Settings > CI / CD > Runners.
   Here, you’ll find the registration token, which is needed to register the runner.

   

2. Register the Runner
   Run the following command to register the GitLab Runner:

    sudo gitlab-runner register
   

   The system will ask for the following details:

   • GitLab instance URL: e.g., https://gitlab.example.com/

   • Registration token: The token from your GitLab project

   • Description: Name for your runner

   • Tags: Optional tags to identify the runner

   • Executor: Choose the executor to run your jobs (e.g., shell, docker, etc.).

3. Start GitLab Runner
   After registration, the runner service can be started with:

    sudo gitlab-runner start
   

   Setting Up CI/CD Pipeline for Dockerized .NET Applications using GitLab CI

   In modern software development, automating the build, test, and deployment process is crucial for efficiency and reliability. GitLab CI/CD provides a robust pipeline setup for automating these tasks. In this step, a Continuous Integration (CI) and Continuous Deployment (CD) pipeline is described for Dockerized .NET applications using GitLab CI. The setup will build and push Docker images to a private registry, then deploy them using Docker Swarm.

   Pipeline Configuration Overview

   The .gitlab-ci.yml file is the main configuration file used by GitLab CI to define the pipeline stages and scripts to execute. Below is an explanation of the pipeline defined for a Dockerized .NET project.

    image: docker:latest
   
    stages:
      - build
      - deploy
   
    variables:
      REGISTRY_URL: "<your Registry URL>"
      IMAGE_TAG: "<latest image tag>"
   

   • Docker Image: The pipeline uses the docker:latest image, which includes Docker CLI tools for building, pushing, and managing containers.

   • Stages: Two stages are defined—build and deploy.

   • Variables: The REGISTRY_URL specifies the location of the private Docker registry, and IMAGE_TAG defines the version of the images being built and deployed.

Build Stage

The build stage involves compiling the Docker images for two services, the API Gateway and the IVR Service, and pushing them to the private registry.

    build:
      stage: build
      script:
        - docker build -t $REGISTRY_URL/dmn/apigateway:$IMAGE_TAG  APIGateway/DMNMiddleware.APIGateway
        - docker push $REGISTRY_URL/dmn/apigateway:$IMAGE_TAG

        - docker build -t $REGISTRY_URL/dmn/ivrservice:$IMAGE_TAG IVRService/DMNMiddleware.IVRService/
        - docker push $REGISTRY_URL/dmn/ivrservice:$IMAGE_TAG
      tags:
        - dmnmiddleware
      only:
        - master

• Docker Build: Two Docker images are built—one for the API Gateway (APIGateway/DMNMiddleware.APIGateway) and another for the IVR Service (IVRService/DMNMiddleware.IVRService).

  • The docker build command is used to create the image, tagged with the registry URL and the image version.

• Docker Push: After building the images, they are pushed to the private Docker registry at 192.168.48.107:5000.

  • The docker push command uploads the images to the specified registry.

• Tags: The runner is configured to use dmnmiddleware as a tag, ensuring that only appropriate runners will execute the job.

• Branch Limitation: This step is set to run only on the master branch to avoid deploying from other branches.

Deploy Stage

The deploy stage involves deploying the services using Docker Swarm by using a pre-configured docker-stack.yml file.

    deploy:
      stage: deploy
      script:
        - echo "Deploying DMN Middleware ..."
        - docker stack rm dmn_middleware
        - sleep 10
        - docker stack deploy -c docker-stack.yml dmn_middleware
      tags:
        - dmnmiddleware
      needs:
        - build
      only:
        - master

• Deployment Script:

  • Docker Stack Removal: The docker stack rm the command removes the existing stack named dmn_middleware to ensure that old services are stopped and replaced by the new deployment.

  • Delay: A 10-second delay (sleep 10) is introduced to give Docker time to clean up the previous deployment before redeploying.

  • Docker Stack Deployment: The docker stack deploy command is used to deploy the updated images to the Docker Swarm cluster using the docker-stack.yml configuration file.

    Example docker-stack.yml File

    Following is just an sample example of docker-stack yml file.

      version: '3.8'
    
      services:
        apigateway:
          image: 192.168.48.107:5000/dmn/apigateway:1.0.0
          deploy:
            replicas: 2
            restart_policy:
              condition: on-failure
          ports:
            - "8080:80"
          networks:
            - dmn_network
    
        ivrservice:
          image: 192.168.48.107:5000/dmn/ivrservice:1.0.0
          deploy:
            replicas: 2
            restart_policy:
              condition: on-failure
          ports:
            - "8081:80"
          networks:
            - dmn_network
    
      networks:
        dmn_network:
          driver: overlay
    
      volumes:
        data:
    

    Explanation of the docker-stack.yml File

    • Version: Specifies the version of the Docker Compose file format. 3.8 is used in this example, compatible with Docker Swarm.

    • Services: Defines the different services in the stack.

      • apigateway:

        • image: Specifies the Docker image for the API Gateway. The image is pulled from the private Docker registry at 192.168.48.107:5000 with the tag 1.0.0.

        • deploy: Configures deployment settings:

          • replicas: Sets the number of replicas (containers) to run for the service.

          • restart_policy: Defines the conditions under which the service should be restarted.

        • ports: Maps port 80 in the container to port 8080 on the host, allowing external access.

        • networks: Connects the service to the dmn_network.

      • ivrservice:

        • image: Specifies the Docker image for the IVR Service, similarly pulled from the private Docker registry.

        • deploy: Configures deployment settings, including replicas and restart_policy.

        • ports: Maps port 80 in the container to port 8081 on the host.

        • networks: Connects the service to the dmn_network.

    • Networks:

      • dmn_network: Defines an overlay network that allows services to communicate with each other within the Docker Swarm cluster.

    • Volumes:

      • data: Declares a volume named data, which can be used for persisting data across container restarts. It is not used in this example but is included to show how volumes are defined.

• Dependency on Build Stage: The deploy job is dependent on the successful completion of the build job using the needs: - build directive, ensuring that only freshly built images are deployed.

• Tags and Branch Restriction: Similar to the build stage, the deploy stage runs only on runners tagged with dmnmiddleware and only on the master branch.

Monitoring Using Portainer

Portainer is a lightweight management UI that simplifies container management for Docker environments. It provides an intuitive web interface for managing Docker containers, images, volumes, networks, and more. Portainer supports Docker Swarm and Kubernetes, making it versatile for both single-host and multi-host setups. Its user-friendly dashboard helps streamline container operations and monitoring, improving overall efficiency.
I don't talk here about how to install portainer because it is quite simple. You can follow the official documentation of portainer for quick up and running. After successful completion of the CI-CD job you can see your stack in portainer.

Thank you for reading my blog.

Have a nice day and Happy Coding :)

1. Operating System Installation: Ensure the required operating system is installed on all nodes.

2. Network Configuration: Verify that the physical network between all nodes is correctly configured and that the nodes can communicate with each other.

Docker Installation

1. Install Docker: Install Docker on all nodes (both master and worker nodes) following the official Docker documentation: https://docs.docker.com/engine/install/ubuntu/

Ensure Docker is properly installed by running:

docker --version

Setting Up Docker Swarm

1. Initialize Docker Swarm on the Master Node:

• On the master node, initialize the Docker Swarm by running:

  docker swarm init

• Note the command and token provided after the initialization. This token is required for worker nodes to join the swarm.

2. Join Worker Nodes to the Swarm:

• On each worker node, use the command provided by the master node to join the swarm:

  docker swarm join --token <worker-token> <master-node-ip>:2377

• Verify that the worker nodes have successfully joined the swarm by running the following command on the master node:

  docker node ls

Deploying the Stack

1. Create/Update the Stack YML File:

• Ensure that the stack YML file (e.g., docker-stack.yml) is up to date with the necessary services and configurations.

2. Deploy the Stack:

• Deploy the stack using the following command on the master node:

  docker stack deploy -c docker-stack.yml <stack-name>

• Confirm that all services are running as expected:

  docker stack services <stack-name>

Troubleshooting Ingress Network Issues

1. Network Troubleshooting:

• If there are issues related to the ingress network, such as network connectivity problems between nodes, use the following command on the affected node(s) to disable checksum offloading:

  ethtool -k ens160 tx-checksum-ip-generic off

• Replace ens160 with the appropriate network interface name for your environment.

2. Verify Network Configuration:

• Ensure that all nodes can communicate over the required ports and that no firewall or network issues are causing problems.

Additional Considerations

1. Regular Monitoring: Continuously monitor the health and performance of the Docker Swarm cluster using tools like docker service ps, docker node ls, and Docker logs.

2. Scaling Services: Adjust the number of replicas or scale services as needed using the stack YML file or docker service scale command.

3. Updating Services: Update services in the stack by modifying the YML file and re-running the docker stack deploy command.

Container Registry

We use Docker’s open-source container registry, Registry 2, to store our container images. This registry can be easily installed and configured within Docker.

docker run -d -p 5000:5000 –restart=always –name registry \

-v /opt/docker-registry/data: /var/lib/registry\

registry:2

This command sets up the registry as a Docker container, with persistent storage for your images at /opt/docker-registry/data.

Note: We must build an image and make the tag to push it in the registry. Also, we need to add insecure registries in the daemon.json of docker. Deamon.json file can be found in /etc/docker/

docker build -t dmn/image_name path_to_dockerfile

docker tag local_image image_with_registry_url

docker push image_with_registry_url

Let me give you a meaningful analogy first.
Imagine you're at a magical tea party with your favorite stuffed animals. Each of them has a unique personality, and they're all eager to join in the fun. You pour pretend tea, share imaginary snacks and have delightful conversations with your furry friends. The party continues until you decide it's time to say goodbye and put your toys away. Just like how you remember the tea party's adventures the next time you play, computers also remember what you were doing during a session. They keep track of the websites you visit, the games you play, and the tasks you complete until you're ready to close the computer or log out. So, think of a session as a magical tea party with your computer, where together, you create delightful memories in the digital world!

A session is a method used for managing state in web development. It functions by storing data on the server, allowing for the storage of various types of objects, including custom ones. Sessions are regarded as a highly effective state management technique because they store data based on the client, ensuring that each user's data is kept separate and secure on the server. This is particularly important in web development because the HTTP protocol, which the web utilizes, is stateless. This means that each time a client sends a request to the server, a new instance of the page is created, rendering the previous data inaccessible. Therefore, to fulfill requirements such as storing and passing control values between web forms, state management techniques like sessions are indispensable.

In ASP.NET, sessions are a crucial aspect of state management, allowing developers to maintain user-specific data across multiple requests. There are several types of sessions in ASP.NET, each with its own use cases, advantages, and disadvantages:

In ASP.NET, sessions are a crucial aspect of state management, allowing developers to maintain user-specific data across multiple requests. There are several types of sessions in ASP.NET, each with its own use cases, advantages, and disadvantages:

1. In-Proc Session State:

   • Use Case: In-Proc session state is the default session state mode in ASP.NET. It stores session data in the web server's memory. It is ideal for applications with a single web server and low to moderate traffic.

   • Advantages:

     • Fast access to session data since it's stored in-memory.

     • No external dependencies or configuration required.

   • Disadvantages:

     • Session data is lost if the web server is restarted or recycled.

     • Not suitable for web farms or load-balanced environments as session data is not shared between servers.

2. StateServer Session State:

   • Use Case: StateServer session state mode stores session data in a separate process called the ASP.NET State Service. It is suitable for web applications hosted on multiple servers or in a web farm environment.

   • Advantages:

     • Session data is preserved even if the web server is restarted or recycled.

     • Suitable for load-balanced environments as session data is stored externally and can be accessed by multiple servers.

   • Disadvantages:

     • Slower access to session data compared to In-Proc session state due to network communication with the State Service.

     • Limited to storing serializable objects in session due to the need for data to be marshaled across processes.

3. SQLServer Session State:

   • Use Case: SQLServer session state mode stores session data in a SQL Server database. It is suitable for web applications requiring high scalability, reliability, and persistence of session data.

   • Advantages:

     • Session data is persisted in a SQL Server database, ensuring data integrity and availability.

     • Suitable for web farms or load-balanced environments as session data is stored centrally in the database.

   • Disadvantages:

     • Slower access to session data compared to In-Proc or StateServer session state due to database communication overhead.

     • Requires additional setup and configuration, including setting up the SQL Server database and configuring connection strings.

Each type of session state in ASP.NET offers different trade-offs in terms of performance, scalability, and reliability. The choice of session state mode depends on the specific requirements and constraints of the web application.

DI is a technique in software development that manages the dependencies between different components or modules in the system.

This is done by providing a component with its required dependencies from an external source instead of allowing it to create or manage its dependencies.

Inversion of Control (IoC)

It is a design pattern that allows the flow of control in a program to be inverted or reversed. Instead of the program controlling the flow of execution, the flow is controlled by an external framework or container.

So, Why should we use IoC?

By applying IoC, an application can decouple its components, making them more modular and easier to test and maintain.

IoC promotes the uses of interfaces and abstraction which makes the code more flexible and extensible.

Types of DI

Constructor Injection

This involves injecting dependencies through a class's constructor. This is the most common form of DI and is often used when a class has mandatory dependencies that it needs in order to function correctly.

Property Injection

This involves injecting dependencies through a class's public properties. Property injection is less common than Constructor injection and is often used when you need to inject optional dependencies.

Method Injection

This involves injecting dependencies through a method call. Method injection is the least common form of DI and is often used when a dependency is only required for a specific method call.

DI in .NET Core

DI in .NET core is a built-in feature that allows you to separate the creation of object graphs from your application code.

To Use DI, you need to register your services with a service container by specifying which services your application needs and how to create them.

Lifetime Management

Lifetime management in Dependency injection refers to the way in which instances of a service are created and managed by the Dependency Injection container. In other words, it determines the lifespan of an object created through Dependency Injection.

The three-lifetime management options are as follow:

1. Transient

2. Scoped

3. Singleton

Transient Method

This is the default lifetime management in the .NET core. A new instance of the service is created each time it is requested from the container.

Methods

AddTransient: Registers a service with transient lifetime management.

Add Transient<TService, TImplementation>: Registers a service and its implementation with transient lifetime management.

When you have a lightweight and stateless service that does not maintain any state between requests, such as a logger or a helper class. When you want to ensure that a new instance of the service is created every time it is requested from the container. This can help prevent issues with thread-saÿety or shared state.

Scoped Method

A single instance of the service is created for each scope. A scope typically corresponds to a web request in a web application.

Methods

AddScoped: Registers a service with the scoped lifetime management. AddScoped<TService, TImplementation>: Registers a service and its implementation with the scoped lifetime management.

When you have a service that needs to maintain a state between requests, but that should not be shared.

Singleton Method

A single instance of the service is created and shared throughout the lifetime of the application. This can be useful for services that are expensive to create or for services that need to maintain state.

Methods

AddSingleton: Registers a service with singleton lifetime management.

AddSingleton<TService, TImplementation>: Registers a service and its implementation with the singleton lifetime management.

Be aware that a single instance of the service will be created and shared throughout the lifetime of the application. This can lead to issues with shared state or thread safety if the service is not designed to be used in this way. Be sure to handle any concurrency issues that may arise when using a singleton.

In this article, I going to guide you to get started with pynt to security test your API. So, you are thinking what a hell is in the earth is pynt. Pynt is a free API security solution that generates automated security tests from your existing functional test collection in a few minutes. Pynt (pynt.io) is a free API security solution that runs seamlessly in Postman. It generates automated security tests based on your existing functional test collection. Simply input your functional test collection name into the Pynt collection and run it to get the security testing coverage for your

Tools you need to install

1. Ensure you are working with the Postman app (install from https://www.postman.com/downloads). Please note that the Pynt solution is based on docker and requires access to the local host, so it doesn't support the Postman web.

2. Ensure the Docker engine is available and running on your machine (install it from: https://docs.docker.com/engine/install/).

Getting Started:

• Open your workspace from the Postman desktop app.

• Download and run the Pynt docker by executing the following command (port number can be changed if already taken):

  • Docker Desktop for Windows, Mac, or Linux - run from cmd/terminal: docker run -p 5001:5001 --pull always [ghcr.io/pynt-io/pynt:postman-latest(the](http://ghcr.io/pynt-io/pynt:postman-latest(the) left port can be changed if already taken on your machine)

  • Docker engine for Linux - run from terminal: docker run --pull always --network=host ghcr.io/pynt-io/pynt:postman-latest

This step should be repeated if you restarted your PC.

Run Pynt docker

How to Run:

Make sure Pynt's docker is still up.

• Click on the 'Variables' tab of the 'Pynt' collection and fill in the values of the required parameters, in the 'CURRENT VALUE' column:

  • API-KEY - your postman API key - If you previously saved and have your API key, enter it here under the 'Current Value' tab. If not, enter https://postman.co/settings/me/api-keys to generate or regenerate your API key as for security reasons it can only be copied at the time of creation. You won't need to modify this parameter again until the API-key expires.

  • PYNT-PORT - the left port number used in the docker run command (default-5001).

  • YOUR-COLLECTION- your functional test collection name, or the collection UID (both are acceptable, UID is preferred if you have two collections with the same name associated with the API-KEY). Pynt will refer to this collection to generate the automated security tests.
    If you wish to have a reference application to test, Pynt provides a vulnerable app example called 'goat' that you can fork from Pynt's public workspace: https://www.postman.com/pynt-io/workspace/pynt and use it here.

  • scanId - output variable, used internally. Ignore.

  • Click 'Save'.

• Run the 'Pynt' collection to get the security results:

  • The security results for OWASP-10 categories will appear on the main console screen.

  • Click on 'View Summary' to view the results summary.

  • In order to see the full report, uncollapse the 'Pynt' collection, go to the last request 'Show Report' and click on 'Send'. choose the 'Visualize' tab on the lower section to see the full report.

If you modified your test collection in any way, simply re-run Pynt collection. Should you need to test another collection, simply update the YOUR-COLLECTIONvariable and re-run the 'Pynt' collection.

See also screenshot examples:

Image 1 - Generate/copy API Key if forgotten

Image 2 - Enter 'Pynt' collection parameters

Image 3 - Run the 'Pynt' collection to generate full OWASP-10 API-security tests for your collection

Image 4 - View the API security test results

Image 5 - View results summary

Image 6 - View visualize report for security summary

Image 7 - View visualize report for detailed findings

I assume you have basic knowledge of C# programming language and the basics of dotnet MVC application.

What is MinIO?

MinIO is a high-performance, distributed object storage system. It is open-source software under GNU 3.0 license. MinIO is AWS S3 compatible but mainly used in a private cloud. MinIO provides a lot of benefits to developers and system engineers. Some of them are given below:

• High availability

• Data redundancy

• Native Kubernetes support

• Horizontal and vertical scaling

• Two-factor data encryption

• Detailed performance monitoring

• IAM framework that offers more flexible access configuration

• Notifications about downloading and uploading data in a queue

Installing MinIO In Windows

For this particular demo, I am using the windows 11 operating System. To install minio we have to download minio.exe first. So, let's browse minio official website, and then click the download button on the very first landing page. Then will see different options for different platforms like windows, mac, linux, docker, Kubernetes, etc. I am using windows that is why I click the windows option. After that, I will download the minio.exe file from there.

Now, open the command prompt and move to the directory where you downloaded minio.exe. Then execute it using the command given below:

minio.exe server D:\minio --console-address :9090

The above command tells minio to start the server and save the uploaded file in D:\minio directory. Now you will see the result shown in the image below:

MinIO Object Storage Server
Copyright: 2015-2023 MinIO, Inc.
License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
Version: RELEASE.2023-01-12T02-06-16Z (go1.19.4 windows/amd64)

Status:         1 Online, 0 Offline.
API: http://192.168.137.220:9000  http://172.27.112.1:9000  http://127.0.0.1:9000
RootUser: minioadmin
RootPass: minioadmin
Console: http://192.168.137.220:9090 http://172.27.112.1:9090 http://127.0.0.1:9090
RootUser: minioadmin
RootPass: minioadmin

Command-line: https://min.io/docs/minio/linux/reference/minio-mc.html#quickstart
   $ mc.exe alias set myminio http://192.168.137.220:9000 minioadmin minioadmin

Documentation: https://min.io/docs/minio/linux/index.html
Warning: The standard parity is set to 0. This can lead to data loss.

+---------------------------------------------------------------+
| You are running an older version of MinIO released 1 week ago |
| Update: Run `mc admin update`                                 |
+---------------------------------------------------------------+

Open browser and enter localhost:9090 in the url. Then you will see the minio login pages.

Enter the username and password that you can find in the command prompt. In my case username = minioadmin and password = minioadmin.

Then you will see the minio dashboard as shown below:

Create a new bucket from the side menu in minio dashboard. MinIO Object Storage uses buckets to organize objects. A bucket is similar to a folder or directory in a filesystem, where each bucket can hold an arbitrary number of objects. MinIO buckets provide the same functionality as AWS S3 buckets. I have created a bucket name oss as you can see in the image object.

Connecting Dotnet MVC application to MinIO server

Create a new MVC application using dotnet cli.

dotnet new mvc -n sampleapp -o src

Install minio client package for dotnet.

dotnet add package minio

Now in the index view of the home controller create a form that has file input and a button to submit.

<form asp-controller="Home" asp-action="Upload" method="post">
    <input type=file name="file"/>
    <button type="submit">Upload</button>
</form>

Now, Let's write a backend when we submit the above HTML form. Before writing the backend code you have to generate the access key and secret key from minio dashboard. Go to your minio console and find the Users page. You can create a new user and set it MINIO_ACCESS_KEY and MINIO_SECRET_KEY or can view user credentials. Note that your policy must allow for credentials reset, the default policy consoleAdmin allows for that.

public IActionResult Upload(IFormFile file)
{
    var endpoint = "127.0.0.1:9000";
    var accessKey = "XXXXXXXXXXX";
    var secretKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
    var minio = new MinioClient()
                .WithEndPoint(endpoint)
                .WithCredentials(accessKey, secretKey)
                .Build();
    Uploader.Run(minio, file).Wait();
    return View("Index");
}

public async static Task Run(MinioClient minio, IFormFile file)
{
    var bucketName = "oss";
    var objectName = file.FileName;
    var contentType = file.ContentType:
    try
    {
        var beArgs = new BucketExistArgs().WithBucket(bucketName);
        bool found = await minio.BucketExistAsync(beArgs).Configure(false);
        if(!found)
        {
            var mbArgs = new MakeBucketArgs().WithBucket(bucketName);
            await minio.MakeBucketAsync(mbArgs).ConfigureAwait(false);
        }    
        using(var fileStream = new MemoryStream())
        {
            file.CopyTo(fileStream);
            var fileBytes = fileStream.ToArray();
            var putObjectArgs = new PutObjectArgs()
                            .WithBucket(bucketName)
                            .WithObject(objectName)
                            .WithStreamData(new                     MemoryStream(fileBytes))
                            .WithObjectSize(fileStream.Length)
                        .WithContentType("application/octet-stream");
            await minio.PutObjectAsync(putObjectArgs).ConfigureAwait(false);
        }
    }
    catch(Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
}

Now, run the MVC application and try to upload the file. It will be uploaded to the bucket in mino.

Thank you! Happy Coding :)

What will we learn from this article?

This article guide teaches you how to set up containerized .NET application using docker and how to use it in a developer environment with the debugger.

• Create a simple dot net MVC application

• Create a new Dockerfile which contains instructions required to build a. Net image.

• Set up docker-compose which set up postgres sql database, pgadmin to monitor postgres database.

• Set up vs code debugger in the visual studio code editor.

Docker

Docker is a software platform that enables rapid development, testing, and deployment of applications. Docker encapsulates software into standardized units called containers that have everything (i.e all dependencies) the software needs to run including libraries, system tools, code, runtime, and settings.

Container

A container is a standard unit of software that packages up code and all its dependencies to that application and runs quickly and reliably from one computing environment to another. We can think container as an isolated process in the operating system which has its own networking and file system. A Docker Container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings.

DotNet

.NET is an open-source developer platform, created by Microsoft, for building many different types of applications. .Net is a free, cross-platform, open-source developer platform for building different types of applications.

With .NET, you can use multiple languages, editors, and libraries to build for web, mobile, desktop, games, IoT, and more. You can write .NET apps in C#, F#, and many other dot net languages.

Software Prerequistes

Before diving into the coding section, we have to make sure the following software is installed. I am using windows 11 for this guide. You can use other operating systems as well.

1. Docker Desktop with docker-compose

2. Visual Studio Code

3. Dotnet Sdk 7

4. Any Web Browser

Creating New .NET MVC Application

For our sample application, let's create a simple application from a template using .NET CLI. Create a directory in our local machine named sampleapp. Open a cmd and change to that directory. Run the following dotnet new command to create a C# app using the ASP.NET MVC template.

mkdir sampleapp
cd sampleapp
dotnet new mvc -n sampleapp -o src --no-https

Above command will create an src file inside sampleapp folder. Furthermore, inside src, we will get asp.net MVC project folders and files. The further structure will look like following

├── src
├── Controllers
│ └── HomeController.cs
├── Models
│ └── ErrorViewModel.cs
├── Views
│ └── Home
│     └── Index.cshtml
│     └── Privacy.cshtml
├── Program.cs
├── Properties
│ └── launchSettings.json
├── appsettings.Development.json
├── appsettings.json
├── sampleapp.csproj
├── obj
│ ├── sampleapp.csproj.nuget.dgspec.json
│ ├── sampleapp.csproj.nuget.g.props
│ ├── sampleapp.csproj.nuget.g.targets
│ ├── project.assets.json
│ └── project.nuget.cache
└── wwwroot
  ├── css
  ├── favicon.ico
  ├── js
  └── lib

Now, Let's start our application and make sure it's running properly. In the command prompt navigate to the src folder and use the dotnet run command.

cd /path/to/sampleapp/src
dotnet run --urls http://localhost:5000

Ouput similar to the following appears.

Building...
info: Microsoft.Hosting.Lifetime[0]
    Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
    Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
    Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
    Content root path: C:\Users\username\sampleapp\src

Now you will see the following page in the browser:

If you get the result as the above image then you will install mvc project correctly and you

are ready to go further.

Create a Dockerfile

In sampleapp directory, create a file named Dockerfile And paste the following code.

FROM mcr.microsoft.com/dotnet/sdk:7.0 as debug

#install debugger for NET Core
RUN apt-get update
RUN apt-get install -y unzip
RUN curl -sSL https://aka.ms/getvsdbgsh | /bin/sh /dev/stdin -v latest -l ~/vsdbg

RUN mkdir /src/
WORKDIR /src/

COPY ./src/testapp.csproj /src/sampleapp.csproj
RUN dotnet restore

COPY ./src/ /src/
RUN mkdir /out/
RUN dotnet publish --no-restore --output /out/ --configuration Release
EXPOSE 80
CMD dotnet run --urls "http://0.0.0.0:80"

The above Dockerfiel is used for building and running a .NET Core application in a Docker Container.

It starts with the base image mcr.microsoft.com/dotnet/sdk:7.0 and tags it as debug.

In summary above docker file will do the following tasks step by step one at a time.

1. Installs the debugger for .NET Core by updating the package list and installing unzip, then downloading and installing the latest version of vsdbg.

2. Creates a directory '/src/' as the working directory.

3. Copies the project file 'sampleapp.csproj' to '/src/' and restores the dependencies.

4. Copies the source code to '/src/' and runs the publish command to build and output the application to '/out/'.

5. Exposes port 80 for external access.

6. Runs the application with the command dotnet run --urls "http://0.0.0.0:80".

Create docker-compose.yml File

Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to define an application’s services, networks, and volumes in a single file, then start and stop the services using a single command.

Open the sampeapp directory in vs code and create a file named docker-compose.yml . Copy and paste the following contents into the file.

version: "3.0"
services:
  db:
    image: postgres
    restart: always
    ports:
      - "5432"
    volumes:
      - postgres:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: password
      POSTGRES_USER: sachin

  pg_admin:
    image: dpage/pgadmin4
    restart: always
    ports:
      - "5555:80"
    volumes:
      - pg_admin:/var/lib/pgadmin
    environment:
      PGADMIN_DEFAULT_EMAIL: sachin.maharjan@dishhome.com.np
      PGADMIN_DEFAULT_PASSWORD: password

  web:
    container_name: csharp
    build:
      context: .
      target: debug
    ports:
     - "5000:80"
    volumes:
      - ./src:/src/
    depends_on:
     - db

volumes:
  postgres:
  pg_admin:

Save and close the docker-compose.yml file. Add the .dockerignore file and paste the following code.

**/bin/
**/obj/

The sampleapp directory structure should now look like

├── samplefile
│ ├── src/
│ ├── Dockerfile
│ ├── .dockerignore
│ ├── docker-compose.yml

The .dockerignore the file is used in a Docker build context to specify files or directories that should be excluded from the build context. This helps to reduce the size of the build context and improve the build time by excluding files and directories that are not necessary for the build. Any files or directories listed in the .dockerignore file will not be included in the build context that is sent to the Docker daemon for building the image.

The docker-compose.yml the file describes a multi-container application. In our docker-compose.yml file, we have three services db, pgadmin and web.

• 'db' is a PostgreSQL database service, which uses the official PostgreSQL image. It will be exposed on port 5432 and the data will be persisted in a Docker volume named 'postgres'. The environment variables 'POSTGRES_PASSWORD' and 'POSTGRES_USER' are set to 'password' and 'sachin' respectively.

• 'pg_admin' is a web-based database administration tool, using the image 'dpage/pgadmin4'. It will be exposed on port 5555 and the data will be persisted in a Docker volume named 'pg_admin'. The environment variables 'PGADMIN_DEFAULT_EMAIL' and 'PGADMIN_DEFAULT_PASSWORD' are set to 'sachin.maharjan@dishhome.com.np' and 'password' respectively.

• 'web' is a .NET Core web application service. The service is built from the current directory and the build context is set to the 'debug' target. The service will be exposed on port 5000 and the source code will be mounted as a volume in the container at the '/src/' directory. The 'depends_on' key ensures that the 'db' service is started before the 'web' service.

• The 'volumes' section at the bottom defines two named volumes: 'postgres' and 'pg_admin'.

Database Connection

Let's add the package to allow the app to talk to a database and update the source files. On your local machine, open a terminal, change the directory to the src directory and run the following command:

cd /path/to/dotnet-docker/src
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

In the src directory, create a Models folder. Inside the Models folder create a file named Student.cs and add the following code to Student.cs:

using System;
using System.Collections.Generic;
namespace sampleapp.Models
{
  public class Student
  {
    public int ID { get; set; }
    public string LastName { get; set; }
    public string FirstMidName { get; set; }
    public DateTime EnrollmentDate { get; set; }
  }
}

Save and close the Student.cs file.

In the src directory, create a Data folder. Inside the Data folder create a file named SchoolContext.cs and add the following code to SchoolContext.cs:

using Microsoft.EntityFrameworkCore;
namespace sampleapp.Data
{
   public class SchoolContext : DbContext
   {
      public SchoolContext(DbContextOptions<SchoolContext> options) : base(options) { }
      public DbSet<Models.Student>? Students { get; set; }
   }
}

Save and close the SchoolContext.cs file.

In the Program.cs file located in the src directory, replace the contents with the following code:

using Microsoft.EntityFrameworkCore;
using sampleapp.Data;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddControllersWithViews();
builder.Services.AddDbContext<ApplicationDbContext>(options =>
   options.UseNpgsql(builder.Configuration.GetConnectionString("DefaultConnection")));
var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

using (var scope = app.Services.CreateScope())
{
    var services = scope.ServiceProvider;

    var context = services.GetRequiredService<ApplicationDbContext>();
    if (context.Database.GetPendingMigrations().Any())
    {
        context.Database.Migrate();
    }
}
app.Run();

Save and close the Program.cs file.

In the appsettings.json file located in the src directory, replace the contents with the following code:

{
   "Logging": {
       "LogLevel": {
           "Default": "Information",
           "Microsoft": "Warning",
           "Microsoft.Hosting.Lifetime": "Information"
       }
   },
   "AllowedHosts": "*",
   "ConnectionStrings": {
       "SchoolContext": "Host=db;Database=my_db;Username=sachin;Password=password"
   }
}

Save and close the appsettings.json file.

In the Index.cshtml file located in the src\Pages directory, replace the contents with the following code:

@{
    ViewData["Title"] = "Home page";
}

<div class="text-center">
    <h1 class="display-4">Welcome</h1>
    <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
</div>

<div class="row mb-auto">
    <p>Student Name is @ViewBag.Student</p>
</div>

Save and close the Index.cshtml file.

In the Index.cshtml.cs file located in the src\Pages directory, replace the contents with the following code:

using System.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using sampleapp.Models;

namespace testapp.Controllers;

public class HomeController : Controller
{
    private readonly ILogger<HomeController> _logger;
    private readonly SchoolDbContext _db;
    public HomeController(ILogger<HomeController> logger, SchoolDbContext db)
    {
        _logger = logger;
        _db = db;
    }

    public IActionResult Index()
    {
        var student = _context.Students?.Where(d=>d.ID==1).FirstOrDefault();
            this.StudentName = $"{s?.FirstMidName} {s?.LastName}";
       ViewBag.Student = student;
        return View();
    }

    public IActionResult Privacy()
    {
        return View();
    }

    [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
    public IActionResult Error()
    {
        return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
    }
}

Save and close the Index.cshtml.cs file.

Now, add migration command to create database and students table in a database named my_db.

dotnet-ef migrations add "InitalMigration"

Note: you need to install dotnet-ef utility tool, for this you can install this using

donet tools install --global dotnet-ef

Now, up the all container using docker-compose up command. cd to sampleapp directory and run the following command.

cd path to sampleapp
docker-compose up --build

If every thing is ok then all three containers web, database and pgadmin will start. Now, go to browser and enter url localhost:5555. you will see the login page of pg admin.

Now, Login into pgadmin using email and password setup in docker-compose.yml file. After that, you will redirect to the home page.

Now right-click on the server and click on to register server option. Then a dialog box will open. In that section, you have to provide the hostname as db port name 5432 and username as sachin and password as password. All credentials are already defined in docker-compose.yml the file.

Now, Open the server menu you will see the database name my_db. Now open that my_db menu you will see the schema section. Under the schema section, you will see tables. Now add a row in the table named students.

so, If you open a browser and enter localhost:5000 you will see the home page with the first name and last name that you have inserted in the database.

Enabling Debugging In VS Code

For enabling debugging in vs code, first, we need the following extensions in vs code

1. VS Code Extension for Docker

2. VS Code Launch configuration

3. C# extension for VS Code

Click on to debug button on the right of the visual studio code. Then You will have the option to create a launch.json file. Click on it to create a launch.json.

Then it will create .vscode under sampleapp directory. when we open .vscode directory we will see the launch.json file. Open the file and paste the code below:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Docker Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeArgs": [ "exec", "-i", "csharp" ],
                "debuggerPath": "/root/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}",
                "quoteArgs": false
            },
            "sourceFileMap": {
                "/src": "${workspaceRoot}/src/"
            }
        },

    ]
}

Now, if you put breakpoints in any c# code and hit the green run button on debug section. Then execution stops at that breakpoint. But you have to choose the correct process during the prompt which pops out while you click the green run button.

The above animation is for node.js, I have kept it just to simulate how it is done.

That is, it! I hope you found this helpful. If you have any questions or are confused about anything, you can reach out to me or you can check out the sample project on GitHub.

Thank you!

Happy Coding :)