Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Mae Dangosfwrdd Kubernetes yn offeryn hawdd ei ddefnyddio ar gyfer cael y wybodaeth ddiweddaraf am eich clwstwr rhedeg a'i reoli heb fawr o ymdrech. Rydych chi'n dechrau ei werthfawrogi hyd yn oed yn fwy pan fydd angen mynediad at y galluoedd hyn nid yn unig gan weinyddwyr / peirianwyr DevOps, ond hefyd gan y rhai sy'n llai cyfarwydd â'r consol a / neu nad ydyn nhw'n bwriadu delio â holl gymhlethdodau rhyngweithio â kubectl a cyfleustodau eraill. Digwyddodd hyn gyda ni: roedd y datblygwyr eisiau mynediad cyflym i ryngwyneb gwe Kubernetes, ac ers i ni ddefnyddio GitLab, daeth yr ateb yn naturiol.

Pam fod hyn?

Efallai y bydd gan ddatblygwyr uniongyrchol ddiddordeb mewn teclyn fel Dangosfwrdd K8s ar gyfer tasgau dadfygio. Weithiau rydych chi eisiau gweld logiau ac adnoddau, ac weithiau lladd codennau, graddfa Deployments/StatefulSets, a hyd yn oed mynd i'r consol cynhwysydd (mae yna geisiadau hefyd, fodd bynnag, mae yna ffordd arall - er enghraifft, trwy kubectl-debug).

Yn ogystal, mae yna foment seicolegol i reolwyr pan maen nhw eisiau edrych ar y clwstwr - i weld bod “popeth yn wyrdd”, a thrwy hynny dawelu eu hunain bod “popeth yn gweithio” (sydd, wrth gwrs, yn gymharol iawn... ond mae hyn y tu hwnt i gwmpas yr erthygl ).

Fel system CI safonol sydd gennym wedi'i gymhwyso GitLab: mae pob datblygwr yn ei ddefnyddio hefyd. Felly, er mwyn rhoi mynediad iddynt, roedd yn rhesymegol integreiddio Dangosfwrdd â chyfrifon GitLab.

Byddaf hefyd yn nodi ein bod yn defnyddio NGINX Ingress. Os ydych chi'n gweithio gydag eraill atebion mynediad, bydd angen i chi ddod o hyd i analogau o anodiadau yn annibynnol i'w hawdurdodi.

Ceisio integreiddio

Gosod dangosfwrdd

Sylw: Os ydych chi'n mynd i ailadrodd y camau isod, yna - er mwyn osgoi gweithrediadau diangen - darllenwch yn gyntaf i'r is-bennawd nesaf.

Gan ein bod yn defnyddio'r integreiddio hwn mewn llawer o osodiadau, rydym wedi awtomeiddio ei osod. Cyhoeddir y ffynonellau sydd eu hangen ar gyfer hyn yn storfa GitHub arbennig. Maent yn seiliedig ar gyfluniadau YAML wedi'u haddasu ychydig o storfa Dangosfwrdd swyddogol, yn ogystal â sgript Bash ar gyfer defnydd cyflym.

Mae'r sgript yn gosod Dangosfwrdd yn y clwstwr ac yn ei ffurfweddu i'w integreiddio â 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

Fodd bynnag, cyn ei ddefnyddio, mae angen i chi fynd i GitLab: Ardal weinyddol → Ceisiadau - ac ychwanegu cais newydd ar gyfer y panel dyfodol. Gadewch i ni ei alw'n “dangosfwrdd kubernetes”:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

O ganlyniad i'w ychwanegu, bydd GitLab yn darparu'r hashes:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Dyma'r rhai sy'n cael eu defnyddio fel dadleuon i'r sgript. O ganlyniad, mae'r gosodiad yn edrych fel hyn:

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

Ar ôl hynny, gadewch i ni wirio bod popeth wedi dechrau:

$ 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

