docker - 为您的容器化应用程序提供自定义命令行工具的最佳实践是什么？

Question

我们是一家软件供应商，目前正在全面研究 Docker，特别是 Kubernetes，以允许客户在他们的环境中安装我们的软件堆栈。
我们的软件带有一大堆命令行工具，主要用于管理目的。虽然大多数管理任务都可以通过 UI 完成，但其他管理任务只能通过这些工具完成。
我们考虑了向在 Docker 上运行我们的软件的客户提供这些工具的方法。第一个想法是为他们提供一个大存档，他们可以下载并在他们的管理机器上运行。
但我们很快想到了提供一个包含所有这些工具的“管理工具”容器的想法。与我们的其他容器不同，这个容器并不是要作为服务器运行，而是可以从脚本或交互方式运行。
尽管相应的 docker 或 kubectl 命令行有点冗长，但这主要是可行的，我认为这种方法有相当多的优点，因为它是一种“带内”方式来发布我们的命令行工具。
但是，某些管理任务需要您将文件传递给相应的命令行工具或工具生成文件(例如，备份)。因此，您需要一种将这些文件放入或取出容器的方法。
在 Docker 环境中，使用“docker run”并将卷或主机目录挂载到包含文件的容器中非常简单。
不过，在 Kubernetes 中，这似乎并不那么简单(请参阅 Create kubernetes pod with volume using kubectl run 以了解使用“kubectl run”的方法......哎呀!)。
在带有卷挂载的常规 pod(使用 YAML 文件创建)中运行管理工具容器并附加到它实际上更简单。

最后，我想听听您对标题问题的看法:让用户可以使用用于管理容器化应用程序的命令行工具的“最佳”方式是什么？

将它们作为专用存档发送并让用户像在容器前世界中一样使用它们？

将它们装在旨在交互使用的容器中(如上所述)？

还有其他想法吗？

问候
PJ

Answer 1

你要 Kubernetes 运算符(operator) .

人们不想使用您的 CLI，他们只是使用您的 CLI 来“完成工作”。如果您可以将 CLI 操作放入 Kubernetes Operator，您将获得任何其他工具都可以使用的标准 API。

例如，假设我们的软件有点像数据库。您的运算符(operator)可以有一个代表每个数据库的条目，其中包含“备份频率”和“多少副本”字段。任何工具(甚至是kubctl CLI)都可以设置这些字段，而您的运算符(operator)会做所有的繁琐工作来实现它。您的客户安装一个运算符(operator)，他们不必管理“完成工作”的临时容器，也不必了解您的 CLI。