ដាក់ពង្រាយកម្មវិធីនៅលើចង្កោម Kubernetes ជាច្រើនជាមួយ Helm

របៀបដែល Dailymotion ប្រើ Kubernetes: ការដាក់ឱ្យប្រើប្រាស់កម្មវិធី

យើងនៅ Dailymotion បានចាប់ផ្តើមប្រើប្រាស់ Kubernetes នៅក្នុងផលិតកម្មកាលពី 3 ឆ្នាំមុន។ ប៉ុន្តែការដាក់ពង្រាយកម្មវិធីនៅទូទាំងចង្កោមជាច្រើនគឺមានភាពរីករាយ ដូច្នេះក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ យើងបានព្យាយាមកែលម្អឧបករណ៍ និងដំណើរការការងាររបស់យើង។

តើវាចាប់ផ្តើមនៅឯណា

នៅទីនេះ យើងនឹងរៀបរាប់អំពីរបៀបដែលយើងដាក់ឱ្យប្រើប្រាស់កម្មវិធីរបស់យើងនៅលើចង្កោម Kubernetes ជាច្រើននៅជុំវិញពិភពលោក។

ដើម្បីដាក់ពង្រាយវត្ថុ Kubernetes ច្រើនក្នុងពេលតែមួយ យើងប្រើ កាន់តំណែងហើយគំនូសតាងរបស់យើងទាំងអស់ត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំង git មួយ។ ដើម្បីដាក់ពង្រាយជង់កម្មវិធីពេញលេញពីសេវាកម្មជាច្រើន យើងប្រើអ្វីដែលគេហៅថាតារាងសង្ខេប។ សំខាន់នេះគឺជាតារាងដែលប្រកាសភាពអាស្រ័យ និងអនុញ្ញាតឱ្យអ្នកចាប់ផ្តើម API និងសេវាកម្មរបស់វាដោយប្រើពាក្យបញ្ជាតែមួយ។

យើងក៏បានសរសេរអក្សរ Python តូចមួយនៅពីលើ Helm ដើម្បីធ្វើការត្រួតពិនិត្យ បង្កើតគំនូសតាង បន្ថែមអាថ៌កំបាំង និងដាក់ពង្រាយកម្មវិធី។ កិច្ចការទាំងអស់នេះត្រូវបានអនុវត្តនៅលើវេទិកា CI កណ្តាលដោយប្រើរូបភាព docker ។

ចូរយើងឈានដល់ចំណុច។

ចំណាំ។ ដូចដែលអ្នកបានអាននេះ បេក្ខជនចេញដំបូងសម្រាប់ Helm 3 ត្រូវបានប្រកាសរួចហើយ។ កំណែចម្បងមានការកែលម្អទាំងមូល ដើម្បីដោះស្រាយបញ្ហាមួយចំនួនដែលយើងបានជួបប្រទះនាពេលកន្លងមក។

ដំណើរការអភិវឌ្ឍន៍គំនូសតាង

យើងប្រើការបែងចែកសម្រាប់កម្មវិធី ហើយយើងបានសម្រេចចិត្តអនុវត្តវិធីសាស្រ្តដូចគ្នាទៅនឹងតារាង។

• សាខា dev ប្រើដើម្បីបង្កើតគំនូសតាងដែលនឹងត្រូវបានសាកល្បងលើក្រុមអភិវឌ្ឍន៍។
• នៅពេលដែលសំណើទាញត្រូវបានដាក់ជូន មេពួកគេត្រូវបានត្រួតពិនិត្យនៅក្នុងដំណាក់កាល។
• ជាចុងក្រោយ យើងបង្កើតសំណើរទាញដើម្បីអនុវត្តការផ្លាស់ប្តូរទៅសាខា ផលិតផល និងអនុវត្តពួកវាក្នុងផលិតកម្ម។

