Vereisten

Om deze alternatieve aanpak te implementeren, zijn er een paar vereisten waaraan voldaan moet worden:

1. Je moet de container inzetten in een Kubernetes cluster.
2. De applicatie moet het toevoegen van JVM-parameters via een omgevingsvariabele ondersteunen.

Startpunt

Laten we aannemen dat je applicatie een StatefulSet gebruikt die er ongeveer zo uitziet:

De naam van de JAVA_OPTS omgevingsvariabele kan variëren afhankelijk van de specifieke applicatie.

De New Relic agent jar verpakken

Om het implementatieproces te vereenvoudigen, maken we een aangepast image dat de New Relic agent jar bevat. Om dit image te maken, gebruiken we een Container File, die er ongeveer zo uit kan zien:

De New Relic agent "injecteren" in de applicatiecontainer

Om de applicatie de New Relic agent jar te laten gebruiken, maken we gebruik van de concepten Kubernetes Init Container en emptyDir.

De resulterende StatefulSet ziet er als volgt uit:

In plaats van de New Relic agent jar in de applicatie-image op te nemen, gebruiken we onze aangepaste newrelic-agent image als een Init Container. Deze container kopieert het newrelic.jar bestand naar een emptyDir volume.

Aangezien de Init Container vóór de gewone applicatiecontainer draait en beide hetzelfde volume delen, is het newrelic.jar-bestand toegankelijk wanneer de JVM start.

Afgezien van het gedeelde volume, hebben we een paar New Relic agent-specifieke omgevingsvariabelen nodig:

• NEW_RELIC_APP_NAME: om de applicatienaam in te stellen
• NEW_RELIC_LICENSE_KEY: om de licentiesleutel op te geven
• NEW_RELIC_LOG_FILE_NAME: om optioneel een niet-standaard log locatie in te stellen, in dit geval STDOUT.

Er zijn een paar extra omgevingsvariabelen beschikbaar in de New Relic Java agent documentatie die gebruikt kunnen worden.

Naast deze basisconfiguratie kun je ook de configuratie van de New Relic server-side agent gebruiken.

Zoals je kunt zien in de JAVA_OPTS omgevingsvariabele, moeten we nog steeds de JVM instrueren om de New Relic agent jar te gebruiken. Het is de moeite waard om te vermelden dat dit specifieke bestand zich op het gedeelde volume bevindt.

Let ook op de "imagePullPolicy" die we hebben ingesteld op "Always" om ervoor te zorgen dat we altijd de laatste image-versie ophalen, zelfs als deze nog steeds dezelfde tag gebruikt.

De New Relic agent bijwerken

Om ervoor te zorgen dat de New Relic agent altijd up-to-date is, kun je een Continuous Integration pipeline opzetten die automatisch een nieuwe container image bouwt wanneer er een nieuwe agent versie beschikbaar komt.

Daarnaast kun je de image taggen met major, major.minor, en major.minor.patch, naast "latest". Hierdoor kun je de agentversie vastpinnen op basis van de specifieke vereisten van je toepassing.

Afhankelijk van de image tag die gespecificeerd is in het manifest bestand van de applicatie, kan het updaten net zo eenvoudig zijn als het herstarten van de applicatie pods.

Als je er de voorkeur aan geeft om de New Relic agent vast te zetten op een specifieke versie, moet je de newrelic-agent image tag in de StatefulSet bijwerken en deze wijziging implementeren in je Kubernetes cluster.

In ieder geval hoef je niet langer een aangepaste image te bouwen om de New Relic agent jar toe te voegen, wat frequentere updates van de agent mogelijk zou moeten maken.

Diagram

Wil je meer ontdekken over Kubernetes?