Endelig skikkelig konfigurasjonsstyring av java-applikasjoner
For oss utviklere som er opptatt av å levere kvalitetsløsninger så har konfigurering av deploymentpakker for ulike miljøer som test, stage og prod vært problematisk og tungvint.
En nokså populær måte bygge deployment pakker på har vært å bruke Mavens funksjonalitet til å definere profiler og filtrer. På denne måten får man definert hvilke konfigurasjonsfiler som skal være med i de ulike miljøene. Ulemen med denne løsinger er at man ender opp med en pakke for hvert miljø, noe driftspersonal ikke ønsker. De ønsker å kunne deploye den samme pakken i alle miljøene.
For å løse dette så er det ofte vanlige å trekke ut konfigurasjonsfiler av deployment pakkene, og legge dem på et bestemt sted(/etc/konfig.properties) hvor de blir lest ved oppstart. Ulempene med denne løsningen er at konfigurasjonsfilene blir spredd ut over forkjellige maskiner. Dette gjør det tungvint å refakturere og endre på strukturene av konfigurasjonsfilene. (I stedet for å endre på konfigurasjonsparameter så beholder man det subboptimale for å unngå å måtte gjøre endringer på flere forskjellige maskiner.) En annen svakhet med denne løsningen er at det blir vanskelige å holde styr på hvilke parameter som er satt i de ulike miljøene for eksempel når man introduserer nye parameter.
En bedre løsning hadde vært å kunne gjøre alle konfigurasjonene på en plass i en fil. Dette er nøyaktig hva Constretto muligjør.
Constretto er et java open-source rammeverk laget av Kaare Nilsen fra Arktekk som gjør det mulig å deploye samme pakke i flere miljøer. Constretto kan ta konfigurasjonsfiler på to forskjellige måter.
Den første er en variant over java properties filer og ser slik ut:
parameter1 = min felles verdi
parameter2 = enda en felles verdi
@test.parameter3 = en verdi for test
@stage.parameter3 = en annen verdi for stage
@prod.parameter3 = en tredje verdi for prod
Vi har altså parametrer som er felles for alle miljøene, samt parametere for hvert miljø.
Den andre konfigurasjonsmåten er basert på gamle gode ini-fil-notasjonen:
[default]
parameter1 = min felles verdi
parameter2 = enda en felles verdi
[test]
parameter3 = en verdi for test
[stage]
parameter3 = en annen verdi for stage
[prod]
parameter3 = en tredje verdi for prod
Så dette var to forskjellige konfigurasjonsmåter, men hvordan vet hvert miljø hvilken parameter3 som skal brukes? Dette gjøres med å angå ved oppstart av java hvilket miljø man er i. For test vil det være –DCONSTRETTO_TAGS=test, og så vil Constretto lese de riktige parameterne.
Til slutt, hvordan kommer disse parameterne inn i selve java-applikasjonene? Bruker man Spring rammeverket så har Constretto en konfigurasjonslaster som oppfører seg veldig likt Springs egen property-placeholder, og som gjør at man når parameterne med vanlig ${parameter3} notasjon:
<constretto:resource location=”classpath:konfigurasjonsfil.properties”/>
<bean class=”KonfigKlasse”>
<property name=”parameter3” value=”${parameter3}”/>
</bean>
En annen måte å få injektet parameterverdier på er å bruke Constretto sine egne snertne java annotasjoner:
public class KonfigKlasse{
private String parameter3;
@Configure
public void configure(String parameter3){
this.parameter3 = parameter3;
}
Alt i alt så har dette revolusjonert konfigurasjonsstyring av java applikasjoner for meg. De er nå mye lettere å vedlikeholde og vi har nå en helt ny kontroll på hvilke parameter som blir brukt i de ulike miljøene.
Av variantene over så foretrekker jeg ini-filer sammen med java annotasjoner.
