Geekly articles weekly

Serverloses Rechnen basierend auf OpenWhisk, Teil 4


Dieser Artikel schließt die OpenWhisk-Reihe mit Übersetzungsnotizen von Priti Desai ab . Heute werden wir uns den Prozess der Bereitstellung von OpenWhisk auf Kubernetes mit korrigierten Befehlen für die Arbeit mit aktuellen Versionen von Anwendungen ansehen. Es wird auch beschrieben, wie OpenWhisk-Funktionen mit Knative und TektonCD in Kubernetes unter Verwendung der Nodejs-Laufzeit gestartet werden.


Stellen Sie OpenWhisk auf Kubernetes bereit


Im Laufe einiger Tage habe ich mit der Bereitstellung von OpenWhisk in Kubernetes experimentiert, um ein schnelles und einfaches Übungsgelände zu schaffen. Und da ich neu bei Kubernetes bin, habe ich anderthalb Tage für einen erfolgreichen Einsatz aufgewendet. Dieses Repository enthält sehr klare Anweisungen für die Bereitstellung von OpenWhisk auf Kubernetes. Hier sind die Bereitstellungsanweisungen für den Mac ( ich mache auch alles unter Linux, da ich Linux bevorzuge. - Anmerkung des Übersetzers).


  1. Wir installieren den asdf Paketmanager. asdf reparieren wir automatisch ~/.bash_profile oder dessen Entsprechung wie ~/.bash_profile :

 $ brew install asdf $ [ -s "/usr/local/opt/asdf/asdf.sh" ] && . /usr/local/opt/asdf/asdf.sh $ source ~/.bash_profile

[ Unter Linux ist dieser Schritt nicht erforderlich, obwohl es ein Gebräu gibt. - Ca. Übersetzer]


  1. Hinzufügen von minikube und kubelet :

 $ asdf plugin-add kubectl $ asdf plugin-add minikube

[ Überspringen Sie diesen Schritt erneut unter Linux. - Ca. Übersetzer]


  1. Wir setzen Minikube und 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

[ Bestimmte Versionen sind installiert, aber ich habe die neuesten verfügbaren Versionen für Linux überprüft. Ich vermute, dass Sie die neuesten sicher setzen können. - Ca. Übersetzer]


Unter Linux geschieht dieser Schritt folgendermaßen (alles wird in ~ / bin abgelegt, was ich in PATH habe, Anmerkung des Übersetzers):


 $ curl -L0 minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && mv minikube ~/bin/ $ curl -L0 https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && mv kubectl ~/bin/

  1. Wir erstellen die Minikube Virtual Machine (VirtualBox muss vorinstalliert sein):

 $ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.9.0 --extra-config=apiserver.Authorization.Mode=RBAC

[ Alles funktioniert für mich mit dem Befehl minikube start , ohne Parameter und mit Standardwerten. - Ca. Übersetzer]


 $ minikube start minikube v1.5.2 on Debian 8.11 Automatically selected the 'virtualbox' driver Downloading VM boot image ... > minikube-v1.5.1.iso.sha256: 65 B / 65 B [--------------] 100.00% ? p/s 0s > minikube-v1.5.1.iso: 143.76 MiB / 143.76 MiB [-] 100.00% 5.63 MiB p/s 26s Creating virtualbox VM (CPUs=2, Memory=4096MB, Disk=20000MB) ... Preparing Kubernetes v1.16.2 on Docker '18.09.9' ... Downloading kubelet v1.16.2 Downloading kubeadm v1.16.2 Pulling images ... Launching Kubernetes ... Waiting for: apiserver Done! kubectl is now configured to use "minikube"

  1. Schalten Sie das Netzwerk in Docker in den Promiscuous-Modus:

 $ minikube ssh -- sudo ip link set docker0 promisc on

  1. Erstellen Sie einen Namespace und markieren Sie den Arbeitsknoten:

 $ kubectl create namespace openwhisk $ kubectl label nodes --all openwhisk-role=invoker

  1. Wir erhalten den Inhalt des Repositorys und definieren den Typ für den Eingang in der Datei mycluster.yaml neu:

 $ git clone https://github.com/apache/incubator-openwhisk-deploy-kube.git $ cd incubator-openwhisk-deploy-kube/ $ cat << "EOF" > mycluster.yaml whisk: ingress: type: NodePort api_host_name: 192.168.99.100 api_host_port: 31001 nginx: httpsNodePort: 31001 EOF

  1. Installieren Sie Helm und stellen Sie es bereit:

 $ 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

