Cet article conclut le cycle des notes traduites sur OpenWhisk de l'auteur . Aujourd'hui, nous examinerons le processus de déploiement d'OpenWhisk sur Kubernetes avec des commandes corrigées pour la compatibilité avec les versions actuelles des applications. Le processus de lancement des fonctions OpenWhisk en utilisant Knative et TektonCD dans Kubernetes avec l'environnement d'exécution Nodejs sera également décrit.
Déploiement d'OpenWhisk sur Kubernetes
En quelques jours, j'ai mené une expérience de déploiement d'OpenWhisk dans Kubernetes pour créer un espace simple et rapide pour pratiquer des tâches. Et comme je suis novice en Kubernetes, je pense qu'il m'a fallu un jour et demi pour réussir le déploiement. Dans le dépôt, il y a des instructions très claires pour déployer OpenWhisk sur Kubernetes. Ici, il y aura des instructions de déploiement faites pour Mac (je vais également tout faire sur Linux car je préfère Linux. — note du traducteur).
- Installation du gestionnaire de packages
asdf, après quoi nous corrigeons automatiquement~/ .bash_profileou son équivalent comme ça :
$ brew install asdf
$ [ -s "/usr/local/opt/asdf/asdf.sh" ] && . /usr/local/opt/asdf/asdf.sh
$ source ~/.bash_profile[Sur Linux, cette étape n'est pas nécessaire, bien que brew soit disponible. — note du traducteur]
- Ajoutons des plugins
minikubeetkubelet:
$ asdf plugin-add kubectl
$ asdf plugin-add minikube[Encore une fois, nous omettons cette étape sur Linux. — note du traducteur]
- Installons minikube et 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[des versions spécifiques sont installées, mais j'ai vérifié tout cela avec les dernières versions disponibles pour Linux ; je soupçonne qu'il est possible d'installer la dernière version sans problème. — note du traducteur]
Sur Linux, cette étape se fait comme ça (tout est installé dans ~/bin, qui est dans mon PATH, note du traducteur) :
$ 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/- Création d'une machine virtuelle minikube (VirtualBox doit être installé au préalable) :
$ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.9.0 --extra-config=apiserver.Authorization.Mode=RBAC[Tout fonctionne pour moi avec la commande minikube start , sans paramètres et avec les valeurs par défaut. — note du traducteur]
$ minikube start
minikube v1.5.2 sur Debian 8.11
Driver 'virtualbox' sélectionné automatiquement
Téléchargement de l'image de démarrage de la VM ...
> 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
Création de la VM virtualbox (CPUs=2, Mémoire=4096MB, Disque=20000MB) ...
Préparation de Kubernetes v1.16.2 sur Docker '18.09.9' ...
Téléchargement de kubelet v1.16.2
Téléchargement de kubeadm v1.16.2
Tirage d'images ...
Lancement de Kubernetes ... Attente de : apiserver
Fait ! kubectl est maintenant configuré pour utiliser "minikube"- Basculons le réseau dans Docker en mode promiscuous :
$ minikube ssh -- sudo ip link set docker0 promisc on- Créons un namespace et marquons le nœud de travail :
$ kubectl create namespace openwhisk
$ kubectl label nodes --all openwhisk-role=invoker- Récupérons le contenu du dépôt et redéfinissons le type pour l'ingress dans le fichier mycluster.yaml :
$ git clone https://github.com/apache/incubator-openwhisk-deploy-kube.git
$ cd incubator-openwhisk-deploy-kube/
$ cat < mycluster.yaml
whisk:
ingress:
type: NodePort
api_host_name: 192.168.99.100
api_host_port: 31001
nginx:
httpsNodePort: 31001
EOF- Installons Helm et effectuons le déploiement avec :
$ brew install kubernetes-helm
$ helm init # init Helm Tiller, pas nécessaire sur Helm v3+
$ kubectl get pods -n kube-system # vérifier que tiller-deploy est en état de fonctionnement, pas nécessaire sur helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml[Sur Linux avec les dernières versions (v3.0.1 était disponible), c'est un peu différent. — note du traducteur]
$ 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- Vérifions que tout est opérationnel (STATUS = Running ou Completed) :
$ kubectl get pods -n openwhisk
NOM PRÊT ÉTAT REDÉMARRAGES ÂGE
openwhisk-1576070780-alarmprovider-6868dc694-plvpf 1/1 En cours 1 1d5h
openwhisk-1576070780-apigateway-8d56f4979-825hf 1/1 En cours 1 1d5h
openwhisk-1576070780-cloudantprovider-544bb46596-9scph 1/1 En cours 1 1d5h
openwhisk-1576070780-controller-0 1/1 En cours 2 1d5h
openwhisk-1576070780-couchdb-7fd7f6c7cc-42tw6 1/1 En cours 1 1d5h
openwhisk-1576070780-gen-certs-z9nsb 0/1 Terminé 0 1d5h
openwhisk-1576070780-init-couchdb-r2vmt 0/1 Terminé 0 1d5h
openwhisk-1576070780-install-packages-27dtr 0/1 Terminé 0 1d4h
openwhisk-1576070780-invoker-0 1/1 En cours 1 1d5h
openwhisk-1576070780-kafka-0 1/1 En cours 1 1d5h
openwhisk-1576070780-kafkaprovider-f8b4cf4fc-7z4gt 1/1 En cours 1 1d5h
openwhisk-1576070780-nginx-6dbdbf69bc-5x76n 1/1 En cours 1 1d5h
openwhisk-1576070780-redis-cfd8756f4-hkrt6 1/1 En cours 1 1d5h
openwhisk-1576070780-wskadmin 1/1 En cours 1 1d5h
openwhisk-1576070780-zookeeper-0 1/1 En cours 1 1d5h
wskopenwhisk-1576070780-invoker-00-1-prewarm-nodejs10 1/1 En cours 0 61s
wskopenwhisk-1576070780-invoker-00-2-prewarm-nodejs10 1/1 En cours 0 61s
wskopenwhisk-1576070780-invoker-00-3-whisksystem-invokerhealtht 1/1 En cours 0 59s- Configuration de wsk pour le fonctionnement :
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwPVérifions :
$ wsk -i list
Entités dans l'espace de noms : défaut
packages
actions
triggers
rulesProblèmes et leurs solutions
getsockopt : connexion refusée
$ wsk -i list
erreur : Impossible d'obtenir la liste des entités pour l'espace de noms 'default' : Get http://192.168.99.100:31001/api/v1/namespaces/_/actions?limit=0&skip=0 : dial tcp 192.168.99.100:31001 : getsockopt : connexion refuséeVérifions que les conteneurs dans l'espace de noms openwhisk sont en statut Running, car parfois cela échoue avec des erreurs CreateContainerConfigError.
L'invocateur est encore en cours d'initialisation — Init:1/2
Le processus de téléchargement de divers environnements d'exécution peut prendre beaucoup de temps. Pour accélérer, vous pouvez spécifier une liste minimale dans le fichier mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"Le conteneur nommé -install-packages- tombe en erreur
Il suffit d'augmenter les délais pour les tests de liveness.
Installation d'OpenWhisk sur Knative
Priti Desai a réalisé l'installation sur un cluster dans le cloud IBM, ainsi que sur minikube standard, en utilisant Knative Build et BuildTemplates. Je vais également installer sur minikube, en m'inspirant de ce qui Dans notre blog précédent — en utilisant les dernières versions du logiciel. Étant donné que Knative Build et BuildTemplates sont officiellement déclarés obsolètes, je vais utiliser la solution recommandée sous la forme de Tekton Pipelines. La suite de l'article est écrite après avoir lu la documentation de Tekton Pipelines, mais elle est basée sur les idées de Priti. Pour travailler, vous aurez besoin d'un accès à un certain Docker Registry — comme l'auteur original, j'utiliserai DockerHub.
$ 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
Construction et fonctionnement d'OpenWhisk sur Knative
- Obtenons le contenu :
$ git clone https://github.com/tektoncd/catalog/
$ cd catalog/openwhisk- Nous définissons les données d'accès au Registry sous forme de variables d'environnement et les enregistrons sous forme de secret Kubernetes :
$ export DOCKER_USERNAME=
$ export DOCKER_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.yamlVérifions :
$ kubectl get secret
NAME TYPE DATA AGE
dockerhub-user-pass kubernetes.io/basic-auth 2 21s- Créons un compte pour l'assemblage des environnements :
$ kubectl apply -f service-account.yamlVérifions :
$ kubectl get serviceaccount/openwhisk-runtime-builder
NAME SECRETS AGE
openwhisk-runtime-builder 2 31m- Créons une tâche pour construire l'image pour OpenWhisk
$ kubectl apply -f openwhisk.yaml
task.tekton.dev/openwhisk created- Lançons la tâche pour construire l'image (avec un exemple NodeJS) :
Créons un fichier taskrun.yaml avec le contenu :
# 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
---Appliquons les données actuelles pour ce fichier :
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yamlAppliquons :
$ 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 createdLa vérification du fonctionnement consiste à obtenir le nom du pod, à vérifier son état. Vous pouvez également consulter le journal de chaque étape, par exemple :
$ 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 Terminé 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":"Échec de la récupération de l'ID du commit GitHub depuis kodata : open "/var/run/ko/refs/heads/master : fichier ou répertoire introuvable"}
{"level":"info","ts":1576532936.538926,"logger":"fallback-logger","caller":"git/git.go:81","msg":"Clonage réussi de https://github.com/apache/openwhisk-runtime-nodejs.git @ master dans le chemin /workspace/runtime-git"}
{"level":"warn","ts":1576532936.5395331,"logger":"fallback-logger","caller":"git/git.go:128","msg":"Erreur inattendue : création de symlink : symlink /tekton/home/.ssh /root/.ssh : le fichier existe"}
{"level":"info","ts":1576532936.8202565,"logger":"fallback-logger","caller":"git/git.go:109","msg":"Modules enfants initialisés et mis à jour avec succès dans le chemin /workspace/runtime-git"}Après l'exécution, nous aurons une image dans le registre qui peut être déployée à l'aide de l'outil kn, destiné à travailler avec des services Knative, par exemple :
kn service create nodejs-helloworld --image docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld
Service 'nodejs-helloworld' créé avec succès dans l'espace de noms 'default'.
Attente de la disponibilité du service 'nodejs-helloworld' ... OK
URL du service :
http://nodejs-helloworld.default.example.comEn cas d'utilisation de Gloo, vous pouvez vérifier le bon fonctionnement de cette manière :
$ 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":"Bonjour le monde !"}Autres articles de la série
Source : habr.com
