Google GCE Standalone Installation Guide

Prerequisites

1. A Google Cloud account

You can create an account if you do not already have one.

This installation guide has not been tested with and is not guaranteed to work using Google Cloud’s Assured Workloads for Government. For assistance installing Develocity using Assured Workloads for Government, please contact your account executive or Develocity customer support if you are already a customer.

2. A Develocity license

You can request a Develocity trial here. If you have purchased Develocity, you will already have a license file.

3. A Google Cloud project with billing enabled

You will need a Google Cloud project that has billing enabled for this installation. If you have a project you wish to use, ensure it has billing and the Compute Engine APIs enabled. You can create a project by following this guide. To enable billing, follow these instructions for your project.

If you are using a new project, you may be asked to enable various APIs when running commands. Go ahead and do this, they are necessary for the installation described in this guide.

4. A Google Cloud IAM user with Compute Engine permissions

If you are the project owner, you likely have all permissions already.

Your Google Cloud IAM user needs permission to create and manage Compute Engine instances, alter firewall rules, and create and manage static IPs. Your instance will be created using the Compute Engine default service account, so you need permission to use it.

You can obtain these permissions using the following built-in roles: roles/compute.admin and roles/iam.serviceAccountUser for the Compute Engine default service account.

If you choose to follow our Cloud SQL appendix, you will need the permissions described in it, too.

Host Requirements

This section outlines GCE host requirements for the installation.

1. Operating System

Develocity supports Ubuntu 18.04/20.04/22.04, RHEL 8.4/8.5/8.6, Debian 11, and Amazon Linux 2. Develocity is expected to work on most modern Linux systems.

2. K3s

K3s needs several ports to be accessible from the host.

Protocol	Port
TCP	6443
TCP	10250
UDP	8472

While these ports don’t need to be accessible from outside the host machine, K3s may access them using a different network interface or non-localhost IP.

3. CPU & Memory

The minimum installation requirements are:

Quad-core 2GHz or better (amd64 architecture)
16 GB free RAM

The example in this manual creates a virtual machine with 4 vCPUs and 16 GB of memory.

4. Database

Develocity installations have two database options:

An embedded database that is highly dependent on disk performance.
A user-managed database that is compatible with PostgreSQL 12, 13, or 14, including Google Cloud SQL.

By default, Develocity stores its data in an embedded PostgreSQL database that is run as part of the application itself, with data stored in a directory mounted on its host machine. However, using Google Cloud SQL can provide a number of benefits, including resource scaling, easier backup and snapshot management, and failover support. See Using Cloud SQL as a Develocity user-managed database for more details.

5. Storage

In addition to the database, Develocity needs some storage capacity for configuration files, logs, build cache artifacts, and database backups. These storage requirements apply regardless of which type of database you use, although the necessary size varies based on the database type. To simplify managing disk space, Gradle recommends mounting a persistent storage volume for Develocity data, logs, and backups. See Storage settings in the Standalone Helm Chart Configuration Guide for configuration details.

The recommended minimum capacities for the persistent volumes are:

Description	Size in GB
Data	250
Backups	250
Logs	10

Capacity

The minimum capacity required for the Develocity installation directory when configured to use the embedded database is 250 GB. The minimum capacity required for the Develocity installation directory when configured to use a user-managed database is 30 GB. It is recommended to create a specific volume for the installation directory to avoid consuming the space required for Develocity, and to ensure at least 10% of the volume’s space is free at all times.

The following are additional disk capacity requirements:

Location Storage Size

Location	Storage Size
`/tmp` ^[1]	1 GB
`/var/lib/rancher/k3s` ^[1]	30 GB

/tmp ^[1]

1 GB

/var/lib/rancher/k3s ^[1]

30 GB

¹ These are not particularly performance sensitive.

Performance

For production workloads, storage volumes should exhibit SSD-class disk performance of at least 3000 IOPS (input/output operations per second). Develocity is not compatible with network-based storage solutions due to limitations of latency and data consistency.

Disk performance has a significant impact on Develocity performance.

Object storage

Develocity can be configured to store Build Scan data in an object storage service, such as Google Cloud Storage. This can improve performance in high-traffic installations by reducing the load on the database. See Build Scan object storage in the Develocity Administration Manual for a description of the benefits and limitations. There are instructions on how to configure Develocity to use Google Cloud Storage as an object store in the Object Storage Configuration section of the Standalone Helm Chart Configuration Guide.