Yn hwyr neu'n hwyrach bydd popeth yn dechrau, fodd bynnag ni fydd awdurdodiad yn gweithio ar unwaith! Y ffaith yw, yn y ddelwedd a ddefnyddir (mae'r sefyllfa mewn delweddau eraill yn debyg) bod y broses o ddal ailgyfeiriad yn yr alwad yn ôl yn cael ei gweithredu'n anghywir. Mae'r amgylchiad hwn yn arwain at y ffaith bod oauth yn dileu'r cwci y mae oauth ei hun yn ei ddarparu i ni ...

Mae'r broblem yn cael ei datrys trwy adeiladu eich delwedd oauth eich hun gyda darn.

Patch oauth ac ailosod

I wneud hyn, byddwn yn defnyddio'r Dockerfile canlynol:

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" ]

A dyma sut olwg sydd ar y clwt rd.patch ei hun

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

Nawr gallwch chi adeiladu'r ddelwedd a'i gwthio i'n GitLab. Nesaf i mewn manifests/kube-dashboard-oauth2-proxy.yaml nodwch y defnydd o'r ddelwedd a ddymunir (amnewidiwch hi gyda'ch delwedd eich hun):

 image: docker.io/colemickens/oauth2_proxy:latest

Os oes gennych gofrestrfa sydd wedi'i chau trwy awdurdodiad, peidiwch ag anghofio ychwanegu'r defnydd o gyfrinach ar gyfer tynnu delweddau:

      imagePullSecrets:
     - name: gitlab-registry

... ac ychwanegwch y gyfrinach ei hun ar gyfer y gofrestrfa:

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

Bydd y darllenydd sylwgar yn gweld bod y llinyn hir uchod yn base64 o'r ffurfwedd:

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

Dyma'r data defnyddiwr yn GitLab, bydd cod Kubernetes yn tynnu'r ddelwedd o'r gofrestrfa.

Ar ôl i bopeth gael ei wneud, gallwch chi gael gwared ar y gosodiad Dangosfwrdd cyfredol (ddim yn gweithio'n gywir) gyda'r gorchymyn:

$ ./ctl.sh -d

... a gosod popeth eto:

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

Mae'n bryd mynd i'r Dangosfwrdd a dod o hyd i fotwm mewngofnodi braidd yn hynafol:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Ar ôl clicio arno, bydd GitLab yn ein cyfarch, gan gynnig mewngofnodi i'w dudalen arferol (wrth gwrs, os nad ydym wedi mewngofnodi yno o'r blaen):

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Rydyn ni'n mewngofnodi gyda manylion GitLab - ac mae popeth yn cael ei wneud:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Ynglŷn â nodweddion Dangosfwrdd

Os ydych chi'n ddatblygwr nad yw wedi gweithio gyda Kubernetes o'r blaen, neu yn syml am ryw reswm heb ddod ar draws Dangosfwrdd o'r blaen, byddaf yn darlunio rhai o'i alluoedd.

Yn gyntaf, gallwch weld bod “popeth yn wyrdd”:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Mae data manylach hefyd ar gael ar gyfer codennau, megis newidynnau amgylchedd, delwedd wedi'i lawrlwytho, dadleuon lansio, a'u cyflwr:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Mae gan leoliadau statws gweladwy:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

...a manylion eraill:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

... ac mae hefyd y gallu i raddfa'r defnydd:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Canlyniad y llawdriniaeth hon:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Ymhlith nodweddion defnyddiol eraill a grybwyllwyd eisoes ar ddechrau'r erthygl mae gwylio logiau:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

... a'r swyddogaeth i fewngofnodi i gonsol cynhwysydd y pod a ddewiswyd:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Er enghraifft, gallwch hefyd edrych ar y terfynau/ceisiadau ar nodau:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Wrth gwrs, nid yw’r rhain i gyd yn alluoedd y panel, ond gobeithio y cewch y syniad cyffredinol.

Anfanteision integreiddio a Dangosfwrdd

Yn yr integreiddio a ddisgrifir nid oes rheoli mynediad. Ag ef, mae pob defnyddiwr sydd ag unrhyw fynediad i GitLab yn cael mynediad i'r Dangosfwrdd. Mae ganddynt yr un mynediad yn y Dangosfwrdd ei hun, sy'n cyfateb i hawliau'r Dangosfwrdd ei hun, sydd yn cael eu diffinio yn RBAC. Yn amlwg, nid yw hyn yn addas i bawb, ond yn ein hachos ni daeth yn ddigonol.

Ymhlith yr anfanteision amlwg yn y Dangosfwrdd ei hun, nodaf y canlynol:

  • mae'n amhosibl mynd i mewn i gonsol y cynhwysydd init;
  • mae'n amhosibl golygu Deployments a StatefulSets, er y gellir pennu hyn yn ClusterRole;
  • Mae cydnawsedd y dangosfwrdd â'r fersiynau diweddaraf o Kubernetes a dyfodol y prosiect yn codi cwestiynau.

Mae'r broblem olaf yn haeddu sylw arbennig.

Statws dangosfwrdd a dewisiadau eraill

Tabl cydweddoldeb dangosfwrdd gyda datganiadau Kubernetes, wedi'i gyflwyno yn fersiwn diweddaraf y prosiect (v1.10.1), ddim yn hapus iawn:

Integreiddio Dangosfwrdd Kubernetes a Defnyddwyr GitLab

Er gwaethaf hyn, mae (eisoes wedi'i fabwysiadu ym mis Ionawr) PR #3476, sy'n cyhoeddi cefnogaeth i K8s 1.13. Yn ogystal, ymhlith materion y prosiect gallwch ddod o hyd i gyfeiriadau at ddefnyddwyr sy'n gweithio gyda'r panel yn K8s 1.14. Yn olaf, yn ymrwymo i mewn i sylfaen cod y prosiect peidiwch â stopio. Felly (o leiaf!) Nid yw statws gwirioneddol y prosiect cynddrwg ag y gallai ymddangos yn gyntaf o'r tabl cydnawsedd swyddogol.

Yn olaf, mae dewisiadau amgen i'r Dangosfwrdd. Yn eu plith:

  1. K8Dash - rhyngwyneb ifanc (mae'r ymrwymiad cyntaf yn dyddio'n ôl i fis Mawrth eleni), sydd eisoes yn cynnig nodweddion da, megis cynrychiolaeth weledol o statws presennol y clwstwr a rheolaeth ei wrthrychau. Wedi'i leoli fel “rhyngwyneb amser real”, oherwydd yn diweddaru'r data a ddangosir yn awtomatig heb fod angen i chi adnewyddu'r dudalen yn y porwr.
  2. Consol OpenShift - rhyngwyneb gwe gan Red Hat OpenShift, a fydd, fodd bynnag, yn dod â datblygiadau eraill y prosiect i'ch clwstwr, nad yw'n addas i bawb.
  3. Kubernator yn brosiect diddorol, wedi'i greu fel rhyngwyneb lefel is (na Dangosfwrdd) gyda'r gallu i weld yr holl wrthrychau clwstwr. Fodd bynnag, mae'n edrych fel bod ei ddatblygiad wedi dod i ben.
  4. Polaris - dim ond y diwrnod o'r blaen cyhoeddi prosiect sy'n cyfuno swyddogaethau panel (sy'n dangos cyflwr presennol y clwstwr, ond nad yw'n rheoli ei amcanion) a “dilysu arferion gorau” yn awtomatig (yn gwirio'r clwstwr i weld a yw ffurfweddiadau'r gosodiadau sy'n rhedeg ynddo yn gywir).

Yn lle casgliadau

Mae dangosfwrdd yn offeryn safonol ar gyfer y clystyrau Kubernetes rydyn ni'n eu gwasanaethu. Mae ei integreiddio â GitLab hefyd wedi dod yn rhan o'n gosodiad diofyn, gan fod llawer o ddatblygwyr yn gyffrous am y galluoedd sydd ganddynt gyda'r panel hwn.

O bryd i'w gilydd mae gan Kubernetes Dashboard ddewisiadau amgen o'r gymuned Ffynhonnell Agored (ac rydym yn hapus i'w hystyried), ond ar hyn o bryd rydym yn parhau gyda'r ateb hwn.

PS

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Ychwanegu sylw