{{announcement.body}}
{{announcement.title}}

GitLab CI/CD Pipelines Integrated Workflow, OCI, Kubernetes, and Registry

DZone 's Guide to

GitLab CI/CD Pipelines Integrated Workflow, OCI, Kubernetes, and Registry

This tutorial will teach you how to run GitLab on Oracle Cloud Infrastructure. Then, see how to put Container Engine for Kubernetes to use in your CI/CD pipelines.

· DevOps Zone ·
Free Resource

Oracle’s public cloud embraces open source technologies and the communities that support them. With the strong shift to cloud native technologies and DevOps methodologies, we’ve heard from many organizations that they want a high-performance, high-reliability cloud that avoids cloud lock-in and allows them to run what they want, whether or not it's built by the cloud provider. Running GitLab on Oracle Cloud Infrastructure gives customers a choice in their DevOps platform as one application for the entire DevOps lifecycle.

GitLab CI/CD and Oracle Cloud

GitLab is a complete open source DevOps platform, delivered as a single application. It fundamentally changes the way Dev, Security, and Ops teams collaborate and build software. When you combine the GitLab CI/CD Pipelines Auto DevOps features with Oracle Cloud Infrastructure Container Engine for Kubernetes, you have a reliable and scalable integrated workflow platform to build, test, deploy, and monitor your code in the cloud.

Container Engine for Kubernetes is a service that helps you deploy, manage, and scale Kubernetes clusters in the cloud. With it, organizations can build dynamic containerized applications by incorporating Kubernetes with services running on their Oracle Cloud Infrastructure.

CI/CD Workflow

Continuous integration (CI) integrates your team’s code in a shared repository. Developers use a pull request to share new code, and the request triggers a pipeline to build, test, and validate the code before it’s merged in the repository. CI helps you catch errors early in the development cycle, reduces integration issues, and avoid compounding problems.

Continuous delivery (CD) ensures that CI-validated code is delivered to your application through a structured deployment pipeline. CD ensures that every change is releasable, lowers the risk for each release, delivers more value frequently, and enables you to get faster and more frequent feedback from customers.

Together, CI and CD enable your team to build quickly and effectively, and they are critical for ensuring an optimized development practice.

Getting Started

First, let’s explore the components needed to build and deploy GitLab CI/CD services in Container Engine for Kubernetes. To install GitLab on Container Engine for Kubernetes, you must have a desktop (cloud VM or on premises) with the Oracle Cloud Infrastructure (oci) and kubectl command lines installed and configured.

Then, the following components are required before proceeding:

  • Kubernetes version 1.14.8 or later
  • Helm/Tiller version 2.14 or later
  • Subnet CIDR and ports for Kubernetes pods and worker nodes open in the local virtual cloud network (VCN) security list

Deployment Process

