Amazon EKS Kubernetes Installation Guide

Cloud services are frequently updated. This documentation may not reflect the latest changes. Always verify steps and interfaces with the current provider documentation.

This manual covers the installation of Develocity on Amazon’s Elastic Kubernetes Service.

Develocity is a Kubernetes-based application, distributed as a Helm chart. Helm is a package manager for Kubernetes applications. Develocity can be installed on Kubernetes clusters running modern Kubernetes versions.
Compatibility between versions of Kubernetes, Helm and the Develocity can be found in the version overview matrix. Later versions may be compatible but haven’t been verified to work.

Helm manages all Develocity components.

Prerequisites

An AWS Account

An AWS paid account is required. A free tier account isn’t sufficient.

This tutorial won’t work on GovCloud accounts (us-gov regions).

A Develocity License

If you have purchased Develocity or started a trial, you should already have a license file called develocity.license. Otherwise, you may request a Develocity trial license.

An AWS IAM User

Grant the user that will manage the instance the AmazonEC2FullAccess AWS managed policy.

To check the current user, run the following command:

aws sts get-caller-identity

And set your preferred region:

aws configure set region us-west-1 (1)

export AWS_REGION=us-west-1 (1)

1	Replace the region-code with your AWS Region of choice.

If you are using AWS’s Cloud Shell (see section AWS CLI), grant the user Cloud Shell permissions using the AWSCloudShellFullAccess AWS managed policy.

If you choose to use Amazon RDS as your database or S3 to store your Build Scan data, you will need the additional permissions described in the appendices.

The IAM user must have permissions to work with Amazon EKS IAM roles, service linked roles, AWS CloudFormation, a VPC, and related resources.

You will need the permissions described by eksctl’s minimum IAM policies.

Host Requirements

This section outlines cluster and host requirements for the installation.

Database

Develocity installations have two database options:

A user-managed database can be any PostgreSQL database compatible with versions 15 through 18, including Amazon RDS and Aurora.
An embedded database that’s highly dependent on disk performance.

The compatibility matrix lists the supported versions for every Develocity release.

By default, Develocity stores its data in a PostgreSQL database run as part of the application, storing database files in a directory mounted on its host machine. Although this is the default, a user-managed database is recommended.

RDS Database

There are instructions for using Amazon RDS as a user-managed database in the RDS appendix. This can have several benefits, including easier resource scaling, backup management, and failover support.

Storage

Develocity uses persistent volume claims to store data, logs, and backups. If your cluster has a default StorageClass, Develocity uses it.

If your cluster has no default StorageClass, or you want a different one, name the StorageClass that provisions the persistent volumes.

You can specify a different StorageClass for each type of storage.

Use faster StorageClasses for data, and a separate slower, cost-efficient one for backups.

Some Pods use more than one persistent volume. On a Kubernetes platform with multiple availability zones, a Pod and its persistent volumes must be in the same zone. In that case, use a StorageClass with a volumeBindingMode of WaitForFirstConsumer, which provisions every persistent volume in the zone where the Pod was scheduled.

Where available, Gradle strongly recommends StorageClasses that allow persistent volume claim expansion. That makes it straightforward to expand storage as Develocity usage increases.

Capacity

The recommended minimum capacities for the persistent volumes are:

Description	Size in GiB
Build Scan data	250
Build Scan data backups	250
Edge Node	50
Test Distribution	10
Logs and Monitoring	20
Embedded Object Storage	75

The embedded object storage provisions a single persistent volume sized to the sum of objectStorage.embedded.storage.internalBuffer.capacity (default 5Gi), objectStorage.embedded.storage.buildCache.capacity (default 50Gi, which holds the durable Build Cache content, including artifacts uploaded from co-located and externally provisioned Edge nodes), and objectStorage.embedded.storage.monitoring.capacity (default 20Gi). Adjust the sub-settings to change the overall PV size.

The Edge node volume provides a low-latency cache for build agents. For optimal read speeds, this volume must be placed on local SSD block storage. Do not use network file systems (NFS) or remotely-mounted volumes. Remote storage introduces significant latency, negating the performance benefits of the cache.

The volume is ephemeral, so it is not retained across Pod restarts, updates, or scale-down. After such an event, the cache starts empty and warms on demand. As builds request entries, the new Pod fetches them from peer Edge nodes. On a miss, it fetches them through Develocity from the durable Object Storage. Expect temporarily reduced performance while the cache warms this way. Reads are still served, but from Object Storage rather than the local volume until the working set is warm again. If the durable Object Storage sits in a different region than the cluster, this refill traffic also increases Develocity’s cross-region read volume. Entries served from Object Storage still register as ordinary remote-cache hits. As a result, the extra warm-up latency does not surface as a distinct signal in the Build Scan. When troubleshooting a slow build that follows an Edge node restart, correlate it with the restart event. No data is lost: the durable copy remains in the Object Storage connected to Develocity.

Adjust the Edge Node volume size with edgeNode.storage.data.capacity, or see the Edge Node configuration for guidance on scaling it.

If you produce more than 1 GB of Build Scan data a day, or retain Build Scan data for 30 days or more, provision more storage for the data volume. If your StorageClass does not allow expanding volumes, add disk capacity upfront for future data growth.

Performance

For production workloads, the data StorageClass should exhibit SSD-class disk performance of at least 3000 IOPS (input/output operations per second). The StorageClasses used for logs and backup volumes might be slower.

Disk performance has a significant impact on Develocity performance. Network file systems (such as Amazon EFS) are not compatible with Develocity due to their performance characteristics.

Object Storage

Develocity administrators can store Build Scan® data and monitoring data such as metrics in an object storage service, such as Amazon S3, Google Cloud Storage, and Microsoft Azure Blob Storage. This can help performance in high-traffic installations by reducing the load on the database. Object storage services offer performance and cost advantages compared to database storage. If you deploy Develocity to a cloud provider or have an internal S3-compatible object store, Gradle recommends using object-based storage for your installation. See Build Scan object storage in the Develocity Administration Manual for a description of the benefits and limitations.

Network Connectivity

Develocity requires network connectivity for periodic license validation.

An installation of Develocity won’t start if it cannot connect to both registry.gradle.com and harbor.gradle.com.

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

When installing Develocity, you will need to provide a hostname, such as develocity.example.com.

Pre-Installation

If you decide to use Cloud Shell, complete sections Eksctl, Helm, Hostname and then skip to Cluster Configuration.

AWS CLI

You will be using the aws command line to provision and configure your server. To install it on your local machine, follow the instructions in the AWS documentation. Use version 2.11.26 or later or 1.27.150 or later.

The