[ Unter Linux mit den neuesten Versionen (v3.0.1 war verfügbar) wird es etwas anders sein. - Ca. Übersetzer]


 $ curl -L0 https://get.helm.sh/helm-v3.0.1-linux-amd64.tar.gz | tar -xzvf - linux-amd64/helm --strip-components=1; sudo mv helm /usr/local/bin $ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default $ helm install ./openwhisk/helm/ --namespace=openwhisk --generate-name -f mycluster.yaml

  1. Überprüfen Sie, ob alles gestiegen ist (STATUS = Running oder Completed):

 $ kubectl get pods -n openwhisk NAME READY STATUS RESTARTS AGE openwhisk-1576070780-alarmprovider-6868dc694-plvpf 1/1 Running 1 1d5h openwhisk-1576070780-apigateway-8d56f4979-825hf 1/1 Running 1 1d5h openwhisk-1576070780-cloudantprovider-544bb46596-9scph 1/1 Running 1 1d5h openwhisk-1576070780-controller-0 1/1 Running 2 1d5h openwhisk-1576070780-couchdb-7fd7f6c7cc-42tw6 1/1 Running 1 1d5h openwhisk-1576070780-gen-certs-z9nsb 0/1 Completed 0 1d5h openwhisk-1576070780-init-couchdb-r2vmt 0/1 Completed 0 1d5h openwhisk-1576070780-install-packages-27dtr 0/1 Completed 0 1d4h openwhisk-1576070780-invoker-0 1/1 Running 1 1d5h openwhisk-1576070780-kafka-0 1/1 Running 1 1d5h openwhisk-1576070780-kafkaprovider-f8b4cf4fc-7z4gt 1/1 Running 1 1d5h openwhisk-1576070780-nginx-6dbdbf69bc-5x76n 1/1 Running 1 1d5h openwhisk-1576070780-redis-cfd8756f4-hkrt6 1/1 Running 1 1d5h openwhisk-1576070780-wskadmin 1/1 Running 1 1d5h openwhisk-1576070780-zookeeper-0 1/1 Running 1 1d5h wskopenwhisk-1576070780-invoker-00-1-prewarm-nodejs10 1/1 Running 0 61s wskopenwhisk-1576070780-invoker-00-2-prewarm-nodejs10 1/1 Running 0 61s wskopenwhisk-1576070780-invoker-00-3-whisksystem-invokerhealtht 1/1 Running 0 59s

  1. Wir konfigurieren wsk für die Arbeit:

 $ wsk property set --apihost 192.168.99.100:31001 $ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP

Wir prüfen:


 $ wsk -i list Entities in namespace: default packages actions triggers rules

Probleme und Lösungen


getsockopt: Verbindung abgelehnt


 $ 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

Wir prüfen, ob die Container im Namespace openwhisk den Status Running haben, weil manchmal stürzt es mit CreateContainerConfigError Fehlern ab.


Aufrufer wird noch initialisiert - Init: 1/2


Das Herunterladen aller Arten von Laufzeiten kann viel Zeit in Anspruch nehmen. Zur Beschleunigung können Sie in der Datei mycluster.yaml eine abgekürzte Mindestliste mycluster.yaml :


 whisk: runtimes: "runtimes-minimal-travis.json"

Ein Container mit dem Namen -install-packages- fällt in Error aus


Erhöhen Sie einfach die Zeitüberschreitungen für Lebendigkeitstests.


Installieren Sie OpenWhisk auf Knative


Priti Desai führte die Installation über dem Cluster in der IBM Cloud sowie auf dem regulären Minikube mithilfe von Knative Build und BuildTemplates durch. Ich werde auch auf minukube installieren, basierend darauf, wie es in unserem Blog zuvor beschrieben wurde - unter Verwendung der neuesten Softwareversionen. Da Knative Build und BuildTemplates offiziell veraltet sind, verwende ich den empfohlenen Ersatz in Form von Tekton-Pipelines. Der Rest des Artikels wurde nach dem Lesen der Tekton Pipelines-Dokumentation geschrieben, jedoch basierend auf den Ideen von Priti. Zum Arbeiten benötigen Sie Zugriff auf eine Docker-Registrierung. Ich verwende DockerHub wie der ursprüngliche Autor.


 $ curl -L0 https://github.com/solo-io/gloo/releases/download/v1.2.10/glooctl-linux-amd64; chmod +x glooctl-linux-amd64; mv glooctl-linux-amd64 ~/bin $ glooctl install knative $ kubectl get pods -n knative-serving NAME READY STATUS RESTARTS AGE activator-77fc555665-rvrst 1/1 Running 0 2m23s autoscaler-5c98b7c9b6-x8hh4 1/1 Running 0 2m21s autoscaler-hpa-5cfd4f6845-w87kq 1/1 Running 0 2m22s controller-7fd74c8f67-tprm8 1/1 Running 0 2m19s webhook-74847bb77c-txr2g 1/1 Running 0 2m17s $ kubectl get pods -n gloo-system NAME READY STATUS RESTARTS AGE discovery-859d7fbc9c-8xhvh 1/1 Running 0 51s gloo-545886d9c6-85mwt 1/1 Running 0 51s ingress-67d4996d75-lkkmw 1/1 Running 0 50s knative-external-proxy-767dfd656c-wwv2z 1/1 Running 0 50s knative-internal-proxy-6fdddcc6b5-7vqd8 1/1 Running 0 51s


