Deploying GitLab CE on AWS ECS with Fargate: A Step-by-Step Guide

A privately hosted Source Code Management (SCM) system is crucial for many organizations, and GitLab stands out as an excellent choice. While Amazon ECS with Fargate may not be the ideal solution for hosting GitLab, it offers a valuable learning opportunity to work with serverless containers, especially when paired with EFS volumes for persistent storage. This project pushed the boundaries of containerized deployments, though it's worth noting that running GitLab on EC2 deployment type**** would be more straightforward and potentially more performant.

The solution I’ve implemented here, despite the complexity with Fargate, can be adapted for EC2-based deployments as well. Key components like VPC setup, security groups, PostgreSQL on RDS, and Redis clusters on ElastiCache are relevant regardless of whether you deploy on Fargate or EC2.

I like to implement Infrastructure as Code (IaC) and efficient CI/CD pipelines in everything I do, so I used Terraform and GitHub Actions for this project. If you’d like to replicate this, feel free to check out my GitHub repository for more details.

Prerequisites:

Basic knowledge of AWS services (ECS, ECR, RDS, ElastiCache)
Familiarity with Docker and Terraform
An AWS account set up for deployment

AWS Components Built with Terraform:

ECS Cluster, Service, and Task Definition
ECR Container Registry
VPC, Public Subnets, Private Subnets, Subnet Groups, Route Tables, Internet Gateway
Necessary Security Groups and IAM roles & policies
Elastic File System (EFS) Volumes
ElastiCache Cluster for Redis
Amazon RDS for PostgreSQL database
Elastic Load Balancer, listeners, and target groups
S3 Bucket for backups and required bucket policies

Setting Up PostgreSQL and Redis (External vs Embedded)

When setting up GitLab, PostgreSQL and Redis are critical components. While it's possible to use the embedded database and caching for smaller-scale setups, I opted for external PostgreSQL and Redis for scalability, high availability, and integration with managed AWS services.

n my setup, all you need to do is go to the terraform directory and then initiate terraform, plan and apply. Make sure your aws setup is correct. You can setup aws cli from this documentation

then its the three main commands

terraform init

terraform plan

terraform apply

Database configurations

Once, your infrastructure is up, you need to make some changes inside the RDS database, if you need external access, you can attach an internet gateway to the private subnet of your database for a while.You can use psql as the client for this next step.

Once done, you can now remove the internet gateway from the subnets route table.Next step is to configure all the settings for Gitlab we want, and all we need to do is create one configuration file i.e gitlab.rb file. This file is inside the docker/config folder in my setup.

Gitlab Configurations

For our deployment on AWS ECS with Fargate, we only need to configure a few key settings in the gitlab.rb file, primarily focusing on the Redis cluster and RDS database connection. we can leave most other settings at their default values.

Here's a sample gitlab.rb configuration to set up GitLab with an external Redis cluster and RDS database:

The CI/CD Pipeline

Now, we leave everything else to the magic that is automation. In my github actions workflow I have setup the pipeline to achieve the following things.

Build and Push Docker Image: The workflow builds a Docker image for GitLab CE and pushes it to Amazon Elastic Container Registry (ECR).
Update ECS Task Definition: It retrieves the current ECS task definition, updates it with the new image tag, and registers the updated task definition.
Force New Deployment: Finally, it updates the ECS service to deploy the new version of GitLab CE.

Here's the sample:name: Build and Push to ECR

OpenID Connect for Github Actions

My way of authentication AWS for github actions is using AWS IAM Identity providers and OpenID Connect. I suggest this to everyone as it is very secure and robust. Meaning, I can configure it to make sure that only my organization, repo and branch can have access to aws.

The final step is to wait for the ecs task to run in your ECS cluster.

Our setup includes the cloudwatch log group for the tasks, make sure you look through the logs in case you encounter problems.

Then you can use your loadbalancer dns name to access your Gitlab! Allow some time for it to be fully up and running !

the default user is root and you can setup the initial password on the gitlab.rb file.

Thank you for making it to the end !

This is a costly project, remember to destroy everything with terraform if you are trying out.

Site Terms, Privacy, and more.