Yes, you can register multiple runners in a same instance, although you have to remember that each runner will eat the CPU when running (no pun intended). This means that you’ll have to register a new runner for each project. It’s perfect if you have a small team, and you’re committing at different schedules and few times a day.
![how to install gitlab on aws ec2 how to install gitlab on aws ec2](https://cdn-images-1.medium.com/max/1024/1*RHHrysbiVGUH7_KYYek6Ow.png)
This means that many projects (a.k.a repositories) will use the same runner to process the Integration pipeline. If you want to use that same instance to process many projects: When it asks you to whether lock the Runner to current project, I’ll leave that one up to you. You’re more than welcome to add tags to the runner. We’re going to leave this empty for simplicity. They are configured in both: .gitlab-ci.yml (More on that later), and the runner itself. Tags are used in the GitLab CI (Continuous Integration) environment to classify, and control access (From the projects in GitLab) to the runners. Then it’s going to ask you for a description, you can just type “Docker Runner” #3.1 A quick note about tags. It’s the runner that communicates to GitLab, not the other way around.
![how to install gitlab on aws ec2 how to install gitlab on aws ec2](https://miro.medium.com/max/552/1*uZWba6bvGAk9XhQNC_SQYw.png)
You do not need to assign an Elastic IP to the spot instance or the dedicated one that the GitLab runner is using. You’re more than welcome to create a dedicated instance, and shut it down when it doesn’t need to. You can just rent it per limited time frames (Spot Instances), and you’ll be good to go. Basically, since the runner will not always run (It only runs when someone with the CI config file pushes to the server), you don’t need to have a server that is 100% active. You can run them in micro, nano, and even spot instances! If you’re not familiar with the latter, Amazon has what they call Spot Instances. The good news is that they’re cheap to run. I wouldn’t recommend it anyways, since GitLab is resource-intensive by its own. They can also be installed in your current machine and do the process there. Yes, they usually reside in a different server than your GitLab installation (Yup, another additional server to spin). It’s basically a scipt that is executed to run the CI jobs.
#HOW TO INSTALL GITLAB ON AWS EC2 HOW TO#
I will make a future tutorial on how to set it up with Google Cloud Platform.įor GitLab to use the CI, it needs help from what it calls a GitLab runner. This will cover running a separate Docker instance that will run the CI. Kubernetes is an open-source container management platform (You can deploy Docker images inside it). GitLab introduced a Kubernetes Cluster that allows you to run CI in there.
![how to install gitlab on aws ec2 how to install gitlab on aws ec2](https://miro.medium.com/max/1104/1*cS4xpyesRbkWwZFBA6Ofqw.png)
Things have changed ever since GitLab 10.3.
![how to install gitlab on aws ec2 how to install gitlab on aws ec2](https://cdn-images-1.medium.com/max/1600/1*mc7lgIRlRaf3FbJDOr20yQ.png)
Feedback is appreciated, in case something needs clarification. I will go through each one of those steps.