问题描述
这个问题来自一位小型开发团队，他们需要在 Azure 上部署应用程序并进行持续集成和持续交付（CI/CD）。他们的团队规模小，主要的开发工作是连接他们的 ERP 系统与一些电商平台（如 Amazon、Walmart、Wayfair 等），还会开发一些内部工具来简化用户的一些任务。目前，他们使用 GitHub 进行版本控制，但是除此之外，并没有任何 CI/CD 流程。他们的服务器是 Azure 上的虚拟机（VMs），任务是通过 Task Scheduler 调度的，日志则发送到一个 Graylog 服务器进行调试。他们使用 gRPC 和 Proto 来实现程序间的通信，但是并没有直接与 ERP 系统交互，而是通过一些 gRPC 服务来实现这一行为。由于缺乏 CI/CD，他们面临着代码部署控制不足、生产环境与 GitHub 上的代码不一致以及整体可视性不足等问题。
解决方案
在经过一些调研后，提出了几个可行的方案，但是也发现每个方案都有一些不适用的地方。以下是对每个方案的评估和解决方案的描述：
方案1：Docker 容器化
已经决定将应用程序和服务 Docker 容器化，这是一个很好的选择，具有许多优势。但是需要解决的问题是如何部署这些 Docker 容器以及保证它们的在线状态和定时任务的执行。
解决方案：
- 使用 Azure Container Apps：Azure Container Apps 是一个不错的选择，可以通过 GitHub Actions 进行 CI/CD，并且可以使用 dapr 来进行服务间的调用。但是需要注意它相对较昂贵，且没有直接支持定时任务的调度。
方案2：使用 Azure Container Instances 与定时任务
虽然 Azure Container Apps 不支持定时任务的调度，但是 Azure 还有其他的容器服务可以考虑，例如 Azure Container Instances，但是需要解决服务调度的问题。
解决方案：
- 结合 Azure Container Instances 和 Azure Functions：Azure Functions 可以用来实现定时任务的调度，将你的定时任务封装成 Azure Functions，并设置合适的触发器来调度它们。
方案3：Nomad
Nomad 是一个适合较小规模部署的替代品，它具有调度作业的能力，但是对于这个团队的开发需求来说，可能还是有一些复杂。
解决方案：
- Nomad 的简化使用：如果你决定使用 Nomad，可以考虑找到更简化的使用方式，或者参考一些 Nomad 的最佳实践，以减少配置和管理的复杂性。
方案4：Rundeck
Rundeck 是比较简单的方案，但是需要确保它适用于你的部署需求。
解决方案：
- 评估 Rundeck 的适用性：仔细评估 Rundeck 是否适用于你所需的部署场景，它能够满足你的定时任务和容器化部署的需求吗？
以上是几个可能的方案，根据团队的需求和偏好，可以选择最适合的方案来实现小规模的 CI/CD，确保代码的部署控制、版本一致性和可视性的提升。希望这些方案可以帮助你做出决策，如果还有其他问题，欢迎继续咨询！