When you build your .NET Core project, NuGet packages are retrieved from nuget.org by default. Sometimes, however, you might want to use a local NuGet repository. For example, you may want to:
- use private NuGet packages, but you don't want anyone except your associates to see them.
- cache a NuGet repository at a server near your build servers
- leave your build server disconnected from the Internet.
I'll explain how to set up a private NuGet server on OpenShift and how you can use this NuGet server when building your .NET Core project in OpenShift using s2i-dotnetcore.
Set up nexus server as a private NuGet server
Unfortunately, the OSS Microsoft NuGet.Server only runs on Windows since it requires the .NET Framework. Nexus is a cross-platform repository solution from Sonatype. The free
OSS runs on Linux and in Linux containers. SonaType provides RHEL (and CentOS) based templates for deploying Nexus OSS on OpenShift.
We create a
nexus project and import the template:
$ oc new-project nexus $ oc create -f https://raw.githubusercontent.com/sonatype/docker-rhel-nexus/master/OpenShift/nexus-rhel.json
After creating objects, an initial build starts. It may take a long time. When the build is finished, a Nexus image is available on OpenShift. Now, we can deploy this image to OpenShift. This template includes a PVC with
readwriteonce access mode and specifid size (default 2Gi). If you don't have available Peresistent Storage, please set up following the document.
$ oc new-app --template=nexus -p APPLICATION_HOSTNAME=nexus.18.104.22.168.nip.io -p SIZE=2Gi
Once deployment is finished, you can access the nexus server with specified hostname using your browser. You can log in as
admin with default password
You will find two NuGet servers under components,
nuget.org-proxy is a caching server of NuGet.org server. When the proxy server doesn't contain the requested NuGet package, it downloads it from NuGet server and stores it. When a stored NuGet package is requested later, the proxy server provides a stored package. No configuration is required to use the
nuget.org-proxy server. Let's use this server with s2i-dotnetcore.
s2i .NET Core with nuget.org-proxy
The OpenShift s2i-dotnetcore builder has a configuration variable for specifying NuGet servers:
DOTNET_RESTORE_SOURCES for a build environment variable. You can specify it when creating your app with OpenShift web console:
Or you can specify it when using the `oc` command,
$ oc new-app --template=dotnet-example --name=dotnet-demo --param=APPLICATION_DOMAIN="dotnet-demo.22.214.171.124.nip.io" --param=CONTEXT_DIR="/app" --param=NAME=dotnet-demo --param=SOURCE_REPOSITORY_URL=https://github.com/redhat-developer/s2i-dotnetcore-ex.git --param=SOURCE_REPOSITORY_REF=dotnetcore-2.0 --param=DOTNET_STARTUP_PROJECT= --param=DOTNET_RESTORE_SOURCES=http://nexus.126.96.36.199.nip.io/repository/nuget.org-proxy/
The build will now use the local NuGet server. When the build is finished, you can find the cached NuGet packages at the nexus console.
Add your private NuGet package
When you want to use nexus server to host your private packages, you can use
nuget-hosted server. You have to push your private packages to this NuGet server. To do so, a NuGet APIKey is required. To find your NuGet, click the user icon on the right in the header and select
NuGet API Key
You also have to add
NuGet API-Key Real to Realms in the server administrator settings. While logged in as the admin user, click the gear icon in the header, then click
Realms and activate it.
Now you can push your package to NuGet server. If your package file is
myawesomelibrary.nupkg, the command is as followed.
$ dotnet nuget push -k --source http://nexus.188.8.131.52.nip.io/repository/nuget-hosted/ myawesomelibrary.nupkg
The Nexus console shows you packages you’ve pushed to the server.
We learned to setup SonaType Nexus OSS on OpenShift and how to use it as a local NuGet server for the OpenShift s2i-dotnetcore builder. If you use nexus for production, you should need to provide sufficient a storage space for nuget packages and setup user authentication.Last updated: September 3, 2019