Бессерверныя вылічэнні на аснове OpenWhisk, частка 4
Гэты артыкул заканчвае цыкл перакладных нататак аб OpenWhisk ад аўтара. Priti Desai. Сёння разгледзім працэс разгортвання OpenWhisk па-над Kubernetes з выпраўленымі камандамі для працаздольнасці з актуальнымі версіямі прыкладанняў. Таксама будзе апісаны працэс запуску функцый OpenWhisk з выкарыстаннем Knative і TektonCD у Kubernetes з выкарыстаннем асяроддзя выканання Nodejs.
Разгортваем OpenWhisk на Kubernetes
За некалькі дзён я правяла эксперымент па разгортванні OpenWhisk у Kubernetes для стварэння простага і хуткага палігона для адпрацоўкі задач. А паколькі я пачатковец у Kubernetes - мяркую, што паўтара дня было выдаткавана на паспяховае разгортванне. У гэтым рэпазітары ёсць вельмі зразумелыя інструкцыі для разгортвання OpenWhisk у Kubernetes. Тут будуць інструкцыі для разгортвання, зробленыя для Mac (я таксама буду рабіць усё на Linux, таму што аддаю перавагу Linux. - заўв. перакладчыка).
Усталёўваны пакетны мэнэджар asdf, пасля чаго аўтаматычна выпраўляем ~/.bash_profile або яго аналаг так:
Усталёўваны Helm і праводжаны разгортванне з яго дапамогай:
$ brew install kubernetes-helm
$ helm init # init Helm Tiller, не нужно на Helm v3+
$ kubectl get pods -n kube-system # verify that tiller-deploy is in the running state, не нужно на helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml
[На Linux з апошнімі версіямі (была даступная v3.0.1) будзе крыху па-іншаму. - заўв. перакладчыка]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
правяраем:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Праблемы і іх рашэнні
getsockopt: connection refused
$ wsk -i list
error: Unable to obtain the list of entities for namespace 'default': Get http://192.168.99.100:31001/api/v1/namespaces/_/actions?limit=0&skip=0: dial tcp 192.168.99.100:31001: getsockopt: connection refused
Правяраем, што кантэйнеры ў namespace openwhisk у статусе Running, т.я. часам яно падае з памылкамі CreateContainerConfigError.
Invoker still initializing - Init:1/2
Працэс спампоўкі разнастайных асяроддзяў выканання можа заняць шмат часу. Для паскарэння можна пазначыць скарочаны мінімальны спіс у файле mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Кантэйнер з імем -install-packages- вывальваецца ў Error
Проста нарасціце таймаўты для liveness тэстаў.
Усталёўка OpenWhisk па-над Knative
Priti Desai праводзіла ўстаноўку па-над кластарам у воблаку IBM, а таксама на звычайным minikube, выкарыстоўваючы Knative Build і BuildTemplates. Я таксама буду ўсталёўваць па-над minukube, па матывах таго, як гэта было апісана у нашым блогу раней - з выкарыстаннем апошніх версій ПА. Паколькі Knative Build і BuildTemplates афіцыйна абвешчаныя састарэлымі, буду выкарыстоўваць рэкамендуемую замену ў выглядзе Tekton Pipelines. Далейшая частка артыкула напісана пасля прачытання дакументацыі да Tekton Pipelines, але заснаваная на ідэях Priti. Для працы запатрабуецца доступ да некаторай Docker Registry - я, як і арыгінальная аўтар, буду выкарыстоўваць DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Ужывальны:
$ kubectl apply -f taskrun.yaml
pipelineresource.tekton.dev/openwhisk-nodejs-runtime-git created
pipelineresource.tekton.dev/openwhisk-nodejs-helloworld-image created
taskrun.tekton.dev/openwhisk-nodejs-helloworld created
Праверка працы складаецца ў атрыманні імя pod`а, прагляду яго статуту. Таксама можна паглядзець часопіс выканання кожнага кроку, напрыклад:
$ kubectl get taskrun
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME
openwhisk-nodejs-helloworld True Succeeded 5m15s 44s
$ kubectl get pod openwhisk-nodejs-helloworld-pod-4640d3
NAME READY STATUS RESTARTS AGE
openwhisk-nodejs-helloworld-pod-4640d3 0/6 Completed 0 5m20s
$ kubectl logs openwhisk-nodejs-helloworld-pod-4640d3 -c step-git-source-openwhisk-nodejs-runtime-git-r8vhr
{"level":"info","ts":1576532931.5880227,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: open /var/run/ko/refs/heads/master: no such file or directory"}
{"level":"info","ts":1576532936.538926,"logger":"fallback-logger","caller":"git/git.go:81","msg":"Successfully cloned https://github.com/apache/openwhisk-runtime-nodejs.git @ master in path /workspace/runtime-git"}
{"level":"warn","ts":1576532936.5395331,"logger":"fallback-logger","caller":"git/git.go:128","msg":"Unexpected error: creating symlink: symlink /tekton/home/.ssh /root/.ssh: file exists"}
{"level":"info","ts":1576532936.8202565,"logger":"fallback-logger","caller":"git/git.go:109","msg":"Successfully initialized and updated submodules in path /workspace/runtime-git"}
Пасля выканання ў нас у Registry з'явіцца выява, які можа быць разгорнуты з дапамогай утыліты kn, прызначанай для працы з Knative сэрвісамі, напрыклад:
kn service create nodejs-helloworld --image docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld
Service 'nodejs-helloworld' successfully created in namespace 'default'.
Waiting for service 'nodejs-helloworld' to become ready ... OK
Service URL:
http://nodejs-helloworld.default.example.com
У выпадку выкарыстання Gloo праверыць працаздольнасць можна так: