Het uitbrengen van software betekende vroeger een onderhoudsvenster en gekruiste vingers. Moderne teams gebruiken strategieën die releases routine maken, en de keuze blauw-groen versus kanarie is een van de eerste waarmee u te maken krijgt. Beide verminderen het risico, maar ze doen dit op tegenovergestelde manieren: de één bereidt een volledige vervanging voor, terwijl de ander beetje bij beetje met echte gebruikers test.

In deze handleiding wordt uitgelegd hoe elk ervan werkt en wat het in de praktijk kost. We hebben de kleine voorbeelden van gebruikersrouting en rollback uitgevoerd in Python 3.13, en de uitvoer komt uit die run. De Kubernetes-voorbeelden zijn illustratief, maar die hebben we niet uitgevoerd. Beschouw de percentages en drempels als startvoorbeelden om aan te passen.

Het korte antwoord

Met blauw-groene implementatie beheert u twee identieke productieomgevingen. De ene bedient gebruikers terwijl u de nieuwe versie implementeert en test, aan de andere kant, en vervolgens schakelt u al het verkeer in één beweging over.

Bij canary-implementatie wordt de nieuwe versie naast de oude uitgevoerd. Je stuurt het een klein percentage van het echte verkeer, vergelijkt de resultaten en vergroot het aandeel stap voor stap totdat het iedereen bedient. De naam komt van de kanaries die mijnwerkers ooit gebruikten als een vroege waarschuwing voor gevaar.

Blauwgroen versus kanarie naast elkaar

Hoe blauw-groene implementatie werkt

1. Blue is live en bedient al het verkeer.
2. Implementeer de nieuwe versie naar groen, die geen gebruikersverkeer ontvangt.
3. Test groen grondig, in de echte productieomgeving, met behulp van rooktesten en interne gebruikers.
4. Schakel de router, load balancer of DNS om verkeer naar groen te sturen.
5. Let goed op, terwijl blauw nog steeds loopt en klaar is.
6. Als er iets mis is, schakel dan terug. Als alles goed is, wordt blauw de volgende inactieve omgeving.

In Kubernetes kunt u de overstap maken door de selector van een service te wijzigen, zodat het verkeer naar verschillend gelabelde pods gaat:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Sterke punten: Het is conceptueel eenvoudig: u kunt de exacte productie-instellingen testen voordat gebruikers deze zien, en het terugdraaien is vrijwel onmiddellijk mogelijk. Zwakke punten: Dubbele infrastructuur kan duur zijn, een bug die langs je tests glipt, bereikt iedereen tegelijk, en open sessies en werk tijdens de vlucht hebben tijdens de overstap zorg nodig. Als u DNS voor de overstap gebruikt, kunnen in de cache opgeslagen records dit vertragen. Nieuw bij de concepten? Bekijk onze Kubernetes-tutorial voor beginners.

Hoe kanarie-inzet werkt

1. Implementeer de nieuwe versie naast de stabiele versie.
2. Leid een klein deel van het verkeer, bijvoorbeeld 5%, naar de kanarie.
3. Vergelijk foutpercentages, latentie en zakelijke statistieken met de stabiele versie.
4. Als u gezond bent, verhoog dan naar 25%, dan 50% en dan 100%.
5. Als er iets verslechtert, stuur dan al het verkeer terug naar de stabiele versie.

Veel teams beginnen met een kanarie met intern personeel, dan met een laagrisicoregio, en dan pas met het bredere publiek.

Sterke punten: Een slechte release treft slechts een kleine groep, en je leert van echt verkeer dat geen enkele testomgeving deze volledig kan reproduceren. Zwakke punten: Je hebt op percentages gebaseerde routing en statistieken per versie nodig, implementaties duren langer en twee versies werken een tijdje samen. Een kleine kanarie kan ook te stil zijn om een ​​betekenisvol signaal te geven, vooral op tijden met weinig verkeer.

Stabiele gebruikersroutering

Het willekeurig kiezen van een versie bij elk verzoek geeft gebruikers een verwarrende ervaring, omdat ze tussen oud en nieuw kunnen stuiteren. Een veel voorkomende oplossing is om een stabiel gebruikers-ID in een bucket te hashen, zodat elke gebruiker altijd hetzelfde antwoord krijgt:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Het daadwerkelijke aandeel volgde nauwgezet de doelstelling. Deze methode heeft nog twee nuttige eigenschappen, en onze run bevestigde beide. Dezelfde gebruiker ontving altijd dezelfde versie. En iedereen in de 5%-groep zat nog steeds op 25%, dus niemand die de nieuwe versie al had, werd teruggezet naarmate de uitrol groeide.

