systemd 与 gitlab cicd
systemd vs gitlab cicd
这可能是个疯狂的问题 -
我想托管一个算法交易系统，它将在上午 9 点触发并运行到下午 3 点。我正在考虑使用 systemd 作为服务托管或使用 gitlab cicd 来触发它。 （我可以随时在这里观看activity）。
最好的选择是什么？ 运行 一整天的 cicd 可靠吗？
我知道你的赏金是说你正在寻找一个规范的答案，但我不认为这个问题真的存在这样的答案，因为根据你的用例没有真正正确的答案。
您绝对可以创建一个 CI/CD 作业并将超时设置为 6 小时，但我认为这并不是您真正想要的。听起来您基本上只是想要一个每天开始并处理您的交易的后台工作。如果作业中的某些内容失败，您可能还需要通知，或者您可能希望它自动重新启动作业。
Systemd 是执行此操作的最简单方法，KISS 始终是设计解决方案时应遵循的良好原则。使用 GitLab 需要您托管 GitLab 服务本身，以及每天执行作业的 运行ner，而 Systemd 只需要您注册该服务。
如果您扩展到尝试同时处理 运行 许多此类作业的程度，您仍然可能会更好地使用 Apache Airflow（或 AWS 步进函数）等工作流管理器等）。
所以总的来说，我不会推荐 CI/CD 解决方案 运行 什么是有效的作业服务器。在规模较小时从 Systemd 开始，然后在需要扩展时迁移到真正的工作流解决方案。
这可能是个疯狂的问题 - 我想托管一个算法交易系统，它将在上午 9 点触发并运行到下午 3 点。我正在考虑使用 systemd 作为服务托管或使用 gitlab cicd 来触发它。 （我可以随时在这里观看activity）。
最好的选择是什么？ 运行 一整天的 cicd 可靠吗？
我知道你的赏金是说你正在寻找一个规范的答案，但我不认为这个问题真的存在这样的答案，因为根据你的用例没有真正正确的答案。
您绝对可以创建一个 CI/CD 作业并将超时设置为 6 小时，但我认为这并不是您真正想要的。听起来您基本上只是想要一个每天开始并处理您的交易的后台工作。如果作业中的某些内容失败，您可能还需要通知，或者您可能希望它自动重新启动作业。
Systemd 是执行此操作的最简单方法，KISS 始终是设计解决方案时应遵循的良好原则。使用 GitLab 需要您托管 GitLab 服务本身，以及每天执行作业的 运行ner，而 Systemd 只需要您注册该服务。
如果您扩展到尝试同时处理 运行 许多此类作业的程度，您仍然可能会更好地使用 Apache Airflow（或 AWS 步进函数）等工作流管理器等）。
所以总的来说，我不会推荐 CI/CD 解决方案 运行 什么是有效的作业服务器。在规模较小时从 Systemd 开始，然后在需要扩展时迁移到真正的工作流解决方案。