ນຳໃຊ້ແອັບພລິເຄຊັນໃນທົ່ວຫຼາຍກຸ່ມ Kubernetes ດ້ວຍ Helm

Dailymotion ໃຊ້ Kubernetes: ການນຳໃຊ້ແອັບພລິເຄຊັນ

ພວກເຮົາຢູ່ທີ່ Dailymotion ເລີ່ມໃຊ້ Kubernetes ໃນການຜະລິດ 3 ປີກ່ອນ. ແຕ່ການນຳໃຊ້ແອັບພລິເຄຊັນໃນທົ່ວກຸ່ມຫຼາຍກຸ່ມແມ່ນມີຄວາມມ່ວນ, ສະນັ້ນ ໃນໄລຍະສອງສາມປີຜ່ານມານີ້ ພວກເຮົາພະຍາຍາມປັບປຸງເຄື່ອງມື ແລະຂະບວນການເຮັດວຽກຂອງພວກເຮົາ.

ມັນເລີ່ມຕົ້ນຢູ່ໃສ

ໃນທີ່ນີ້ພວກເຮົາຈະໃຫ້ລາຍລະອຽດກ່ຽວກັບວິທີທີ່ພວກເຮົານຳໃຊ້ແອັບພລິເຄຊັນຂອງພວກເຮົາໃນທົ່ວກຸ່ມ Kubernetes ຫຼາຍກຸ່ມທົ່ວໂລກ.

ເພື່ອນຳໃຊ້ວັດຖຸ Kubernetes ຫຼາຍອັນພ້ອມກັນ, ພວກເຮົາໃຊ້ Helm, ແລະຕາຕະລາງທັງຫມົດຂອງພວກເຮົາຖືກເກັບໄວ້ໃນ repository git ດຽວ. ເພື່ອນໍາໃຊ້ stack ຄໍາຮ້ອງສະຫມັກຢ່າງເຕັມທີ່ຈາກການບໍລິການຈໍານວນຫນຶ່ງ, ພວກເຮົາໃຊ້ອັນທີ່ເອີ້ນວ່າຕາຕະລາງສະຫຼຸບ. ໂດຍພື້ນຖານແລ້ວ, ນີ້ແມ່ນຕາຕະລາງທີ່ປະກາດຄວາມເພິ່ງພາອາໄສແລະຊ່ວຍໃຫ້ທ່ານສາມາດເລີ່ມຕົ້ນ API ແລະການບໍລິການຂອງມັນດ້ວຍຄໍາສັ່ງດຽວ.

ພວກເຮົາຍັງໄດ້ຂຽນຕົວອັກສອນ Python ນ້ອຍໆຢູ່ເທິງສຸດຂອງ Helm ເພື່ອເຮັດການກວດສອບ, ສ້າງຕາຕະລາງ, ເພີ່ມຄວາມລັບ, ແລະນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກ. ວຽກງານທັງຫມົດເຫຼົ່ານີ້ແມ່ນປະຕິບັດຢູ່ໃນເວທີ CI ກາງໂດຍໃຊ້ຮູບພາບ docker.

ຂໍໃຫ້ມາຮອດຈຸດ.

ຫມາຍ​ເຫດ​. ໃນຂະນະທີ່ທ່ານອ່ານນີ້, ຜູ້ສະຫມັກການປ່ອຍຕົວທໍາອິດສໍາລັບ Helm 3 ໄດ້ຖືກປະກາດແລ້ວ. ສະບັບຕົ້ນຕໍປະກອບມີການປັບປຸງທັງຫມົດເພື່ອແກ້ໄຂບາງບັນຫາທີ່ພວກເຮົາໄດ້ພົບໃນອະດີດ.

ຂະບວນການພັດທະນາຕາຕະລາງ

ພວກເຮົາໃຊ້ສາຂາສໍາລັບຄໍາຮ້ອງສະຫມັກ, ແລະພວກເຮົາໄດ້ຕັດສິນໃຈນໍາໃຊ້ວິທີການດຽວກັນກັບຕາຕະລາງ.

