DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Java CI/CD: From Local Build to Jenkins Continuous Integration
  • Jenkins in the Age of Kubernetes: Strengths, Weaknesses, and Its Future in CI/CD
  • Dockerizing an Ansible Playbook, Part 2
  • A Concise Guide to DevSecOps and Their Importance in CI/CD Pipeline

Trending

  • How to Use AWS Aurora Database for a Retail Point of Sale (POS) Transaction System
  • How Large Tech Companies Architect Resilient Systems for Millions of Users
  • Caching 101: Theory, Algorithms, Tools, and Best Practices
  • How to Introduce a New API Quickly Using Micronaut
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. DevOps and CI/CD
  4. GitLab CI/CD Pipelines Integrated Workflow, OCI, Kubernetes, and Registry

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

By 
Gilson Melo user avatar
Gilson Melo
·
Mar. 31, 20 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
11.9K Views

Join the DZone community and get the full member experience.

Join For Free

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.

    • Push an Image to Oracle Cloud Infrastructure Registry
    • Pull an Image from Oracle Cloud Infrastructure Registry when Deploying a Load-Balanced Application to a Cluster
  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!

Continuous Integration/Deployment Kubernetes GitLab Docker (software) Pipeline (software) Integration workflow Cloud

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

Opinions expressed by DZone contributors are their own.

Related

  • Java CI/CD: From Local Build to Jenkins Continuous Integration
  • Jenkins in the Age of Kubernetes: Strengths, Weaknesses, and Its Future in CI/CD
  • Dockerizing an Ansible Playbook, Part 2
  • A Concise Guide to DevSecOps and Their Importance in CI/CD Pipeline

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!