បរិយាកាសនីមួយៗមានឃ្លាំងឯកជនផ្ទាល់ខ្លួនរបស់វា ដែលរក្សាទុកតារាងរបស់យើង ហើយយើងប្រើប្រាស់ សារមន្ទីរ ជាមួយ APIs មានប្រយោជន៍ខ្លាំងណាស់។ វិធីនេះយើងធានាឱ្យមានភាពឯកោយ៉ាងតឹងរ៉ឹងរវាងបរិស្ថាន និងការសាកល្បងក្នុងពិភពពិតនៃគំនូសតាង មុនពេលប្រើពួកវាក្នុងការផលិត។

ឃ្លាំងគំនូសតាងនៅក្នុងបរិយាកាសផ្សេងៗគ្នា

គួរកត់សម្គាល់ថា នៅពេលដែលអ្នកអភិវឌ្ឍន៍ជំរុញសាខាអភិវឌ្ឍន៍ កំណែនៃគំនូសតាងរបស់ពួកគេត្រូវបានរុញដោយស្វ័យប្រវត្តិទៅកាន់ dev Chartmuseum ។ ដូច្នេះ អ្នកអភិវឌ្ឍន៍ទាំងអស់ប្រើឃ្លាំង dev ដូចគ្នា ហើយអ្នកត្រូវបញ្ជាក់កំណែតារាងរបស់អ្នកដោយប្រុងប្រយ័ត្ន ដើម្បីកុំឱ្យប្រើការផ្លាស់ប្ដូររបស់នរណាម្នាក់ដោយចៃដន្យ។

លើសពីនេះទៅទៀត ស្គ្រីប 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 ក្នុង​ពពក។

ការដាក់ពង្រាយចែកចាយ

តម្លៃ Global Helm

តម្លៃ Helm សកលចំនួន 4 អនុញ្ញាតឱ្យអ្នកកំណត់ភាពខុសគ្នារវាងចង្កោម។ គំនូសតាងរបស់យើងទាំងអស់មានតម្លៃអប្បបរមាលំនាំដើម។

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

តម្លៃសកល

តម្លៃទាំងនេះជួយកំណត់បរិបទសម្រាប់កម្មវិធីរបស់យើង ហើយត្រូវបានប្រើសម្រាប់គោលបំណងផ្សេងៗ៖ ការត្រួតពិនិត្យ ការតាមដាន ការកត់ត្រា ការហៅទូរសព្ទខាងក្រៅ ការធ្វើមាត្រដ្ឋាន។ល។

• "ពពក"៖ យើងមានវេទិកា 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 -}}

គំរូគំរូមួកសុវត្ថិភាព

តក្កវិជ្ជានេះត្រូវបានកំណត់នៅក្នុងគំរូជំនួយដើម្បីជៀសវាងការពង្រាយ Kubernetes YAML ។

សេចក្តីប្រកាសអំពីពាក្យសុំ

ឧបករណ៍ដាក់ពង្រាយរបស់យើងគឺផ្អែកលើឯកសារ YAML ច្រើន។ ខាងក្រោមនេះគឺជាឧទាហរណ៍នៃរបៀបដែលយើងប្រកាសសេវាកម្មមួយ និងធរណីមាត្រនៃការធ្វើមាត្រដ្ឋានរបស់វា (ចំនួននៃការចម្លង) នៅក្នុងចង្កោមមួយ។

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 ហើយនៅពេលដែលពេលវេលាដាក់ពង្រាយមកដល់ សូមបញ្ចូលពួកវាទៅក្នុង 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"

