Paneli i Kubernetes është një mjet i lehtë për t'u përdorur për marrjen e informacionit të përditësuar në lidhje me grupin tuaj të funksionimit dhe menaxhimin e tij me përpjekje minimale. Ju filloni ta vlerësoni edhe më shumë kur aksesi në këto aftësi është i nevojshëm jo vetëm nga administratorët/inxhinierët e DevOps, por edhe nga ata që janë më pak të mësuar me konsolën dhe/ose nuk kanë ndërmend të merren me të gjitha ndërlikimet e ndërveprimit me kubectl dhe shërbimet e tjera. Kjo ndodhi me ne: zhvilluesit donin qasje të shpejtë në ndërfaqen e internetit të Kubernetes, dhe meqenëse ne përdorim GitLab, zgjidhja erdhi natyrshëm.
Pse eshte kjo?
Zhvilluesit e drejtpërdrejtë mund të jenë të interesuar për një mjet si K8s Dashboard për korrigjimin e detyrave. Ndonjëherë ju dëshironi të shikoni regjistrat dhe burimet, dhe ndonjëherë të vrisni pods, të shkallëzoni Deployments/StatefulSets dhe madje të shkoni te konsola e kontejnerit (ka edhe kërkesa për të cilat, megjithatë, ekziston një mënyrë tjetër - për shembull, përmes ).
Për më tepër, ka një moment psikologjik për menaxherët kur duan të shikojnë grupin - të shohin se "gjithçka është e gjelbër", dhe kështu të sigurojnë veten se "gjithçka po funksionon" (që, natyrisht, është shumë relative ... por kjo është përtej qëllimit të artikullit).
Si një sistem standard CI kemi GitLab: të gjithë zhvilluesit e përdorin gjithashtu. Prandaj, për t'u siguruar atyre akses, ishte logjike të integrohej Dashboard me llogaritë e GitLab.
Do të vërej gjithashtu se ne përdorim NGINX Ingress. Nëse punoni me të tjerët , do t'ju duhet të gjeni në mënyrë të pavarur analoge të shënimeve për autorizim.
Duke u përpjekur për integrim
Instalimi i pultit
Kujdes: Nëse do të përsërisni hapat e mëposhtëm, atëherë - për të shmangur veprimet e panevojshme - së pari lexoni në nëntitullin tjetër.
Meqenëse ne e përdorim këtë integrim në shumë instalime, ne kemi automatizuar instalimin e tij. Burimet e nevojshme për këtë janë publikuar në . Ato bazohen në konfigurime paksa të modifikuara YAML nga , si dhe një skript Bash për vendosje të shpejtë.
Skripti instalon Dashboard në grup dhe e konfiguron atë për t'u integruar me 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 messageSidoqoftë, përpara se ta përdorni, duhet të shkoni te GitLab: Zona e administratorit → Aplikacionet - dhe të shtoni një aplikacion të ri për panelin e ardhshëm. Le ta quajmë "pulti i kubernetes":
Si rezultat i shtimit të tij, GitLab do të sigurojë hash-et:
Janë ato që përdoren si argumente për skenarin. Si rezultat, instalimi duket si ky:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comPas kësaj, le të kontrollojmë që gjithçka filloi:
$ 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 14sMegjithatë, herët a vonë gjithçka do të fillojë autorizimi nuk do të funksionojë menjëherë! Fakti është se në imazhin e përdorur (situata në imazhet e tjera është e ngjashme) procesi i kapjes së një ridrejtimi në kthimin e thirrjes zbatohet gabimisht. Kjo rrethanë çon në faktin se oauth fshin cookie-n që na ofron vetë oauth...
Problemi zgjidhet duke ndërtuar imazhin tuaj të oauth me një patch.
Patch oauth dhe riinstaloje
Për ta bërë këtë, ne do të përdorim skedarin e mëposhtëm Docker:
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" ]Dhe ja se si duket vetë patch-i 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 Tani mund ta ndërtoni imazhin dhe ta shtyni atë në GitLab tonë. Më pas në manifests/kube-dashboard-oauth2-proxy.yaml tregoni përdorimin e imazhit të dëshiruar (zëvendësoni atë me tuajin):
image: docker.io/colemickens/oauth2_proxy:latestNëse keni një regjistër që është i mbyllur me autorizim, mos harroni të shtoni përdorimin e një sekreti për tërheqjen e imazheve:
imagePullSecrets:
- name: gitlab-registry... dhe shtoni vetë sekretin për regjistrin:
---
apiVersion: v1
data:
.dockercfg: eyJyZWdpc3RyeS5jb21wYW55LmNvbSI6IHsKICJ1c2VybmFtZSI6ICJvYXV0aDIiLAogInBhc3N3b3JkIjogIlBBU1NXT1JEIiwKICJhdXRoIjogIkFVVEhfVE9LRU4iLAogImVtYWlsIjogIm1haWxAY29tcGFueS5jb20iCn0KfQoK
=
kind: Secret
metadata:
annotations:
name: gitlab-registry
namespace: kube-system
type: kubernetes.io/dockercfgLexuesi i vëmendshëm do të shohë se vargu i gjatë i mësipërm është base64 nga konfigurimi:
{"registry.company.com": {
"username": "oauth2",
"password": "PASSWORD",
"auth": "AUTH_TOKEN",
"email": "mail@company.com"
}
}Këto janë të dhënat e përdoruesit në GitLab, kodi Kubernetes do të tërheqë imazhin nga regjistri.
Pasi të jetë bërë gjithçka, mund të hiqni instalimin aktual (nuk funksionon siç duhet) të panelit me komandën:
$ ./ctl.sh -d... dhe instaloni gjithçka përsëri:
$ ./ctl.sh -i --gitlab-url https://gitlab.example.com --oauth2-id 6a52769e… --oauth2-secret 6b79168f… --dashboard-url dashboard.example.comËshtë koha për të shkuar te Paneli dhe për të gjetur një buton mjaft arkaik të hyrjes:
Pasi të klikojmë mbi të, GitLab do të na përshëndesë, duke ofruar hyrjen në faqen e tij të zakonshme (natyrisht, nëse nuk kemi hyrë më parë atje):
Ne regjistrohemi me kredencialet e GitLab - dhe gjithçka është bërë:
Rreth veçorive të Panelit
Nëse jeni një zhvillues që nuk keni punuar më parë me Kubernetes, ose thjesht për ndonjë arsye nuk keni hasur më parë në Dashboard, unë do t'i ilustroj disa nga aftësitë e tij.
Së pari, ju mund të shihni se "gjithçka është e gjelbër":
Të dhëna më të detajuara janë gjithashtu të disponueshme për pods, të tilla si variablat e mjedisit, imazhi i shkarkuar, argumentet e nisjes dhe gjendja e tyre:
Vendosjet kanë statuse të dukshme:
...dhe detaje të tjera:
... dhe ekziston gjithashtu aftësia për të shkallëzuar vendosjen:
Rezultati i këtij operacioni:
Ndër veçoritë e tjera të dobishme të përmendura tashmë në fillim të artikullit është shikimi i regjistrave:
... dhe funksioni për t'u identifikuar në tastierën e kontejnerit të podit të zgjedhur:
Për shembull, mund të shikoni edhe kufijtë/kërkesat në nyje:
Sigurisht, këto nuk janë të gjitha aftësitë e panelit, por shpresoj që të keni idenë e përgjithshme.
Disavantazhet e integrimit dhe Paneli
Në integrimin e përshkruar nuk ka kontrolli i aksesit. Me të, të gjithë përdoruesit me çdo akses në GitLab fitojnë akses në Panel. Ata kanë të njëjtin akses në vetë Panelin, që korrespondon me të drejtat e vetë Panelit, i cili . Natyrisht, kjo nuk është e përshtatshme për të gjithë, por për rastin tonë doli të jetë e mjaftueshme.
Ndër disavantazhet e dukshme në vetë Panelin, vërej sa vijon:
- është e pamundur të futesh në tastierën e kontejnerit fillestar;
- është e pamundur të modifikosh Deployments dhe StatefulSets, megjithëse kjo mund të rregullohet në ClusterRole;
- Pajtueshmëria e pultit me versionet më të fundit të Kubernetes dhe e ardhmja e projektit ngre pyetje.
Problemi i fundit meriton vëmendje të veçantë.
Statusi i panelit dhe alternativat
Tabela e përputhshmërisë së panelit me publikimet e Kubernetes, e paraqitur në versionin më të fundit të projektit (), jo shumë i lumtur:
Përkundër kësaj, ekziston (i miratuar tashmë në janar) , i cili njofton mbështetje për K8s 1.13. Përveç kësaj, midis çështjeve të projektit mund të gjeni referenca për përdoruesit që punojnë me panelin në K8s 1.14. Së fundi, në bazën e kodit të projektit mos u ndal. Pra (të paktën!) statusi aktual i projektit nuk është aq i keq sa mund të duket fillimisht nga tabela zyrtare e përputhshmërisë.
Më në fund, ka alternativa për Pult. Midis tyre:
- — një ndërfaqe e re (kryerjet e para datojnë në mars të këtij viti), e cila tashmë ofron veçori të mira, të tilla si një paraqitje vizuale e statusit aktual të grupit dhe menaxhimi i objekteve të tij. Pozicionuar si një "ndërfaqe në kohë reale", sepse përditëson automatikisht të dhënat e shfaqura pa kërkuar që ju të rifreskoni faqen në shfletues.
- - një ndërfaqe në internet nga Red Hat OpenShift, e cila, megjithatë, do të sjellë zhvillime të tjera të projektit në grupin tuaj, i cili nuk është i përshtatshëm për të gjithë.
- është një projekt interesant, i krijuar si një ndërfaqe e nivelit më të ulët (se Paneli) me aftësinë për të parë të gjitha objektet e grupimit. Megjithatë, duket se zhvillimi i tij ka ndaluar.
- - vetëm ditën tjetër një projekt që kombinon funksionet e një paneli (tregon gjendjen aktuale të grupimit, por nuk menaxhon objektet e tij) dhe "vlefshmërinë e praktikave më të mira" automatike (kontrollon grupin për korrektësinë e konfigurimeve të vendosjeve që ekzekutohen në të).
Në vend të konkluzioneve
Paneli është një mjet standard për grupimet Kubernetes që ne ofrojmë. Integrimi i tij me GitLab është bërë gjithashtu pjesë e instalimit tonë të paracaktuar, pasi shumë zhvillues janë të ngazëllyer për aftësitë që kanë me këtë panel.
Paneli i Kubernetes ka periodikisht alternativa nga komuniteti me burim të hapur (dhe ne jemi të lumtur t'i konsiderojmë ato), por në këtë fazë ne mbetemi me këtë zgjidhje.
PS
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com