To deploy GitLab on Oracle Contain Engine for Kubernetes, review the Deployment Guide and follow these steps.

  1. Run the following commands. Change example.com to your own DNS. If you want Helm to install the GitLab resources in a different namespace, add --namespace NEW_NAME_SPACE after the --install option.

    Shell
     




    xxxxxxxxxx
    1


     
    1
    helm repo add gitlab https://charts.gitlab.io/
    2
    helm repo update
    3
    helm upgrade --install gitlab gitlab/gitlab --set externalUrl=http://gitlab.example.com \
    4
      --timeout 600s \
    5
      --set global.hosts.domain=example.com \
    6
      --set certmanager-issuer.email=me@example.com


  2. After the provisioning process is done, run the following command to identify the external IP address assigned to GitLab:

    Shell
     




    xxxxxxxxxx
    1


     
    1
    kubectl get services gitlab-nginx-ingress-controller


  3. Point the DNS entry from step 1 (for example, gitlab.example.com) to GitLab. Use your own DNS zone management service to update the DNS record entry. Otherwise, you will get a "default backend - 404" error message in step 5. If you get the 404 error message, fix the DNS entry and re-create the gitlab-runner pod.

  4. After the DNS zone record has been created, use the following command to get the base64 root password, which you need to connect in the dashboard.

    Shell
     




    xxxxxxxxxx
    1


     
    1
    kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo "


  5. Wait for all the pods to be up and running before proceeding. The following screenshot shows a list of the pods that will be installed through Helm.

  6. Open a browser, type the DNS address, and then use the root username with the base64 password.

  7. Add your existing Container Engine for Kubernetes cluster information in GitLab. Select Kubernetes in the Admin Area menu, click Add Kubernetes cluster, click the Add existing cluster tab, and enter the following information:

    • Name: Your cluster’s name, available in the ~/.kube/config file.

    • Environment scope: Enter * .

    • API URL: Get the API URL by running this command:

      Shell
       




      xxxxxxxxxx
      1


       
      1
      kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'


    • CA Certificate: Run kubectl get secrets. One of the secrets listed should be named similar to default-token-xxxxx. Copy that token name and use it in the following command. Get the certificate by running this command:

      Shell
       




      xxxxxxxxxx
      1


       
      1
      kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode


    • Token: GitLab authenticates against Kubernetes by using service tokens, which are scoped to a particular namespace. The token used should belong to a service account with cluster-admin privileges. Follow these steps to create this service account:

      1. Create a file called gitlab-admin-service-account.yaml with the following contents:

        YAML
         




        xxxxxxxxxx
        1
        18


         
        1
        apiVersion: v1
        2
        kind: ServiceAccount
        3
        metadata:
        4
          name: gitlab-admin
        5
          namespace: kube-system
        6
        ---
        7
        apiVersion: rbac.authorization.k8s.io/v1beta1
        8
        kind: ClusterRoleBinding
        9
        metadata:
        10
          name: gitlab-admin
        11
        roleRef:
        12
          apiGroup: rbac.authorization.k8s.io
        13
          kind: ClusterRole
        14
          name: cluster-admin
        15
        subjects:
        16
        - kind: ServiceAccount
        17
          name: gitlab-admin
        18
          namespace: kube-system


      2. Run the following command to apply the service account and cluster role binding to your cluster:

        Shell
         




        xxxxxxxxxx
        1


         
        1
        kubectl apply -f gitlab-admin-service-account.yaml


        Output:

        Plain Text
         




        xxxxxxxxxx
        1


         
        1
        serviceaccount "gitlab-admin" created
        2
        clusterrolebinding "gitlab-admin" created


      3. Retrieve the token for the gitlab-admin service account:

        Shell
         




        xxxxxxxxxx
        1


         
        1
        kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')


  8. Click Add Kubernetes Cluster. An instance cluster is added.

  9. In the Instance Cluster, install the following components:

    • Helm Tiller
    • Ingress
    • Cert-Manager
    • Prometheus
    • GitLab Runner
  10. After you install Ingress, a new public Oracle Cloud Infrastructure load balancer is provisioned.

  11. Change the base domain to the load balancer public IP address as suggested in the UI (for example, OCI_Public_IP.nip.io), and then click Save Changes. Additional details are available in the GitLab documentation.

That's it! The GitLab CI/CD Pipelines installation and integration with Container Engine for Kubernetes is done. Now, it's time to test your GitLab CI/CD workflow.

Using GitLab CI/CD Pipelines with Oracle Cloud Infrastructure Registry

