Sidecar

En sidecar er en hjælpekomponent, som udrulles sammen med en primær applikation for at levere en afgrænset funktion. Komponenten kører typisk som en separat proces eller container og følger applikationsinstansens livscyklus.

Funktionen kan eksempelvis være logopsamling, konfigurationshentning eller en netværksproxy. Mønstret adskiller hjælpefunktionen fra applikationens forretningskode, men bevarer en tæt kobling mellem komponenternes placering og drift.

Hvorfor er begrebet vigtigt?

En fælles hjælpekomponent kan give flere applikationer samme tekniske funktion uden en særskilt kodeimplementering i hvert programmeringssprog. Det kan gøre vedligeholdelse og opgraderinger mere ensartede.

Koblingen har også en pris. En sidecar bruger ressourcer for hver tilknyttet instans og kan påvirke opstart, sundhedsvurdering og afslutning. En separat tjeneste eller en fælles agent kan være et bedre valg, hvis funktionen skal skaleres eller vedligeholdes uafhængigt af applikationen.

Typisk misforståelse

En sidecar er ikke automatisk en del af et service mesh. En mesh-proxy kan bruge mønstret, men en logopsamler kan også være en sidecar uden at indgå i et mesh.

Samme pod i Kubernetes betyder heller ikke automatisk adgang til hele hovedcontainerens filsystem. Containerne deler poddens netværk og kan dele eksplicit konfigurerede volumes. Rettigheder, monteringer og ressourcegrænser skal vurderes konkret; hjælperen er ikke uden videre en selvstændig sikkerhedsgrænse.

Eksempel

En fiktiv ældre applikation skriver logs til en fil på et delt volume. En sidecar læser filen og videresender relevante hændelser til organisationens logmodtager. Applikationens forretningskode behøver dermed ikke en ny integration til logplatformen.

Teamet begrænser hjælperens adgang og afprøver, hvad der sker, hvis logmodtageren er utilgængelig: Vokser filer eller buffere, og kan applikationen fortsat arbejde? Det kontrollerer også afslutningen, så en planlagt nedlukning ikke giver et uopdaget hul i den nødvendige logopsamling. Casen viser opgavefordelingen, ikke en færdig driftskonfiguration.

Best practice

• Giv hjælperen én tydelig opgave og en navngiven ejer for vedligeholdelse.

• Sammenlign med en fælles agent eller selvstændig tjeneste, før funktionen kopieres til hver appinstans.

• Begræns rettigheder, netværksadgang og delte volumes til det nødvendige; beskyt følsomme logdata.

• Planlæg ressourcer, opstart, sundhedskontrol og afslutning som en del af det samlede workload.

• Versionsstyr komponenterne, og afprøv både normal drift, genstart og svigt i den eksterne afhængighed.