• ສາຂາ dev ໃຊ້ເພື່ອສ້າງຕາຕະລາງທີ່ຈະຖືກທົດສອບໃນກຸ່ມການພັດທະນາ.
• ເມື່ອຄໍາຮ້ອງຂໍດຶງຖືກສົ່ງກັບ ຕົ້ນສະບັບ, ເຂົາເຈົ້າໄດ້ຖືກກວດກາຢູ່ໃນຂັ້ນຕອນ.
• ສຸດທ້າຍ, ພວກເຮົາສ້າງຄໍາຮ້ອງຂໍດຶງເພື່ອເຮັດການປ່ຽນແປງສາຂາ ຜະລິດຕະພັນ ແລະນໍາໃຊ້ພວກມັນໃນການຜະລິດ.

ແຕ່ລະສະພາບແວດລ້ອມມີບ່ອນເກັບມ້ຽນສ່ວນຕົວຂອງຕົນເອງທີ່ເກັບຮັກສາຕາຕະລາງຂອງພວກເຮົາ, ແລະພວກເຮົາໃຊ້ ຫໍພິພິທະພັນ Chartmuseum ດ້ວຍ APIs ທີ່ມີປະໂຫຍດຫຼາຍ. ວິທີນີ້ພວກເຮົາຮັບປະກັນຄວາມໂດດດ່ຽວຢ່າງເຂັ້ມງວດລະຫວ່າງສະພາບແວດລ້ອມແລະການທົດສອບຕົວຈິງຂອງຕາຕະລາງກ່ອນທີ່ຈະນໍາໃຊ້ພວກມັນໃນການຜະລິດ.

ຄັງເກັບຕາຕະລາງໃນສະພາບແວດລ້ອມທີ່ແຕກຕ່າງກັນ

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າເມື່ອຜູ້ພັດທະນາຊຸກຍູ້ສາຂາ dev, ສະບັບຂອງຕາຕະລາງຂອງພວກເຂົາຈະຖືກ pushed ໂດຍອັດຕະໂນມັດໄປຫາ dev Chartmuseum. ດັ່ງນັ້ນ, ນັກພັດທະນາທັງຫມົດໃຊ້ dev repository ດຽວກັນ, ແລະທ່ານຈໍາເປັນຕ້ອງກໍານົດສະບັບພາສາຂອງທ່ານຢ່າງລະມັດລະວັງເພື່ອບໍ່ໃຫ້ໃຊ້ການປ່ຽນແປງຂອງຄົນອື່ນໂດຍບັງເອີນ.

ຍິ່ງໄປກວ່ານັ້ນ, script Python ຂອງພວກເຮົາຍັງກວດສອບວັດຖຸ Kubernetes ຕໍ່ກັບຂໍ້ມູນຈໍາເພາະ Kubernetes OpenAPI ໂດຍໃຊ້ Kubeval, ກ່ອນທີ່ຈະເຜີຍແຜ່ພວກມັນຢູ່ໃນ Chartmusem.

ລາຍລະອຽດທົ່ວໄປຂອງຂະບວນການພັດທະນາຕາຕະລາງ

1. ການ​ຕັ້ງ​ຄ່າ​ວຽກ​ງານ​ທໍ່​ຕາມ​ສະ​ເພາະ​ gazr.io ສໍາລັບການຄວບຄຸມຄຸນນະພາບ (lint, unit-test).
2. ການຊຸກຍູ້ຮູບພາບ docker ດ້ວຍເຄື່ອງມື Python ທີ່ນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ.
3. ການຕັ້ງຄ່າສະພາບແວດລ້ອມໂດຍຊື່ສາຂາ.
4. ການກວດສອບໄຟລ໌ Kubernetes yaml ໂດຍໃຊ້ Kubeval.
5. ເພີ່ມສະບັບຂອງຕາຕະລາງແລະຕາຕະລາງຫຼັກຂອງມັນໂດຍອັດຕະໂນມັດ (ຕາຕະລາງທີ່ຂຶ້ນກັບຕາຕະລາງທີ່ມີການປ່ຽນແປງ).
6. ການສົ່ງຕາຕະລາງໄປຫາ Chartmuseum ທີ່ກົງກັບສະພາບແວດລ້ອມຂອງມັນ

