Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Boxiang Sun
gitlab-ce
Commits
2343d3a5
Commit
2343d3a5
authored
Nov 13, 2017
by
Achilleas Pipinellis
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Clear up sections
parent
61eed644
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
53 additions
and
20 deletions
+53
-20
doc/articles/runner_autoscale_aws/index.md
doc/articles/runner_autoscale_aws/index.md
+53
-20
No files found.
doc/articles/runner_autoscale_aws/index.md
View file @
2343d3a5
...
@@ -4,10 +4,11 @@ last_updated: 2017-11-10
...
@@ -4,10 +4,11 @@ last_updated: 2017-11-10
# Autoscaling GitLab Runner on AWS
# Autoscaling GitLab Runner on AWS
GitLab Runner has the ability to autoscale which means automatically spawning
One of the biggest advantages of GitLab Runner is its ability to automatically
new machines on demand. This proves very useful in situations where you
spin up and down VMs to make sure your builds get processed immediately. It's a
don't use your Runners 24/7 and want to have a cost-effective and scalable
great feature, and if used correctly, it can be extremely useful in situations
solution.
where you don't use your Runners 24/7 and want to have a cost-effective and
scalable solution.
## Introduction
## Introduction
...
@@ -15,9 +16,35 @@ In this tutorial, we'll explore how to properly configure a GitLab Runner in
...
@@ -15,9 +16,35 @@ In this tutorial, we'll explore how to properly configure a GitLab Runner in
AWS that will serve as the bastion where it will spawn new Docker machines on
AWS that will serve as the bastion where it will spawn new Docker machines on
demand.
demand.
## Installation and configuration
In addition, we'll make use of
[
Amazon's EC2 Spot instances
](
https://aws.amazon.com/ec2/spot/
)
which will greatly reduce the costs of the Runner instances while still using
quite powerful autoscaling machines.
The bastion will not run any jobs itself.
## Prerequisites
The first step is to install GitLab Runner in an EC2 instance that will serve
as the bastion to spawning new machines. This doesn't have to be a powerful
machine since it will not run any jobs itself, a
`t2.micro`
instance will do.
This machine will be a dedicated host since we need it always up and running,
thus it will be the only standard cost.
NOTE:
**Note:**
For the bastion instance, choose a distribution that both Docker and GitLab
Runner support, for example either Ubuntu, Debian, CentOS or RHEL will work fine.
Install the prerequisites:
1.
Log in your server
1.
[
Install GitLab Runner from the official GitLab repository
](
https://docs.gitlab.com/runner/install/linux-repository.html
)
1.
[
Install Docker
](
https://docs.docker.com/engine/installation/#server
)
1.
[
Install Docker Machine
](
https://docs.docker.com/machine/install-machine/
)
You can now move on to the most important part, configuring GitLab Runner.
## Configuring GitLab Runner to use the AWS machine driver
Before configuring the GitLab Runner, you need to first register it, so that
it connects with your GitLab instance.
Edit
`/etc/gitlab-runner/config.toml`
:
Edit
`/etc/gitlab-runner/config.toml`
:
...
@@ -30,15 +57,12 @@ check_interval = 0
...
@@ -30,15 +57,12 @@ check_interval = 0
url
=
"<url to your GitLab CI host>"
url
=
"<url to your GitLab CI host>"
token
=
"<registration token>"
token
=
"<registration token>"
executor
=
"docker+machine"
executor
=
"docker+machine"
environment
=
["GODEBUG=netdns=cgo"]
output_limit
=
16384
limit
=
4
limit
=
4
[runners.docker]
[runners.docker]
image
=
"
ruby:2.1
"
image
=
"
alpine
"
privileged
=
true
privileged
=
true
disable_cache
=
false
disable_cache
=
false
volumes
=
["/cache"]
volumes
=
["/cache"]
extra_hosts
=
[
"gitlab.thehumangeo.com:<our internal GitLab IP>"
,
"nexus.thehumangeo.com:<our internal Nexus IP>"
]
[runners.cache]
[runners.cache]
Type
=
"s3"
Type
=
"s3"
ServerAddress
=
"s3.amazonaws.com"
ServerAddress
=
"s3.amazonaws.com"
...
@@ -68,13 +92,17 @@ check_interval = 0
...
@@ -68,13 +92,17 @@ check_interval = 0
"amazonec2-instance-type=m4.2xlarge"
,
"amazonec2-instance-type=m4.2xlarge"
,
"amazonec2-ssh-user=ubuntu"
,
"amazonec2-ssh-user=ubuntu"
,
"amazonec2-ssh-keypath=/etc/gitlab-runner/certs/gitlab-aws-autoscaler"
,
"amazonec2-ssh-keypath=/etc/gitlab-runner/certs/gitlab-aws-autoscaler"
,
"amazonec2-ami=ami-996372fd"
,
"amazonec2-zone=a"
,
"amazonec2-zone=a"
,
"amazonec2-root-size=32"
,
"amazonec2-root-size=32"
,
]
]
```
```
## Cutting costs with AWS spot instances
Under
`MachineOptions`
you can add anything that the
[
AWS Docker Machine driver
supports
](
https://docs.docker.com/machine/drivers/aws/#options
)
.
## Cutting down costs with Amazon EC2 Spot instances
As described by Amazon:
>
>
Amazon EC2 Spot instances allow you to bid on spare Amazon EC2 computing capacity.
Amazon EC2 Spot instances allow you to bid on spare Amazon EC2 computing capacity.
...
@@ -83,24 +111,29 @@ pricing, you can significantly reduce the cost of running your applications,
...
@@ -83,24 +111,29 @@ pricing, you can significantly reduce the cost of running your applications,
grow your application’s compute capacity and throughput for the same budget,
grow your application’s compute capacity and throughput for the same budget,
and enable new types of cloud computing applications.
and enable new types of cloud computing applications.
-
https://aws.amazon.com/ec2/spot/
-
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html
-
https://aws.amazon.com/blogs/aws/focusing-on-spot-instances-lets-talk-about-best-practices/
In
`/etc/gitlab-runner/config.toml`
under the
`MachineOptions`
section:
In
`/etc/gitlab-runner/config.toml`
under the
`MachineOptions`
section:
```
toml
```
toml
MachineOptions
=
[
MachineOptions
=
[
"amazonec2-request-spot-instance=true"
,
"amazonec2-request-spot-instance=true"
,
"amazonec2-spot-price=0.03"
,
"amazonec2-spot-price=0.03"
,
"amazonec2-block-duration-minutes=
18
0"
"amazonec2-block-duration-minutes=
6
0"
]
]
```
```
### Caveats of spot instances
With this configuration, Docker Machines are created on Spot instances with a
maximum bid price of $0.03 per hour and the duration of the Spot instance is
capped at 60 minutes.
To learn more about Amazon EC2 Spot instances, visit the following links:
-
https://aws.amazon.com/ec2/spot/
-
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html
-
https://aws.amazon.com/blogs/aws/focusing-on-spot-instances-lets-talk-about-best-practices/
### Caveats of Spot instances
If the
s
pot price raises, the auto-scale Runner would fail to create new machines.
If the
S
pot price raises, the auto-scale Runner would fail to create new machines.
This eventually eats 60 requests and then AWS won't accept any more. Then once
This eventually eats 60 requests and then AWS won't accept any more. Then once
the spot price is acceptable, you are locked out for a bit because the call amount
the spot price is acceptable, you are locked out for a bit because the call amount
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment