Konfigurations- och sekretesshantering med Consul-mall på Kubernetes

Onur Yilmaz

Följ

23 mars, 2020 – 6 min read

Som plattformsteam på Trendyol Tech var ett av våra mål att göra applikationskonfigurering och hemlighetshantering dynamiskt, tillförlitligt, säkert och abstraherat från applikationer. Vi har använt Kubernetes ConfigMaps och Secrets under lång tid och de uppfyller inte våra krav helt och hållet. Till exempel; när vi ändrar en konfiguration på en ConfigMap måste vi starta om våra applikationspoddar för att ändringen ska träda i kraft. Ibland tar det flera minuter innan ändringen återspeglas på alla programinstanser. Ett annat problem är att Kubernetes secrets inte är tillräckligt säkra. Vi behöver att våra hemligheter är säkra och granskningsbara.

Våra huvudkrav var:

  • Vi bör kunna ändra applikationskonfigurationer dynamiskt utan att starta om applikationsprocesser. När vi ändrar en konfiguration ska det påverka alla programinstanser omedelbart.
  • Våra programhemligheter måste vara säkra och granskningsbara. Vi vill också tillhandahålla rollbaserad åtkomstkontroll till hemligheter.
  • Vi måste abstrahera konfigurationshanteringen från programmen. Med andra ord ska programmen inte veta var och hur hemligheter och konfigurationer förvaras och tillhandahålls för dem.
  • Vårt system för hantering av konfigurationer och hemligheter måste vara högtillgängligt och skalbart.

Efter en del efterforskningar kom vi fram till två program; envconsul och consul-template.

Vi visste redan att Vault är industristandardverktyget för lagring av hemligheter. Det uppfyller alla våra krav och har funktioner som dynamiska hemligheter, vilket kan vara användbart för oss i framtiden. Du kan också använda Consul som lagringsbackend för Vault.

Consul är ett distribuerat, högtillgängligt och skalbart verktyg för upptäckt och konfiguration av tjänster. I vårt fall kommer vi bara att använda nyckelvärdeslagringsfunktionen i Consul för att bevara icke hemliga konfigurationer.

Vi skulle kunna använda envconsul eller consul-template främst för det tredje kravet: att abstrahera konfigurationshanteringen från programmen.

Envconsul ger ett sätt att starta en underprocess med miljövariabler som fylls på från Consul och Vault.

Consul-template fyller på värden från Consul och Vault i filsystemet och håller värdena synkroniserade när man arbetar i daemon-läge.

En tolvfaktorsregel för appen är, lagra konfigurationer i miljön. Men problemet med Envconsul (eller miljövariabler) är att du inte kan ändra en process miljövariabler utan att starta om den. Detta strider mot vårt första krav. Vi vill kunna ändra konfigurationer utan att starta om applikationsprocesser. Därför bestämde vi oss för consul-template.

Grundläggande arkitektur för applikationsprocessen och consul-template daemon som körs tillsammans

I consul-template kan du använda en mallfil för att rendera konfigurationsfiler. Detta ger oss stor flexibilitet. Här är ett exempel på en mallfil;

Consul-template läser den här mallen, ersätter platshållare med värden från Consul om du använder nyckelordet ”key” och från Vault om du använder nyckelordet ”with secret”. Du kan läsa mer om mallspråk här. Den renderade utdatafilen skulle se ut så här;

server:
port: "8080"
toggles:
fooEnabled: true
database:
username: "username"
password: "password"

Lämna ett svar

Din e-postadress kommer inte publiceras.