🥇دمج لوحة تحكم Kubernetes ومستخدمي GitLab

Kubernetes Dashboard هي أداة سهلة الاستخدام للحصول على معلومات محدثة حول مجموعة قيد التشغيل والحد الأدنى من إدارتها. تبدأ في تقدير ذلك أكثر عندما يكون الوصول إلى هذه الإمكانات مطلوبًا ليس فقط من قبل المسؤولين/مهندسي DevOps، ولكن أيضًا من قبل أولئك الذين هم أقل اعتيادًا على وحدة التحكم و/أو لا ينوون التعامل مع جميع تعقيدات التفاعل مع kubectl و المرافق الأخرى. لقد حدث هذا معنا: أراد المطورون الوصول بسرعة إلى واجهة ويب Kubernetes، وبما أننا نستخدم GitLab، فقد جاء الحل بشكل طبيعي.

لماذا هذا؟

قد يكون المطورون المباشرون مهتمين بأداة مثل K8s Dashboard لمهام تصحيح الأخطاء. في بعض الأحيان ترغب في عرض السجلات والموارد، وفي بعض الأحيان ترغب في إيقاف البودات، وتوسيع نطاق عمليات النشر/مجموعات الحالة، وحتى الانتقال إلى وحدة تحكم الحاوية (توجد أيضًا طلبات، ولكن هناك طريقة أخرى لذلك - على سبيل المثال، من خلال kubectl-debug).

بالإضافة إلى ذلك، هناك لحظة نفسية للمديرين عندما يريدون النظر إلى المجموعة - ليروا أن "كل شيء أخضر"، وبالتالي يطمئنون أنفسهم إلى أن "كل شيء يعمل" (وهو بالطبع أمر نسبي للغاية... ولكن هذا خارج نطاق المقال).

كنظام CI قياسي لدينا تطبق GitLab: يستخدمه جميع المطورين أيضًا. لذلك، لتزويدهم بإمكانية الوصول، كان من المنطقي دمج Dashboard مع حسابات GitLab.

سألاحظ أيضًا أننا نستخدم NGINX Ingress. إذا كنت تعمل مع الآخرين حلول الدخول، ستحتاج إلى العثور على نظائرها للتعليقات التوضيحية بشكل مستقل للحصول على الترخيص.

محاولة التكامل

تركيب لوحة القيادة

اهتمام: إذا كنت ستعيد الخطوات أدناه، فتجنب العمليات غير الضرورية - اقرأ أولاً العنوان الفرعي التالي.

وبما أننا نستخدم هذا التكامل في العديد من عمليات التثبيت، فقد قمنا بأتمتة تثبيته. ونشرت المصادر اللازمة لذلك في مستودع جيثب خاص. وهي تعتمد على تكوينات YAML المعدلة قليلاً من مستودع لوحة القيادة الرسميةبالإضافة إلى برنامج Bash النصي للنشر السريع.

يقوم البرنامج النصي بتثبيت Dashboard في المجموعة وتكوينه للتكامل مع 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 نفسه...

تم حل المشكلة عن طريق إنشاء صورة المصادقة الخاصة بك باستخدام التصحيح.

تصحيح 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 من الوصول إلى لوحة المعلومات. لديهم نفس الوصول إلى لوحة المعلومات نفسها، بما يتوافق مع حقوق لوحة المعلومات نفسها، والتي يتم تعريفها في RBAC. من الواضح أن هذا لا يناسب الجميع، ولكن بالنسبة لحالتنا تبين أنه كاف.

ومن العيوب الملحوظة في لوحة التحكم نفسها أذكر ما يلي:

من المستحيل الدخول إلى وحدة التحكم في حاوية init؛
من المستحيل تحرير عمليات النشر وStatefulSets، على الرغم من إمكانية إصلاح ذلك في ClusterRole؛
يثير توافق لوحة المعلومات مع أحدث إصدارات Kubernetes ومستقبل المشروع تساؤلات.

المشكلة الأخيرة تستحق اهتماما خاصا.

حالة لوحة القيادة والبدائل

جدول توافق لوحة المعلومات مع إصدارات Kubernetes، المعروض في الإصدار الأخير من المشروع (v1.10.1)، لست سعيدًا جدًا:

وعلى الرغم من ذلك، هناك (تم اعتماده بالفعل في يناير) رقم العلاقات العامة 3476، الذي يعلن عن دعم K8s 1.13. بالإضافة إلى ذلك، من بين مشكلات المشروع، يمكنك العثور على مراجع للمستخدمين الذين يعملون مع اللوحة في K8s 1.14. أخيراً، يرتكب في قاعدة التعليمات البرمجية للمشروع لا تتوقف. لذا (على الأقل!) فإن الوضع الفعلي للمشروع ليس سيئًا كما قد يبدو للوهلة الأولى من جدول التوافق الرسمي.

وأخيرا، هناك بدائل للوحة القيادة. فيما بينها:

K8داش - واجهة حديثة (يعود تاريخ الالتزام الأول إلى شهر مارس من هذا العام)، والتي تقدم بالفعل ميزات جيدة، مثل التمثيل المرئي للحالة الحالية للمجموعة وإدارة كائناتها. تم وضعها على أنها "واجهة في الوقت الفعلي"، لأن يقوم تلقائيًا بتحديث البيانات المعروضة دون الحاجة إلى تحديث الصفحة في المتصفح.
وحدة تحكم OpenShift - واجهة ويب من Red Hat OpenShift، والتي، مع ذلك، ستجلب تطورات أخرى للمشروع إلى مجموعتك، وهي ليست مناسبة للجميع.
كوبرناتور هو مشروع مثير للاهتمام، تم إنشاؤه كواجهة ذات مستوى أدنى (من لوحة المعلومات) مع القدرة على عرض كافة كائنات المجموعة. ومع ذلك، يبدو أن تطورها قد توقف.
بولاريس - فقط في اليوم الآخر أعلن مشروع يجمع بين وظائف اللوحة (يظهر الحالة الحالية للمجموعة، لكنه لا يدير كائناتها) و"التحقق من أفضل الممارسات" التلقائي (يتحقق من المجموعة للتأكد من صحة تكوينات عمليات النشر الجارية فيها).

بدلا من الاستنتاجات

تعد لوحة المعلومات أداة قياسية لمجموعات Kubernetes التي نخدمها. لقد أصبح تكاملها مع GitLab أيضًا جزءًا من التثبيت الافتراضي لدينا، نظرًا لأن العديد من المطورين متحمسون للإمكانيات المتوفرة لديهم مع هذه اللوحة.

تحتوي لوحة تحكم Kubernetes بشكل دوري على بدائل من مجتمع المصدر المفتوح (ويسعدنا أن نأخذها بعين الاعتبار)، ولكن في هذه المرحلة نبقى مع هذا الحل.

PS

اقرأ أيضًا على مدونتنا:

المصدر: www.habr.com

تكامل Kubernetes Dashboard و GitLab Users