Kubernetes ड्यासबोर्ड र GitLab प्रयोगकर्ताहरूको एकीकरण

Kubernetes Dashboard तपाईको चलिरहेको क्लस्टरको बारेमा अद्यावधिक जानकारी प्राप्त गर्न र यसलाई न्यूनतम प्रयासमा व्यवस्थापन गर्न प्रयोग गर्न सजिलो उपकरण हो। तपाइँ यसलाई अझ बढि कदर गर्न थाल्नुहुन्छ जब यी क्षमताहरूमा पहुँच प्रशासकहरू/DevOps ईन्जिनियरहरू द्वारा मात्र आवश्यक पर्दैन, तर कन्सोलमा कम अभ्यस्त र/वा kubectl सँग अन्तर्क्रिया गर्ने सबै जटिलताहरूसँग व्यवहार गर्न चाहँदैनन्। अन्य उपयोगिताहरू। यो हामीसँग भयो: विकासकर्ताहरू Kubernetes वेब इन्टरफेसमा द्रुत पहुँच चाहन्थे, र हामीले GitLab प्रयोग गर्दा, समाधान स्वाभाविक रूपमा आयो।

यो किन हो?

प्रत्यक्ष विकासकर्ताहरूले डिबगिङ कार्यहरूको लागि K8s ड्यासबोर्ड जस्ता उपकरणमा रुचि राख्न सक्छन्। कहिलेकाहीँ तपाईं लगहरू र स्रोतहरू हेर्न चाहनुहुन्छ, र कहिलेकाहीं पोडहरू मार्न चाहनुहुन्छ, डिप्लोयमेन्ट/स्टेटफुलसेटहरू मापन गर्नुहोस् र कन्टेनर कन्सोलमा पनि जानुहोस् (त्यहाँ अनुरोधहरू पनि छन्, तथापि, त्यहाँ अर्को तरिका छ - उदाहरणका लागि, मार्फत। kubectl-debug).

थप रूपमा, त्यहाँ प्रबन्धकहरूका लागि एक मनोवैज्ञानिक क्षण हो जब तिनीहरू क्लस्टरमा हेर्न चाहन्छन् - "सबै कुरा हरियो छ" हेर्नको लागि, र यसरी आफूलाई "सबै कुराले काम गरिरहेको छ" भनेर आश्वस्त पार्छ (जुन, अवश्य पनि, धेरै सापेक्ष छ ... तर यो लेखको दायरा बाहिर छ)।

मानक CI प्रणालीको रूपमा हामीसँग छ लागू गरियो GitLab: सबै विकासकर्ताहरूले यसलाई पनि प्रयोग गर्छन्। त्यसकारण, तिनीहरूलाई पहुँच प्रदान गर्न, GitLab खाताहरूसँग ड्यासबोर्ड एकीकृत गर्न तार्किक थियो।

म यो पनि नोट गर्नेछु कि हामी NGINX Ingress प्रयोग गर्छौं। यदि तपाईं अरूसँग काम गर्नुहुन्छ प्रवेश समाधानहरू, तपाईंले आधिकारिकताको लागि एनोटेसनहरूको एनालगहरू स्वतन्त्र रूपमा फेला पार्न आवश्यक छ।

एकीकरण प्रयास गर्दै

ड्यासबोर्ड स्थापना

सावधानी: यदि तपाइँ तलका चरणहरू दोहोर्याउन जाँदै हुनुहुन्छ भने, त्यसपछि - अनावश्यक कार्यहरूबाट बच्न - पहिले अर्को उपशीर्षकमा पढ्नुहोस्।

हामीले धेरै स्थापनाहरूमा यो एकीकरण प्रयोग गरेको हुनाले, हामीले यसको स्थापना स्वचालित गरेका छौं। यसका लागि आवश्यक स्रोतहरू प्रकाशित छन् विशेष GitHub भण्डार। तिनीहरू बाट थोरै परिमार्जित YAML कन्फिगरेसनहरूमा आधारित छन् आधिकारिक ड्यासबोर्ड भण्डार, साथै द्रुत तैनातीको लागि ब्यास स्क्रिप्ट।

