ادغام داشبورد Kubernetes و کاربران GitLab

ادغام داشبورد Kubernetes و کاربران GitLab

داشبورد Kubernetes ابزاری با کاربری آسان برای دریافت اطلاعات به روز در مورد خوشه در حال اجرا و مدیریت آن با حداقل تلاش است. زمانی که دسترسی به این ویژگی‌ها نه تنها برای مدیران/مهندسین DevOps، بلکه برای کسانی که کمتر به کنسول عادت دارند و/یا قصد ندارند با همه پیچیدگی‌های تعامل با kubectl و کوبک‌ل مواجه شوند، به این ویژگی‌ها نیاز دارند، حتی بیشتر از آن قدردانی می‌کنید. سایر خدمات آب و برق این اتفاق برای ما افتاد: توسعه‌دهندگان می‌خواستند به رابط وب Kubernetes دسترسی سریع داشته باشند، و از آنجایی که ما از GitLab استفاده می‌کنیم، راه‌حل به طور طبیعی پیدا شد.

چرا این هست؟

توسعه دهندگان مستقیم ممکن است به ابزاری مانند داشبورد K8s برای اشکال زدایی وظایف علاقه مند باشند. گاهی اوقات می‌خواهید گزارش‌ها و منابع را مشاهده کنید، و گاهی اوقات پادها را بکشید، Deployments/StatefulSets را مقیاس‌بندی کنید، و حتی به کنسول کانتینر بروید (همچنین درخواست‌هایی وجود دارد که با این حال، راه دیگری وجود دارد - برای مثال، از طریق kubectl-debug).

علاوه بر این، یک لحظه روانی برای مدیران وجود دارد که وقتی می خواهند به خوشه نگاه کنند - ببینند "همه چیز سبز است" و بنابراین به خود اطمینان دهند که "همه چیز کار می کند" (که البته بسیار نسبی است ... اما این از حوصله مقاله خارج است).

ما به عنوان یک سیستم CI استاندارد داریم کاربردی GitLab: همه توسعه دهندگان نیز از آن استفاده می کنند. بنابراین، برای دسترسی به آنها، منطقی بود که داشبورد را با حساب های GitLab ادغام کنیم.

همچنین اشاره می کنم که ما از NGINX Ingress استفاده می کنیم. اگر با دیگران کار می کنید راه حل های ورودی، باید به طور مستقل آنالوگ های حاشیه نویسی را برای مجوز پیدا کنید.

تلاش برای ادغام

نصب داشبورد

توجه: اگر قصد دارید مراحل زیر را تکرار کنید، پس - برای جلوگیری از انجام عملیات غیر ضروری - ابتدا عنوان فرعی بعدی را بخوانید.

از آنجایی که ما از این ادغام در بسیاری از نصب ها استفاده می کنیم، نصب آن را خودکار کرده ایم. منابع مورد نیاز برای این کار در منتشر شده است مخزن ویژه GitHub. آنها بر اساس تنظیمات YAML اندکی تغییر یافته از مخزن رسمی داشبوردو همچنین یک اسکریپت 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" بنامیم:

ادغام داشبورد Kubernetes و کاربران GitLab

در نتیجه اضافه کردن آن، 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

با این حال، دیر یا زود همه چیز شروع خواهد شد مجوز فورا کار نخواهد کرد! واقعیت این است که در تصویر استفاده شده (وضعیت در سایر تصاویر مشابه است) روند گرفتن تغییر مسیر در callback به اشتباه اجرا شده است. این شرایط منجر به این واقعیت می شود که oath کوکی را که خود 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

وقت آن است که به داشبورد بروید و یک دکمه ورود نسبتاً قدیمی پیدا کنید:

ادغام داشبورد Kubernetes و کاربران GitLab

پس از کلیک بر روی آن، GitLab به ما خوش آمد می گوید و پیشنهاد می کند به صفحه معمول خود وارد شوید (البته اگر قبلاً در آنجا وارد نشده باشید):

ادغام داشبورد Kubernetes و کاربران GitLab

ما با اعتبار GitLab وارد می شویم - و همه چیز انجام می شود:

ادغام داشبورد Kubernetes و کاربران GitLab

درباره ویژگی های داشبورد

اگر توسعه‌دهنده‌ای هستید که قبلاً با Kubernetes کار نکرده‌اید یا به دلایلی قبلاً با Dashboard برخورد نکرده‌اید، برخی از قابلیت‌های آن را توضیح خواهم داد.

اولاً، می توانید ببینید که "همه چیز سبز است":

ادغام داشبورد Kubernetes و کاربران GitLab

داده های دقیق تری نیز برای پادها موجود است، مانند متغیرهای محیط، تصویر دانلود شده، آرگومان های راه اندازی و وضعیت آنها:

ادغام داشبورد Kubernetes و کاربران GitLab

استقرارها دارای وضعیت های قابل مشاهده هستند:

ادغام داشبورد Kubernetes و کاربران GitLab

