Artykuł ten kończy serię przetłumaczonych notatek autora na temat OpenWhisk Priti Desai. Dziś przyjrzymy się procesowi wdrażania OpenWhisk poprzez Kubernetes z poprawionymi poleceniami do pracy z aktualnymi wersjami aplikacji. Omówi także proces uruchamiania funkcji OpenWhisk przy użyciu Knative i TektonCD na Kubernetesie przy użyciu środowiska uruchomieniowego Nodejs.
Wdrażanie OpenWhisk na Kubernetesie
W ciągu kilku dni eksperymentowałem z wdrażaniem OpenWhisk na platformie Kubernetes, aby stworzyć prosty i szybki poligon testowy. A ponieważ jestem nowy w Kubernetes, uważam, że półtora dnia poświęcono na pomyślne wdrożenie. W to W repozytoriach znajdują się bardzo jasne instrukcje dotyczące wdrażania OpenWhisk na Kubernetesie. Oto instrukcje wdrażania przygotowane dla komputerów Mac (Zrobię też wszystko na Linuksie, bo wolę Linuksa. - około. tłumacz).
Instalowanie menedżera pakietów asdf, po czym automatycznie poprawiamy ~/.bash_profile lub jego odpowiednik, taki jak ten:
[Ponownie pomiń ten krok w systemie Linux. - około. tłumacz]
Zainstaluj minikube i kubelet:
$ asdf install kubectl 1.9.0
$ asdf global kubectl 1.9.0
$ asdf install minikube 0.25.2
$ asdf global minikube 0.25.2
[określone wersje są zainstalowane, ale sprawdziłem wszystko na najnowszych dostępnych wersjach dla Linuksa; Podejrzewam, że możesz bezpiecznie zainstalować najnowsze. - około. tłumacz]
W systemie Linux ten krok wykonuje się mniej więcej tak (wszystko jest umieszczane w ~/bin, który jest wymieniony w mojej PATH, uwaga tłumacza):
$ 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
[Na Linuksie z najnowszymi wersjami (dostępna była wersja 3.0.1) będzie trochę inaczej. - około. tłumacz]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
Sprawdzanie:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Problemy i rozwiązania
getsockopt: połączenie odrzucone
$ 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
Sprawdzanie, czy kontenery znajdują się w przestrzeni nazw openwhisk w statusie Running, ponieważ czasami zawiesza się z błędami CreateContainerConfigError.
Invoker nadal się inicjuje — Init:1/2
Proces pobierania różnych środowisk wykonawczych może zająć dużo czasu. Aby przyspieszyć działanie, możesz określić w pliku skróconą listę minimalną mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Pojemnik z nazwą -zainstaluj-pakiety- zawiesza się do błędu
Po prostu zwiększ limity czasu dla testów żywotności.
Instalowanie OpenWhisk na Knative
Priti Desai przeprowadziła instalację na szczycie klastra w chmurze IBM, a także na zwykłym minikube, korzystając z Knative Build i BuildTemplates. Zainstaluję także na Minukube, w zależności od tego, jak to zrobić zostało to opisane na naszym blogu wcześniej – korzystając z najnowszych wersji oprogramowania. Ponieważ Knative Build i BuildTemplates zostały oficjalnie uznane za przestarzałe, użyję zalecanego zamiennika w postaci Tekton Pipelines. Pozostała część artykułu została napisana po zapoznaniu się z dokumentacją Tekton Pipelines, ale opiera się na pomysłach Priti. Do pracy będziesz potrzebować dostępu do jakiegoś rejestru Dockera - ja, podobnie jak oryginalny autor, będę korzystać z DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Stosujemy:
$ 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
Sprawdzenie pracy polega na uzyskaniu nazwy kapsuły i przejrzeniu jej statusu. Możesz także wyświetlić dziennik wykonania każdego kroku, na przykład:
$ 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"}
Po wykonaniu w Rejestrze będziemy mieli obraz, który można wdrożyć za pomocą narzędzia kn, zaprojektowanego do współpracy z usługami Knative, na przykład:
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
Jeśli korzystasz z Gloo, możesz sprawdzić jego funkcjonalność w ten sposób: