brandon/oam
1
0
Fork 0
mirror of https://gitea.com/mcereda/oam.git synced 2026-02-09 05:44:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore(gitlab/runner): improve readability

Browse Source
This commit is contained in:
Michele Cereda
2024-11-06 21:16:01 +01:00
parent 43bcd3b57c
commit a3b8e1bdeb
1 changed files with 34 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
knowledge base/gitlab/runner.md
View File

@@ -45,14 +45,14 @@ gitlab-runner exec docker \
# Force a configuration file reload.
sudo kill -HUP $(pidof 'gitlab-runner')
sudo kill -s 'SIGHUP' $(pidof 'gitlab-runner')
sudo pkill --signal 'SIGHUP' 'gitlab-runner'
```
</details>
Each runner executor is assigned 1 task at a time by default.
Each _Worker_ is assigned a single task at a time by default.
Runners require the main instance to give the full certificate chain upon connection.
Runners require the Server to provide the full certificate chain upon connection.
The `runners.autoscaler.policy.periods` setting appears to be a full blown cron job, not just a time frame.
@@ -63,17 +63,17 @@ Given the following policies:
```toml
[[runners]]
[runners.autoscaler]
[[runners.autoscaler.policy]]
[[runners.autoscaler.policy]] # policy 1
periods = [ "* 7-19 * * mon-fri" ]
…
[[runners.autoscaler.policy]]
[[runners.autoscaler.policy]] # policy 2
periods = [ "30 8-18 * * mon-fri" ]
…
```
It will **not** work as _apply policy 1 between 07:00 and 19:00 but override it with policy 2 between 08:30 and
18:30_.<br/>
Instead, the runner will:
Instead, the Runner will:
- Apply policy 1 every minute of every hour between 07:00 and 19:00, **and**
- Override policy 1 by applying policy 2 only on the 30th minute of every hour between 08:00 and 18:00.
@@ -82,15 +82,15 @@ Meaning it will reapply policy 1 at the 31st minute of every hour in the period
</details>
One can use system signals to interact with runners.
One can use system signals to interact with Runners.
<details style="margin-top: -1em; padding: 0 0 1em 1em;">
| Signal | Command it operates on | Effect | Example |
| ---------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| `SIGINT` | `register` | Cancel ongoing runner registrations.<br/>Delete runners if already registered. | |
| `SIGINT` | `register` | Cancel ongoing Runner registrations.<br/>Delete Runners if already registered. | |
| `SIGINT`<br/>`SIGTERM` | `run`<br/>`run-single` | Abort all running builds and exit as soon as possible.<br/>Use twice to exit immediately (forceful shutdown). | |
| `SIGQUIT` | `run`<br/>`run-single` | Stop accepting new builds and exit as soon as currently running builds finish (graceful shutdown). | `sudo kill -SIGQUIT <main_runner_pid>` |
| `SIGQUIT` | `run`<br/>`run-single` | Stop accepting new builds and exit as soon as the currently running builds finish (graceful shutdown). | `sudo kill -SIGQUIT <main_runner_pid>` |
| `SIGHUP` | run | Force reloading the configuration file. | `sudo kill -SIGHUP <main_runner_pid>` |
> Do **not** use `killall` or `pkill` for graceful shutdowns if one is using the `shell` or `docker` executors.<br/>
@@ -101,6 +101,8 @@ One can use system signals to interact with runners.
## Pull images from private AWS ECR registries
FIXME
1. Create an IAM Role in one's AWS account and attach it the
`arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly` IAM policy.
1. Create and InstanceProfile using the above IAM Role.
@@ -163,15 +165,22 @@ Autoscale-enabled wrap for the `docker` executor. Supports all `docker` executor
Creates instances on-demand to accommodate jobs processed by the runner leveraging it, which acts as manager.<br/>
The runner itself will **not** execute jobs, just delegate them.
A Runner registers to the Server and acts as Runner Autoscaler.<br/>
The Autoscaler shall be configured to use `docker-autoscaler` as the executor, and shall be granted permissions to
discover and scale the resources it uses to scale automatically.
Leverages [fleeting] plugins to scale automatically.<br/>
Fleeting is an abstraction for a group of autoscaled instances, and uses plugins supporting cloud providers.
This is an abstraction for a group of automatically scaled instances, and uses plugins supporting cloud providers.
Both the manager and the instances executing jobs require the Docker Engine to be installed.<br/>
The manager will connect to the instances via SSH and execute Docker commands. The user it connects with **must** be
able to execute those commands commands (most likely by being part of the `docker` group on the instances).
The Autoscaler connects to the Workers through SSH (if Linux-based) and executes Docker commands.<br/>
The user it connects with **must** be able to execute Docker commands with**out** a password (most likely by being part
of the `docker` group on the Worker).
Container images are pulled by the manager and sent to the instances it creates.<br/>
The instances do **not** require container registry access themselves this way.
Jobs are executed in containers.<br/>
The container images are pulled by the Autoscaler, which then feeds them to the Workers. As such:
- Workers do **not** need direct image access.
- **Both** the Autoscaler **and** the Workers require the Docker Engine to be installed.
<details>
<summary>Setup</summary>
@@ -251,7 +260,7 @@ Requirements:
- Desired capacity = 0.
The runner will take care of scaling up and down.
- An IAM Policy granting the **manager** instance the permissions needed to scale the ASG.<br/>
- An IAM Policy granting the **Autoscaler** instance the permissions needed to scale the ASG.<br/>
Refer the [Recommended IAM Policy](https://gitlab.com/gitlab-org/fleeting/plugins/aws#recommended-iam-policy).
<details style="margin-top: -1em; padding-bottom: 1em;">
@@ -295,8 +304,8 @@ Requirements:
</details>
- \[if needed] The [amazon ecr docker credential helper] installed on the **manager** instance.
- \[if needed] An IAM Policy granting the **manager** instance the permissions needed to pull images from ECRs.
- \[if needed] The [amazon ecr docker credential helper] installed on the **Autoscaler** instance.
- \[if needed] An IAM Policy granting the **Autoscaler** instance the permissions needed to pull images from ECRs.
<details style="margin-top: -1em; padding-bottom: 1em;">
@@ -338,8 +347,8 @@ Procedure:
</details>
1. Install the gitlab runner on the **manager** instance.
1. Configure the runner to use the `docker-autoscaler` executor.
1. Install GitLab Runner on the **Autoscaling** instance.
1. Configure the Runner to use the `docker-autoscaler` executor.
<details style="margin-top: -1em; padding-bottom: 1em;">
@@ -347,7 +356,7 @@ Procedure:
concurrent = 10
[[runners]]
name = "docker autoscaler"
name = "runner autoscaler using docker autoscaler"
url = "https://gitlab.example.org"
token = "<token>"
executor = "docker-autoscaler"
@@ -387,6 +396,8 @@ Procedure:
> If using this executor with EC2 instances, Azure Compute, or GCE, migrate to the
> [GitLab Runner Autoscaler](#gitlab-runner-autoscaler).
<details style="padding: 0 0 0 1em">
[Supported cloud providers][docker machine's supported cloud providers].
Using this executor opens up specific [configuration settings][docker machine executor autoscale configuration].
@@ -518,6 +529,8 @@ concurrent = 40
</details>
</details>
### Instance executor
Refer [Instance executor](#instance-executor).