ການຈັດການຄວາມແຕກຕ່າງໃນທົ່ວກຸ່ມ

ສະຫະພັນກຳມະບານ

ມີເວລາທີ່ພວກເຮົາໃຊ້ ສະຫະພັນຂອງກຸ່ມ Kubernetes, ບ່ອນທີ່ວັດຖຸ Kubernetes ສາມາດຖືກປະກາດຈາກຈຸດສິ້ນສຸດ API ດຽວ. ແຕ່ບັນຫາເກີດຂຶ້ນ. ຕົວຢ່າງ, ບາງວັດຖຸ Kubernetes ບໍ່ສາມາດຖືກສ້າງຢູ່ໃນຈຸດສິ້ນສຸດຂອງສະຫະພັນ, ເຮັດໃຫ້ມັນຍາກທີ່ຈະຮັກສາວັດຖຸສະຫະພັນແລະວັດຖຸອື່ນໆສໍາລັບແຕ່ລະກຸ່ມ.

ເພື່ອແກ້ໄຂບັນຫາ, ພວກເຮົາໄດ້ເລີ່ມຈັດການກຸ່ມຢ່າງເປັນເອກະລາດ, ເຊິ່ງເຮັດໃຫ້ຂະບວນການງ່າຍດາຍຫຼາຍ (ພວກເຮົາໃຊ້ສະບັບທໍາອິດຂອງສະຫະພັນ; ບາງສິ່ງບາງຢ່າງອາດຈະມີການປ່ຽນແປງໃນຄັ້ງທີສອງ).

ແພລະຕະຟອມທີ່ແຈກຢາຍທາງພູມສາດ

ປະຈຸບັນແພລດຟອມຂອງພວກເຮົາຖືກແຈກຢາຍໃນທົ່ວ 6 ພາກພື້ນ - 3 ທ້ອງຖິ່ນແລະ 3 ໃນຄລາວ.

ການ​ປະ​ຕິ​ບັດ​ການ​ແຈກ​ຢາຍ​

ຄຸນຄ່າທົ່ວໂລກ

4 ຄ່າ Helm ທົ່ວໂລກຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດຄວາມແຕກຕ່າງລະຫວ່າງກຸ່ມ. ແຜນວາດທັງໝົດຂອງພວກເຮົາມີຄ່າຂັ້ນຕ່ຳເລີ່ມຕົ້ນ.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

ຄຸນຄ່າທົ່ວໂລກ

ຄຸນຄ່າເຫຼົ່ານີ້ຊ່ວຍກໍານົດສະພາບການສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາແລະຖືກນໍາໃຊ້ເພື່ອຈຸດປະສົງຕ່າງໆ: ການຕິດຕາມ, ການຕິດຕາມ, ການບັນທຶກ, ການໂທຫາພາຍນອກ, ການປັບຂະຫນາດ, ແລະອື່ນໆ.

• "cloud": ພວກເຮົາມີແພລະຕະຟອມ Kubernetes ປະສົມ. ຕົວຢ່າງ, API ຂອງພວກເຮົາຖືກນຳໃຊ້ໃນເຂດ GCP ແລະໃນສູນຂໍ້ມູນຂອງພວກເຮົາ.
• "env": ບາງຄ່າອາດຈະປ່ຽນແປງສໍາລັບສະພາບແວດລ້ອມທີ່ບໍ່ແມ່ນການຜະລິດ. ຕົວຢ່າງ, ການກໍານົດຊັບພະຍາກອນແລະການຕັ້ງຄ່າອັດຕະໂນມັດ.
• "ພາກພື້ນ": ຂໍ້ມູນນີ້ຊ່ວຍກໍານົດສະຖານທີ່ຂອງກຸ່ມແລະສາມາດຖືກນໍາໃຊ້ເພື່ອກໍານົດຈຸດສິ້ນສຸດໃກ້ຄຽງສໍາລັບການບໍລິການພາຍນອກ.
• "clusterName": ຖ້າແລະເມື່ອພວກເຮົາຕ້ອງການກໍານົດຄ່າສໍາລັບແຕ່ລະກຸ່ມ.

ນີ້ແມ່ນຕົວຢ່າງສະເພາະ:

{{/* Returns Horizontal Pod Autoscaler replicas for GraphQL*/}}
{{- define "graphql.hpaReplicas" -}}
{{- if eq .Values.global.env "prod" }}
{{- if eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- else }}
minReplicas: 150
{{- end }}
maxReplicas: 1400
{{- else }}
minReplicas: 4
maxReplicas: 20
{{- end }}
{{- end -}}

ຕົວຢ່າງແມ່ແບບຂອງ Helm

ເຫດຜົນນີ້ຖືກກໍານົດໄວ້ໃນແມ່ແບບຜູ້ຊ່ວຍເພື່ອຫຼີກເວັ້ນການ cluttering Kubernetes YAML.

ປະກາດສະໝັກ

ເຄື່ອງມືການນຳໃຊ້ຂອງພວກເຮົາແມ່ນອີງໃສ່ຫຼາຍໄຟລ໌ YAML. ຂ້າງລຸ່ມນີ້ແມ່ນຕົວຢ່າງຂອງວິທີການທີ່ພວກເຮົາປະກາດການບໍລິການແລະ topology ຂະຫນາດຂອງມັນ (ຈໍານວນຂອງ replicas) ໃນກຸ່ມ.

releases:
  - foo.world

foo.world:                # Release name
  services:               # List of dailymotion's apps/projects
    foobar:
      chart_name: foo-foobar
      repo: [email protected]:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

ນິຍາມການບໍລິການ

ນີ້ແມ່ນໂຄງຮ່າງຂອງຂັ້ນຕອນທັງໝົດທີ່ກຳນົດຂັ້ນຕອນການເຮັດວຽກຂອງພວກເຮົາ. ຂັ້ນ​ຕອນ​ສຸດ​ທ້າຍ​ປະ​ຕິ​ບັດ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກັບ​ຫຼາຍ​ກຸ່ມ​ຄົນ​ງານ​ພ້ອມ​ກັນ​.

ຂັ້ນຕອນການນຳໃຊ້ Jenkins

ຈະເປັນແນວໃດກ່ຽວກັບຄວາມລັບ?

ກ່ຽວກັບຄວາມປອດໄພ, ພວກເຮົາຕິດຕາມຄວາມລັບທັງຫມົດຈາກສະຖານທີ່ທີ່ແຕກຕ່າງກັນແລະເກັບຮັກສາໃຫ້ເຂົາເຈົ້າຢູ່ໃນ vault ເປັນເອກະລັກ Vault ໃນປາຣີ.

ເຄື່ອງມືການຈັດວາງຂອງພວກເຮົາສະກັດເອົາຄ່າລັບຈາກ Vault ແລະ, ເມື່ອເວລາການໃຊ້ງານມາຮອດ, ໃສ່ພວກມັນເຂົ້າໄປໃນ Helm.

ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາໄດ້ກໍານົດແຜນທີ່ລະຫວ່າງຄວາມລັບໃນ Vault ແລະຄວາມລັບທີ່ຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາຕ້ອງການ:

secrets:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       contexts:                                                                                                                                                                                                   
         - name: "default"                                                                                                                                                                                         
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - name: "cluster1"                                                                                                                                                                           
           vaultPath: "/kv/dev/stack1/app1/test"                                                                                                                                                               
           vaultKey: "password"

• ພວກເຮົາໄດ້ກໍານົດກົດລະບຽບທົ່ວໄປທີ່ຈະປະຕິບັດຕາມໃນເວລາທີ່ບັນທຶກຄວາມລັບຢູ່ໃນ Vault.
• ຖ້າຄວາມລັບໃຊ້ ຕໍ່ກັບບໍລິບົດສະເພາະ ຫຼືກຸ່ມ, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມລາຍການສະເພາະ. (ທີ່ນີ້ context cluster1 ມີມູນຄ່າຂອງຕົນເອງສໍາລັບ stack-app1-password ລັບ).
• ຖ້າບໍ່ດັ່ງນັ້ນຄ່າແມ່ນໃຊ້ ໂດຍຄ່າເລີ່ມຕົ້ນ.
• ສໍາລັບແຕ່ລະລາຍການໃນບັນຊີລາຍຊື່ນີ້ໃນ Kubernetes ຄວາມລັບ ຄູ່ຄີ-ຄ່າຖືກໃສ່. ດັ່ງນັ້ນ, ແມ່ແບບລັບໃນຕາຕະລາງຂອງພວກເຮົາແມ່ນງ່າຍດາຍຫຼາຍ.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
type: Opaque

