Over the last year or so I had been looking at migrating our current single-node Gitlab server to a more de-coupled/distributed architecture. The primary purpose was to ensure that a single component would not bring down the entire platform.
By implementing a decoupled and distributed architecture, we were able to ensure that no single component can bring down the entire platform. This approach also enhances the robustness and reliability of our system, allowing each component to operate independently and mitigate potential points of failure.
Our deployment utilizes the Community Edition of GitLab, hosted on AWS. GitLab requires the integration of multiple components and services to function seamlessly. To achieve a resilient and worry-free platform, we undertook the following configurations:
- GitLab Container on EC2
- The GitLab application is containerized and deployed on an EC2 instance. This provides a flexible and scalable environment for running GitLab, allowing us to easily manage and update the application as needed.
- GitLab Runners on EC2 Spot Instances
- We utilize EC2 Spot Instances for GitLab Runners. Spot Instances are cost-effective and can be dynamically scaled based on the workload. This setup ensures that our CI/CD pipelines are efficient and cost-effective, leveraging the elasticity of AWS.
- AWS Redis Cluster
- An AWS Redis Cluster is used for caching and session management. Redis provides high-performance in-memory data storage, which improves the speed and responsiveness of our GitLab instance. It is configured to handle high availability and failover scenarios.
- AWS RDS for PostgreSQL
- PostgreSQL is the database backend for GitLab, hosted on AWS RDS. AWS RDS provides automated backups, patching, and scaling, ensuring that our database is reliable and well-maintained. PostgreSQL is chosen for its robustness and compatibility with GitLab.
- AWS EFS for Persistent GitLab Data
- GitLab requires persistent storage for repositories, artifacts, and other data. AWS EFS (Elastic File System) is used to provide scalable and highly available storage. EFS ensures that data is accessible across multiple instances and is resilient to failures.
- Daily Overnight Backups of EFS and PostgreSQL to S3
- To safeguard our data, we perform daily overnight backups of both EFS and PostgreSQL to AWS S3. S3 provides durable and secure storage for our backups, ensuring that we can quickly recover from any data loss scenarios.
Setting up Redis, RDS, and EFS followed standard procedures. However, the key to achieving a fully immutable infrastructure was the meticulous configuration of EC2’s userdata. Userdata scripts are used to automate the initialization and configuration of EC2 instances, ensuring that each instance is set up consistently and can be easily replaced if needed.
By leveraging these AWS services and configurations, we have built a resilient and scalable GitLab deployment that minimizes downtime and maintenance efforts. This architecture allows us to focus on delivering value to our users, knowing that our platform is robust and reliable.
Drop a comment below if you have any questions.