Does this library still has external docker engine dependency?

[nithinbandaru1]

I have read this article which is great by the way.

One confusing thing about is this below block.

A container image is made of two primary parts: some JSON configuration containing metadata about how 
the image can be run, and a list of tarball archives that represent the file system. 

In .NET 7, we added several APIs to the .NET Runtime for handling TAR files and streams
(https://devblogs.microsoft.com/dotnet/announcing-dotnet-7-preview-4/#added-new-tar-apis,)
and that opened the door to manipulating container images programmatically.

This approach has been demonstrated very successfully in projects like Jib
(https://github.com/GoogleContainerTools/jib) in the Java ecosystem, 
Ko (https://github.com/google/ko) for Go, 
and even in .NET with projects like konet (https://github.com/lippertmarkus/konet). 
It’s obvious that a simple tool-driven approach to generate container images is becoming more popular.

1. Does this mean images are built by using this library itself or it generates the docker commands and execute them using installed docker engine.?

2. If it builds images by itself does this mean it follows the OCI specifications and also does this mean that at some point this library can be used as base for .NET based docker engines and docker engine GUIs?

[baronfel]

Hey @nithinbandaru1, thanks for the questions. This project is currently not a standalone library, but yes it does create OCI images following the spec. It does not require Docker to create the images, but the default mode of operation saves the newly-generated image to the local Docker daemon. This of course can be customized - you can push the image to any compliant container registry via the ContainerRegistry MSBuild property, or to a local .tar.gz file.

The tools built into the .NET SDK are not directly usable as a library - for that I might suggest using https://github.com/mthalman/DockerRegistryClient, though that library is very focused on the 'read' side of the equation. This repo originally started out as a library, but we combined the unopinionated library and the very opinionated MSBuild Task code early on for development convenience.

One of my longer-term wishlist items for this repo is to

• contribute write-based operations to https://github.com/mthalman/DockerRegistryClient
• contribute several protocol quirk lessons learned that are in the SDK tools to https://github.com/mthalman/DockerRegistryClient
• migrate the SDK tools to use https://github.com/mthalman/DockerRegistryClient as a base

[nithinbandaru1]

Thanks for the info @baronfel .

My second question is more of pointing towards local docker operations like build, run etc., (docker engine specific).
Also, right that pull, push part of local docker operations but more remote registry specific.

I think combining both SDK and this library (both read and write) would create a closer to docker engine tool 😀.

[baronfel]

@nithinbandaru1 maybe you're looking for a library more like https://github.com/dotnet/Docker.DotNet? This should let you interact with the Docker daemon directly from .NET.

[nithinbandaru1]

Hmm not really.

https://github.com/mthalman/DockerRegistryClient - Client for Docker registry.
https://github.com/dotnet/Docker.DotNet - Client for Docker engine.
These SDK build tool - Docker engine itself (With super small feature set now. If this is extended to full feature set and can be a standalone deployment, then Docker.DotNet can be a client lib for this).

Hope now it's clear what I mean.

[baronfel]

Ah, I think I see. The SDK tooling isn't going to grow to be a replacement for the Docker Engine itself. Docker has roughly three main parts:

• Docker the image builder syntax/data models (aka Dockerfiles, the OCI container schemas, etc)
• Docker the container runtime
• Docker the container registry

The SDK is only ever going to do the first part. You still need Docker or another container runtime to run the generated images, and the SDK doesn't really care about storing a lot of images (though we do store metadata/layers in our own cache strictly for building user app images).