Develocity is not compatible with network-based storage solutions due to limitations of latency and data consistency.

6. Network Connectivity

Develocity requires network connectivity for periodic license validation.

An installation of Develocity will not start if it cannot connect to both registry.gradle.com and harbor.gradle.com.

It is strongly recommended that production installations of Develocity are configured to use HTTPS with a trusted certificate.

Before installing Develocity, verify that your DNS points to your Develocity instance by running dig develocity.example.com or ping develocity.example.com in a console window.

develocity.example.com A 12.34.56.78

Preinstallation

You need to use the gcloud CLI tool to create Google Cloud resources and install Develocity. You can either install it locally, or use Google Cloud’s Cloud Shell, which comes with gcloud preinstalled and mostly preconfigured.

You can use Cloud Shell via SSH by following these instructions. This requires installing gcloud locally, and then using it to SSH into Cloud Shell, where you would run the guide’s commands.

We assume you are using bash as your shell, although any shell that is fairly compatible (e.g. zsh) should work without much trouble.

When files are referred to in this guide, they are assumed to be on the machine you are running the command on. When running commands on your VM, any necessary files will be explicitly uploaded. If you are using Cloud Shell, you will need to upload any referenced files to the shell machine by following the Cloud Shell documentation.

1. Install `gcloud`

You will be using the gcloud command line tool to provision and configure the Google Compute Engine VM. To install gcloud on your local machine, follow the instructions in the Google Cloud documentation.

Cloud Shell already has gcloud installed, so if you are using Cloud Shell, skip this step and go to 2. Configure gcloud. If you have already configured your project and zone, skip to Creating a Google Compute Engine VM.

2. Configure `gcloud`

gcloud configurations are not saved by default by Cloud Shell. To save your configuration, follow these instructions.

To configure gcloud, run gcloud init and follow the initialization guide. You want to use the project you created or decided on in 3. A Google Cloud project with billing enabled. If your project doesn’t have a default zone, you need to set the zone (and region, which will often be set automatically from the zone) to the zone you wish to install Develocity in. If you don’t know which zone or region to select, consult Google Cloud’s region and zone documentation.

Pick the region geographically closest to you or to any pre-existing compute resources, such as CI agents, to ensure the best performance.

Creating a Google Compute Engine VM

In this section you will create a Google Compute Engine instance to run Develocity.

If you’re using Cloud Shell, remember to run these commands there.

1. Create an external IP

Before creating your VM instance, you need to create a static external IP for Develocity to use. While it’s possible to configure the IP and hostname later by running helm upgrade with the updated Helm values file and updating your VM, it is easier to configure them now.

This step isn’t strictly necessary; Compute Engine instances are automatically assigned an external IP. However, this IP will change whenever you restart the instance, making maintaining DNS records and the Helm values configuration difficult.

To create the static IP, run:

$ gcloud compute addresses create develocity-static-ip

You can see the IP address used by the resource by running:

$ gcloud compute addresses describe develocity-static-ip --format='value(address)'

The static external IP resource is managed separately from your VM. It will not be automatically deleted if the VM using it is deleted.

2. Create a virtual machine

Looking at the host requirements for CPU and memory, let’s create an instance with 250 GiB of storage, 4 CPUs and 16 GiB of RAM.

If you do not have a preferred operating system, gcloud will use debian-11 as a base operating system. If you prefer a different operating system, choose one appropriate for your environment after consulting the Develocity operating system requirements.

For this guide, let’s name the instance gradle-enterprise and define our settings by entering the following command in the terminal:

$ gcloud compute instances create gradle-enterprise \
    --address=$(gcloud compute addresses describe develocity-static-ip --format='value(address)') \
    --custom-cpu=4 \
    --custom-memory=16GB \
    --boot-disk-size=250GB

If you have a preferred supported operating system, you can pass it as a parameter to the create command as described here. A list of public base images can be found here.

The majority of the disk space is used by Develocity’s embedded database. If you use a user-managed database (such as Cloud SQL, as described in an appendix), you can reduce the boot disk size to 50GB.

You may see a warning about the disk size being larger than the image size. This is not an issue if you are using the default debian-11 operating system or any other public image.

3. Set up firewall rules

On the Google Compute Platform, firewall rules are set at project level. There are some ports you will need to expose to access Develocity. These are:

Port 80 for HTTP
Port 443 for HTTPS

If Develocity is using HTTPS, as it does by default, you don’t need to expose port 80. However, if you do, Develocity will automatically redirect any HTTP traffic to HTTPS.