... و جزئیات دیگر:

ادغام داشبورد Kubernetes و کاربران GitLab

... و همچنین قابلیت مقیاس بندی استقرار وجود دارد:

ادغام داشبورد Kubernetes و کاربران GitLab

نتیجه این عملیات:

ادغام داشبورد Kubernetes و کاربران GitLab

از دیگر ویژگی‌های مفیدی که قبلاً در ابتدای مقاله ذکر شد، مشاهده گزارش‌ها است:

ادغام داشبورد Kubernetes و کاربران GitLab

... و عملکرد ورود به کنسول کانتینر پاد انتخابی:

ادغام داشبورد Kubernetes و کاربران GitLab

برای مثال، می‌توانید محدودیت‌ها/درخواست‌های گره‌ها را نیز بررسی کنید:

ادغام داشبورد Kubernetes و کاربران GitLab

البته اینها همه قابلیت های پنل نیست، اما امیدوارم ایده کلی را گرفته باشید.

معایب ادغام و داشبورد

در ادغام توصیف شده وجود ندارد کنترل دسترسی. با استفاده از آن، همه کاربران با هر گونه دسترسی به GitLab به داشبورد دسترسی پیدا می کنند. آنها همان دسترسی را در خود داشبورد دارند، مطابق با حقوق خود داشبورد، که در RBAC تعریف شده اند. بدیهی است که این برای همه مناسب نیست، اما برای مورد ما کافی بود.

از جمله معایب قابل توجه در خود داشبورد، موارد زیر را ذکر می کنم:

  • ورود به کنسول کانتینر init غیرممکن است.
  • ویرایش Deployments و StatefulSets غیرممکن است، اگرچه می توان آن را در ClusterRole برطرف کرد.
  • سازگاری داشبورد با آخرین نسخه های Kubernetes و آینده پروژه سوالاتی را ایجاد می کند.

آخرین مشکل سزاوار توجه ویژه است.

وضعیت داشبورد و گزینه های جایگزین

جدول سازگاری داشبورد با نسخه های Kubernetes، ارائه شده در آخرین نسخه پروژه (v1.10.1) خیلی خوشحال نیست:

ادغام داشبورد Kubernetes و کاربران GitLab

با وجود این، وجود دارد (که قبلاً در ژانویه به تصویب رسیده است) PR #3476، که از K8s 1.13 پشتیبانی می کند. علاوه بر این، در میان مسائل پروژه می توانید ارجاعاتی به کاربرانی که با پنل کار می کنند در K8s 1.14 بیابید. سرانجام، متعهد می شود به پایه کد پروژه متوقف نشوید. بنابراین (حداقل!) وضعیت واقعی پروژه به آن بدی نیست که در ابتدا از جدول سازگاری رسمی به نظر می رسد.

در نهایت، جایگزین هایی برای داشبورد وجود دارد. از جمله:

  1. K8Dash - یک رابط جوان (اولین commit ها به مارس سال جاری برمی گردد)، که در حال حاضر ویژگی های خوبی را ارائه می دهد، مانند نمایش بصری وضعیت فعلی خوشه و مدیریت اشیاء آن. به عنوان یک "رابط بلادرنگ" قرار گرفته است، زیرا به طور خودکار داده های نمایش داده شده را بدون نیاز به بازخوانی صفحه در مرورگر به روز می کند.
  2. کنسول OpenShift - یک رابط وب از Red Hat OpenShift، که با این حال، پیشرفت های دیگر پروژه را به خوشه شما می آورد که برای همه مناسب نیست.
  3. کوبرناتور پروژه جالبی است که به عنوان یک رابط سطح پایین تر (نسبت به داشبورد) با قابلیت مشاهده تمام اشیاء خوشه ای ایجاد شده است. با این حال، به نظر می رسد توسعه آن متوقف شده است.
  4. ستاره قطبی - همین دیروز اعلام کرد پروژه ای که عملکردهای یک پانل را ترکیب می کند (وضعیت فعلی خوشه را نشان می دهد، اما اشیاء آن را مدیریت نمی کند) و "اعتبارسنجی بهترین شیوه ها" خودکار (کلاستر را از نظر صحت تنظیمات Deployments در حال اجرا در آن بررسی می کند).

به جای نتیجه گیری

داشبورد یک ابزار استاندارد برای خوشه‌های Kubernetes است که ما ارائه می‌کنیم. ادغام آن با GitLab نیز بخشی از نصب پیش فرض ما شده است، زیرا بسیاری از توسعه دهندگان از قابلیت هایی که با این پنل دارند هیجان زده هستند.

داشبورد Kubernetes به طور دوره‌ای جایگزین‌هایی از جامعه منبع باز دارد (و ما خوشحالیم که آنها را در نظر می‌گیریم)، ​​اما در این مرحله ما با این راه‌حل باقی می‌مانیم.

PS

در وبلاگ ما نیز بخوانید:

منبع: www.habr.com

اضافه کردن نظر