This example demonstrates how to use the GitLab CI/CD workflow to pull an image from a private Oracle Cloud Infrastructure Registry repo, rebuild it, and push it back into the Registry using a new build name.

  1. If you have a private image available in your Registry repo, skip to the next step. If you don’t have a private image available, build a Docker image, upload it to a private Registry repo, and create a Kubernetes secret (use your Registry username and password for the secret info). The following tutorials explain these steps.

  2. Add the following variables to GitLab. Navigate to Settings > CI/CD, expand Variables, and add the following variable keys and values:

    • OKE_REGISTRY: Your Registry region endpoint (for example, iad.ocir.io)
    • OKE_REGISTRY_IMAGE: Your Registry image (for example, iad.ocir.io/tenancy_name/imagename:build)
    • OKE_REGISTRY_NEW_IMAGE: Your new Registry image build version that will be pushed into Registry after the build process (for example, iad.ocir.io/tenancy_name/imagename:new_image)
    • OKE_REGISTRY_PASSWORD: Your Oracle Cloud Infrastructure auth token. For more information, see the documentation.
    • OKE_REGISTRY_USER: Oracle_Cloud_Infrastructure_tenancy_name/usernam
  3. Create an internal blank project (for example, gitlab-docker-ocir-oke).

  4. Create two new files, Dockerfile and .gitla-ci.yml. These are just basic examples to get GitLab working with Container Engine for Kubernetes and Registry. Modify them to match your requirements.

    • .gitlab-ci.yml

      YAML
       




      xxxxxxxxxx
      1
      39


       
      1
      docker-build-master:
      2
        # Official docker image.
      3
        image: docker:latest
      4
        stage: build
      5
        services:
      6
          - name: docker:19.03.0-dind
      7
            entrypoint: ["env", "-u", "DOCKER_HOST"]
      8
            command: ["dockerd-entrypoint.sh"]
      9
        variables:
      10
          #CI_DEBUG_TRACE: "true"
      11
          DOCKER_HOST: tcp://localhost:2375/
      12
          DOCKER_DRIVER: overlay2
      13
          DOCKER_TLS_CERTDIR: ""
      14
        before_script:
      15
          - docker login -u "$OKE_REGISTRY_USER" -p "$OKE_REGISTRY_PASSWORD" $OKE_REGISTRY
      16
        script:
      17
          - docker info 
      18
          - docker build  --pull -t "$OKE_REGISTRY_IMAGE" .
      19
          - docker tag "$OKE_REGISTRY_IMAGE" "$OKE_REGISTRY_NEW_IMAGE"
      20
          - docker push "$OKE_REGISTRY_NEW_IMAGE"
      21
        only:
      22
          - master
      23
        
      24
      docker-build:
      25
        # Official docker image.
      26
        image: docker:latest
      27
        stage: build
      28
        services:
      29
          - docker:19.03.0-dind
      30
        before_script:
      31
          - docker login -u "$OKE_REGISTRY_USER" -p "$OKE_REGISTRY_PASSWORD" $OKE_REGISTRY
      32
        script:
      33
          - docker info
      34
          - docker build  --pull -t "$OKE_REGISTRY_IMAGE" .
      35
          - docker tag "$OKE_REGISTRY_IMAGE" "$OKE_REGISTRY_NEW_IMAGE"
      36
          - docker push "$OKE_REGISTRY_NEW_IMAGE"
      37
        except:
      38
          - master
      39
       
                    


      Dockerfile
    • Dockerfile
       




      x


       
      1
      FROM nginx
      2
         VOLUME /usr/share/nginx/html


After these files have been created and saved, GitLab Auto DevOps triggers Pipelines. Then, it pulls your Registry image, builds a new one, tags it using the $OKE_REGISTRY_NEW_IMAGE name, and pushes it into Registry.

5. Refresh the Registry dashboard, and a new image appears.

Your setup and tests are done! GitLab CI/CD Pipelines has been deployed and integrated with Container Engine for Kubernetes and Registry.

Conclusion

Combining Container Engine for Kubernetes with the GitLab CI/CD integrated workflow capabilities gives you a robust and scalable DevOps platform that’s production ready. For more information, see the Container Engine for Kubernetes documentation and the Gitlab website. If you want to experience Gitlab on Container Engine for Kubernetes for yourself, sign up for an Oracle Cloud Infrastructure account and start testing today!

Topics:
devops, gitlab cicd pipelines integrated workflow, kubernetes, oracle cloud infrastructure, registry, tutorial

Published at DZone with permission of Gilson Melo , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}