Using secrets in Azure Container Instances

Introduction

---

At work I am involved in one of our internal project development. This project is a relatively small (less than 30 pages) ASP.NET Core 3.1 Razor Pages application. From it’s first days application is hosted in Azure using Azure Container Instance, Azure SQL Database and Azure Key Vault (continues integration and deployment pipelines are powered by Azure DevOps).

There is nothing special in such setup, however as it happens with setups of this kind, there is one thing that has to be managed prior to implementing it – “How to securely pass secrets to Azure Container Instances and securely read secrets stored in Azure Key Vault (ex. read database connection string) from within Azure Container Instances?”

Finding the answer was my responsibility, so I have created a dummy project and dived into Azure documentation. This post contains results of my findings composed, as I hope, in easy and understandable format.

CoherentSolutions.Extensions.Configuration.AnyWhere Release 1.0.3

The new release of CoherentSolutions.Extensions.Configuration.AnyWherec is here!

The release 1.0.3 is available on NuGet.

The release notes can be found on project version page.

What’s new?

This release includes minor bug-fix, performance improvement and a new configuration adapter for Azure Key Vault.

Interested? Let’s see the details!

CoherentSolutions.Extensions.Hosting.ServiceFabric Release v1.4.0

The new version of CoherentSolutions.Extensions.Hosting.ServiceFabric is released!

The version 1.4.0 is available on NuGet.

The release notes can be found on project version page.

What’s new?

---

This release brings support for custom implementations of ICommunicationListener.

Let’s see the details!

Release of CoherentSolutions.Extensions.Configuration.AnyWhere

Today I am announcing the first release of CoherentSolutions.Extensions.Configuration.AnyWhere!

The 1.0.2 version is available on NuGet.

What this project is about?

Writing extensible applications usually requires application to be able to change its behavior without code changes. This is mostly refer to execution of the application in different environment: on developers box, staging and production.

In traditional ASP.NET Core application environment management is handled somehow like this:

    WebHost.CreateDefaultBuilder(args)
      .UseStartup<Startup>()
      .Build()
      .Run();
    

The WebHost.CreateDefaultBuilder automatically includes appsettings.json and appsettings.{environment}.json configuration files allowing application to load configuration depending on the environment (the environment value is read from ASPNETCORE_ENVIRONMENT environment variable).

When you need something more sophisticated than different .json configuration file i.e to consume configuration from different configuration sources then traditional approach is to use IHostingEnvironment extension methods like: IsDevelopment, IsStaging or more generically IsEnvironment to configure additional configuration sources during startup:

    WebHost.CreateDefaultBuilder(args)
      .ConfigureAppConfiguration(
        (ctx, config) =>
        {
          if (ctx.HostingEnvironment.IsEnvironment("env"))
          {
            // register custom configuration source
          }
        })
      .UseStartup<Startup>()
      .Build()
      .Run();
    

While this works we still have strong relationship between our code and environments.

This is the part where CoherentSolutions.Extensions.Configuration.AnyWhere comes in.

Running Service Fabric Unit-Tests in Linux Container

Introduction

As you may know (or not) I am working on open-source project that simplifies configuration of Service Fabric Reliable Services in .NET. This project (as I believe almost all projects) has unit-tests and some of these unit-tests use (indirectly) instances of StatefulService and StatelessService classes.

Quite recently (a few month ago) I was configuring continuous integration using AWS CodeBuild. Simple enough I created the following build definition:

  version: 0.2
  phases:
    install:
      commands:
        - cd src
    pre_build:
      commands:
        - dotnet restore
    build:
      commands:
        - dotnet build -c Release --no-restore
        - dotnet test -c Test --no-restore --no-build
  

… and used aws/codebuild/dot-net:core-2.0 image on Linux as build environment.

Unfortunately the first build ended with the the following exception:

System.TypeInitializationException
The type initializer for ‘System.Fabric.Common.AppTrace’ threw an exception.
System.DllNotFoundException
Unable to load shared library ‘libFabricCommon.so’ or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibFabricCommon.so.so: cannot open shared object file: No such file or directory.

The solution was found but this was a long journey…