GitLab autodeployment for testing

Parameters

Parameters are passed via environment variables:

variable name required default description
GITLAB_CHART_VERSION no latest available Chart version to use. Must align with the charts provided within TAG of the operator
IMG no registry.gitlab.com/gitlab-org/cloud-native/gitlab-operator Operator Container Image Name
TAG no master Operator Container Image Tag. Needs an override in most cases
GITLAB_CHART_DIR yes   path to a clone of GitLab Chart repo
GITLAB_OPERATOR_DIR no . path to a clone of GitLab Operator repo
GITLAB_OPERATOR_MANIFEST no   Optional reference to manifest for Operator deployment, if empty - auto-generated from ${GITLAB_OPERATOR_DIR}. To note: to reference proper image and tag set up IMG and TAG environment variables
GITLAB_CR_DEPLOY_MODE no selfsigned Select mode of deployment: selfsigned or certmanager
GITLAB_OPERATOR_DOMAIN no ${LOCAL_IP}.nip.io for KinD, cloud-native.win for other platforms Domain for GitLab (operator) deployment
GITLAB_HOST no *.${GITLAB_OPERATOR_DOMAIN} Common name to use for GitLab endpoint self-signed cert
GITLAB_KEY_FILE no gitlab.key Self-signed cert key file
GITLAB_CERT_FILE no gitlab.crt Self-signed cert file
GITLAB_PAGES_HOST no *.pages.${GITLAB_OPERATOR_DOMAIN} Common name to use for GitLab Pages endpoint self-signed cert
GITLAB_PAGES_KEY_FILE no pages.key Self-signed cert key file
GITLAB_PAGES_CERT_FILE no pages.crt Self-signed cert file
GITLAB_ACME_EMAIL no output of git config user.email Email used for cert-manager. Not necessary in KinD deployments
GITLAB_RUNNER_TOKEN no   Runner Token, if empty it’s auto-retrieved from running GitLab Instance
KIND no kind command line executable name for KinD
KIND_CLUSTER_NAME no gitlab KinD cluster name
KIND_IMAGE no kindest/node:v1.18.19 value of --image argument for KinD
KIND_LOCAL_IP yes, for KinD   Local IP required to provision Certs etc for the domain ${LOCAL_IP}.nip.io
KUBECTL no kubectl path to kubectl command
HELM no helm path to helm command
MAKE no helm path to GNU make command

Tool pointer variables ($KIND, $KUBECTL, $HELM, etc.)

Main use of tool pointer variables is to point to particular tool path or path to a wrapper script (like k for kubectl, for example).

One of the alternative uses for any one of those variables is to get some debugging info:

KUBECTL="echo kubectl" provision_and_deploy.sh deploy_operator

However, this can also be achieved by using bash -x provision_and_deploy.sh.

GCP

Example with Cert-Manager (ran from the root of gitlab-operator repo):

export GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_DOMAIN="mydomain.k8s-ft.win" \
       GITLAB_ACME_EMAIL="somebody@gitlab.com" \
       GITLAB_CR_DEPLOY_MODE="certmanager"

PROJECT="gcp-project-123" CLUSTER_NAME="mydomain" \
    bash ${GITLAB_CHART_DIR}/scripts/gke_bootstrap_script.sh up

# ...wait for provisioning to complete
scripts/provision_and_deploy.sh generic_deploy

Alternatively, use a CR generated by a pipeline (downloaded into ./123-my-branch.yaml, for example):

cd scripts
export GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_DIR=~/work/gitlab-operator \
       GITLAB_OPERATOR_MANIFEST=./123-my-branch.yaml \
       GITLAB_OPERATOR_DOMAIN="mydomain.k8s-ft.win" \
       GITLAB_ACME_EMAIL="somebody@gitlab.com" \
       GITLAB_CR_DEPLOY_MODE="certmanager"

PROJECT="gcp-project-123" CLUSTER_NAME="mydomain" \
    bash ${GITLAB_CHART_DIR}/scripts/gke_bootstrap_script.sh up

# ...wait for provisioning to complete
./provision_and_deploy.sh generic_deploy

The command above above has been run from the within scripts/ directory (note the use of GITLAB_OPERATOR_DIR).

One can deploy with self-signed certs, in which case KIND_LOCAL_IP should be provided (use “cluster IP”) and not GITLAB_OPERATOR_DOMAIN.

KinD

By default deployment is done with Self-Signed cert:

export KIND_CLUSTER_NAME=gitlab \
        KIND_LOCAL_IP=192.168.3.194 \
        GITLAB_CHART_DIR=~/work/gitlab \
export KIND_CLUSTER_NAME=gitlab \
       KIND_LOCAL_IP=192.168.3.194 \
       GITLAB_CHART_DIR=~/work/gitlab

scripts/provision_and_deploy.sh kind_deploy

Alternatively, use a CR generated by a pipeline (downloaded into ./123-my-branch.yaml, for example):

cd scripts
export KIND_CLUSTER_NAME=gitlab \
        KIND_LOCAL_IP=192.168.3.194 \
        GITLAB_CHART_DIR=~/work/gitlab \
        GITLAB_OPERATOR_MANIFEST=./123-my-branch.yaml \
        GITLAB_OPERATOR_DIR=~/work/gitlab-operator
export KIND_CLUSTER_NAME=gitlab \
       KIND_LOCAL_IP=192.168.3.194 \
       GITLAB_CHART_DIR=~/work/gitlab \
       GITLAB_OPERATOR_MANIFEST=./123-my-branch.yaml \
       GITLAB_OPERATOR_DIR=~/work/gitlab-operator

./provision_and_deploy.sh kind_deploy

The command above has been run from within the scripts/ directory (note the use of GITLAB_OPERATOR_DIR).

That’s it! You should now be able to navigate to https://gitlab.(your IP).nip.io and log in with the root password.

NOTE: Use of cert-manager for generating certificates for Ingresses in KinD is not possible unless your KinD instance is publicly accessible.

Runner deployment

Once base deployment has been performed do the runner deployment (retaining same exported variables):

scripts/provision_and_deploy.sh runner_deploy

Alternatively, do everything in one go (we’ll use kind deploy for example):

scripts/provision_and_deploy.sh kind_deploy runner_deploy