Heb je een aangepaste container image nodig om de New Relic agent jar in Kubernetes op te nemen?
“Bouwen we een aangepaste container image om de New Relic agent jar toe te voegen?”
Dat was de vraag die we onszelf stelden de laatste keer dat we een van onze Atlassian-applicaties aan het updaten waren. Als je werkt met een container image die is gebouwd en geleverd door de applicatieleverancier, kan het een vervelende en tijdrovende taak zijn om een nieuwe aangepaste image te maken om de New Relic agent jar voor elke applicatie en elke New Relic agent-versie toe te voegen.
Vereisten
Om deze alternatieve benadering te implementeren, moet aan een aantal vereisten worden voldaan:
- Je moet de container implementeren in een Kubernetes-cluster.
- De toepassing moet ondersteuning bieden voor het toevoegen van JVM-parameters via een omgevingsvariabele.
Startpunt
Laten we aannemen dat je applicatie een StatefulSet gebruikt die er ongeveer zo uitziet:
De naam van de omgevingsvariabele JAVA_OPTS kan variëren, afhankelijk van de specifieke applicatie.
De New Relic agent jar verpakken
Om het implementatieproces te vereenvoudigen, maken we een aangepaste image die de New Relic agent jar bevat. Om deze image te maken, gebruiken we een containerbestand, dat er ongeveer zo uit kan zien:
De New Relic agent "injecteren" in de applicatiecontainer
Om de applicatie te sturen om de New Relic agent jar te gebruiken, gebruiken we de Kubernetes Init Container- en emptyDir-concepten.
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 bestand newrelic.jar naar een emptyDir-volume.
Aangezien de Init-Container vóór de reguliere applicatiecontainer draait en beide hetzelfde volume delen, is het bestand newrelic.jar 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 loglocatie in te stellen, in dit geval STDOUT
Er zijn enkele aanvullende omgevingsvariabelen beschikbaar in de documentatie van de New Relic Java agent die je kan gebruiken.
Naast deze basisconfiguratie kan je de New Relic server-side agent configuratie gebruiken.
Zoals je kan zien in de omgevingsvariabele JAVA_OPTS, moeten we de JVM nog steeds instrueren om de New Relic agent jar te gebruiken. Dit specifieke bestand bevindt zich op het gedeelde volume.
Let ook op de "imagePullPolicy" die we hebben ingesteld op "Always" om ervoor te zorgen dat we steeds de nieuwste image-versie ophalen, zelfs als deze nog steeds dezelfde tag gebruikt.
De New Relic agent updaten
Om ervoor te zorgen dat de New Relic agent altijd up-to-date is, kan je een Continuous Integration pipeline opzetten die automatisch een nieuwe container image bouwt wanneer er een nieuwe agentversie beschikbaar komt.
Bovendien kan je de container image taggen met major, major.minor en major.minor.patch, naast "latest". Hiermee kan je de agentversie vastzetten op basis van de specifieke vereisten van je applicatie.
Afhankelijk van de image tag die is opgegeven in het manifestbestand van de applicatie, kan bijwerken net zo eenvoudig zijn als het opnieuw opstarten van de applicatiepods.
Als je de New Relic agent liever vastpint aan een specifieke versie, moet je de newrelic-agent image tag in de StatefulSet bijwerken en deze wijziging implementeren in je Kubernetes-cluster.
Je hoeft nu niet langer een aangepaste image te bouwen om alleen de New Relic agent jar toe te voegen, waardoor de agent vaker kan worden bijgewerkt.
Diagram
Do you want to discover more about Kubernetes?
