4 个版本 (1 个稳定版本)
| 1.3.0 | 2022年1月4日 |
|---|---|
| 0.1.2 | 2021年12月28日 |
| 0.1.1 | 2021年12月27日 |
| 0.1.0 | 2021年12月27日 |
在 命令行工具 中排名第 2552
395KB
1.5K SLoC
具有额外功能的 Docker 抽象层
快速旅行:
这个工具最初是为了简化开发多个需要相互交互的小型项目/api，通过允许每个项目定义其容器化启动方式而诞生的。我敢说，现在它甚至可以用来 在一定程度上 协调小型服务网络的工作方式。当您不需要 Kubernetes 的可扩展性时，我想。
它是什么
总的来说，它不是拥有一个包含大量服务的庞大 docker-compose.yml 文件，而是在您的项目中分散多个较小的文件。
当服务之间的依赖性增加时，大型 compose 文件会很快变得难以管理。Carbon 旨在通过让每个服务对其自身负责，而不是集中在一个文件中，在一定程度上解决这个问题。
它的工作原理
-
Carbon 需要一个
.env文件才能正常运行。这是您定义所有迷你项目位置的地方。如果您在一个组织中工作，该组织内的所有项目（希望）都在同一个目录中。这就是您告诉 Carbon 查找的目录，通过设置PROJECTS_DIRECTORY环境变量。如果使用.env文件，所有这些变量也将提供给carbon.yml文件（请阅读下面的内容以了解更多信息）。您可以使用carbon env add <file_path> <alias>命令将.env文件添加到 Carbon。 -
每个服务都有权在其目录中定义一个
carbon.yml文件。这个文件可以包含在正常docker-compose.yml文件中写入的service:块中的内容。这个 carbon 文件告诉 Carbon 如何启动该服务。 -
每个服务也可以在其目录内定义一个
carbon-isotope.yml文件。这个文件可以用来存储服务的第二种配置。我个人一直在使用这个来设置完全相同的服务，但将其所有端口暴露出来，以便用于开发。 -
一旦你准备好了
.env文件，并且你的项目之一包含一个carbon.yml文件，你就可以使用carbon service start <服务名称>命令启动该服务。请注意，Carbon 会查看一个与您提供的名称相同的目录。这是一个当前的限制：容器名称 + 目录名称需要匹配。
这就是 Carbon 在 docker compose 之上添加的所有额外功能。它确实添加了一些包装功能，使使用 docker cli 变得更容易。请查看 覆盖 部分。
覆盖
Carbon 也做 Docker 的事情，有时做得更好。
- 命令返回彩色输出/表格，以便更清晰地了解您正在查看的内容。
- Carbon 有一个命令可以快速启动一个新的服务，并将其立即添加到现有的 Docker 网络中。
- 显示网络信息
- 显示容器信息
- 在飞行中重建已运行的服务。当镜像已更新并且需要硬重置时很有用。这将在服务之前将其终止（至少目前是这样的）。
- 轻松管理环境变量
- 启动服务
- 停止服务
- 创建网络
- 删除网络
- 连接到网络
- ...等等
安装
- 目前，安装是通过
cargo完成的，因为它能满足我的需求。
cargo install carbon-cli
- 还为您添加了一个 shell 别名，因为否则它将被命名为
carbon-cli。只是carbon已经被占用，对此我无能为力。
只需确保您在 主目录 中有一个 .local 目录。Carbon 将在此处跟踪您在使用过程中选择的所有设置（在一个名为 carbon-footprint.yml 的文件中）
技巧
以下是一些可能有用的小信息
- 可以使用多个
.env文件，因为每个文件在添加时都会被赋予一个别名，以后也可以将其设置为 活动。使用carbon env ls列出所有.env文件。Carbon 总是使用 活动 的.env文件。 - Carbon 的每个子命令都有一个别名（通常是原始命令的第一个字母）。例如，
list的别名为ls。 - 服务
start、stop、add和rebuild命令都可以用于多个服务。您不必多次运行命令，只需运行一次，包括所有内容即可。之后您可以整理网络。
获取帮助
如果您认为某件事应该感觉正常，但实际上并不正常，请遵循清单
- 您是否通过添加
-h标志来查看命令的正确用法？例如：carbon service -h。 - 您是否阅读了（非常基础的（抱歉））有关一切应该如何工作的说明？（定义在上方）
- 在讨论中搜寻，看看是否有任何可能与你问题相关的内容。
紧急情况：如果上述任何方法都没有帮助。请开始一个讨论并标记贡献者。不要直接创建问题，因为这可能根本不是问题。可能是我们这里的文档不够完善，或者根本就不是一项实际的功能。
贡献
如果你认为某个功能出了问题，或者应该实现，或者存在一个bug（意外的功能），讨论它是确保你想要的实际上发生的最有效方法。除非你想要自己动手实现它，这也是完全可以接受的。
以下是你可以这样做
- 关于它开始一个讨论。确保将所有似乎相关的各方都拉进来。
- 说出你的想法。
这是一个积极维护的工具，因为我确实在自己的项目中经常使用它，然而除非我需要一个功能，否则我不知道有什么缺失，所以让事情发生最好的方式就是提出它。
请注意，与修复相关的提交应以fix:开头，与功能相关的提交应以feat:开头。这允许git-cliff在每次发布时构建关于发生了什么的良好总结。
图片
如果你更倾向于视觉形式，这里有一些以图片形式展示的使用方法
- 帮助菜单
- 列出所有可用的容器/服务
- 列出所有可用的网络
- 启动名为
hemingway的服务
- 停止名为hemingway的服务
依赖项
~3.5–4.5MB
~83K SLoC