Search code examples
gitlab-cigitlab-ci-runner

How do I associate a Gitlab Runner with a physical server/environment?


I'm attempting to setup a development environment consisting of 3 stages (development, staging and prod) each deployed to their own physical server. I have an additional server configured with GitLab to handle source control. We have a branch called "main" that developers work off of. Typically a developer will branch off of main, work on their change and merge back into main triggering a pipeline that updates the development server using the gitlab-runner with a shell executor. Once some basic tests have been run successfully, we now want these commits to go to staging server. I'm trying to add a manual step to the end of our existing pipeline so that if the last commit is deemed ready to move on to more intensive testing the developer can click the run button in GitLab Pipelines triggering the deployment to the staging server.

What I can't figure out is how to say that when doing the deploy job the runner associated with the staging server should be used instead of the one running on the development server. I've looked at environments but don't see a way to link a runner to a specific environment. I'm thinking that tagging the commit with something like "Stage-version" might work it looks like that might re-run the pipeline on the development server again. How could this be accomplished with the physical server setup being a hard requirement. I know being able to use containers would make this easier but I'm not able to do that yet for other reasons.


Solution

  • From your description, you should be able to use the same runner(s) for all three environments. In other words, there's nothing in Gitlab preventing you from using the same runner(s). If you have a business reason to do so however, what you're looking for are GitLab CI tags (NOT git tags).

    When registering a Runner, you can specify tags for that specific runner. If a pipeline job has the same tag, that job can only run on runners with that tag. This is useful if for example only a certain runner has some specific software installed that the job needs, or if that runner has access to an external resource but others don't, etc.

    Here's an example from the docs:

    windows job:
      stage:
        - build
      tags:
        - windows
      script:
        - echo Hello, %USERNAME%!
    
    osx job:
      stage:
        - build
      tags:
        - osx
      script:
        - echo "Hello, $USER!"
    

    In this example, the windows job has the tag windows. Presumably, the runner with the windows tag is on a Windows box, while the osx job runs on a Mac.