ບັນຫາແລະຂໍ້ຈໍາກັດ

ເຮັດວຽກກັບຫຼາຍ repositories

ໃນປັດຈຸບັນພວກເຮົາແຍກການພັດທະນາຂອງຕາຕະລາງແລະຄໍາຮ້ອງສະຫມັກ. ນີ້ຫມາຍຄວາມວ່ານັກພັດທະນາຕ້ອງເຮັດວຽກຢູ່ໃນສອງ git repositories: ຫນຶ່ງສໍາລັບຄໍາຮ້ອງສະຫມັກ, ແລະຫນຶ່ງສໍາລັບການກໍານົດການນໍາໃຊ້ຂອງຕົນກັບ Kubernetes. 2 git repositories ຫມາຍຄວາມວ່າ 2 workflows, ແລະມັນງ່າຍສໍາລັບມືໃຫມ່ທີ່ຈະສັບສົນ.

ການຄຸ້ມຄອງຕາຕະລາງທົ່ວໄປແມ່ນມີຄວາມຫຍຸ້ງຍາກ

ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວແລ້ວ, ຕາຕະລາງທົ່ວໄປແມ່ນເປັນປະໂຫຍດຫຼາຍສໍາລັບການກໍານົດການເພິ່ງພາອາໄສແລະນໍາໃຊ້ຫຼາຍຄໍາຮ້ອງສະຫມັກຢ່າງໄວວາ. ແຕ່ພວກເຮົາໃຊ້ --reuse-valuesເພື່ອຫຼີກເວັ້ນການຜ່ານຄ່າທັງຫມົດທຸກຄັ້ງທີ່ພວກເຮົານໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ເປັນສ່ວນຫນຶ່ງຂອງຕາຕະລາງທົ່ວໄປນີ້.

ໃນຂະບວນການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງ, ພວກເຮົາມີພຽງແຕ່ສອງຄ່າທີ່ປ່ຽນແປງເປັນປົກກະຕິ: ຈໍານວນຂອງ replicas ແລະ tag ຮູບພາບ (ສະບັບ). ອື່ນ, ຄ່າທີ່ຫມັ້ນຄົງຫຼາຍແມ່ນມີການປ່ຽນແປງດ້ວຍຕົນເອງ, ແລະນີ້ແມ່ນຂ້ອນຂ້າງຍາກ. ຍິ່ງໄປກວ່ານັ້ນ, ຄວາມຜິດພາດອັນໜຶ່ງໃນການນຳໃຊ້ຕາຕະລາງທົ່ວໄປສາມາດນຳໄປສູ່ຄວາມລົ້ມເຫຼວທີ່ຮ້າຍແຮງ, ດັ່ງທີ່ພວກເຮົາໄດ້ເຫັນຈາກປະສົບການຂອງພວກເຮົາເອງ.

ການປັບປຸງໄຟລ໌ການຕັ້ງຄ່າຫຼາຍອັນ

ເມື່ອຜູ້ພັດທະນາເພີ່ມແອັບພລິເຄຊັນໃຫມ່, ລາວຕ້ອງປ່ຽນໄຟລ໌ຫຼາຍ: ການປະກາດແອັບພລິເຄຊັນ, ລາຍຊື່ຄວາມລັບ, ເພີ່ມແອັບພລິເຄຊັນເປັນການເພິ່ງພາອາໄສຖ້າມັນຖືກລວມຢູ່ໃນຕາຕະລາງທົ່ວໄປ.

ການອະນຸຍາດ Jenkins ແມ່ນຂະຫຍາຍເກີນໄປໃນ Vault