स्क्रिप्टले क्लस्टरमा ड्यासबोर्ड स्थापना गर्दछ र यसलाई 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 मा जानु पर्छ: प्रशासन क्षेत्र → अनुप्रयोगहरू - र भविष्य प्यानलको लागि नयाँ अनुप्रयोग थप्नुहोस्। यसलाई "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 आफैले हामीलाई प्रदान गर्दछ ...

समस्या एक प्याच संग आफ्नो शपथ छवि निर्माण गरेर हल गरिएको छ।

प्याच शपथ र पुन: स्थापना

यो गर्नको लागि, हामी निम्न 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 credentials को साथ लग इन गर्छौं - र सबै कुरा सकियो:

ड्यासबोर्ड सुविधाहरू बारे

यदि तपाईं एक विकासकर्ता हुनुहुन्छ जसले पहिले Kubernetes सँग काम गर्नुभएको छैन, वा केवल कुनै कारणले गर्दा ड्यासबोर्डको सामना गर्नुभएन भने, म यसको केही क्षमताहरू चित्रण गर्नेछु।

पहिले, तपाईले देख्न सक्नुहुन्छ कि "सबै हरियो छ":

थप विस्तृत डेटा पोडहरूका लागि पनि उपलब्ध छ, जस्तै वातावरण चरहरू, डाउनलोड गरिएको छवि, सुरुवात तर्कहरू, र तिनीहरूको अवस्था:

डिप्लोयमेन्टहरू देखिने स्थितिहरू छन्:

... र अन्य विवरणहरू:

... र त्यहाँ तैनाती मापन गर्ने क्षमता पनि छ:

यस अपरेशनको नतिजा:

लेखको सुरुमा पहिले नै उल्लेख गरिएका अन्य उपयोगी सुविधाहरू मध्ये लगहरू हेर्नु हो:

... र चयन गरिएको पोडको कन्टेनर कन्सोलमा लग इन गर्ने प्रकार्य:

उदाहरणका लागि, तपाईंले नोडहरूमा सीमा/अनुरोधहरू पनि हेर्न सक्नुहुन्छ:

निस्सन्देह, यी प्यानलका सबै क्षमताहरू होइनन्, तर मलाई आशा छ कि तपाईंले सामान्य विचार पाउनुहुन्छ।

एकीकरण र ड्यासबोर्डका बेफाइदाहरू

वर्णन गरिएको एकीकरणमा त्यहाँ छैन पहुँच नियन्त्रण। यसको साथ, GitLab मा पहुँच भएका सबै प्रयोगकर्ताहरूले ड्यासबोर्डमा पहुँच प्राप्त गर्छन्। तिनीहरूसँग ड्यासबोर्डमा नै समान पहुँच छ, ड्यासबोर्डको अधिकारसँग सम्बन्धित, जुन RBAC मा परिभाषित गरिएको छ। निस्सन्देह, यो सबैको लागि उपयुक्त छैन, तर हाम्रो मामलाको लागि यो पर्याप्त भयो।

ड्यासबोर्डमा देख्न सकिने बेफाइदाहरू मध्ये, म निम्नलाई नोट गर्छु:

• init कन्टेनरको कन्सोलमा पुग्न असम्भव छ;
• यो डिप्लोयमेन्ट र स्टेटफुलसेटहरू सम्पादन गर्न असम्भव छ, यद्यपि यसलाई क्लस्टररोलमा फिक्स गर्न सकिन्छ;
• Kubernetes को नवीनतम संस्करणहरु संग ड्यासबोर्डको अनुकूलता र परियोजना को भविष्य प्रश्न उठाउँछ।

पछिल्लो समस्या विशेष ध्यान योग्य छ।

ड्यासबोर्ड स्थिति र विकल्पहरू

Kubernetes विज्ञप्ति संग ड्यासबोर्ड अनुकूलता तालिका, परियोजना को नवीनतम संस्करण मा प्रस्तुत (v1.10.1), धेरै खुसी छैन:

