Ĉi tiu artikolo finas la serion de tradukitaj notoj pri OpenWhisk de la aŭtoro Priti Desai. Hodiaŭ ni rigardos la procezon de deploji OpenWhisk super Kubernetes kun korektitaj komandoj por labori kun aktualaj versioj de aplikaĵoj. Ĝi ankaŭ kovros la procezon de funkciado de OpenWhisk-funkcioj uzante Knative kaj TektonCD sur Kubernetes uzante la rultempon de Nodejs.
Deplojante OpenWhisk sur Kubernetes
Dum kelkaj tagoj, mi eksperimentis kun deplojado de OpenWhisk al Kubernetes por krei simplan kaj rapidan testejon. Kaj ĉar mi estas nova en Kubernetes, mi kredas, ke tago kaj duono estis elspezita por sukcesa disfaldo. EN ĉi tio La deponejoj havas tre klarajn instrukciojn por disfaldi OpenWhisk sur Kubernetes. Jen la deploj instrukcioj faritaj por Mac (Mi ankaŭ faros ĉion en Linukso ĉar mi preferas Linukson. — ĉ. tradukisto).
Instalante la pakaĵadministrilon asdf, post kio ni aŭtomate korektas ~/.bash_profile aŭ ĝia ekvivalento jene:
[Denove, preterlasu ĉi tiun paŝon en Linukso. — ĉ. tradukisto]
Instalu minikube kaj 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
[specifaj versioj estas instalitaj, sed mi kontrolis ĉion pri la plej novaj disponeblaj versioj por Linukso; Mi suspektas, ke vi povas sekure instali la plej novan. — ĉ. tradukisto]
En Linukso, ĉi tiu paŝo estas farita kiel ĉi tio (ĉio estas metita en ~/bin, kiu estas listigita en mia PATH, noto de la tradukinto):
$ 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
[En Linukso kun la plej novaj versioj (v3.0.1 estis disponebla) ĝi estos iom malsama. — ĉ. tradukisto]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
Ni kontrolas:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Problemoj kaj iliaj solvoj
getsockopt: konekto rifuzita
$ 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
Kontrolante ke la ujoj estas en la nomspaco openwhisk en statuso Running, ĉar foje ĝi frakasas kun eraroj CreateContainerConfigError.
Alvokanto ankoraŭ praviganta — Init:1/2
La procezo de elŝuto de diversaj rultempaj medioj povas daŭri longan tempon. Por akceli aferojn, vi povas specifi mallongigitan minimuman liston en la dosiero mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Ujo kun nomo -instali-pakojn- kraŝas al Eraro
Nur pliigu la tempodaŭrojn por vivtestoj.
Instalante OpenWhisk super Knative
Priti Desai efektivigis la instaladon supre de areto en la IBM-nubo, same kiel sur regula minikube, uzante Knative Build kaj BuildTemplates. Mi ankaŭ instalos sur minukube, laŭ kiel ĝi estis priskribita en nia blogo pli frue - uzante la plej novajn versiojn de programaro. Ĉar Knative Build kaj BuildTemplates estas oficiale malrekomenditaj, mi uzos la rekomenditan anstataŭaĵon en la formo de Tekton Pipelines. La resto de la artikolo estis skribita post legado de la dokumentaro por Tekton Pipelines, sed baziĝas sur la ideoj de Priti. Por funkcii, vi bezonos aliron al iu Docker Registry - mi, kiel la origina aŭtoro, uzos DockerHub.
Ni aplikas la aktualajn datumojn por ĉi tiu dosiero:
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Ni aplikas:
$ 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
Kontroli la laboron konsistas en ricevi la nomon de la balgo kaj vidi ĝian staton. Vi ankaŭ povas vidi la ekzekutprotokolo de ĉiu paŝo, ekzemple:
$ 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"}
Post ekzekuto, ni havos bildon en la Registro kiu povas esti deplojita per la kn-ilaĵo, desegnita por labori kun Knative-servoj, ekzemple:
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
Se vi uzas Gloo, vi povas kontroli ĝian funkcion jene: