Questo articolo conclude la serie di note tradotte su OpenWhisk dall'autore Priti Desai. Oggi esamineremo il processo di distribuzione di OpenWhisk su Kubernetes con i comandi corretti per funzionare con le versioni attuali delle applicazioni. Coprirà inoltre il processo di esecuzione delle funzioni OpenWhisk utilizzando Knative e TektonCD su Kubernetes utilizzando il runtime Nodejs.
Distribuzione di OpenWhisk su Kubernetes
Nel corso di alcuni giorni, ho sperimentato la distribuzione di OpenWhisk su Kubernetes per creare un banco di prova semplice e veloce. E poiché sono nuovo in Kubernetes, credo che sia stato dedicato un giorno e mezzo a una distribuzione di successo. IN Questo I repository contengono istruzioni molto chiare per la distribuzione di OpenWhisk su Kubernetes. Ecco le istruzioni di distribuzione realizzate per Mac (Farò tutto anche su Linux perché preferisco Linux. - ca. traduttore).
Installazione del gestore pacchetti asdf, dopodiché correggiamo automaticamente ~/.bash_profile o il suo equivalente in questo modo:
[Ancora una volta, salta questo passaggio su Linux. - ca. traduttore]
Installa minikube e 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
[sono installate versioni specifiche, ma ho controllato tutto sulle ultime versioni disponibili per Linux; Sospetto che tu possa tranquillamente installare l'ultima versione. - ca. traduttore]
Su Linux, questo passaggio viene eseguito in questo modo (tutto viene inserito in ~/bin, che è elencato nel mio PERCORSO, nota del traduttore):
$ 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
[Su Linux con le ultime versioni (era disponibile la v3.0.1) sarà leggermente diverso. - ca. traduttore]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
Controlliamo:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Problemi e soluzioni
getsockopt: connessione rifiutata
$ 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
Verifica che i contenitori siano nello spazio dei nomi openwhisk nello stato Running, Perché a volte si blocca con errori CreateContainerConfigError.
L'invoker è ancora in fase di inizializzazione: Init:1/2
Il processo di download di vari ambienti runtime può richiedere molto tempo. Per velocizzare le cose, puoi specificare un elenco minimo abbreviato nel file mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Contenitore con nome -installa-pacchetti- si blocca in Errore
Aumenta semplicemente i timeout per i test di attività.
Installazione di OpenWhisk su Knative
Priti Desai ha eseguito l'installazione su un cluster nel cloud IBM, nonché su un normale minikube, utilizzando Knative Build e BuildTemplates. Lo installerò anche sopra minukube, in base a come è stato descritto nel nostro blog in precedenza, utilizzando le versioni software più recenti. Poiché Knative Build e BuildTemplates sono stati ufficialmente deprecati, utilizzerò la sostituzione consigliata sotto forma di Tekton Pipelines. Il resto dell'articolo è stato scritto dopo aver letto la documentazione di Tekton Pipelines, ma si basa sulle idee di Priti. Per funzionare, avrai bisogno dell'accesso ad alcuni registri Docker: io, come l'autore originale, utilizzerò DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Applichiamo:
$ 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
Il controllo del lavoro consiste nell'ottenere il nome del pod e visualizzarne lo stato. Puoi anche visualizzare il registro di esecuzione di ogni passaggio, ad esempio:
$ 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"}
Dopo l'esecuzione, avremo un'immagine nel registro che può essere distribuita utilizzando l'utilità kn, progettata per funzionare con i servizi Knative, ad esempio:
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 usi Gloo, puoi verificarne la funzionalità in questo modo: