Kanarie-ontplooiing is 'n baie effektiewe manier om nuwe kode op 'n subset van gebruikers te toets. Dit verminder aansienlik die verkeerslading wat problematies kan wees tydens die ontplooiingsproses, aangesien dit slegs binne 'n spesifieke subset plaasvind. Hierdie nota word gewy aan hoe om so 'n ontplooiing te organiseer deur Kubernetes en ontplooiingsoutomatisering te gebruik. Ons neem aan jy weet iets van Helm- en Kubernetes-hulpbronne.
'n Eenvoudige kanarie-ontplooiing na Kubernetes sluit twee sleutelhulpbronne in: die diens self en die ontplooiingsinstrument. Kanarie-ontplooiing werk deur 'n enkele diens wat interaksie het met twee verskillende hulpbronne wat opdateringsverkeer bedien. Een van hierdie hulpbronne sal werk met die "kanarie" weergawe, en die tweede sal werk met die stabiele weergawe. In hierdie situasie kan ons die aantal kanarie-weergawes reguleer om die hoeveelheid verkeer wat nodig is om te bedien, te verminder. As jy byvoorbeeld verkies om Yaml te gebruik, sal dit so lyk in Kubernetes:
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Selector will route traffic to both deployments.
Dit is selfs makliker om hierdie opsie voor te stel met behulp van kubectl, en in
Outomatisering van kanarie-ontplooiing
Eerstens benodig ons 'n Helm-kaartkaart, wat reeds die hulpbronne bevat wat ons hierbo bespreek het. Dit behoort so iets te lyk:
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Die basis van die Helm-konsep is die bestuur van multi-weergawe vrystellings. Die stabiele weergawe is ons belangrikste stabiele tak van die projekkode. Maar met Helm kan ons 'n kanarievrystelling met ons eksperimentele kode ontplooi. Die belangrikste ding is om verkeersuitruiling tussen die stabiele weergawe en die kanarievrystelling te handhaaf. Ons sal dit alles bestuur deur 'n spesiale keurder te gebruik:
selector:
app.kubernetes.io/name: myapp
Ons "kanarie" en stabiele ontplooiingshulpbronne sal hierdie etiket op die modules aandui. As alles korrek gekonfigureer is, sal ons tydens die ontplooiing van die kanarie-weergawe van ons Helm-kaartkaart sien dat verkeer na die nuut ontplooide modules gelei sal word. Die stabiele weergawe van hierdie opdrag sal soos volg lyk:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v1 # Goes into app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5
Kom ons kyk nou na ons kanarievrystelling. Om die kanarie-weergawe te ontplooi, moet ons twee dinge onthou. Die vrystellingnaam moet anders wees sodat ons nie 'n opdatering na die huidige stabiele weergawe uitrol nie. Die weergawe en merker moet ook anders wees sodat ons ander kode kan ontplooi en verskille deur hulpbronmerkers kan identifiseer.
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v2 # Goes into app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1
Dis al! As jy die diens ping, kan jy sien dat die kanarie-opdatering verkeer slegs 'n deel van die tyd lei.
As u op soek is na ontplooiingsoutomatiseringsinstrumente wat die beskryfde logika insluit, let dan op
Bron: will.com