यो बावजुद, त्यहाँ (पहिले नै जनवरी मा अपनाइएको) छ PR #३४७६, जसले K8s 1.13 को लागि समर्थन घोषणा गर्दछ। थप रूपमा, परियोजना मुद्दाहरू बीचमा तपाइँ K8s 1.14 मा प्यानलसँग काम गर्ने प्रयोगकर्ताहरूको सन्दर्भहरू फेला पार्न सक्नुहुन्छ। अन्तमा, प्रतिबद्ध गर्दछ परियोजनाको कोड आधारमा रोक्नुहोस्। त्यसोभए (कम्तिमा!) परियोजनाको वास्तविक स्थिति त्यति खराब छैन जति यो पहिलो आधिकारिक अनुकूलता तालिकाबाट देखिन्छ।

अन्तमा, त्यहाँ ड्यासबोर्ड विकल्पहरू छन्। उनीहरु मध्ये:

1. K8Dash — एक युवा इन्टरफेस (पहिलो कमिट यस वर्षको मार्चमा फिर्ता हुन्छ), जसले पहिले नै राम्रो सुविधाहरू प्रदान गर्दछ, जस्तै क्लस्टरको हालको स्थितिको दृश्य प्रतिनिधित्व र यसको वस्तुहरूको व्यवस्थापन। "वास्तविक-समय इन्टरफेस" को रूपमा राखिएको, किनभने तपाईँले ब्राउजरमा पृष्ठ रिफ्रेस गर्न आवश्यक बिना प्रदर्शित डाटा स्वचालित रूपमा अद्यावधिक गर्दछ।
2. OpenShift कन्सोल - Red Hat OpenShift बाट एक वेब इन्टरफेस, जसले, तथापि, तपाइँको क्लस्टरमा परियोजनाको अन्य विकासहरू ल्याउनेछ, जुन सबैका लागि उपयुक्त छैन।
3. कुबर्नेटर सबै क्लस्टर वस्तुहरू हेर्न सक्ने क्षमताको साथ तल्लो-स्तर (ड्यासबोर्ड भन्दा) इन्टरफेसको रूपमा सिर्जना गरिएको एउटा रोचक परियोजना हो। तर, यसको विकास रोकिएको देखिन्छ ।
4. पोलारिस - अर्को दिन मात्र घोषणा गरियो एउटा परियोजना जसले प्यानलको कार्यहरू संयोजन गर्दछ (क्लस्टरको हालको अवस्था देखाउँदछ, तर यसको वस्तुहरू व्यवस्थापन गर्दैन) र स्वचालित "उत्तम अभ्यासहरूको प्रमाणीकरण" (यसमा चलिरहेको डिप्लोयमेन्टहरूको कन्फिगरेसनहरूको शुद्धताको लागि क्लस्टर जाँच गर्दछ)।

निष्कर्षको सट्टा

ड्यासबोर्ड हामीले सेवा गर्ने Kubernetes क्लस्टरहरूको लागि एक मानक उपकरण हो। GitLab सँग यसको एकीकरण पनि हाम्रो पूर्वनिर्धारित स्थापनाको अंश बनेको छ, किनकि धेरै विकासकर्ताहरू यस प्यानलसँग भएका क्षमताहरूको बारेमा उत्साहित छन्।

Kubernetes Dashboard सँग आवधिक रूपमा खुला स्रोत समुदायबाट विकल्पहरू छन् (र हामी तिनीहरूलाई विचार गर्न पाउँदा खुसी छौं), तर यस चरणमा हामी यो समाधानको साथ रहन्छौं।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «kubebox र Kubernetes को लागि अन्य गोलाहरू»;
• «Kubernetes र GitLab (समीक्षा र भिडियो रिपोर्ट) संग उत्तम CI/CD अभ्यासहरू»;
• «Dapp र GitLab CI प्रयोग गरेर Kubernetes मा अनुप्रयोगहरू निर्माण र तैनाती गर्नुहोस्»;
• «उत्पादनमा निरन्तर एकीकरण र वितरणको लागि GitLab CI। भाग १: हाम्रो पाइपलाइन"।

स्रोत: www.habr.com