Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Using .NET Core 2.1 on OpenShift Container Platform

You can install .NET Core image streams on Linux, Mac, or Windows operating system.

3.1. Installing .NET Core 2.1 image streams
Copy link

.NET Core image streams definition can be defined globally in the openshift namespace or locally in your specific project.

Procedure

  1. If you are a system administrator or otherwise have sufficient permissions, change to the openshift project. Using the openshift project allows you to globally update the image stream definitions. 

    $ oc project openshift

    If you do not have permissions to use the openshift project, you can still update your project definitions starting with Step 2.

  2. List all available .NET Core image versions: 

    $ oc describe is dotnet -n openshift
$ oc describe is dotnet

    The output shows installed images or the message Error from server (NotFound) if no images are installed.

  3. Import new image streams: 

    $ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/dotnet_imagestreams_rhel8.json

    If image streams were already installed, use the replace command to update the image stream definitions. 

    $ oc replace -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/dotnet_imagestreams_rhel8.json

3.2. Deploying applications from source using oc
Copy link

You can use OpenShift Client (oc) for application deployment.

The following example demonstrates how to deploy the example-app application using oc, which is in the app folder on the dotnetcore-2.1 branch of the redhat-developer/s2i-dotnetcore-ex GitHub repository:

Procedure

  1. Create a new OpenShift project: 

    $ oc new-project sample-project

  2. Add the ASP.NET Core application: 

    $ oc new-app --name=example-app 'dotnet:2.1~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.1' --build-env DOTNET_STARTUP_PROJECT=app

  3. Track the progress of the build: 

    $ oc logs -f bc/example-app

  4. View the deployed application once the build is finished: 

    $ oc logs -f dc/example-app

    The application is now accessible within the project.

  5. Optional: Make the project accessible externally: 

    $ oc expose svc/example-app

  6. Obtain the shareable URL: 

    $ oc get routes

You can use .NET Core Source-to-Image (S2I) builder image to build applications using binary artifacts that you provide.

Prerequisites

  1. Published application.

    For more information, see Section 2.3, “Publishing applications using .NET Core 2.1”.

Procedure

  1. Create a new binary build: 

    $ oc new-build --name=my-web-app dotnet:2.1 --binary=true

  2. Start the build and specify the path to the binary artifacts on your local machine: 

    $ oc start-build my-web-app --from-dir=bin/Release/netcoreapp2.1/publish

  3. Create a new application: 

    $ oc new-app my-web-app

3.4. Environmental variables for .NET Core 2.1
Copy link

The .NET Core images support several environment variables to control the build behavior of your .NET Core application. You can set these variables as part of the build configuration, or add them to the .s2i/environment file in the application source code repository.

Expand
Variable NameDescriptionDefault

DOTNET_STARTUP_PROJECT

Selects the project to run. This must be a project file (for example, csproj or fsproj) or a folder containing a single project file.

.

DOTNET_ASSEMBLY_NAME

Selects the assembly to run. This must not include the .dll extension. Set this to the output assembly name specified in csproj (PropertyGroup/AssemblyName).

The name of the csproj file

DOTNET_RESTORE_SOURCES

Specifies the space-separated list of NuGet package sources used during the restore operation. This overrides all of the sources specified in the NuGet.config file.

 

DOTNET_TOOLS

Specifies a list of .NET tools to install before building the app. It is possible to install a specific version by post pending the package name with @<version>.

 

DOTNET_NPM_TOOLS

Specifies a list of NPM packages to install before building the application.

 

DOTNET_TEST_PROJECTS

Specifies the list of test projects to test. This must be project files or folders containing a single project file. dotnet test is invoked for each item.

 

DOTNET_CONFIGURATION

Runs the application in Debug or Release mode. This value should be either Release or Debug.

Release

DOTNET_VERBOSITY

Specifies the verbosity of the dotnet build commands. When set, the environment variables are printed at the start of the build. This variable can be set to one of the msbuild verbosity values (q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]).

 

HTTP_PROXY, HTTPS_PROXY

Configures the HTTP or HTTPS proxy used when building and running the application, respectively.

 

DOTNET_RM_SRC

When set to true, the source code will not be included in the image.

 

DOTNET_SSL_DIRS

Specifies a list of folders or files with additional SSL certificates to trust. The certificates are trusted by each process that runs during the build and all processes that run in the image after the build (including the application that was built). The items can be absolute paths (starting with /) or paths in the source repository (for example, certificates).

 

NPM_MIRROR

Uses a custom NPM registry mirror to download packages during the build process.

 

ASPNETCORE_URLS

This variable is set to http://*:8080 to configure ASP.NET Core to use the port exposed by the image. Changing this is not recommended.

http://*:8080

DOTNET_RESTORE_DISABLE_PARALLEL

When set to true, disables restoring multiple projects in parallel. This reduces restore timeout errors when the build container is running with low CPU limits.

false

DOTNET_INCREMENTAL

When set to true, the NuGet packages will be kept so they can be re-used for an incremental build. Defaults to false.

 

DOTNET_PACK

When set to true, creates a tar.gz file at /opt/app-root/app.tar.gz that contains the published application.

 

[OBSOLETE: April 2019] - DOTNET_SDK_VERSION

Selects the default sdk version when building. If there is a global.json file in the source repository, that takes precedence. When set to latest, the latest sdk in the image is used.

Lowest sdk version available in the image

Three sample applications are available:

  • dotnet-example: This is the default model–view–controller (MVC) application.
  • dotnet-runtime-example: This shows how to build an MVC application using a chained build. The application is built in ubi8/dotnet-21. The result is deployed in ubi8/dotnet-21-runtime. Note that chained builds are not supported on OpenShift Online.
  • dotnet-pgsql-persistent: This is the Microsoft ASP.NET Core MusicStore sample application using a PostgreSQL backend.

To add the samples using the OpenShift Web Console, browse to your project and click Add to project. You can filter for dotnet. If the samples do not show up, you can add them to your installation by running the following commands: 

$ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-example.json
$ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-runtime-example.json
$ oc create -f https://raw.githubusercontent.com/redhat-developer/s2i-dotnetcore/master/templates/dotnet-pgsql-persistent.json
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top