Fingoweb Autoscaling GitLab CI Runners on AWS

You get self-hosted GitLab CI runners in your AWS account. When jobs are in the queue, the worker instances start. When the worker instances have no jobs, Auto Scaling terminates them. Thus, you pay for compute mainly when jobs run. A small manager instance runs all the time. All the configuration is infrastructure as code in your repository, with Terraform as the default.

This service is for teams with GitLab.com or self-managed GitLab. It is for you if: Your pipelines wait for runners when the load is high. Your runners are on fixed servers. You want CI jobs to run in your AWS account, near the resources that they deploy.

• We examine your pipelines: job types, job duration, resource needs, the maximum number of jobs at the same time, Docker builds, and the jobs that need deployment credentials.
• We design the runners: GitLab Runner with the docker-autoscaler executor on Amazon EC2 Auto Scaling groups.
• We use Spot Instances of different instance types in different Availability Zones. An On-Demand pool runs the jobs that must not wait or stop.
• If you need builds for more than one architecture, we also add Arm64 runners on AWS Graviton.
• Spot interruptions: we add retry rules to your pipeline configuration. Thus, a job that stops because of an interruption starts again automatically. Long jobs run on the On-Demand pool.
• Cache: an Amazon S3 distributed cache, and an Amazon ECR pull-through cache for public container images. The pull-through cache also prevents problems with the Docker Hub rate limits.
• Network and cost: an S3 gateway endpoint, and subnets that decrease the NAT Gateway charges. We also add an AWS Budgets alert.
• Runner capacity and job queue time: we show these metrics in Amazon CloudWatch or in your current tools.

Security:

• Separate runner pools for merge request jobs, and for jobs on protected branches and deployments.
• An IAM role with minimum permissions for each pool.
• IMDSv2 with a hop limit of 1. Thus, job containers on the default Docker network cannot read the credentials of the instance role.
• Short-term AWS credentials for deployments through GitLab OpenID Connect.
• If the internet cannot get access to your GitLab instance, deployments use the instance role of the protected deployment pool.

Deliverables:

• Runners with Auto Scaling, registered to your GitLab group or projects.
• Infrastructure code for the runners in your repository, with Terraform as the default.
• Changes to your pipeline configuration: runner tags, retry rules and image references to the pull-through cache.
• Handover documents.

Not in this service: Changes to test suites or build logic that the new runners do not need. If you want these changes, we can agree on them as pipeline optimization in the private offer. Migration from other CI platforms. Administration or upgrades of a self-managed GitLab server.

• Permissions to make runners in your GitLab group or projects.
• An IAM role for the deployment. If you prefer, your pipeline deploys the code, and we do not need the role.
• The exact IAM policy comes from the agreed design. It gives access only to the services that the runners use:
  • Amazon EC2, EC2 Auto Scaling and Amazon VPC
  • Amazon S3 and Amazon ECR
  • AWS Secrets Manager, AWS Budgets and Amazon CloudWatch
  • IAM roles and the OpenID Connect provider for the runners
• You examine the policy before you make the role. At the end of the work, you delete the role. Our access documentation in Additional resources gives more information.
• A Docker Hub account for the pull-through cache.
• Access to your pipeline configuration, and a contact who knows your build process.

Note on AWS costs: If the work needs more resources in your AWS account, you pay the AWS charges for these resources. These charges are not part of your AWS Marketplace transaction.