Docker Support for Isolator

Introduction

Some of you may remember - and hopefully have even tried! - my Isolator project. Isolator is a framework for running isolated code for .NET. What this means is that possibly unsafe code can be run in a secure, isolated, way.

It offers some quite different isolation strategies:

  • Process isolation: the code to execute runs in another process, possibly under a different identity (on Windows only)
  • Assembly isolation: uses an assembly load context to isolate the code execution, which is then unloaded
  • Distributed isolation: the code to execute is sent to possibly another server for execution
  • Scanned: the code to execute is first checked for problematic code using my ReferencesScanner project

Now, I added support for Docker isolation! What this means is, if you have Docker running on your machine, you can spawn an image that will just be used for running your code, and after that will be gone. This provides another very restricted level of isolation.

For Docker API calls, I used Docker.DotNet, a great library for interacting with Docker from the .NET Foundation that even has a small contribution by myself. Another option would be to use TestContainers, something for later.

I strongly advise you to have a look at my first post before proceeding, so that you have the concepts present.

Using Docker Isolation

There is a new class, DockerIsolatorHost, that also implements IIsolationHost.

In order to use the new mechanism, you need to have Docker running, either locally or on a remote server that can be accessed:

using var host = new DockerIsolationHost(); //we can pass URL and credentials if we want to
var plugin = new HelloWorldPlugin(); //see example from my original post
var context = new IsolationContext
{
    Properties = new Dictionary<string, object>
    {
        ["Greeting"] = "Hello, World!"
    },
    Arguments = ["This", "is", "a", "test"]
}; 
var result = await host.ExecutePluginAsync(plugin, context);

And that's it, everything works in exactly the same way, including:

  • The result from the plugin is returned with the right type
  • The context's properties are also updated, which means you can use them for returning values
  • The standard output and error for the execution are captured and returned

By default, an image for .NET 9 is used (mcr.microsoft.com/dotnet/runtime/9.0), but we can specify a different one by setting the NetVersion property (only major and minor versions, make sure the version exists first!):

host.NetVersion = new Version(10, 0);

Also, it is required to add a reference to Isolator.Docker Nuget package to your project, this is the one that contains the bootstrap app (not to be used directly), you don't need the Isolator package as it is imported automatically. Most important: only .NET up to version 9 packages can be used for the plugin, as that's the version that Isolator has been built against! Something to revisit soon.

Behind the scene, what it does is:

  • Creates a container from an official Microsoft .NET image (from mcr.microsoft.com/dotnet/runtime)
  • Binds the folder containing the assembly of the plugin type to the container working directory
  • Sets as the execution target a bootstrap app (from Isolator.Docker) which takes as its parameters the plugin type to execute plus the context (I'd like to get rid of this additional assembly but for now we will have to live with it)
  • Starts the container and extracts the results from its output
  • Removes the container when finished

Mind you, this is transparent to us, all we need is the code I've shown. I may be adding some more options to this one in the future, to control some aspects of Docker.

Conclusion

As always, I hope you find this useful. There may still exist some strategies to implement, feel free to suggest or ask anything by creating an issue on the GitHub repo here.

GitHub: https://github.com/rjperes/Isolator

Nuget: https://nuget.org/packages/Isolator.Docker

Location: Coimbra, Portugal

Comments

Post a Comment

Popular posts from this blog

Modern Mapping with EF Core

Image
Introduction In EF Core (as in most O/RMs) we can map and store multiple things: Objects that hold a single value, like int , string , bool , float , Guid , DateTime , TimeSpan , Uri , etc. These are (somewhat wrongly) called primitive types  and are always included inside some container, like the following Objects that hold multiple single values and which have an identity, for example, Customer , Product , Order . These are called entity types  and they must have an identity that makes them unique amongst all the other objects of the same type Objects that are structured to hold multiple values, but have no identity, such as Address , Coordinate . These are called value types  and are merely a collection of (possibly related) properties We can also have collections of the previous things There's more to it, of course, for example, it is even possible to represent  inheritance of entities , of which I talked about before , In this post I am going to cover so...
Read more

C# Magical Syntax

Introduction This post is an update to an old one on my  old blog  and it was inspired by my latest posts on C# versus Java . You may not have realized that some of the patterns that you’ve been using for ages in your C# programs are based on conventions, rather than on a specific API. What I mean by this is, some constructs in C# are based on some magical methods with well-defined names which are not defined in any base class or interface, but yet just work. Let’s see what they are. Enumerating Collections You are probably used to iterating through collections using the foreach statement. If you are, you may know that foreach actually wraps a call to a method called GetEnumerator , like the one that is defined by the IEnumerable and IEnumerable<T> interfaces. Thus, you might think, the magic occurs because the collection implements one or the two, but you would be wrong: it turns out that in order to iterate through a class using foreach all it takes is that the c...
Read more

.NET 10 Validation

Note: this is an update to my original post . Introduction I wrote about  entity validation  in the past, the reason I'm coming back to it is that there are some changes in .NET 10, related to validation. Let's cover the original validation API and then explain what has changed. .NET Validation Validation is implemented in the System.ComponentModel.DataAnnotations namespace. I'll describe it first and then move to the small changes in .NET 10. .NET has featured a way to validate classes and their properties for a long time, the API is called  Data Annotations Validation , and it integrates nicely with ASP.NET Core MVC and other frameworks (not Entity Framework Core, as  I've talked recently , nor ASP.NET Core Minimal APIs ). It is essentially, but not just, based on a set of attributes, one interface, and a class that performs validations on a target class and its properties, from the validation attributes it contain. The base class for attribute validation is ca...
Read more