ការរួមបញ្ចូលគ្នានៃផ្ទាំងគ្រប់គ្រង Kubernetes និងអ្នកប្រើប្រាស់ GitLab

Kubernetes Dashboard គឺជាឧបករណ៍ងាយស្រួលប្រើសម្រាប់ការទទួលបានព័ត៌មានថ្មីៗអំពីចង្កោមដែលកំពុងដំណើរការរបស់អ្នក និងគ្រប់គ្រងវាដោយការខិតខំប្រឹងប្រែងតិចតួចបំផុត។ អ្នកចាប់ផ្តើមពេញចិត្តចំពោះវាកាន់តែខ្លាំងនៅពេលដែលការចូលប្រើសមត្ថភាពទាំងនេះមិនត្រឹមតែត្រូវការដោយអ្នកគ្រប់គ្រង/វិស្វករ DevOps ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងដោយអ្នកដែលមិនសូវទម្លាប់ប្រើប្រាស់កុងសូល និង/ឬមិនមានបំណងដោះស្រាយជាមួយនឹងភាពស្មុគស្មាញទាំងអស់នៃការធ្វើអន្តរកម្មជាមួយ kubectl និង ឧបករណ៍ប្រើប្រាស់ផ្សេងទៀត។ វាបានកើតឡើងជាមួយយើង៖ អ្នកអភិវឌ្ឍន៍ចង់បានការចូលប្រើរហ័សទៅកាន់ចំណុចប្រទាក់បណ្ដាញ Kubernetes ហើយចាប់តាំងពីយើងប្រើ GitLab ដំណោះស្រាយបានកើតឡើងដោយធម្មជាតិ។

ហេតុអ្វីបានជានេះ?

អ្នកអភិវឌ្ឍន៍ដោយផ្ទាល់ប្រហែលជាចាប់អារម្មណ៍លើឧបករណ៍ដូចជា K8s Dashboard សម្រាប់បំបាត់កំហុស។ ពេលខ្លះអ្នកចង់មើលកំណត់ហេតុ និងធនធាន ហើយជួនកាលសម្លាប់ផត ធ្វើមាត្រដ្ឋាន ការដាក់ពង្រាយ/ការកំណត់ស្ថានភាព និងសូម្បីតែចូលទៅកាន់កុងសូលកុងតឺន័រ (ក៏មានសំណើផងដែរ ដែលទោះជាយ៉ាងណា មានវិធីមួយផ្សេងទៀត - ឧទាហរណ៍ តាមរយៈ kubectl-បំបាត់កំហុស).

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

ជាប្រព័ន្ធស្តង់ដារ CI យើងមាន បានអនុវត្ត GitLab៖ អ្នកអភិវឌ្ឍន៍ទាំងអស់ក៏ប្រើវាដែរ។ ដូច្នេះ ដើម្បីផ្តល់ឱ្យពួកគេនូវការចូលប្រើ វាសមហេតុផលក្នុងការរួមបញ្ចូល Dashboard ជាមួយគណនី GitLab ។

ខ្ញុំក៏នឹងកត់សម្គាល់ផងដែរថាយើងប្រើ NGINX Ingress ។ ប្រសិនបើអ្នកធ្វើការជាមួយអ្នកដទៃ ដំណោះស្រាយ ingressអ្នកនឹងត្រូវស្វែងរកដោយឯករាជ្យនូវ analogues នៃចំណារពន្យល់សម្រាប់ការអនុញ្ញាត។

កំពុងព្យាយាមរួមបញ្ចូល

ការដំឡើងផ្ទាំងគ្រប់គ្រង

យកចិត្តទុកដាក់៖ ប្រសិនបើអ្នកនឹងធ្វើម្តងទៀតនូវជំហានខាងក្រោម បន្ទាប់មក - ដើម្បីជៀសវាងប្រតិបត្តិការដែលមិនចាំបាច់ - ដំបូងអានទៅចំណងជើងរងបន្ទាប់។