Erstellen Sie OpenWhisk und führen Sie es auf Knative aus


  1. Wir erhalten den Inhalt dieses Repositorys :

 $ git clone https://github.com/tektoncd/catalog/ $ cd catalog/openwhisk

  1. Wir richten die Daten für den Zugriff auf die Registry in Form von Umgebungsvariablen ein und speichern sie als Kubernetes-Geheimnis:

 $ export DOCKER_USERNAME=<your docker hub username> $ export DOCKER_PASSWORD=<your docker hub password> $ sed -e 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -e 's/${DOCKER_PASSWORD}/'"$DOCKER_PASSWORD"'/' docker-secret.yaml.tmpl > docker-secret.yaml $ kubectl apply -f docker-secret.yaml

Wir prüfen:


 $ kubectl get secret NAME TYPE DATA AGE dockerhub-user-pass kubernetes.io/basic-auth 2 21s

  1. Erstellen Sie ein Konto zum Erstellen von Umgebungen:

 $ kubectl apply -f service-account.yaml

Wir prüfen:


 $ kubectl get serviceaccount/openwhisk-runtime-builder NAME SECRETS AGE openwhisk-runtime-builder 2 31m

  1. Erstellen Sie eine Aufgabe, um ein Image für OpenWhisk zu erstellen

 $ kubectl apply -f openwhisk.yaml task.tekton.dev/openwhisk created

  1. Führen Sie die Task aus, um das Image zu erstellen (am Beispiel von NodeJS):

Erstellen Sie die Datei taskrun.yaml mit dem Inhalt:


 # Git Pipeline Resource for OpenWhisk NodeJS Runtime apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: openwhisk-nodejs-runtime-git spec: type: git params: - name: revision value: master - name: url value: https://github.com/apache/openwhisk-runtime-nodejs.git --- # Image Pipeline Resource for OpenWhisk NodeJS Sample Application apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: openwhisk-nodejs-helloworld-image spec: type: image params: - name: url value: docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld --- # Task Run to build NodeJS image with the action source apiVersion: tekton.dev/v1alpha1 kind: TaskRun metadata: name: openwhisk-nodejs-helloworld spec: serviceAccountName: openwhisk-runtime-builder taskRef: name: openwhisk inputs: resources: - name: runtime-git resourceRef: name: openwhisk-nodejs-runtime-git params: - name: DOCKERFILE value: "./runtime-git/core/nodejs10Action/knative/Dockerfile" - name: OW_ACTION_NAME value: "nodejs-helloworld" - name: OW_ACTION_CODE value: "function main() {return {payload: 'Hello World!'};}" - name: OW_PROJECT_URL value: "" outputs: resources: - name: runtime-image resourceRef: name: openwhisk-nodejs-helloworld-image ---

Wir wenden die aktuellen Daten für diese Datei an:


 $ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml

Wir bewerben uns:


 $ 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

Das Überprüfen der Arbeit besteht darin, den Namen des Pods abzurufen und seinen Status anzuzeigen. Sie können auch das Protokoll jedes Schritts anzeigen, zum Beispiel:


 $ 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"}

Nach der Ausführung wird in unserer Registrierung ein Image angezeigt, das mit dem Dienstprogramm kn bereitgestellt werden kann, das für die Arbeit mit Knative-Diensten entwickelt wurde. Beispiel:


 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

Wenn Sie Gloo verwenden, können Sie die Funktionalität folgendermaßen überprüfen:


 $ curl -H "Host: nodejs-helloworld.default.example.com" -X POST $(glooctl proxy url --name knative-external-proxy) {"OK":true} $ curl -H "Host: nodejs-helloworld.default.example.com" -X POST $(glooctl proxy url --name knative-external-proxy) {"payload":"Hello World!"}

Andere Fahrradartikel


Serverloses Rechnen basierend auf OpenWhisk, Teil 1
Serverloses Rechnen basierend auf OpenWhisk, Teil 2
Serverloses Rechnen basierend auf OpenWhisk, Teil 3
Serverloses Rechnen basierend auf OpenWhisk, Teil 4

Source: https://habr.com/ru/post/de481000/

More articles:


All Articles