我是一个经验丰富的开发人员。我对Docker、Jenkins、Git、Kubernetes有着广泛的了解。。
我有一个现有的jenkins工作，它从我们的Git回购中检查一些东西，构建一个docker映像，并将其推送到AWS ECR。这显然需要在我们的jenkins实例上预先安装一些东西(curl、aws-cli、docker等(
我们可以访问由外部团队管理的GitLab实例。我对我们的"群"拥有所有者特权。我想在GitLab中重新创建我的詹金斯工作，所以(天真地(我只是做了这样的事情：
stages: # List of stages for jobs, and their order of execution
- build
pre-install: # install various pre-requisite tools
script:
- apt-get update && apt-get -y upgrade && apt-get autoremove && apt-get autoclean
- apt-get install -y unzip curl jq wget
- etc.
- #install docker here etc.
- #Build etc.
- push to ecr etc.
因此，我了解到GitLab实际上是在我无法访问的kubernetes集群中的某种容器中调用这些构建。我认为这被称为"自动devops"？
以下是一些问题：
- 如果我想在auto-devops提供的"runner"中预装一些东西(假设是这样(，我该怎么做？我甚至可以用我的访问级别做到这一点吗？也就是说，我假设作业在docker容器中运行，我如何构建和指定用于该容器的映像
- 我可以用"auto-devops"构建一个docker镜像吗(有一种东西叫"docker In docker"(DIND(，但它的文档看起来像是用斯瓦希里语写的
- 有人能给我一段解释吗？"哦，是的，我知道你在哪里，这就是gitlab的真实含义，超越了git repo和jenkins等。">
谢谢。
在Gitlab CI中，Gitlab运行者是阶段的执行者。它们有不同的类型——这里有描述https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-遗嘱执行人。
你不需要访问跑步者正在运行的机器。构建取决于运行程序类型，例如，如果shell-在远程服务器上(而不是在docker中(，如果docker-在容器中(通常图像在.gitlab ci.yml中指定(，等等
如果您想预安装一些东西，请使用before_script(最好使用default，因为before_script已经是一个过时的构造
例如
image: gcc
build:
stage: build
before_script:
- apt update && apt -y install make autoconf
script:
- g++ helloworld.cpp -o mybinary
这是DIND
DIND这是从容器到运行主机的Docker守护进程的连接(例如，允许在Docker容器中构建程序(
以下是对关键词的责任的完美描述https://docs.gitlab.com/ee/ci/yaml/