Este artículo finaliza la serie de notas traducidas sobre OpenWhisk del autor. Priti Desai. Hoy veremos el proceso de implementación de OpenWhisk sobre Kubernetes con comandos corregidos para trabajar con versiones actuales de aplicaciones. También cubrirá el proceso de ejecución de funciones de OpenWhisk usando Knative y TektonCD en Kubernetes usando el tiempo de ejecución de Nodejs.
Implementación de OpenWhisk en Kubernetes
En el transcurso de unos días, experimenté implementando OpenWhisk en Kubernetes para crear un campo de pruebas simple y rápido. Y como soy nuevo en Kubernetes, creo que dediqué un día y medio a una implementación exitosa. EN Este Los repositorios tienen instrucciones muy claras para implementar OpenWhisk en Kubernetes. Aquí están las instrucciones de implementación hechas para Mac (También haré todo en Linux porque prefiero Linux. — aprox. traductor).
Instalación del administrador de paquetes asdf, después de lo cual corregimos automáticamente ~/.bash_profile o su equivalente así:
[Nuevamente, omita este paso en Linux. — aprox. traductor]
Instale minikube y 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
[hay versiones específicas instaladas, pero verifiqué todo en las últimas versiones disponibles para Linux; Sospecho que puedes instalar la última versión de forma segura. — aprox. traductor]
En Linux, este paso se realiza de esta manera (todo se coloca en ~/bin, que aparece en mi RUTA, nota del traductor):
$ 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 Linux con las últimas versiones (v3.0.1 estaba disponible) será un poco diferente. — aprox. traductor]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
Comprobamos:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Problemas y soluciones
getockopt: conexión rechazada
$ 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
Comprobando que los contenedores están en el espacio de nombres. openwhisk en estado Running, porque a veces falla con errores CreateContainerConfigError.
El invocador aún se inicializa: Init:1/2
El proceso de descarga de varios entornos de ejecución puede llevar mucho tiempo. Para acelerar las cosas, puede especificar una lista mínima abreviada en el archivo mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Contenedor con nombre -instalar-paquetes- se bloquea por error
Simplemente aumente los tiempos de espera para las pruebas de vida.
Instalación de OpenWhisk sobre Knative
Priti Desai llevó a cabo la instalación sobre un clúster en la nube de IBM, así como en un minikube normal, utilizando Knative Build y BuildTemplates. También lo instalaré encima de minukube, según cómo fue descrito en nuestro blog anteriormente, utilizando las últimas versiones de software. Dado que Knative Build y BuildTemplates han quedado oficialmente obsoletos, usaré el reemplazo recomendado en forma de Tekton Pipelines. El resto del artículo fue escrito después de leer la documentación de Tekton Pipelines, pero se basa en las ideas de Priti. Para trabajar, necesitará acceso a algún registro de Docker; yo, como el autor original, usaré DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Aplicamos:
$ 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
Verificar el trabajo consiste en obtener el nombre del pod y ver su estado. También puede ver el registro de ejecución de cada paso, por ejemplo:
$ 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"}
Después de la ejecución, tendremos una imagen en el Registro que se puede implementar usando la utilidad kn, diseñada para funcionar con los servicios de Knative, por ejemplo:
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
Si usas Gloo, puedes comprobar su funcionalidad de esta manera: