我们是一家软件供应商，目前正在对Docker尤其是Kubernetes进行总体研究，以使客户能够在其环境中安装我们的软件堆栈。 我们的软件带有一整套命令行工具，这些命令行工具主要用于管理目的。虽然大多数管理任务可以通过UI完成，但其他管理任务只能通过这些工具完成。 我们考虑了向在Docker上运行我们的软件的客户提供这些工具的方法。首先想到的是为他们提供一个大的存档，他们可以下载并在管理计算机上运行。 但是我们很快想到了提供一个包含所有这些工具的“管理工具”容器的想法。与我们的其他容器不同，该容器并不是要作为服务器运行，而是可以通过脚本或交互方式运行。 甚至认为相应的docker或kubectl命令行会有点冗长，这种方法大都可行，而且我认为该方法具有一定的优势，因为这也是发布命令行工具的“带内”方式。 但是，某些管理任务要求您将文件传递到相应的命令行工具，或者工具会生成文件（例如备份）。因此，您需要一种将这些文件放入或取出容器的方法。 在Docker环境中，使用“ docker run”将卷或主机目录装载到包含文件的容器中非常简单。 但是，在Kubernetes中，这似乎并不那么简单（请参见Create kubernetes pod with volume using kubectl run，了解使用“ kubectl run” ... Yikes来执行此操作的方法）。 在具有卷挂载的常规pod（使用YAML文件创建）中运行管理工具容器并附加到它实际上更为简单。
最后，我想听听您对标题问题的看法：为用户提供用于管理容器化应用程序的命令行工具的“最佳”方法是什么？
问候 PJ
答案 0 :(得分：2)
您要 Kubernetes运营商。
人们不想使用您的CLI，他们只是在使用CLI来“完成工作”。如果您可以将CLI操作放入Kubernetes Operator中，那么您将获得任何其他工具都可以使用的标准API。
例如，假设我们的软件有点像数据库。您的操作员可能会有一个代表每个数据库的条目，其中将包含“备份频率”和“副本数”字段。任何工具（甚至kubctl CLI）都可以设置这些字段，并且操作员会进行所有肮脏的工作来实现它。您的客户安装了一个操作员，他们不必管理“完成工作”的临时容器，也不必了解您的CLI。
答案 1 :(得分：1)
以下选项应可供用户使用：
https://cmd.io/ 答案 2 :(得分：0)
我和下一个软件工程师一样喜欢命令行工具。我认为 Docker不应该成为您解决方案的一部分。
作为工具使用者，我非常清楚这两个重要的细节：我需要root等效特权才能在Docker中运行某些东西，并且Docker容器与我的主应用程序具有独立的文件系统空间。以Docker本身为例，很高兴知道我可以
docker images | grep dmaze | awk '{ print $1 ":" $2 }' | xargs docker rmi
但是如果我将docker替换为扩展的docker run -e ... -v ... -v ... vendor/imagename command调用，这将变得更加困难。
类似地，值得浏览Stack Overflow以查找类似问题：
我已经将工具打包在Docker中。我正在尝试运行它。我需要什么
docker run -v选项来授予它访问文件的权限？它不以root用户身份运行；我需要什么权限设置？如果我有一个文件引用了另一个文件，如何使文件名在环境之间保持一致？我忘了docker run -v，现在我的输出文件已经全部消失了吗？
如果您的工具打包为Docker映像，那么您会将所有这些复杂性推给用户。对我来说，只需将一些东西放到$PATH中即可。
作为工具供应商，给您带来的好处似乎很小。 Docker映像是单个工件，但是tar文件也是。您可能可以依赖一组通用的基础C库和易于使用的语言运行时。例如，您可以使用标准的Python库完成很多工作，几乎每个Linux安装都将提供可用的库。
Kubernetes在这里绝对不适用。这对于在集群环境中运行分布式应用程序最有用。一些非常敬业的开发人员可能有minikube可用，但这不是日常工作，并且在Kubernetes pod中获得交互式shell比在Docker容器中获得交互式shell更是一个例外（或者应该这样做）。是）。