Create the firewall rules via the following commands:

$ gcloud compute firewall-rules create develocity-http --allow tcp:80 --description="GE HTTP"
$ gcloud compute firewall-rules create develocity-https --allow tcp:443 --description="GE HTTPS"

You can check these have been set correctly by running the following command:

$ gcloud compute firewall-rules list

NAME                    NETWORK  DIRECTION  PRIORITY  ALLOW                         DENY
default-allow-icmp      default  INGRESS    65534     icmp
default-allow-internal  default  INGRESS    65534     tcp:0-65535,udp:0-65535,icmp
default-allow-rdp       default  INGRESS    65534     tcp:3389
default-allow-ssh       default  INGRESS    65534     tcp:22
develocity-http                 default  INGRESS    1000      tcp:80
develocity-https                default  INGRESS    1000      tcp:443

4. Configure the hostname

Google Cloud Platform machines are provisioned with an external IP address but no hostname. Develocity is not accessible directly by IP, but there are services like nip.io that automatically map hostnames to IPs, so using your own hostname is not required. If you want to access Develocity by a host name of your choosing (e.g. develocity.example.com), you will need the ability to create the necessary DNS record to route this name to the instance IP address. You can start with a public DNS name based on the IP address, and later reconfigure to use a custom hostname if desired.

If you intend to use a custom hostname to access your Develocity instance, you now need to add the appropriate DNS records. Add an A record for your hostname that points to the IP you created in the step 1 of this guide. For example:

develocity.example.com A 34.110.226.160

You should verify that your DNS record works correctly before installing Develocity, such as by using dig develocity.example.com.

Google Cloud has its own Cloud DNS service, which can be used for this guide. However, there is no integration with Google Compute Engine that makes it preferable to other DNS services.

If you do not wish to set up a permanent DNS record at this time, you can instead use a service like nip.io to provide one based on the IP address. Any of the dash-based naming schemes on the nip.io web page should work, but the following command will generate a useful short name tied to that IP address:

$ GE_IP_ADDR=$(gcloud compute addresses describe develocity-static-ip --format='value(address)')

$ echo "gradle-enterprise-$(printf '%02x' $(echo ${GE_IP_ADDR//./ })).nip.io"

gradle-enterprise-226ee2a0.nip.io

gradle-enterprise-226ee2a0.nip.io can then be used as the hostname.

Installing Develocity

In this section you will install Develocity on your newly created instance. For full details on installation options, please see the Develocity Helm Standalone Installation Manual.

1. Prepare a Helm values file

Create a Helm values file named values.yaml as shown below:

values.yaml

global:
  hostname: develocity.example.com (1)

1	Use the hostname you decided on in 4. Configure the hostname or substitute it later as shown below.

See Appendix A of the Standalone Helm Chart Configuration Guide to download an example configuration file.

When adding things to your Helm values file, merge any duplicate blocks. Alternatively, you can use separate files and pass all of them with --values «file» when running Helm commands.

This file configures Develocity and its installation. For more details on what is configurable, see the Standalone Helm Chart Configuration Guide.

If you want to use a nip.io hostname as described in 4. Configure the hostname, you can substitute it into the Helm values file by running:

$ GE_IP_ADDR=$(gcloud compute addresses describe develocity-static-ip --format='value(address)')

$ GE_HOSTNAME="gradle-enterprise-$(printf '%02x' $(echo ${GE_IP_ADDR//./ })).nip.io"

$ sed -i "s/develocity.example.com/${GE_HOSTNAME}/g" path/to/values.yaml

On macOS, you may need to replace -i with -i '' when using sed.

If you want to provide an SSL certificate instead of having Develocity generate a self-signed one, follow HTTP or HTTPS in the Standalone Helm Chart Configuration Guide.

If you want to use a Cloud SQL PostgreSQL instance as your database instead of the embedded database, follow Using Cloud SQL as a Develocity user-managed database.

2. Copy configuration files to the instance

Copy the Helm values file you created and your Develocity license file to the instance:

$ gcloud compute scp path/to/values.yaml gradle-enterprise:~
$ gcloud compute scp path/to/develocity.license gradle-enterprise:~

If you are using a custom SSL certificate, copy the certificate and key files to the instance as well.

3. Install K3s and Helm on your VM

SSH into the instance:

$ gcloud compute ssh gradle-enterprise

