Geekly articles weekly

Computação sem servidor baseada no OpenWhisk, parte 4


Este artigo conclui a série de notas de tradução do OpenWhisk de Priti Desai . Hoje, veremos o processo de implantação do OpenWhisk no Kubernetes com comandos corrigidos para trabalhar com as versões atuais dos aplicativos. Ele também descreverá como iniciar as funções do OpenWhisk usando o Knative e o TektonCD no Kubernetes usando o tempo de execução do Nodejs.


Implantar o OpenWhisk no Kubernetes


Ao longo de alguns dias, experimentei implantar o OpenWhisk no Kubernetes para criar um campo de treinamento rápido e fácil. E como sou novo no Kubernetes, acredito que um dia e meio foi gasto em uma implantação bem-sucedida. Este repositório tem instruções muito claras para implantar o OpenWhisk no Kubernetes. Aqui estão as instruções de implantação feitas para o Mac ( também farei tudo no Linux, porque prefiro o Linux. - Nota do tradutor).


  1. Instalamos o gerenciador de pacotes asdf , após o qual corrigimos automaticamente ~/.bash_profile ou seu análogo da seguinte maneira:

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

[ No Linux, esta etapa não é necessária, embora exista uma mistura. - aprox. tradutor]


  1. Adicione kubelet e kubelet :

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

[ Mais uma vez, pule esta etapa no Linux. - aprox. tradutor]


  1. Colocamos 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

[ versões específicas estão instaladas, mas verifiquei tudo nas últimas versões disponíveis para Linux; Eu suspeito que você pode colocar com segurança o mais recente. - aprox. tradutor]


No Linux, esta etapa é feita assim (tudo é colocado em ~ / bin, que eu tenho no PATH, nota do tradutor):


 $ 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. Criamos a máquina virtual minikube (o VirtualBox deve ser pré-instalado):

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

[ Tudo funciona para mim com o comando minikube start , sem parâmetros e com valores padrão. - aprox. tradutor]


 $ 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. Alterne a rede no Docker para o modo promíscuo:

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

  1. Crie um espaço para nome e marque o nó de trabalho:

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

  1. Obtemos o conteúdo do repositório e redefinimos o tipo de entrada no arquivo mycluster.yaml:

 $ 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. Instale o Helm e implemente usando-o:

 $ 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

[ No Linux com as versões mais recentes (a v3.0.1 estava disponível), será um pouco diferente. - aprox. tradutor]


 $ 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. Verifique se tudo aumentou (STATUS = Em execução ou Concluído):

 $ 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. Configuramos o wsk para o trabalho:

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

Verificamos:


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

Problemas e soluções


getsockopt: conexão recusada


 $ 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

Verificamos se os contêineres no espaço openwhisk nome openwhisk no status Running , porque Às vezes, ele trava com os erros do CreateContainerConfigError .


Invoker ainda inicializando - Init: 1/2


O processo de download de todos os tipos de tempos de execução pode levar muito tempo. Para acelerar, você pode especificar uma lista mínima abreviada no arquivo mycluster.yaml :


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

Um contêiner chamado -install-packages- cai no erro


Apenas aumente o tempo limite para testes de animação.


Instale o OpenWhisk em cima do Knative


O Priti Desai executou a instalação na parte superior do cluster na nuvem IBM, bem como no minikube comum, usando Knative Build e BuildTemplates. Também instalarei no minukube, com base em como foi descrito em nosso blog anteriormente - usando as versões mais recentes do software. Como o Knative Build e o BuildTemplates foram oficialmente descontinuados, usarei a substituição recomendada na forma de Tekton Pipelines. O restante do artigo foi escrito após a leitura da documentação da Tekton Pipelines, mas com base nas idéias de Priti. Para funcionar, você precisará acessar alguns Docker Registry - eu, como o autor original, utilizarei o 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


Crie e execute o OpenWhisk sobre o Knative


  1. Nós obtemos o conteúdo deste repositório :

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

  1. Configuramos os dados para acessar o Registro na forma de variáveis ​​de ambiente e os salvamos como um segredo do Kubernetes:

 $ 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

Verificamos:


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

  1. Crie uma conta para criar ambientes:

 $ kubectl apply -f service-account.yaml

Verificamos:


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

  1. Crie uma tarefa para criar uma imagem para o OpenWhisk

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

  1. Execute a tarefa para construir a imagem (usando o NodeJS como exemplo):

Crie o arquivo taskrun.yaml com o conteúdo:


 # 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 ---

Aplicamos os dados atuais para este arquivo:


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

Nós 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

A verificação do trabalho consiste em obter o nome do pod, visualizando seu status. Você também pode ver o log de cada etapa, por exemplo:


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

Após a execução, uma imagem aparecerá em nosso Registro que pode ser implantada usando o utilitário kn, projetado para trabalhar com serviços Knative, por exemplo:


 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

No caso de usar o Gloo, você pode verificar a funcionalidade:


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

Outros artigos do ciclo


Computação sem servidor baseada no OpenWhisk, parte 1
Computação sem servidor baseada no OpenWhisk, parte 2
Computação sem servidor baseada no OpenWhisk, parte 3
Computação sem servidor baseada no OpenWhisk, parte 4

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

More articles:


All Articles