• យើង​បាន​កំណត់​ច្បាប់​ទូទៅ​ដែល​ត្រូវ​អនុវត្ត​នៅពេល​កត់ត្រា​អាថ៌កំបាំង​នៅក្នុង​បន្ទប់​គេង។
• ប្រសិនបើការសម្ងាត់ត្រូវបានអនុវត្ត ទៅបរិបទជាក់លាក់ ឬចង្កោមអ្នកត្រូវបន្ថែមធាតុជាក់លាក់មួយ។ (នៅទីនេះ context cluster1 មានតម្លៃផ្ទាល់ខ្លួនសម្រាប់ secret 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

បញ្ហានិងដែនកំណត់

ធ្វើការជាមួយឃ្លាំងជាច្រើន។

ឥឡូវនេះយើងបែងចែកការអភិវឌ្ឍន៍នៃគំនូសតាង និងកម្មវិធី។ នេះមានន័យថាអ្នកអភិវឌ្ឍន៍ត្រូវធ្វើការនៅក្នុងឃ្លាំង git ពីរ៖ មួយសម្រាប់កម្មវិធី និងមួយទៀតសម្រាប់កំណត់ការដាក់ពង្រាយរបស់វាទៅ Kubernetes ។ 2 git repositories មានន័យថា 2 workflows ហើយវាងាយស្រួលសម្រាប់អ្នកទើបចាប់ផ្តើមយល់ច្រលំ។

ការគ្រប់គ្រងគំនូសតាងទូទៅគឺជាការពិបាក

ដូចដែលយើងបាននិយាយរួចមកហើយ គំនូសតាងទូទៅមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់ការកំណត់អត្តសញ្ញាណភាពអាស្រ័យ និងដាក់ឱ្យប្រើប្រាស់កម្មវិធីច្រើនយ៉ាងរហ័ស។ ប៉ុន្តែយើងប្រើ --reuse-valuesដើម្បីជៀសវាងការឆ្លងកាត់តម្លៃទាំងអស់ រាល់ពេលដែលយើងដាក់ពង្រាយកម្មវិធីដែលជាផ្នែកមួយនៃគំនូសតាងទូទៅនេះ។

នៅក្នុងដំណើរការនៃការចែកចាយបន្ត យើងមានតម្លៃតែពីរប៉ុណ្ណោះដែលផ្លាស់ប្តូរទៀងទាត់គឺចំនួននៃការចម្លង និងស្លាករូបភាព (កំណែ)។ ផ្សេងទៀត តម្លៃដែលមានស្ថេរភាពជាងមុនត្រូវបានផ្លាស់ប្តូរដោយដៃ ហើយនេះពិតជាពិបាកណាស់។ លើសពីនេះទៅទៀត កំហុសមួយក្នុងការដាក់ពង្រាយគំនូសតាងទូទៅអាចនាំឱ្យមានការបរាជ័យធ្ងន់ធ្ងរ ដូចដែលយើងបានឃើញពីបទពិសោធន៍ផ្ទាល់របស់យើង។

ការធ្វើបច្ចុប្បន្នភាពឯកសារកំណត់រចនាសម្ព័ន្ធច្រើន។

នៅពេលអ្នកអភិវឌ្ឍន៍បន្ថែមកម្មវិធីថ្មី គាត់ត្រូវផ្លាស់ប្តូរឯកសារជាច្រើន៖ ការប្រកាសកម្មវិធី បញ្ជីអាថ៌កំបាំង បន្ថែមកម្មវិធីជាការពឹងផ្អែកប្រសិនបើវាត្រូវបានបញ្ចូលក្នុងតារាងទូទៅ។

ការអនុញ្ញាតរបស់ Jenkins ត្រូវបានពង្រីកពេកនៅក្នុង Vault

ឥឡូវនេះយើងមានមួយ។ AppRoleដែលអានអាថ៌កំបាំងទាំងអស់ពីតុដេក។

ដំណើរ​ការ​ត្រឡប់​វិញ​មិន​ត្រូវ​បាន​ស្វ័យ​ប្រវត្តិ​ទេ។

ដើម្បី​ត្រឡប់​វិញ អ្នក​ត្រូវ​រត់​ពាក្យ​បញ្ជា​លើ​ចង្កោម​ជា​ច្រើន ហើយ​វា​មាន​កំហុស។ យើងអនុវត្តប្រតិបត្តិការនេះដោយដៃដើម្បីធានាថាលេខសម្គាល់កំណែត្រឹមត្រូវត្រូវបានបញ្ជាក់។

យើងកំពុងឆ្ពោះទៅកាន់ GitOps

គោលដៅ​របស់​យើង

យើងចង់ត្រឡប់តារាងទៅឃ្លាំងនៃកម្មវិធីដែលវាដាក់ពង្រាយ។

ដំណើរការការងារនឹងដូចគ្នានឹងការអភិវឌ្ឍន៍។ ឧទាហរណ៍ នៅពេលដែលសាខាមួយត្រូវបានរុញទៅមេ ការដាក់ពង្រាយនឹងត្រូវបានកេះដោយស្វ័យប្រវត្តិ។ ភាពខុសគ្នាសំខាន់រវាងវិធីសាស្រ្តនេះ និងលំហូរការងារបច្ចុប្បន្ននឹងទៅជានោះ។ អ្វីគ្រប់យ៉ាងនឹងត្រូវបានគ្រប់គ្រងនៅក្នុង git (កម្មវិធីខ្លួនវា និងវិធីដែលវាត្រូវបានដាក់ពង្រាយនៅក្នុង Kubernetes)។

មានអត្ថប្រយោជន៍ជាច្រើន៖

• ច្រើន កាន់តែច្បាស់ សម្រាប់អ្នកអភិវឌ្ឍន៍។ វាកាន់តែងាយស្រួលរៀនពីរបៀបអនុវត្តការផ្លាស់ប្តូរនៅក្នុងតារាងមូលដ្ឋាន។
• និយមន័យនៃការប្រើប្រាស់សេវាកម្មអាចត្រូវបានបញ្ជាក់ កន្លែងដូចគ្នានឹងលេខកូដ សេវាកម្ម។
• គ្រប់គ្រងការដកចេញនូវគំនូសតាងទូទៅ. សេវាកម្មនេះនឹងមានការចេញផ្សាយ Helm ផ្ទាល់ខ្លួន។ វា​នឹង​អនុញ្ញាត​ឱ្យ​អ្នក​គ្រប់គ្រង​វដ្ត​ជីវិត​របស់​កម្មវិធី (rollback, upgrade) នៅ​កម្រិត​តូច​បំផុត ដើម្បី​កុំឱ្យ​ប៉ះពាល់​ដល់​សេវាកម្ម​ផ្សេងទៀត។
• អត្ថប្រយោជន៍នៃ 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 ។ ខ្ញុំនឹងសរសេរប្រកាសមួយទៀតក្នុងពេលឆាប់ៗនេះអំពីដំណាក់កាលទី XNUMX៖ របៀបដែលយើងបានផ្លាស់ទីទៅលំហូរការងារ GitOps ជាមួយ ហូរ. ខ្ញុំ​នឹង​ប្រាប់​អ្នក​ពី​របៀប​ដែល​យើង​រៀបចំ​អ្វី​គ្រប់​យ៉ាង និង​ការ​លំបាក​ណា​ដែល​យើង​ជួប​ប្រទះ (ឃ្លាំង​ច្រើន អាថ៌កំបាំង ។ល។) តាមដានព័ត៌មាន។

នៅទីនេះ យើងបានព្យាយាមពណ៌នាអំពីវឌ្ឍនភាពរបស់យើងនៅក្នុងដំណើរការនៃការដាក់ពង្រាយកម្មវិធីក្នុងរយៈពេលប៉ុន្មានឆ្នាំកន្លងមកនេះ ដែលនាំឱ្យមានគំនិតអំពីវិធីសាស្រ្ត GitOps ។ យើងមិនទាន់បានទៅដល់គោលដៅនៅឡើយទេ ហើយនឹងរាយការណ៍អំពីលទ្ធផល ប៉ុន្តែឥឡូវនេះយើងជឿជាក់ថាយើងបានធ្វើរឿងត្រឹមត្រូវ នៅពេលដែលយើងសម្រេចចិត្តធ្វើឱ្យអ្វីៗទាំងអស់មានលក្ខណៈសាមញ្ញ ហើយនាំវាឱ្យកាន់តែជិតទៅនឹងទម្លាប់របស់អ្នកអភិវឌ្ឍន៍។

ប្រភព: www.habr.com