This will ask you for a passphrase (which you will need to remember for next time you want to access the instance) and generate an SSH key. It will then ask you for the passphrase again, and if successful will give you command line access to the machine.

Once you’re on the machine, install K3s and make it available to the current user:

$ curl -sfL https://get.k3s.io | sh -
$ sudo chown ${UID} /etc/rancher/k3s/k3s.yaml
$ mkdir -p "${HOME}/.kube"
$ ln -s /etc/rancher/k3s/k3s.yaml "${HOME}/.kube/config"

Then install Helm:

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

If you’re following the Cloud SQL appendix, you should do Deploy the Cloud SQL Proxy now.

4. Install the `gradle-enterprise-standalone` Helm chart

First, add the https://helm.gradle.com/ helm repository and update it:

$ helm repo add gradle https://helm.gradle.com/
$ helm repo update gradle

If you’re using an older Helm version (which Cloud Shell may), you may need to run helm repo update instead of helm repo update gradle.

Then run helm install with the following command:

$ helm install \
    --create-namespace --namespace develocity \
    develocity-standalone \
    gradle/gradle-enterprise-standalone \
    --values ./values.yaml \(1)
    --set-file global.license.file=./develocity.license (2)

1	The Helm values file you created in 1. Prepare a Helm values file and uploaded in 2. Copy configuration files to the instance.
2	The license you obtained in 2. A Develocity license and uploaded in 2. Copy configuration files to the instance.

You should see output similar to this:

NAME: develocity-standalone
LAST DEPLOYED: Wed Jul 13 04:08:35 2022
NAMESPACE: develocity
STATUS: deployed
REVISION: 1
TEST SUITE: None

5. Wait for Develocity to start

You can see the status of Develocity starting up by examining its pods.

$ kubectl --namespace develocity get pods

NAME                                              READY   STATUS              RESTARTS   AGE
gradle-enterprise-operator-76694c949d-md5dh       1/1     Running             0          39s
gradle-database-65d975cf8-dk7kw                   0/2     Init:0/2            0          39s
gradle-build-cache-node-57b9bdd46d-2txf5          0/1     Init:0/1            0          39s
gradle-proxy-0                                    0/1     ContainerCreating   0          39s
gradle-metrics-cfcd8f7f7-zqds9                    0/1     Running             0          39s
gradle-test-distribution-broker-6fd84c6988-x6jvw  0/1     Init:0/1            0          39s
gradle-keycloak-0                                 0/1     Pending             0          39s
gradle-enterprise-app-0                           0/1     Pending             0          39s

Eventually the pods should all report as Running:

$ kubectl --namespace develocity get pods

NAME                                               READY   STATUS    RESTARTS   AGE
gradle-enterprise-operator-76694c949d-md5dh        1/1     Running   0          4m
gradle-proxy-0                                     1/1     Running   0          3m
gradle-database-65d975cf8-dk7kw                    2/2     Running   0          3m
gradle-enterprise-app-0                            1/1     Running   0          3m
gradle-metrics-cfcd8f7f7-zqds9                     1/1     Running   0          3m
gradle-test-distribution-broker-6fd84c6988-x6jvw   1/1     Running   0          3m
gradle-build-cache-node-57b9bdd46d-2txf5           1/1     Running   0          4m
gradle-keycloak-0                                  1/1     Running   0          3m

Once all pods have a status of Running, the system is up and can you can interact with it by visiting its URL in a web browser.

You can also visit the URL immediately, and will see a starting screen, which will then redirect to a Build Scan list once the app has started.

Develocity uses a self-signed SSL certificate by default, so most browsers will warn about an untrusted certificate. To avoid this, use a trusted SSL certificate as described in Networking options.

If the pods do not all start correctly, please see the troubleshooting section in the Develocity Administration Manual.

Using Develocity

Many features of Develocity, including access control, database backups, and Build Scan retention are configured in Develocity itself, once it is running. The Post-installation setup section of the administration manual walks you through the various features that you can configure.

For instructions on how to start using Develocity in your builds, consult the Getting Started with Develocity guide. See Teardown and Cleanup for instructions on deleting the instance hosting Develocity and related resources.

Appendix A: Using Cloud SQL as a Develocity user-managed database

Develocity can use a user-managed database instead of using its own embedded database. This can have a number of benefits, including easier resource scaling (and even autoscaling), easier backup and snapshot management, and failover support. For details on the pros and cons of using a user-managed database with Develocity, see the database section of the installation manual. This appendix will walk you through using Google Cloud SQL as a user-managed database.

