Интеграција Кубернетес контролне табле и ГитЛаб корисника

Кубернетес контролна табла је алатка која се лако користи за добијање ажурираних информација о вашем покренутом кластеру и управљање њиме уз минималан напор. Почињете још више да цените када приступ овим могућностима буде потребан не само администраторима/ДевОпс инжењерима, већ и онима који су мање навикли на конзолу и/или не намеравају да се баве свим замршеностима интеракције са кубецтл и друге комуналне услуге. Ово се десило са нама: програмери су желели брз приступ Кубернетес веб интерфејсу, а пошто користимо ГитЛаб, решење је дошло природно.

Зашто је ово?

Директни програмери могу бити заинтересовани за алат као што је К8с Дасхбоард за задатке отклањања грешака. Понекад желите да видите евиденције и ресурсе, а понекад да убијете подове, скалирате Деплоиментс/СтатефулСетс, па чак и да одете на конзолу контејнера (постоје и захтеви за које, међутим, постоји други начин - на пример, преко кубецтл-дебуг).

Поред тога, постоји психолошки моменат за менаџере када желе да погледају кластер – да виде да је „све зелено“, и да се тако увере да „све функционише“ (што је, наравно, веома релативно... али ово је ван оквира чланка).

Као стандардни ЦИ систем имамо примењује се ГитЛаб: користе га и сви програмери. Стога, да би им се омогућио приступ, било је логично интегрисати Дасхбоард са ГитЛаб налозима.

Такође ћу напоменути да користимо НГИНКС Ингресс. Ако радите са другима улазна решења, мораћете самостално да пронађете аналоге напомена за ауторизацију.

Покушај интеграције

Инсталација контролне табле

Пажња: Ако ћете поновити доле наведене кораке, онда - да бисте избегли непотребне операције - прво прочитајте следећи поднаслов.

Пошто ову интеграцију користимо у многим инсталацијама, аутоматизовали смо њену инсталацију. Извори потребни за то објављени су у специјално ГитХуб спремиште. Засновани су на мало измењеним ИАМЛ конфигурацијама од званично складиште Дасхбоард-а, као и Басх скрипту за брзу примену.

Скрипта инсталира контролну таблу у кластер и конфигурише је за интеграцију са ГитЛаб-ом:

$ ./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

Међутим, пре него што га употребите, потребно је да одете у ГитЛаб: Админ област → Апликације - и додате нову апликацију за будући панел. Назовимо то „кубернетес контролна табла“:

Као резултат његовог додавања, ГитЛаб ће обезбедити хешове:

Они се користе као аргументи сценарију. Као резултат, инсталација изгледа овако:

$ ./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

Међутим, пре или касније све ће почети ауторизација неће радити одмах! Чињеница је да је у коришћеној слици (ситуација на другим сликама је слична) процес хватања преусмеравања у повратном позиву имплементиран погрешно. Ова околност доводи до тога да оаутх брише колачић који нам сам оаутх пружа...

Проблем се решава изградњом сопствене оаутх слике са закрпом.

Закрпите оаутх и поново инсталирајте

Да бисмо то урадили, користићемо следећи Доцкерфиле:

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

А ево како изгледа сама закрпа рд.патцх

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

Сада можете да направите слику и гурнете је у наш ГитЛаб. Следећи у 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

Пажљиви читалац ће видети да је дуги низ изнад басе64 из конфигурације:

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

Ово су кориснички подаци у ГитЛаб-у, Кубернетес код ће повући слику из регистра.

Након што је све урађено, можете уклонити тренутну (не ради исправно) инсталацију контролне табле помоћу наредбе:

$ ./ctl.sh -d

... и поново инсталирајте све:

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

Време је да одете на контролну таблу и пронађете прилично архаично дугме за пријаву:

Након што кликнете на њега, ГитЛаб ће нас поздравити, нудећи да се пријавимо на своју уобичајену страницу (наравно, ако се претходно нисмо пријавили тамо):

Пријављујемо се са ГитЛаб акредитивима - и све је готово:

О функцијама контролне табле

