Make your own docker command!

jacob — Thu, 05 Mar 2020 20:40:49 +0000

I saw this post about a custom cli app to make it just a little nicer to quickly shell in to a local docker container:

Docket : connect to your docker's container easily !

pob ・ Mar 5 ・ 2 min read

And I thought, what if instead of a brand new command, it was part of the docker cli? It's not well advertised, but you can! So I installed it as a custom docker command. Official docs here.

There are a couple rules.

Where does the script go? I wanted to run docker goto. The easiest choice for me was ~/.docker/cli-plugins/docker-goto. Whatever subcommand name you want, just prefix it with "docker-"
You must have a subcommand called "docker-cli-plugin-metadata". When I run docker goto docker-cli-plugin-metadata, it has to output specific json. This block is enough:
```
if [[ "$1" == "docker-cli-plugin-metadata" ]]; then
cat << HERE
{
  "SchemaVersion": "0.1.0",
  "Vendor": "example.com",
}
HERE
exit
fi
```
Make it executable: chmod +x ~/.docker/cli-plugins/docker-goto

Now you can make it do whatever you want! Full code in this gist.

Configure entity framework with dependency injection

jacob — Mon, 03 Feb 2020 23:25:41 +0000

Problem

You're following the configuration options pattern. To configure an entity framework context, you need to inject an IOptions container. But during ConfigureServices, the dependency injection container isn't ready.

Is this useful to me?

Should be relevant to at least asp core 2.2 and 3.x.

Solution

Entity framework lets you provide a context factory. The factory is defined during ConfigureServices, but it's only used after. Use the overload with a callback that includes an IServiceProvider. The IServiceProvider gives access to the DI container, so you can access any IOptions.

public void ConfigureServices(IServiceCollection services)
{
  services.Configure<DatabaseSettings>(o =>
  {
    o.Database = "some db";
    o.Username = "some user";
    o.Password = "some password";
  });

  services.AddDbContextPool<MyDbContext>((IServiceProvider sp, DbContextOptionsBuilder builder) =>
  {
    var dbsettings = sp.GetRequiredService<IOptions<DatabaseSettings>>();
    var env = sp.GetRequiredService<IWebHostEnvironment>();
    builder.UseNpgsql(dbsettings.Value.GetConnectionString());
    builder.EnableSensitiveDataLogging(env.IsDevelopment());
  });
}

public class DatabaseSettings
{
  public string Database { get; set; }
  public string Username { get; set; }
  public string Password { get; set; }
  public string GetConnectionString() => new NpgsqlConnectionStringBuilder
  {
    // ...
  }.ConnectionString;
}

For this to work, your context must have a single constructor. That constructor must accept a DbContextOptions object:

public class MyDbContext : DbContext
{
  // ...

  public MyDbContext(DbContextOptions options) : base(options) { }
}

You can override OnConfiguring if you like, the docs say:

If both are used, OnConfiguring is applied last and can overwrite options supplied to the constructor argument.

Can I use IConfigureOptions?

No.

Lots of things need to be configured inside ConfigureServices, but also need IOptions. Entity framework uses a factory callback pattern. Another pattern asp core uses is IConfigureOptions. Ef core 3.1 does not use the IConfigureOptions pattern.

Forem: jacob