In echte systemen zorgt een service mesh, load balancer of een tool zoals Argo Rollouts of Flagger meestal voor deze routing, dus je hoeft het niet zelf te schrijven. Het is nog steeds nuttig om te begrijpen wat ze doen.

Automatisering van de beslissing

Een kanarie werkt alleen als iemand de versies daadwerkelijk vergelijkt. Geautomatiseerde controles zijn betrouwbaarder dan iemand die naar grafieken kijkt. Hier is het kernidee, waarbij het foutenpercentage van de kanarie wordt vergeleken met dat van de stabiele versie:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Let op het eerste geval. Het foutenpercentage lijkt hoog, maar met slechts 100 verzoeken is dit nog niet voldoende bewijs. Echte tools passen zorgvuldiger statistieken toe en kijken samen naar verschillende signalen:

Het databaseprobleem

Applicatiecode kan binnen enkele seconden worden verwisseld, maar gegevens niet. Beide strategieën delen doorgaans één database, dus tijdens een implementatie en na een rollback moeten de oude en nieuwe versie beide met hetzelfde schema werken.

Het standaardantwoord is het patroon uitbreiden en inkrimpen. Stel dat u name wilt hernoemen naar full_name:

1. Uitbreiden: voeg de nieuwe kolom toe. De oude code blijft onaangetast.
2. Migreren: code vrijgeven die naar beide kolommen schrijft en oude rijen aanvult.
3. Schakelaar: geeft code vrij die uit de nieuwe kolom leest.
4. Contract: zodra niets de oude kolom gebruikt, verwijdert u deze in een latere release.

Hiervoor zijn meerdere releases nodig, maar elke stap kan veilig worden teruggedraaid. Het in één keer uitvoeren van RENAME COLUMN zou elke versie kapot maken die de andere naam verwachtte. Wees ook voorzichtig met langlopende schemawijzigingen, omdat deze blokkeringen kunnen veroorzaken. Lees voor meer informatie over SQL-transacties.

Rollen en andere strategieën

Een Kubernetes-implementatie voert standaard een rolling update uit, wat bij veel services past. Een voortschrijdende update verschuift ook geleidelijk, maar het aandeel ervan is afhankelijk van het aantal exemplaren en analyseert niet zelf de resultaten of pauzeert niet bij slechte statistieken.

Hoe zit het met feature flags?

Bij de implementatie wordt code op servers geplaatst en release maakt een functie beschikbaar voor gebruikers. Functievlaggen houden deze gescheiden, doordat u een functie kunt inschakelen voor gekozen gebruikers zonder iets te implementeren. Ze werken heel goed met beide strategieën: inzetten met de vlag uit en vervolgens geleidelijk inschakelen. Ze vervangen deze strategieën niet, omdat een vlag je niet kan beschermen tegen een release die crasht bij het opstarten. Vergeet niet om oude vlaggen te verwijderen, aangezien deze zich ophopen als technische schulden.

Hoe te kiezen

Ze kunnen ook gecombineerd worden. Sommige teams zetten een groene omgeving in en verplaatsen het verkeer er vervolgens geleidelijk naartoe, waardoor ze een schone omgeving en een beperkte explosieradius krijgen. Wat je ook kiest, automatiseer het via je CI/CD-pijplijn, zoals onze GitHub Actions-gids uitlegt.

Veel voorkomende fouten

• Schakelwijzigingen doorvoeren. Terugdraaien helpt niet als de oude code de gegevens niet kan lezen.
• Er zijn geen terugdraaicriteria. Bepaal wat ‘slecht’ betekent voordat de release begint, en niet tijdens een incident.
• De omgevingen laten veranderen. Als groen verschilt van blauw, bewijzen je tests minder. Definieer beide met infrastructuur als code.
• Alleen technische statistieken worden gemeten. Een release kan foutloos zijn en toch het afrekenproces verstoren.
• Oefen nooit met terugrollen. Oefen het, zodat het werkt als je onder druk staat.
• Achtergrondtaken vergeten. Werknemers en geplande taken hebben ook een plan nodig tijdens een overstap.

Tot slot

Blauw-groen geeft u een schone, snelle omschakeling. Canary geeft je een kleine, afgemeten belichting. Als uw monitoring nog steeds eenvoudig is, begin dan met rolling updates of blauw-groen, en investeer in statistieken per versie voordat u canaries uitprobeert. Oefen vervolgens een rollback voor uw volgende release, inclusief de database. Die ene oefening heeft de neiging om te onthullen wat er echt moet worden opgelost.

Veelgestelde vragen

Blijf leren