Skip to content

Provide Remote Development for GDK

Overview

To align with our commitment to dogfood GitLab product features, we propose enabling GitLab's Remote Development within the GDK. This will significantly improve the developer workflow and allow us to provide any feedback to the product teams.

Documentation

Steps to Set Up Remote Development Workspace as of 2023-07-11

Screenshot_2023-07-11_at_9.23.55_AM

I followed the instructions in the Setting up a Workspace to create a workspace in my GCP sandbox.

⚠ Ensure that the GitLab project is created in a top-level group and not in a top-level personal namespace due to the current limitation (internal slack discussion).

  • Set up a Kubernetes cluster that the GitLab agent for Kubernetes supports. See the supported Kubernetes versions.

    • Create a standard GKE cluster (No Autopilot cluster):

      gcloud container clusters create nhashizume-remote-development \
--zone us-central1-a \
--node-locations us-central1-a,us-central1-b,us-central1-c

  • Ensure autoscaling for the Kubernetes cluster is enabled.

    • Enable autoscaling for the cluster by editing Node Pool and click Enable cluster autoscaler (I set to min: 1, max: 3).

  • In the Kubernetes cluster, verify that a default storage class is defined so that volumes can be dynamically provisioned for each workspace.

    • Verify that a default storage class is defined:

      kubectl get storageclass

  • In the Kubernetes cluster, install an Ingress controller of your choice (for example, ingress-nginx), and make that controller accessible over a domain. For example, point *.workspaces.example.dev and workspaces.example.dev to the load balancer exposed by the Ingress controller.

    1. Purchase a non-trademark domain name nhashizume.net by following Non-Trademark Domain Names guide.

    2. Register the domain.

    3. Install nginx-ingress and configure the domain load-balancer by following Ingress-Nginx Deployment - Quick Start guide.

    4. Create DNS A records for the domain nhashizume.net and set it to the IP address of the nginx-ingress controller by following Set Up DNS Records for a Domain Name and Add a Record guides.

      gcloud dns record-sets transaction start --zone="${ZONE_NAME}"
gcloud dns record-sets transaction add "${NGINX_INGRESS_IP}" --name="nhashizume.net." --type=A --ttl=300 --zone="${ZONE_NAME}"
gcloud dns record-sets transaction add "${NGINX_INGRESS_IP}" --name="*.nhashizume.net." --type=A --ttl=300 --zone="${ZONE_NAME}"
gcloud dns record-sets transaction execute --zone="${ZONE_NAME}"

  • In the Kubernetes cluster, install gitlab-workspaces-proxy.

    1. Create a Signing key.
    2. Make sure to check that you have helm version 3.11.0 or higher (I upgraded it with asdf install helm 3.11.0).
    3. Follow Installation Instructions.
    4. Note that creating TXT records is necessary in GCP for the ACME DNS challenge.

  • In the Kubernetes cluster, install the GitLab agent for Kubernetes.

  • Configure remote development settings for the GitLab agent with this snippet, and update dns_zone as needed:

    remote_development:
  enabled: true
  dns_zone: "workspaces.example.dev"

    You can use any agent defined under the root group of your project, provided that remote development is properly configured for that agent.

  • You must have at least the Developer role in the root group.

  • In each public project you want to use this feature for, create a devfile:

    1. On the left sidebar, at the top, select Search GitLab (🔍) to find your project.
    2. In the root directory of your project, create a file named .devfile.yaml. You can use one of the example configurations.

  • Ensure the container images used in the devfile support arbitrary user IDs.

Actions as of 2023-08-23

  1. Start up GDK successfully in the sandbox GCP project
    • Configure the fs.inotify.max_user_watches setting in the Daemonset.
    • GDK starts successfully when support/gitlab-remote-development/remote-development-gdk-bootstrap.sh is executed.
  2. Create a new GCP project
    • Get approval for an access request to create a new GCP project under the Engineering Productivity team's GCP folder.
  3. Set up infrastructure resources
    • Provision infrastructure resources using these Terraform scripts that were used in the sandbox GCP project once we have the new GCP project.
  4. Generate TLS certificates for gitlab-workspaces-proxy
    • EDIT: Since the certificates are associated with domain names and not IP addresses, and the domain name remains the same, generating certificates is not necessary. Collaborate with the Infrastructure team to generate certificates for the gitlab-workspaces-proxy.
  5. Configure DNS zone and records
    • Collaborate with the Infrastructure team to configure DNS zone and records for the new infrastructure resources.
  6. Configure a GitLab agent for https://gitlab.com/gitlab-org

Impacted categories

The following categories relate to this issue:

Steps to replicate (optional)

Proposal (optional)

Environment (optional)

  • Operating system name: <!-- output of uname -a command -->
  • Architecture: <!-- output of arch command -->
  • The contents of your gdk.yml (if any)
  • Ruby version: <!-- output of ruby --version command -->
  • GDK version: <!-- output of git rev-parse --short HEAD command -->
Edited by Nao Hashizume