Azure Functions V2 – KeyVault and IConfiguration

Update:

The method below to get IConfiguration from your DI container is not needed anymore, since Azure Functions are supporting Dependency Injection now: Azure Functions DI

With that you don’t need the extra ConfigProvider and the ConfigAttribute anymore.

AddAzureKeyVault is still valid and works like a charm, also check out the auto refresh on it. AzureKeyVaultConfigurationOptions


Since Azure Functions V2 are out of preview finally, I started using them more and more. Obviously you run into some sort of issues immediately, like how do you get your app settings out of IConfiguration since there is no real .Net Core dependency injection built in right now. Just adding IConfiguration to the function itself doesn’t work. Or how do you access the KeyVault and have the values auto resolve.

Well, its actually not that difficult. And no you don’t have to add those “Inject” provider/attribute unless you want to, but you kind of follow the same steps.

I’m using a default function v2 in my example with an HttpTrigger and you can find the code on my Github.

In order to get your IConfiguration and use the built-in “AddAzureKeyVault” to add the KeyVault provider, all you have to do is create an implementation of “IWebJobsStartup” which will give you the “IWebJobsBuilder”. I guess that sounds familiar if you have used ASP.Net Core apps.

You can now access the current IConfiguration and add the KeyVault. After that you have to replace the existing one with the new configuration in order to make it accessible later with the key vault provider you added.

[assembly: WebJobsStartup(typeof(FunctionStartup))]
namespace FunctionApp1
{
    public class FunctionStartup : IWebJobsStartup
    {
        public void Configure(IWebJobsBuilder builder)
        {
            //Get the current config and merge it into a new ConfigurationBuilder to keep the old settings
            var configurationBuilder = new ConfigurationBuilder();
            var descriptor = builder.Services.FirstOrDefault(d => d.ServiceType == typeof(IConfiguration));
            if (descriptor?.ImplementationInstance is IConfigurationRoot configuration)
            {
                configurationBuilder.AddConfiguration(configuration);
            }

            //build the config in order to access the appsettings for getting the key vault connection settings
            var config = configurationBuilder.Build();

            var vaultUrl = config["VaultUrl"];
            var vaultClientId = config["VaultClientId"];
            var vaultClientSecret = config["VaultClientSecret"];

            //add the key vault to the configuration builder
            configurationBuilder.AddAzureKeyVault(vaultUrl, vaultClientId, vaultClientSecret);

            //build the config again so it has the key vault provider
            config = configurationBuilder.Build();

            //replace the existing config with the new one
            builder.Services.Replace(ServiceDescriptor.Singleton(typeof(IConfiguration), config));

            //add the ConfigProvider if you want to use IConfiguration in your function
            //the ConfigProvider is just an implementation of IExtensionConfigProvider to give you access to the current IConfiguration
            builder.AddExtension<ConfigProvider>();
        }
    }
}

Continue reading “Azure Functions V2 – KeyVault and IConfiguration”

Local Docker Images on Kubernetes – Docker for Windows

Failed to pull image “testapp:latest”: rpc error: code = Unknown desc = Error response from daemon: pull access denied for testapp, repository does not exist or may require ‘docker login’

Why??? It is there…

I just installed Docker for Windows + Kubernetes on my PC because I wanted to test some changes I made to the Kubernetes C# client, so I quickly created an easy .Net Core Console App and made an image with:

FROM microsoft/dotnet:2.1-sdk-alpine AS build 
WORKDIR /app

# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out

FROM microsoft/dotnet:2.1-runtime-alpine AS runtime
WORKDIR /app
COPY --from=build /app/out ./
ENTRYPOINT ["dotnet", "TestApp.dll"]

Then I built it with:

docker build -t testapp .

Checked the images in docker:

Good, it is in my local image store. So I could run it now in Kubernetes with the Kube file I created:

apiVersion: batch/v1
kind: Job
metadata:
  name: testapp-job
  labels:
    app: testapp
spec:
 template:
   spec:
      containers:
      - name: testapp-job
        image: testapp:v1
      restartPolicy: Never

So I ran:

kubectl create -f .\Kube.yml

And checked the Kubernetes Dashboard:

Well it has nothing to do with the login or the repository. It’s more about the tag, it makes Kubernetes not look into your local store for some reason.

How do you fix this:

Just apply a different tag and use that. As simple as that.

Continue reading “Local Docker Images on Kubernetes – Docker for Windows”