Ако сте програмер који раније није радио са Кубернетес-ом или једноставно из неког разлога нисте раније наишли на Дасхбоард, илустроваћу неке од његових могућности.

Прво, можете видети да је „све зелено“:

Детаљнији подаци су такође доступни за подове, као што су варијабле окружења, преузета слика, аргументи за покретање и њихово стање:

Примене имају видљиве статусе:

...и остали детаљи:

... а ту је и могућност скалирања имплементације:

Резултат ове операције:

Међу осталим корисним функцијама које су већ поменуте на почетку чланка је преглед евиденције:

... и функција за пријављивање на конзолу контејнера изабраног под:

На пример, можете погледати и ограничења/захтеве на чворовима:

Наравно, ово нису све могућности панела, али надам се да сте добили општу идеју.

Недостаци интеграције и контролне табле

У описаној интеграцији нема контрола приступа. Уз то, сви корисници са било којим приступом ГитЛабу добијају приступ контролној табли. Имају исти приступ у самој контролној табли, што одговара правима саме контролне табле, која дефинисани су у РБАЦ-у. Очигледно, ово није погодно за све, али за наш случај се показало довољним.

Међу уочљивим недостацима на самој контролној табли, примећујем следеће:

• немогуће је ући у конзолу инит контејнера;
• немогуће је уређивати Деплоиментс и СтатефулСетс, иако се то може поправити у ЦлустерРоле;
• Компатибилност контролне табле са најновијим верзијама Кубернетеса и будућност пројекта постављају питања.

Последњи проблем заслужује посебну пажњу.

Статус контролне табле и алтернативе

Табела компатибилности контролне табле са Кубернетес издањима, представљена у најновијој верзији пројекта (вКСНУМКС), није баш срећно:

Упркос томе, постоји (већ усвојен у јануару) ПР #3476, који најављује подршку за К8с 1.13. Поред тога, међу проблемима пројекта можете пронаћи референце на кориснике који раде са панелом у К8с 1.14. коначно, обавезује у базу кода пројекта не заустављају се. Дакле (барем!) стварни статус пројекта није тако лош као што се на први поглед чини из званичне табеле компатибилности.

Коначно, постоје алтернативе за контролну таблу. Међу њима:

1. К8Дасх — млад интерфејс (први урезивање датирају из марта ове године), који већ нуди добре карактеристике, попут визуелног представљања тренутног статуса кластера и управљања његовим објектима. Позициониран као „интерфејс у ​​реалном времену“, јер аутоматски ажурира приказане податке без потребе да освежавате страницу у претраживачу.
2. Конзола ОпенСхифт - веб интерфејс из Ред Хат ОпенСхифт-а, који ће, међутим, донети друге развоје пројекта у ваш кластер, што није погодно за све.
3. Кубернатор је занимљив пројекат, креиран као интерфејс нижег нивоа (од Дасхбоард) са могућношћу прегледа свих објеката кластера. Међутим, изгледа да је његов развој стао.
4. Поларис - баш пре неки дан најавио пројекат који комбинује функције панела (показује тренутно стање кластера, али не управља његовим објектима) и аутоматску „валидацију најбољих пракси“ (проверава исправност конфигурација Деплоиментс-а у кластеру).

Уместо закључака

Контролна табла је стандардни алат за Кубернетес кластере које опслужујемо. Његова интеграција са ГитЛаб-ом је такође постала део наше подразумеване инсталације, јер су многи програмери узбуђени због могућности које имају са овим панелом.

Кубернетес Дасхбоард повремено има алтернативе из заједнице отвореног кода (и радо ћемо их размотрити), али у овој фази остајемо при овом решењу.

ПС

Прочитајте и на нашем блогу:

• «кубебок и друге шкољке за Кубернетес";
• «Најбоље ЦИ/ЦД праксе са Кубернетес-ом и ГитЛаб-ом (преглед и видео извештај)";
• «Направите и примените апликације у Кубернетесу користећи дапп и ГитЛаб ЦИ";
• «ГитЛаб ЦИ за континуирану интеграцију и испоруку у производњи. Први део: наш цевовод'.

Извор: ввв.хабр.цом