Obtain the required permissions

You will need permission to create and manage Cloud SQL instances and service accounts, and to add roles to service accounts.

You can obtain these permissions using the following built-in roles: roles/iam.serviceAccountAdmin, roles/resourcemanager.projectIamAdmin, roles/iam.serviceAccountUser and roles/cloudsql.admin.

If getting roles/iam.serviceAccountAdmin and roles/resourcemanager.projectIamAdmin is difficult, you can have someone else who has permission to create service accounts and add roles to them complete 1. Create a Google Cloud service account with Cloud SQL permissions. You still need roles/iam.serviceAccountUser for that service account.

You will also need to ensure that cloudresourcemanager.googleapis.com is enabled for your project.

Set up a Cloud SQL instance

Before starting, it is a good idea to review Develocity’s supported Postgres versions and storage requirements.

1. Decide on a root username and password

Decide on a root password for the database instance. We will refer to it as «db-root-password». This is the password you will use for your database connection, so save it somewhere secure.

Develocity uses the superuser to set up the database and create the migrator and application users. However, some customers have internal security policies that forbid them from providing any database superuser credentials to third-party applications. If so, you can avoid using the superuser entirely by running the database setup scripts yourself, as described in option two for credentials in the Database options section of Standalone Helm Chart Configuration Guide. Please contact Gradle support for help with this.

2. Create the Cloud SQL instance

Create the Cloud SQL instance:

$ gcloud sql instances create gradle-enterprise-database \
    --database-version=POSTGRES_14 \
    --cpu=2 \
    --memory=8GB \
    --storage-size=250GB \
    --require-ssl \
    --database-flags=max_connections=200 \
    --zone=$(gcloud config get compute/zone) \(1)
    --root-password=«db-root-password»

1	The zone where you created your Compute Engine VM.

This will create an instance with 2 CPUs and 8 GB of RAM, with 250 GB of storage, without any replication. The storage will automatically increase if necessary, but will not decrease.

Cloud SQL databases are not backed up by default, but this can be easily enabled. See the backup documentation.

Consult the command reference to see all options available when creating the Cloud SQL instance.

It is possible to create an instance with a private (VPC-only) IP. Consult this documentation for details. The connection method we use will still work with a private IP, with some modifications described in the Cloud SQL proxy docs.

3. Create a database

Cloud SQL instances don’t come with a database by default, so you need to create one for Develocity:

$ gcloud sql databases create gradle_enterprise --instance=gradle-enterprise-database

Create and use a service account with Cloud SQL permissions

To enable our Compute Engine instance to access our Cloud SQL instance, we will configure our Compute Engine instance to use a service account with the roles/cloudsql.client role.

1. Create a Google Cloud service account with Cloud SQL permissions

You need to create a Google Cloud service account to authenticate with Cloud SQL with:

$ gcloud iam service-accounts create ge-service-account \
    --display-name="Develocity Service Account"
$ gcloud projects add-iam-policy-binding $(gcloud config get project) \
    --member="serviceAccount:ge-service-account@$(gcloud config get project).iam.gserviceaccount.com" \
    --role="roles/cloudsql.client"

2. Use the service account for your VM

To use your new service account, you will set it as the service account for your Compute Engine instance:

$ gcloud compute instances stop gradle-enterprise
$ gcloud compute instances set-service-account gradle-enterprise \
    --service-account "ge-service-account@$(gcloud config get project).iam.gserviceaccount.com" \
    --scopes=https://www.googleapis.com/auth/cloud-platform
$ gcloud compute instances start gradle-enterprise

If for some reason you can’t change the instance’s service account, you can use your service account by creating a JSON key and mount it to the Cloud SQL deployment. You will need to alter the deployment manifest in Deploy the Cloud SQL Proxy according to GKE’s documentation. Note that the service account must still have the required Cloud SQL permissions.

Configure Develocity to use your Cloud SQL instance

Add the following configuration snippet to your Helm values file:

values.yaml

database:
  location: user-managed
  connection:
    host: gradle-database-proxy
    port: 5432
    databaseName: gradle_enterprise
    params: "?ssl=false"
  credentials:
    superuser:
      username: postgres
      password: «db-root-password»

When adding things to your Helm values file, merge any duplicate blocks. Alternatively, you can use separate files and pass all of them with --values «file» when running Helm commands.

The superuser is only used to set up the database and create migrator and application users. You can avoid using the superuser by setting up the database yourself, as described in the database section of Develocity’s installation manual. Please contact Gradle support for help with this.

