Konfigurera Gradle build cache-noder i Azure Kubernetes Service (AKS)

Som build engineer stötte jag på flera utmaningar med Gradle build cache som krävde ett enkelt och kostnadseffektivt alternativ till Gradle Enterprise, med följande fördelar:

• Kortare buildtider genom effektiv cachning.

• Enkel skalning i takt med att projektet växer.

• Konsekventa builds i olika miljöer.

• En budgetvänlig lösning.

• Full kontroll över min cacheinfrastruktur.

Observera att den beskrivna implementationen, som driftsattes i AKS, passade vår organisation (Eficode) men enkelt kan anpassas till en annan plattform.

Vad är Gradle build cache?

Gradle build cache är en kraftfull funktion som lagrar och återanvänder resultatet från tidigare builds. Den minskar tiden för efterföljande builds avsevärt, vilket är särskilt fördelaktigt i CI/CD-miljöer där flera builds körs.

Projektöversikt

Vårt projekt erbjuder en robust och skalbar lösning för att driftsätta Gradle build cache-noder i AKS. Du hittar det som open source här. Viktiga komponenter är:

• Ett Kubernetes StatefulSet med två repliker av build cache-noden.

• En Kubernetes Service som exponerar cachen.

• En Ingress Controller för extern åtkomst.

• AzureFile för beständig lagring.

Förutsättningar

För att implementera lösningen behöver du:

• Ett Azure Kubernetes Service-kluster.

• Kubernetes CLI (kubectl).

• Azure CLI (az).

• Docker CLI.

Implementeringssteg

Vi valde AzureFile för den beständiga volymen eftersom vi bedömde att det var den enklaste lösningen för AKS. Beroende på behoven i ditt projekt, team eller organisation kan du vilja överväga ett alternativ.

Konfigurera Azure-filresurs

Vi började med att skapa en Azure-filresurs för att ge våra cache-noder beständig lagring. Det innebar att skapa ett lagringskonto och en filresurs samt konfigurera nödvändiga Kubernetes-secrets.

Därefter driftsatte vi StatefulSet och tjänsten med hjälp av Kubernetes-manifest. StatefulSet säkerställde att våra cache-noder hade stabila nätverksidentiteter och beständig lagring.

kubectl apply -f gradle-cache-stateful-set.yamlkubectl apply -f service.yaml

Konfigurera Ingress

Vi konfigurerade en Ingress-resurs för att hantera extern åtkomst till våra cache-noder. Det gjorde det möjligt för våra utvecklare att interagera med cachen utanför Kubernetes-klustret. I exemplet använde vi webapprouting.kubernetes.azure.com som Ingress-klass för enkelhetens skull, eftersom vi inte hade några strikta krav på hur cache-noderna skulle nås. Du kanske däremot föredrar en riktig HTTPS-server.

För att begränsa eller konfigurera användaråtkomst kan du ange en egen konfiguration i «config-dir»/config.yaml på noden, men det medför vissa utmaningar.

Vi ville ha en förkonfigurerad användaråtkomst från början, med filen config.yaml angiven som en secret. Om du vill montera en secret eller config map som konfigurationsfil för build cache-noden måste den vara skrivbar.

Det går att montera secrets eller config maps med läs- och skrivbehörighet, men det kräver att du inaktiverar en feature gate och påverkar därmed hela miljön, vilket inte rekommenderas.

För att generera saltade hashade lösenord använde vi det här kommandot:

docker run --interactive --tty gradle/build-cache-node:19.0 hashFör den här konfigurationen skapade vi en Kubernetes secret:

Åtkomst till build cache-noden

Hitta den externa IP-adressen för din Ingress för att komma åt cache-servern:

Du kan sedan enkelt öppna den i din webbläsare: http://<external-ip>:5071

Konfigurera ditt Gradle-projekt med cache-noden

Alternativa lagringslösningar

Vi valde Azure file share för vår implementation, men det finns flera alternativa lagringslösningar som kan passa olika miljöer och krav. Till exempel Amazon Elastic File System om teamet använder AWS, Google Cloud Filestore för GKE samt flera molnleverantörsoberoende alternativ som Rook, Longhorn, OpenEBS och fler.

När du väljer ett alternativ bör du ta hänsyn till följande faktorer utifrån din molnleverantör eller lokala infrastruktur:

• Prestandakrav.

• Behov av skalbarhet.

• Funktioner för datareplikering och backup.

• Kostnad.

• Enkel hantering och integration med befintliga verktyg.

För vårt projekt gav Azure File Share rätt balans mellan enkelhet, prestanda och integration med vår Azure-baserade infrastruktur. Att implementera en Gradle build cache-nod i AKS förbättrade våra buildtider och den övergripande effektiviteten i CI/CD avsevärt. Varje lösning har dock sina styrkor, och det bästa valet beror i slutändan på ditt specifika användningsfall och din miljö.

Genom att använda Kubernetes StatefulSets och Azures robusta molninfrastruktur kunde vi skapa en skalbar, beständig och säker lösning för våra behov av build cache.

Jag hoppas att det här blogginlägget fungerar som en användbar referens för ditt team när ni vill optimera Gradle builds i en Kubernetes-miljö. Ta gärna del av alla implementationsdetaljer i vårt GitHub-repository.