本文介绍了使用gitlabRunner在Windows EC2上开始构建的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

gitlab CI的新手.我有一个自定义的Windows AMI(带有必需的预安装软件),我想在其中运行构建.

New to gitlab CI. I have a custom windows ami (with required pre-installed software) where I would like to run the build.

我的一个选择是保持该实例始终为ON并在其上安装运行程序,但这似乎是对计算的浪费(我已经尝试过此设置).

One of my options is to keep this instance always ON and install the runner on it, but that seems like a waste of compute (I have already tried this set up).

我可以从gitlab CI启动实例吗?我意识到跑步者仍然需要在某个地方运行,可能是在较低层的机器上.我提到了gitlab上提供的AWS自动缩放文档,但它着重介绍了如何使用docker自动缩放.我无法使用与自定义映像绑定的docker设置.

Can I start the instance from gitlab CI? I realize that the runner still needs to be running somewhere, probably on a lower tier machine. I referred to the AWS autoscaling doc available on gitlab, but it highlights how to autoscale with docker. I cannot use the docker setup, kind of tied to the custom image.

如何在ec2实例中生成并运行管道?

How can I spawn and run my pipeline in the ec2 instance?

推荐答案

Gitlab不知道跑步者在哪里跑步,他们只会知道跑步者是否连接了,所以不,Gitlab本身将无法启动一个实例.

Gitlab has no knowledge of where the runners are running, they will only know if a runner is connected or not, so no, Gitlab itself would not be able to start up an instance.

但是,您可以做的是专门做一个小实例,点击Gitlab API,以确定有多少未完成的作业以及有多少工作人员可以使用它.如果没有跑步者,但有工作要做,请启动跑步者实例.如果有跑步者但没有工作,请停止实例.

What you can do however is dedicate a small instance to hitting the Gitlab API to determine how many pending jobs there are and how many runners are available to work it. If there are no runners but there are jobs to be worked, start a runner instance. If there are runners but no jobs, stop an instance.

以下是一些方便使用的Gitlab API:

Here are some Gitlab API's that should come in handy:

  • Runners API(获取跑步者列表,注册新跑步者,删除跑步者等): https://docs.gitlab.com/ee/api/runners.html
  • 管道API(获取项目的管道,获取单个管道等)
  • 作业API(获取管道作业,取消作业,重试等)

这是我将如何实施:首先,我要为最大跑步者定义一个阈值,为最大跑步者定义一个阈值,然后再将跑步者增加1.例如,也许我希望一次不超过10个跑步者,并且队列中不超过6个工作在我添加另一个跑步者(最大数量)之前.

Here's how I would implement it:First, I'd define a threshold for max runners, and one for max pending jobs before increasing the runners by 1. For example, maybe I want no more than 10 runners running at at time, and no more than 6 jobs in the queue before I add another runner (up to the max).

然后

  • 点击Runners API以获取跑步人数.
  • 点击Projects API,以获取所有启用了管道的项目.
  • 为每个项目点击管道API,以获取所有待处理/进行中的管道.
  • 为每个管道点击作业API,以获取所有待处理的作业
  • 如果没有跑步者,但有待处理的工作,则添加1个跑步者.
  • 如果有1个以上的跑步者但少于最大跑步者,并且大于工作阈值,则将1个跑步者加至最大.
  • 如果跑步者多于0个且没有待处理的工作,则销毁一个休眠的跑步者(并从Gitlab中注销它,以便Runners API调用保持干净).
  • 睡一两分钟,然后从顶部循环.

这只是一个简单的示例,可以轻松扩展以满足您的需求.

This is just a simple example and can easily be extended to fit your needs.

这篇关于使用gitlabRunner在Windows EC2上开始构建的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-25 00:21