ចាប់តាំងពីយើងប្រើការរួមបញ្ចូលនេះនៅក្នុងការដំឡើងជាច្រើន យើងបានធ្វើឱ្យការដំឡើងរបស់វាដោយស្វ័យប្រវត្តិ។ ប្រភពដែលត្រូវការសម្រាប់ការនេះត្រូវបានបោះពុម្ពផ្សាយនៅក្នុង ឃ្លាំង GitHub ពិសេស. ពួកវាផ្អែកលើការកំណត់រចនាសម្ព័ន្ធ YAML ដែលបានកែប្រែបន្តិចបន្តួចពី ឃ្លាំង Dashboard ផ្លូវការក៏ដូចជាស្គ្រីប Bash សម្រាប់ការដាក់ពង្រាយរហ័ស។

ស្គ្រីបដំឡើងផ្ទាំងគ្រប់គ្រងនៅក្នុងចង្កោម ហើយកំណត់រចនាសម្ព័ន្ធវាសម្រាប់ការរួមបញ្ចូលជាមួយ GitLab៖

$ ./ctl.sh  
Usage: ctl.sh [OPTION]... --gitlab-url GITLAB_URL --oauth2-id ID --oauth2-secret SECRET --dashboard-url DASHBOARD_URL
Install kubernetes-dashboard to Kubernetes cluster.
Mandatory arguments:
 -i, --install                install into 'kube-system' namespace
 -u, --upgrade                upgrade existing installation, will reuse password and host names
 -d, --delete                 remove everything, including the namespace
     --gitlab-url             set gitlab url with schema (https://gitlab.example.com)
     --oauth2-id              set OAUTH2_PROXY_CLIENT_ID from gitlab
     --oauth2-secret          set OAUTH2_PROXY_CLIENT_SECRET from gitlab
     --dashboard-url          set dashboard url without schema (dashboard.example.com)
Optional arguments:
 -h, --help                   output this message

ទោះយ៉ាងណាក៏ដោយ មុននឹងប្រើវា អ្នកត្រូវចូលទៅកាន់ GitLab: Admin area → Applications - ហើយបន្ថែមកម្មវិធីថ្មីសម្រាប់បន្ទះនាពេលអនាគត។ ចូរហៅវាថា "ផ្ទាំងគ្រប់គ្រង Kubernetes"៖

ជាលទ្ធផលនៃការបន្ថែមវា GitLab នឹងផ្តល់នូវសញ្ញាសម្គាល់៖

ពួក​គេ​គឺ​ជា​អ្នក​ដែល​ត្រូវ​បាន​ប្រើ​ជា​អាគុយម៉ង់​ចំពោះ​ស្គ្រីប។ ជាលទ្ធផលការដំឡើងមើលទៅដូចនេះ:

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

បន្ទាប់ពីនោះសូមពិនិត្យមើលថាអ្វីគ្រប់យ៉ាងបានចាប់ផ្តើម:

$ kubectl -n kube-system get pod | egrep '(dash|oauth)'
kubernetes-dashboard-76b55bc9f8-xpncp   1/1       Running   0          14s
oauth2-proxy-5586ccf95c-czp2v           1/1       Running   0          14s

ទោះយ៉ាងណាក៏ដោយ មិនយូរមិនឆាប់ អ្វីៗនឹងចាប់ផ្តើម ការអនុញ្ញាតនឹងមិនដំណើរការភ្លាមៗទេ។! ការពិតគឺថានៅក្នុងរូបភាពដែលបានប្រើ (ស្ថានភាពនៅក្នុងរូបភាពផ្សេងទៀតគឺស្រដៀងគ្នា) ដំណើរការនៃការចាប់បញ្ជូនបន្តក្នុងការហៅត្រឡប់មកវិញត្រូវបានអនុវត្តមិនត្រឹមត្រូវ។ កាលៈទេសៈនេះនាំឱ្យមានការពិតដែលថា oauth លុបខូគីដែល oauth ខ្លួនវាផ្តល់ឱ្យយើង ...

បញ្ហា​ត្រូវ​បាន​ដោះស្រាយ​ដោយ​ការ​បង្កើត​រូបភាព oauth ផ្ទាល់​ខ្លួន​របស់​អ្នក​ជាមួយ​នឹង​បំណះ។

Patch Oauth និងដំឡើងឡើងវិញ

ដើម្បីធ្វើដូចនេះយើងនឹងប្រើ Dockerfile ខាងក្រោម៖

FROM golang:1.9-alpine3.7
WORKDIR /go/src/github.com/bitly/oauth2_proxy

RUN apk --update add make git build-base curl bash ca-certificates wget 
&& update-ca-certificates 
&& curl -sSO https://raw.githubusercontent.com/pote/gpm/v1.4.0/bin/gpm 
&& chmod +x gpm 
&& mv gpm /usr/local/bin
RUN git clone https://github.com/bitly/oauth2_proxy.git . 
&& git checkout bfda078caa55958cc37dcba39e57fc37f6a3c842  
ADD rd.patch .
RUN patch -p1 < rd.patch 
&& ./dist.sh

FROM alpine:3.7
RUN apk --update add curl bash  ca-certificates && update-ca-certificates
COPY --from=0 /go/src/github.com/bitly/oauth2_proxy/dist/ /bin/

EXPOSE 8080 4180
ENTRYPOINT [ "/bin/oauth2_proxy" ]
CMD [ "--upstream=http://0.0.0.0:8080/", "--http-address=0.0.0.0:4180" ]

ហើយនេះគឺជាអ្វីដែលបំណះ rd.patch ខ្លួនវាមើលទៅដូច

diff --git a/dist.sh b/dist.sh
index a00318b..92990d4 100755
--- a/dist.sh
+++ b/dist.sh
@@ -14,25 +14,13 @@ goversion=$(go version | awk '{print $3}')
sha256sum=()
 
echo "... running tests"
-./test.sh
+#./test.sh
 
-for os in windows linux darwin; do
-    echo "... building v$version for $os/$arch"
-    EXT=
-    if [ $os = windows ]; then
-        EXT=".exe"
-    fi
-    BUILD=$(mktemp -d ${TMPDIR:-/tmp}/oauth2_proxy.XXXXXX)
-    TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
-    FILENAME="oauth2_proxy-$version.$os-$arch$EXT"
-    GOOS=$os GOARCH=$arch CGO_ENABLED=0 
-        go build -ldflags="-s -w" -o $BUILD/$TARGET/$FILENAME || exit 1
-    pushd $BUILD/$TARGET
-    sha256sum+=("$(shasum -a 256 $FILENAME || exit 1)")
-    cd .. && tar czvf $TARGET.tar.gz $TARGET
-    mv $TARGET.tar.gz $DIR/dist
-    popd
-done
+os='linux'
+echo "... building v$version for $os/$arch"
+TARGET="oauth2_proxy-$version.$os-$arch.$goversion"
+GOOS=$os GOARCH=$arch CGO_ENABLED=0 
+    go build -ldflags="-s -w" -o ./dist/oauth2_proxy || exit 1
  
checksum_file="sha256sum.txt"
cd $DIR/dists
diff --git a/oauthproxy.go b/oauthproxy.go
index 21e5dfc..df9101a 100644
--- a/oauthproxy.go
+++ b/oauthproxy.go
@@ -381,7 +381,9 @@ func (p *OAuthProxy) SignInPage(rw http.ResponseWriter, req *http.Request, code
       if redirect_url == p.SignInPath {
               redirect_url = "/"
       }
-
+       if req.FormValue("rd") != "" {
+               redirect_url = req.FormValue("rd")
+       }
       t := struct {
               ProviderName  string
               SignInMessage string

ឥឡូវនេះអ្នកអាចបង្កើតរូបភាពហើយរុញវាចូលទៅក្នុង GitLab របស់យើង។ បន្ទាប់នៅក្នុង manifests/kube-dashboard-oauth2-proxy.yaml ចង្អុលបង្ហាញការប្រើប្រាស់រូបភាពដែលអ្នកចង់បាន (ជំនួសវាដោយខ្លួនអ្នក)៖

 image: docker.io/colemickens/oauth2_proxy:latest

ប្រសិនបើអ្នកមានបញ្ជីឈ្មោះដែលត្រូវបានបិទដោយការអនុញ្ញាត កុំភ្លេចបន្ថែមការប្រើប្រាស់អាថ៌កំបាំងសម្រាប់ទាញរូបភាព៖

      imagePullSecrets:
     - name: gitlab-registry

... ហើយបន្ថែមអាថ៌កំបាំងដោយខ្លួនឯងសម្រាប់ការចុះបញ្ជី៖

---
apiVersion: v1
data:
 .dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
 annotations:
 name: gitlab-registry
 namespace: kube-system
type: kubernetes.io/dockercfg

អ្នកអានដែលយកចិត្តទុកដាក់នឹងឃើញថាខ្សែវែងខាងលើគឺ base64 ពីការកំណត់៖

{"registry.company.com": {
 "username": "oauth2",
 "password": "PASSWORD",
 "auth": "AUTH_TOKEN",
 "email": "[email protected]"
}
}

នេះគឺជាទិន្នន័យអ្នកប្រើប្រាស់នៅក្នុង GitLab លេខកូដ Kubernetes នឹងទាញរូបភាពចេញពីបញ្ជីឈ្មោះ។

បន្ទាប់ពីអ្វីៗគ្រប់យ៉ាងរួចរាល់ អ្នកអាចដកចរន្ត (មិនដំណើរការត្រឹមត្រូវ) ការដំឡើងផ្ទាំងគ្រប់គ្រងដោយប្រើពាក្យបញ្ជា៖

$ ./ctl.sh -d

... ហើយដំឡើងអ្វីៗគ្រប់យ៉ាងម្តងទៀត៖

$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.com

វាដល់ពេលដែលត្រូវចូលទៅកាន់ផ្ទាំងគ្រប់គ្រង ហើយស្វែងរកប៊ូតុងចូលដែលមានលក្ខណៈបុរាណ៖

បន្ទាប់ពីចុចលើវា GitLab នឹងស្វាគមន៍យើងដោយផ្តល់ឱ្យយើងចូលទៅក្នុងទំព័រធម្មតារបស់វា (ជាការពិតណាស់ប្រសិនបើយើងមិនបានចូលពីមុនទេ):

យើងចូលដោយប្រើព័ត៌មានសម្ងាត់ GitLab ហើយអ្វីៗគ្រប់យ៉ាងរួចរាល់៖

អំពីមុខងាររបស់ផ្ទាំងគ្រប់គ្រង

ប្រសិនបើអ្នកជាអ្នកអភិវឌ្ឍន៍ដែលមិនបានធ្វើការជាមួយ Kubernetes ពីមុនមក ឬដោយហេតុផលមួយចំនួនដែលមិនបានជួបប្រទះ Dashboard ពីមុនមក ខ្ញុំនឹងបង្ហាញពីសមត្ថភាពមួយចំនួនរបស់វា។

ដំបូងអ្នកអាចឃើញថា "អ្វីគ្រប់យ៉ាងគឺពណ៌បៃតង":

ទិន្នន័យលម្អិតបន្ថែមក៏មានសម្រាប់ផតដែរ ដូចជាអថេរបរិស្ថាន រូបភាពដែលបានទាញយក អាគុយម៉ង់ចាប់ផ្តើម និងស្ថានភាពរបស់វា៖

ការដាក់ពង្រាយមានស្ថានភាពដែលអាចមើលឃើញ៖

... និងព័ត៌មានលម្អិតផ្សេងទៀត៖

... ហើយ​ក៏​មាន​សមត្ថភាព​ក្នុង​ការ​ធ្វើ​មាត្រដ្ឋាន​ការ​ដាក់​ពង្រាយ៖

លទ្ធផលនៃប្រតិបត្តិការនេះ៖

ក្នុងចំណោមមុខងារមានប្រយោជន៍ផ្សេងទៀតដែលបានរៀបរាប់រួចហើយនៅដើមអត្ថបទគឺការមើលកំណត់ហេតុ៖

... និងមុខងារដើម្បីចូលទៅក្នុងកុងសូលកុងតឺន័រនៃផតដែលបានជ្រើសរើស៖

ឧទាហរណ៍ អ្នកក៏អាចមើលដែនកំណត់/សំណើនៅលើថ្នាំង៖

ជាការពិតណាស់ ទាំងនេះមិនមែនជាសមត្ថភាពទាំងអស់របស់បន្ទះនោះទេ ប៉ុន្តែខ្ញុំសង្ឃឹមថាអ្នកទទួលបានគំនិតទូទៅ។

គុណវិបត្តិនៃការរួមបញ្ចូលនិងផ្ទាំងគ្រប់គ្រង

នៅក្នុងការរួមបញ្ចូលដែលបានពិពណ៌នាមិនមានទេ។ ការគ្រប់គ្រងការចូលប្រើ. ជាមួយវា អ្នកប្រើប្រាស់ទាំងអស់ដែលមានសិទ្ធិចូលប្រើ GitLab ទទួលបានសិទ្ធិចូលទៅកាន់ផ្ទាំងគ្រប់គ្រង។ ពួកគេមានសិទ្ធិចូលប្រើដូចគ្នានៅក្នុង Dashboard ខ្លួនវាផ្ទាល់ ដែលត្រូវនឹងសិទ្ធិរបស់ Dashboard ខ្លួនវា ដែល ត្រូវបានកំណត់នៅក្នុង RBAC. ជាក់ស្តែង នេះមិនស័ក្តិសមសម្រាប់មនុស្សគ្រប់គ្នា ប៉ុន្តែសម្រាប់ករណីរបស់យើង វាបានប្រែក្លាយថាគ្រប់គ្រាន់ហើយ។

ក្នុងចំណោមគុណវិបត្តិដែលគួរឱ្យកត់សម្គាល់នៅក្នុង Dashboard ខ្លួនវាផ្ទាល់ ខ្ញុំកត់សម្គាល់ដូចខាងក្រោម:

• វាមិនអាចទៅរួចទេក្នុងការចូលទៅក្នុងកុងសូលនៃធុង init;
• វាមិនអាចទៅរួចទេក្នុងការកែសម្រួល Deployments និង StatefulSets ទោះបីជាវាអាចត្រូវបានជួសជុលនៅក្នុង ClusterRole ក៏ដោយ។
• ភាពឆបគ្នារបស់ផ្ទាំងគ្រប់គ្រងជាមួយនឹងកំណែចុងក្រោយបំផុតរបស់ Kubernetes និងអនាគតនៃគម្រោងបង្កើតជាសំណួរ។

បញ្ហាចុងក្រោយសមនឹងទទួលបានការយកចិត្តទុកដាក់ជាពិសេស។

ស្ថានភាពផ្ទាំងគ្រប់គ្រង និងជម្រើសជំនួស

តារាងភាពឆបគ្នានៃផ្ទាំងគ្រប់គ្រងជាមួយនឹងការចេញផ្សាយ Kubernetes ដែលបង្ហាញនៅក្នុងកំណែចុងក្រោយបំផុតនៃគម្រោង (v1.10.1), មិនសប្បាយចិត្តខ្លាំងណាស់:

បើទោះបីជានេះ, មាន (អនុម័តរួចហើយនៅក្នុងខែមករា) PR # 3476ដែលប្រកាសការគាំទ្រសម្រាប់ K8s 1.13 ។ លើសពីនេះទៀត ក្នុងចំណោមបញ្ហាគម្រោង អ្នកអាចស្វែងរកឯកសារយោងទៅកាន់អ្នកប្រើប្រាស់ដែលធ្វើការជាមួយបន្ទះនៅក្នុង K8s 1.14 ។ ទីបំផុត ប្តេជ្ញា ចូលទៅក្នុងមូលដ្ឋានកូដរបស់គម្រោងមិនបញ្ឈប់។ ដូច្នេះ (យ៉ាងហោចណាស់!) ស្ថានភាពជាក់ស្តែងនៃគម្រោងគឺមិនអាក្រក់ដូចដែលវាហាក់ដូចជាដំបូងពីតារាងភាពត្រូវគ្នាជាផ្លូវការ។

ទីបំផុតមានជម្រើសជំនួស Dashboard ។ ក្នុងចំណោម​ពួកគេ:

1. K8Dash - ចំណុចប្រទាក់វ័យក្មេង (ការប្តេជ្ញាចិត្តដំបូងមានកាលបរិច្ឆេទត្រឡប់ទៅខែមីនានៃឆ្នាំនេះ) ដែលផ្តល់នូវលក្ខណៈពិសេសល្អរួចទៅហើយ ដូចជាការបង្ហាញរូបភាពនៃស្ថានភាពបច្ចុប្បន្ននៃចង្កោម និងការគ្រប់គ្រងវត្ថុរបស់វា។ ត្រូវបានដាក់ជា "ចំណុចប្រទាក់ពេលវេលាពិត" ពីព្រោះ ធ្វើបច្ចុប្បន្នភាពទិន្នន័យដែលបានបង្ហាញដោយស្វ័យប្រវត្តិដោយមិនតម្រូវឱ្យអ្នកធ្វើបច្ចុប្បន្នភាពទំព័រនៅក្នុងកម្មវិធីរុករក។
2. កុងសូល OpenShift - ចំណុចប្រទាក់បណ្ដាញពី Red Hat OpenShift ដែលនឹងនាំមកនូវការអភិវឌ្ឍន៍ផ្សេងទៀតនៃគម្រោងទៅកាន់ចង្កោមរបស់អ្នក ដែលមិនសមរម្យសម្រាប់មនុស្សគ្រប់គ្នា។
3. Kubernator គឺជាគម្រោងគួរឱ្យចាប់អារម្មណ៍មួយ ដែលបង្កើតជាចំណុចប្រទាក់កម្រិតទាប (ជាងផ្ទាំងគ្រប់គ្រង) ជាមួយនឹងសមត្ថភាពក្នុងការមើលវត្ថុចង្កោមទាំងអស់។ ទោះយ៉ាងណាក៏ដោយ វាហាក់ដូចជាការអភិវឌ្ឍន៍របស់វាបានឈប់ហើយ។
4. ប៉ូលឺរី - ទើបតែថ្ងៃមុន។ បានប្រកាស គម្រោងដែលរួមបញ្ចូលគ្នានូវមុខងារនៃបន្ទះមួយ (បង្ហាញស្ថានភាពបច្ចុប្បន្ននៃចង្កោម ប៉ុន្តែមិនគ្រប់គ្រងវត្ថុរបស់វា) និង "សុពលភាពនៃការអនុវត្តល្អបំផុត" ដោយស្វ័យប្រវត្តិ (ពិនិត្យមើលចង្កោមសម្រាប់ភាពត្រឹមត្រូវនៃការកំណត់រចនាសម្ព័ន្ធនៃការដាក់ពង្រាយដែលកំពុងដំណើរការនៅក្នុងវា)។

ជំនួសឱ្យការសន្និដ្ឋាន

ផ្ទាំងគ្រប់គ្រងគឺជាឧបករណ៍ស្តង់ដារសម្រាប់ចង្កោម Kubernetes ដែលយើងបម្រើ។ ការរួមបញ្ចូលរបស់វាជាមួយ GitLab ក៏បានក្លាយជាផ្នែកមួយនៃការដំឡើងលំនាំដើមរបស់យើងផងដែរ ដោយសារតែអ្នកអភិវឌ្ឍន៍ជាច្រើនមានការរំភើបចំពោះសមត្ថភាពដែលពួកគេមានជាមួយបន្ទះនេះ។

Kubernetes Dashboard ជាទៀងទាត់មានជម្រើសពីសហគមន៍ប្រភពបើកចំហ (ហើយយើងរីករាយក្នុងការពិចារណាពួកវា) ប៉ុន្តែនៅដំណាក់កាលនេះ យើងនៅតែមានដំណោះស្រាយនេះ។

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

• «kubebox និងសែលផ្សេងទៀតសម្រាប់ Kubernetes»
• «ការអនុវត្ត CI/CD ល្អបំផុតជាមួយ Kubernetes និង GitLab (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)»
• «បង្កើត និងប្រើប្រាស់កម្មវិធីនៅក្នុង Kubernetes ដោយប្រើ dapp និង GitLab CI»
• «GitLab CI សម្រាប់ការរួមបញ្ចូលជាបន្តបន្ទាប់ និងការចែកចាយនៅក្នុងផលិតកម្ម។ ផ្នែកទី 1: បំពង់របស់យើង។"។

ប្រភព: www.habr.com