This embeds your database superuser credentials in your Helm values file, meaning it must be kept secure. If you prefer to provide the credentials as a Kubernetes secret, consult Develocity’s database instructions.

While we recommend completing this appendix before installing the Develocity Helm chart, it is possible to do it afterwards and then update the the Helm release. To do this, follow the instructions in the installation manual.

Switching to a user-managed database after installing Develocity will result in the loss of any data stored prior to the switch. This may not be an issue for new installations. If it is, follow the user-managed database migration guide.

Deploy the Cloud SQL Proxy

To connect to the instance, you will use the Cloud SQL Auth proxy running as a standalone service. While the official documentation recommends running the proxy as a sidecar container, this does not work for Develocity because some of our init-containers require database access.

You will use the K3s cluster that you installed in 3. Install K3s and Helm on your VM to run and manage the proxy. This integrates best with Develocity, and avoids using yet another service management tool. This step must be done after 3. Install K3s and Helm on your VM but before 4. Install the gradle-enterprise-standalone Helm chart.

First, get the connection name of your Cloud SQL instance by running:

$ gcloud sql instances describe gradle-enterprise-database --format='value(connectionName)'

We will refer to this as «connection-name»

Then deploy the proxy and create a service for it by applying the following manifest to the k3s cluster on your VM:

database-proxy.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: gradle-enterprise
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gradle-database-proxy
  namespace: gradle-enterprise
spec:
  selector:
    matchLabels:
        app.kubernetes.io/part-of: gradle-enterprise
        app.kubernetes.io/component: database-proxy
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: gradle-enterprise
        app.kubernetes.io/component: database-proxy
    spec:
      containers:
      - name: cloud-sql-proxy
        image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:latest (1)
        ports:
        - containerPort: 6543
        args: (2)
          - "--port"
          - "6543"
          - "--address"
          - "0.0.0.0"
          - "«connection-name»" (3)
        securityContext:
          runAsNonRoot: true
---
apiVersion: v1
kind: Service
metadata:
  name: gradle-database-proxy
  namespace: gradle-enterprise
spec:
  selector:
    app.kubernetes.io/part-of: gradle-enterprise
    app.kubernetes.io/component: database-proxy
  ports:
  - port: 5432
    targetPort: 6543

1	This uses the latest version of the Cloud SQL proxy. It is recommended to use a specific version for long-lived environments.
2	The arguments to the Cloud SQL proxy.
3	The connection name of your Cloud SQL instance, which you can substitute as shown below.

In any long-lived deployments, you should use a specific version of the Cloud SQL Proxy instead of latest. See item 1 above.

The arguments used here are only valid for major version 2 of the Cloud SQL Proxy. If you’re using version 1, you can reverse-migrate the arguments using the migration guide.

To apply this manifest, run the following command:

$ kubectl apply -f database-proxy.yaml

Consult the GKE and Cloud SQL tutorial and Connect from GKE documentation for more details on using the Cloud SQL proxy from kubernetes. These are GKE-specific guides, though, so some instructions (mostly around using service accounts) don’t apply here. For details on using a service account with the Compute Engine, consult the Connect from Compute Engine documentation.

Appendix B: Teardown and Cleanup

This appendix will walk you through tearing down Develocity and deleting any resources created by following this guide.

To delete your instance, run:

$ gcloud compute instances delete gradle-enterprise

This will inform you that the instance and attached storage will be destroyed, and ask if you are sure. Choose “Yes” to continue.

To delete the static IP address, run:

$ gcloud compute addresses delete develocity-static-ip

To delete the firewall rules you created, run:

$ gcloud compute firewall-rules delete develocity-http
$ gcloud compute firewall-rules delete develocity-https

If you’re using other resources, like a Cloud SQL database, remember to delete them too. Cloud SQL teardown instructions are in the section below.

Cloud SQL

If you followed Using Cloud SQL as a Develocity user-managed database, you have some additional cleanup to do.

Deleting a Cloud SQL instance also deletes any automated backups of its database.

To delete your Cloud SQL instance, run:

$ gcloud sql instances delete gradle-enterprise-database

To also delete the service account you created, run:

$ gcloud iam service-accounts delete \
    "ge-service-account@$(gcloud config get project).iam.gserviceaccount.com"

This must be done after deleting your Compute Engine instance.

If you didn’t get full permissions for service account management, you may not be able to do this yourself.