ໃນປັດຈຸບັນພວກເຮົາມີຫນຶ່ງ AppRole, ເຊິ່ງອ່ານຄວາມລັບທັງຫມົດຈາກ Vault.

ຂະບວນການ rollback ບໍ່ແມ່ນອັດຕະໂນມັດ

ເພື່ອ rollback, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດໍາເນີນການຄໍາສັ່ງໃນຫຼາຍ clusters, ແລະນີ້ແມ່ນ fraught ມີຄວາມຜິດພາດ. ພວກເຮົາດໍາເນີນການນີ້ດ້ວຍຕົນເອງເພື່ອຮັບປະກັນວ່າ ID ສະບັບທີ່ຖືກຕ້ອງຖືກລະບຸ.

ພວກເຮົາກໍາລັງກ້າວໄປສູ່ GitOps

ເປົ້າOurາຍຂອງພວກເຮົາ

ພວກເຮົາຕ້ອງການກັບຄືນຕາຕະລາງກັບ repository ຂອງຄໍາຮ້ອງສະຫມັກທີ່ມັນ deploy.

ຂະບວນການເຮັດວຽກຈະຄືກັນກັບການພັດທະນາ. ຕົວຢ່າງ, ເມື່ອສາຂາຖືກຍູ້ໃຫ້ເປັນແມ່ບົດ, ການຕິດຕັ້ງຈະຖືກກະຕຸ້ນໂດຍອັດຕະໂນມັດ. ຄວາມແຕກຕ່າງຕົ້ນຕໍລະຫວ່າງວິທີການນີ້ແລະຂະບວນການເຮັດວຽກໃນປະຈຸບັນຈະເປັນແບບນັ້ນ ທຸກສິ່ງທຸກຢ່າງຈະຖືກຄຸ້ມຄອງໃນ git (ແອັບພລິເຄຊັນຕົວມັນເອງແລະວິທີການທີ່ມັນຖືກ ນຳ ໃຊ້ໃນ Kubernetes).

ມີຫຼາຍຂໍ້ໄດ້ປຽບ:

• ຫຼາຍ ຈະແຈ້ງກວ່າ ສໍາ​ລັບ​ການ​ພັດ​ທະ​ນາ​. ມັນງ່າຍກວ່າທີ່ຈະຮຽນຮູ້ວິທີການນໍາໃຊ້ການປ່ຽນແປງໃນຕາຕະລາງທ້ອງຖິ່ນ.
• ສາມາດກຳນົດການກຳນົດການນຳໃຊ້ການບໍລິການໄດ້ ສະຖານທີ່ດຽວກັນກັບລະຫັດ ການບໍລິການ.
• ການຄຸ້ມຄອງການໂຍກຍ້າຍຂອງຕາຕະລາງທົ່ວໄປ. ການບໍລິການຈະມີການປ່ອຍ Helm ຂອງຕົນເອງ. ນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດຈັດການວົງຈອນຊີວິດຂອງແອັບພລິເຄຊັນ (rollback, ຍົກລະດັບ) ໃນລະດັບນ້ອຍທີ່ສຸດ, ເພື່ອບໍ່ໃຫ້ຜົນກະທົບຕໍ່ການບໍລິການອື່ນໆ.
• ຜົນປະໂຫຍດຂອງ git ສໍາລັບການຈັດການຕາຕະລາງ: ຍົກເລີກການປ່ຽນແປງ, ບັນທຶກການກວດສອບ, ແລະອື່ນໆ. ຖ້າທ່ານຕ້ອງການຍົກເລີກການປ່ຽນແປງໃນຕາຕະລາງ, ທ່ານສາມາດເຮັດສິ່ງນີ້ໂດຍໃຊ້ git. ການຕິດຕັ້ງເລີ່ມຕົ້ນອັດຕະໂນມັດ.
• ທ່ານອາດຈະພິຈາລະນາປັບປຸງຂະບວນການພັດທະນາຂອງທ່ານດ້ວຍເຄື່ອງມືເຊັ່ນ Skaffold, ເຊິ່ງນັກພັດທະນາສາມາດທົດສອບການປ່ຽນແປງໃນສະພາບການທີ່ໃກ້ຊິດກັບການຜະລິດ.

