Commit a7488ca1 authored by Evan Read's avatar Evan Read Committed by Steve Azzopardi

Fix anchors in Runner documentation

parent 71689b3d
......@@ -459,7 +459,7 @@ found in the separate [runners autoscale documentation](autoscale.md).
| `MaxBuilds` | Builds count after which machine will be removed. |
| `MachineName` | Name of the machine. It **must** contain `%s`, which will be replaced with a unique machine identifier. |
| `MachineDriver` | Docker Machine `driver` to use. More details can be found in the [Docker Machine configuration section](autoscale.md#supported-cloud-providers). |
| `MachineOptions` | Docker Machine options. More details can be found in the [Docker Machine configuration section](autoscale.md#the-supported-cloud-providers). |
| `MachineOptions` | Docker Machine options. More details can be found in the [Docker Machine configuration section](autoscale.md#supported-cloud-providers). |
Example:
......
......@@ -111,15 +111,15 @@ autoscale parameters:
```
At the beginning, when no jobs are queued, GitLab Runner starts two machines
(`IdleCount = 2`), and sets them in _Idle_ state. Notice that we have also set
(`IdleCount = 2`), and sets them in _Idle_ state. Notice that we have also set
`IdleTime` to 30 minutes (`IdleTime = 1800`).
Now, let's assume that 5 jobs are queued in GitLab CI. The first 2 jobs are
sent to the _Idle_ machines of which we have two. GitLab Runner now notices that
the number of _Idle_ is less than `IdleCount` (`0 < 2`), so it starts 2 new
machines. Then, the next 2 jobs from the queue are sent to those newly created
machines. Again, the number of _Idle_ machines is less than `IdleCount`, so
GitLab Runner starts 2 new machines and the last queued job is sent to one of
sent to the _Idle_ machines of which we have two. GitLab Runner now notices that
the number of _Idle_ is less than `IdleCount` (`0 < 2`), so it starts 2 new
machines. Then, the next 2 jobs from the queue are sent to those newly created
machines. Again, the number of _Idle_ machines is less than `IdleCount`, so
GitLab Runner starts 2 new machines and the last queued job is sent to one of
the _Idle_ machines.
We now have 1 _Idle_ machine, so GitLab Runner starts another 1 new machine to
......@@ -413,6 +413,6 @@ and one option for Docker Machine itself (`engine-registry-mirror`).
[docker-machine-docs]: https://docs.docker.com/machine/
[docker-machine-driver]: https://docs.docker.com/machine/drivers/
[docker-machine-installation]: https://docs.docker.com/machine/install-machine/
[runners-cache]: advanced-configuration.md#the-runners-cache-section
[runners-machine]: advanced-configuration.md#the-runners-machine-section
[runners-cache]: advanced-configuration.md#the-runnerscache-section
[runners-machine]: advanced-configuration.md#the-runnersmachine-section
[registry]: https://docs.docker.com/registry/
......@@ -51,7 +51,7 @@ Docker Machine will attempt to use a
with rules for port `2376`, which is required for communication with the Docker
daemon. Instead of relying on Docker, you can create a security group with the
rules you need and provide that in the Runner options as we will
[see below](#the-runners-machine-section). This way, you can customize it to your
[see below](#the-runnersmachine-section). This way, you can customize it to your
liking ahead of time based on your networking environment.
### AWS credentials
......@@ -62,7 +62,7 @@ Create a new user with [policies](https://docs.aws.amazon.com/AWSEC2/latest/User
for EC2 (AmazonEC2FullAccess) and S3 (AmazonS3FullAccess). To be more secure,
you can disable console login for that user. Keep the tab open or copy paste the
security credentials in an editor as we'll use them later during the
[Runner configuration](#the-runners-machine-section).
[Runner configuration](#the-runnersmachine-section).
## Prepare the bastion instance
......@@ -91,7 +91,7 @@ Before configuring the GitLab Runner, you need to first register it, so that
it connects with your GitLab instance:
1. [Obtain a Runner token](https://docs.gitlab.com/ee/ci/runners/)
1. [Register the Runner](../../register/index.md#gnu-linux)
1. [Register the Runner](../../register/index.md#gnulinux)
1. When asked the executor type, enter `docker+machine`
You can now move on to the most important part, configuring the GitLab Runner.
......@@ -173,7 +173,7 @@ Example:
disable_cache = true
```
[Read more](../advanced-configuration.md#the-runners-docker-section)
[Read more](../advanced-configuration.md#the-runnersdocker-section)
about all the options you can use under `[runners.docker]`.
### The `runners.cache` section
......@@ -200,7 +200,7 @@ In the following example, we use Amazon S3:
Here's some more info to further explore the cache mechanism:
- [Reference for `runners.cache`](../advanced-configuration.md#the-runners-cache-section)
- [Reference for `runners.cache`](../advanced-configuration.md#the-runnerscache-section)
- [Reference for `runners.cache.s3`](../advanced-configuration.html#the-runnerscaches3-section)
- [Deploying and using a cache server for GitLab Runner](../autoscale.md#distributed-runners-caching)
- [How cache works](https://docs.gitlab.com/ee/ci/yaml/#cache)
......@@ -283,7 +283,7 @@ VPC is configured correctly with an Internet Gateway (IGW) and routing is fine,
but it’s something to consider if you've got a more complex configuration. Read
more in [Docker docs about VPC connectivity](https://docs.docker.com/machine/drivers/aws/#vpc-connectivity).
[Read more](../advanced-configuration.md#the-runners-machine-section)
[Read more](../advanced-configuration.md#the-runnersmachine-section)
about all the options you can use under `[runners.machine]`.
### Getting it all together
......@@ -349,7 +349,7 @@ pricing, you can significantly reduce the cost of running your applications,
grow your application’s compute capacity and throughput for the same budget,
and enable new types of cloud computing applications.
In addition to the [`runners.machine`](#the-runners-machine-section) options
In addition to the [`runners.machine`](#the-runnersmachine-section) options
you picked above, in `/etc/gitlab-runner/config.toml` under the `MachineOptions`
section, add the following:
......@@ -360,9 +360,9 @@ section, add the following:
]
```
In this configuration with an empty `amazonec2-spot-price`, AWS sets your
bidding price for a Spot instance to the default On-Demand price of that
instance class. If you omit the `amazonec2-spot-price` completely, Docker
In this configuration with an empty `amazonec2-spot-price`, AWS sets your
bidding price for a Spot instance to the default On-Demand price of that
instance class. If you omit the `amazonec2-spot-price` completely, Docker
Machine will set the bidding price to a [default value of $0.50 per
hour](https://docs.docker.com/machine/drivers/aws/#environment-variables-and-default-values).
......@@ -394,7 +394,7 @@ costs of your infrastructure, you must be aware of the implications.
Running CI jobs on Spot instances may increase the failure rates because of the
Spot instances pricing model. If the price exceeds your bid, the existing Spot
instances will be terminated within two minutes and all your jobs on that host
instances will be terminated within two minutes and all your jobs on that host
will fail.
As a consequence, the auto-scale Runner would fail to create new machines while
......
......@@ -26,7 +26,7 @@ out of the scope of this documentation. For more details please read the
## Configuring GitLab Runner
1. [Register a GitLab Runner](../register/index.md#gnu-linux) and select the
1. [Register a GitLab Runner](../register/index.md#gnulinux) and select the
`docker+machine` executor when asked.
1. Edit [`config.toml`](../commands/README.md#configuration-file) and configure
the Runner to use Docker machine. Visit the dedicated page covering detailed
......
# Run GitLab Runner on a Kubernetes cluster
TIP: **Tip:**
TIP: **Tip:**
We also provide a [GitLab Runner Helm Chart](https://docs.gitlab.com/ce/install/kubernetes/gitlab_runner_chart.html).
To install the GitLab CI Runner on Kubernetes there are several resources that need to be defined and then pushed to the cluster with `kubectl`. This topic covers how to:
......@@ -42,7 +42,7 @@ data:
image = "busybox"
```
Update the `url` and `token` with your values. The parameter `image` is optional and is the default Docker image used to be used to run jobs.
Update the `url` and `token` with your values. The parameter `image` is optional and is the default Docker image used to be used to run jobs.
>**Note:**
> Don't use the `gitlab-managed-apps` namespace for this runner. It should be reserved for applications installed through the GitLab UI.
......@@ -100,4 +100,4 @@ Assuming that your kubectl context has already been set to the cluster in questi
The new runner will now show up in the GitLab web UI at the appropriate level (instance, group or project).
For more details see [Kubernetes executor](../executors/kubernetes.md)
and the [[runners.kubernetes] section of advanced configuration](../configuration/advanced-configuration.md#the-runners-kubernetes-section).
and the [[runners.kubernetes] section of advanced configuration](../configuration/advanced-configuration.md#the-runnerskubernetes-section).
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment