Search code examples
continuous-integrationgitlabgitlab-cicontinuous-deploymentautodeploy

How should I deploy the result of the CI/CD pipeline on my production server

I am having this GitLab CI/CD which builds then tests and pushes my projects container to GitLab container register successfully. But now I am wondering how I can do the deployment stage automated too. currently, I am doing it manually and after each successful pipeline, I SSH to my server and run several commands to pull the latest images from the GitLab.com container registry and then run them. But I would like to make this step automated as well. Yet, I don't know how? Actually I have seen some examples of opening an ssh session from CI/CD pipeline but it doesn't feel secure enough. So I was wondering is there a better way for this or I have to actually do this.

Not that I am using gitlab.com so the GitLab server is not installed on my machine and I can't share assets between them directly

Solution

  • There are many ways to achieve this, depending on your setup, other requirements, scale etc.
    I'll just give you two options.

    I. Kubernetes

    1. create cluster (ie control plane) somewhere
    2. add your cluster to GitLab (now GitLab can even create cluster for you in AWS and GCP, check this page)
    3. attach your target machine as a worker node to the cluster
    4. create Kubernetes YAML files \ Helm chart for your application and deploy via usual ways, e.g. kubectl apply -f ... or helm install ..., or rely on Auto DevOps to do this step for you

    This is quite complex but sort of "right" way of doing things.

    II. Private GitLab runner

    1. go to Settings > CI/CD > Runners of your GitLab project or group
    2. obtain the registration token
    3. install your own GitLab runner right on the target machine, and register it on the GitLab server using registration token, see example
    4. give runner some specific tag
    5. use that tag in your .gitlab-ci.yml file, see documentation
    6. then deployment process is just a local process of docker pull... and docker run ... for your image

    This is a lot simpler, but is a "wrong" way, as you are mixing CI\CD infrastructure with target environment.