ການເຄື່ອນຍ້າຍສອງຂັ້ນຕອນ

ນັກພັດທະນາຂອງພວກເຮົາໄດ້ໃຊ້ຂະບວນການເຮັດວຽກນີ້ເປັນເວລາ 2 ປີແລ້ວ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງຢາກໃຫ້ການເຄື່ອນຍ້າຍບໍ່ເຈັບປວດເທົ່າທີ່ເປັນໄປໄດ້. ດັ່ງນັ້ນ, ພວກເຮົາຕັດສິນໃຈທີ່ຈະເພີ່ມຂັ້ນຕອນລະດັບປານກາງກ່ຽວກັບວິທີການໄປສູ່ເປົ້າຫມາຍ.
ຂັ້ນ​ຕອນ​ທໍາ​ອິດ​ແມ່ນ​ງ່າຍ​ດາຍ​:

• ພວກເຮົາຮັກສາໂຄງສ້າງທີ່ຄ້າຍຄືກັນສໍາລັບການຕັ້ງຄ່າການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກ, ແຕ່ຢູ່ໃນວັດຖຸດຽວທີ່ເອີ້ນວ່າ DailymotionRelease.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "/kv/dev/ns1/app1/test"
          vaultKey: "password"

• 1 ການປ່ອຍຕໍ່ແອັບພລິເຄຊັນ (ໂດຍບໍ່ມີຕາຕະລາງທົ່ວໄປ).
• ຕາຕະລາງຢູ່ໃນບ່ອນເກັບ git ຂອງແອັບພລິເຄຊັນ.

ພວກເຮົາໄດ້ສົນທະນາກັບນັກພັດທະນາທັງຫມົດ, ດັ່ງນັ້ນຂະບວນການການເຄື່ອນຍ້າຍໄດ້ເລີ່ມຂຶ້ນແລ້ວ. ຂັ້ນຕອນທໍາອິດແມ່ນຍັງຖືກຄວບຄຸມໂດຍໃຊ້ເວທີ CI. ຂ້ອຍຈະຂຽນຂໍ້ຄວາມອື່ນໃນໄວໆນີ້ກ່ຽວກັບໄລຍະສອງ: ວິທີທີ່ພວກເຮົາຍ້າຍໄປຢູ່ໃນຂັ້ນຕອນການເຮັດວຽກ GitOps ກັບ ໄຫຼ. ຂ້ອຍຈະບອກເຈົ້າວ່າພວກເຮົາຕັ້ງຄ່າທຸກຢ່າງແນວໃດ ແລະປະສົບກັບຄວາມຫຍຸ້ງຍາກອັນໃດ (ບ່ອນເກັບມ້ຽນຫຼາຍອັນ, ຄວາມລັບ, ແລະອື່ນໆ). ຕິດຕາມຂ່າວ.

ໃນທີ່ນີ້ພວກເຮົາໄດ້ພະຍາຍາມອະທິບາຍຄວາມຄືບຫນ້າຂອງພວກເຮົາໃນຂັ້ນຕອນການເຮັດວຽກຂອງການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກໃນປີທີ່ຜ່ານມາ, ເຊິ່ງເຮັດໃຫ້ຄວາມຄິດກ່ຽວກັບວິທີການ GitOps. ພວກເຮົາຍັງບໍ່ທັນໄດ້ບັນລຸເປົ້າຫມາຍແລະຈະລາຍງານກ່ຽວກັບຜົນໄດ້ຮັບ, ແຕ່ໃນປັດຈຸບັນພວກເຮົາຫມັ້ນໃຈວ່າພວກເຮົາໄດ້ເຮັດຢ່າງຖືກຕ້ອງເມື່ອພວກເຮົາຕັດສິນໃຈເຮັດໃຫ້ທຸກສິ່ງທຸກຢ່າງງ່າຍດາຍແລະເຮັດໃຫ້ມັນໃກ້ຊິດກັບນິໄສຂອງນັກພັດທະນາ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com