Simplex et securus modus agendi cum Helm in automatis canariis

Instruere canaria efficacissima via est ad probandum novum codicem in usorum copia. Signanter redigit onus negotiationis quod problematicum esse potest in processu instruere, quod solum intra certam partem occurrit. Haec nota vacat quomodo talis instruere usus Kubernetes et automationem instruere. Ponimus te aliquid scire de opibus Helm et Kubernetibus.



Simplex instruere canaria ad Kubernetes duas facultates praecipuas continet: ipsum servitium et instrumentum instruere. Instrumentum instruere per unicum ministerium operatur quod correspondet cum duobus diversis opum actis negotiationis servientibus. Una harum facultatum versione "canariae" laborabit, altera cum versione stabili laborabit. Hoc in casu, numerum versionum canariarum moderari possumus ad redigendum quantitatem negotiationis quae ad ministrandum requiruntur. Si, exempli gratia, Yaml uti mavis, tum in Kubernetes hoc simile spectabit;

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.

Facilius etiam est hanc optionem utens kubectl et in . fingere Documenta Kubernetes Etiam plena est in hac missione doceo. Sed praecipua quaestio huius postis est quomodo nos hunc processum Helm utentem automate facturi sumus.

Automation de instruere

Imprimis, tabula geographica Helm chart, quae iam facultates de quibus supra tractavimus complectitur. Videre debet aliquid simile hoc;

~/charts/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Fundamentum Helm conceptus est administratio multi-versionis solvo. Versio stabilis est nostra principalis ramus stabilis documenti codicem. Sed apud Helm possumus cum codice nostro experimentalem emissionem pandere. Summa est, ut negotiatio commercium inter versionem stabilem et missionem canariam servet. Nos omnia haec tractabimus utendo selecto speciali:

selector:
  app.kubernetes.io/name: myapp

Nostrae facultates "canariae" ac stabilis instruere opes hunc pittacium in modulis indicabunt. Si omnia recte configurantur, tum in programmatis tabulae chartulae Helm nostrae versionis canariae videbimus commercium ad modos explicandi modulos ordinandos esse. Haec versio stabilis huius praecepti haec erit:

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

Nunc scriptor canarium emissio nostra perscriptio. Ad versionem canariam explicandam, duo meminisse necesse est. Nomen emissio differre debet ut renovationem ad versionem stabilem hodiernam non evolvamus. Versio et tag alia quoque esse debent ut alium codicem explicare atque differentias per tags resource cognoscere possumus.

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

Ita est! Si ministerium pingis, videre potes ut viae canariae update negotiantes partem tantum temporis.

Si instrumenta automationis quaerunt instruere quae logicam descriptam includunt, operam da Deliverybot quod Galea automation instrumenta in GitHub. Helm chartis methodum adhibendam supra scriptam sunt in Github; hic. In genere haec speculatio theorica fuit quomodo efficiendum automationem instruere potest versionibus canariis in praxi, cum notionibus et exemplis specificis.

Source: www.habr.com