<p>we are a software vendor that is currently investigating Docker in general and Kubernetes in particular as a way to allow customers to install our software stack in their environment.
Our software comes with a whole bunch of command line tools, which are mainly used for adminstration purposes. While most admin tasks can be done through the UI, others can only be done through these tools.
We thought on ways to provide these tools to customers running our software on Docker. First thought was to just make a big archive available to them, which they can download and run on their admin machine.
But we quickly came up with the idea to instead provide an "admin tools" container that contains all these tools. Different from our other containers, this one is not meant to be run as a server, but to be run either from scripts or interactively.
Even thought the corresponding docker or kubectl command lines get a bit lengthy, this mostly works and I think the approach has quite some merit, as it is an "in-band" way to also publish our command line tools.
However, some administration tasks require you to pass files to the respective command line tool or the tools generate files (e.g., backups). So you need a way to get these files into or out of your container.
In a Docker environment, it is quite straightforward to use "docker run" and mount a volume or host directory into your container which contains the files.
In Kubernetes, this seem to be not as straightforward, though (see <a href="https://stackoverflow.com/questions/37555281/create-kubernetes-pod-with-volume-using-kubectl-run">Create kubernetes pod with volume using kubectl run</a> for an approach to do this with "kubectl run"... Yikes!).
Running the admin tools container in a regular pod (created with a YAML file) with a volume mount and attaching to it is actually simpler.</p>

<p>In the end, I would like to get your thoughts on the title question: What is the "best" way to make command line tools for the administration of containerized applications available to their users?</p>

<ul>
<li>Ship them as a dedicated archive and let users use them as they did in the pre-container world?</li>
<li>Ship them in containers that are meant to be used interactively (as described above)?</li>
<li>any other ideas?</li>
</ul>

<p>Regards
PJ</p>

PalatinateJ
<p>You want <strong>Kubernetes Operators</strong>.</p>

<p>People don't want to use your CLI, they are only using your CLI to "get stuff done". If you can put your CLI actions into a Kubernetes Operator, you get a standard API that any other tool can use.</p>

<p>For example, let's say our software is kinda like a database. Your operator could have an entry representing each database, which would have fields for "how often to backup" and "how many replicas". Any tool (or even the <code>kubctl</code> CLI) can set those fields, and your operator does all the dirty work to make it happen. Your customers install a single operator, and they don't have to manage the transient containers that "get work done", nor do they have to understand your CLI.</p>
