Consellos e trucos de Kubernetes: sobre o desenvolvemento local e a telepresencia

Cada vez nos preguntan máis sobre o desenvolvemento de microservizos en Kubernetes. Os desenvolvedores, especialmente de linguaxes interpretadas, queren corrixir rapidamente o código no seu IDE favorito e ver o resultado sen esperar á compilación/implementación, simplemente premendo F5. E cando se trataba dunha aplicación monolítica, abondaba con instalar localmente unha base de datos e un servidor web (en Docker, VirtualBox...), e despois gozar de inmediato do desenvolvemento. Co corte de monolitos en microservizos e a chegada de Kubernetes, coa aparición de dependencias entre si, todo fíxose un pouco máis difícil. Canto máis estes microservizos, máis problemas. Para gozar de novo do desenvolvemento, cómpre levantar máis dun ou dous contedores Docker, e ás veces incluso máis dunha ducia... En xeral, todo isto pode levar bastante tempo, xa que tamén hai que manterlo actualizado. .

En diferentes momentos intentamos diferentes solucións ao problema. E comezarei coas solucións acumuladas ou simplemente coas "muletas".

1. Muletas

A maioría dos IDE teñen a capacidade de editar código directamente no servidor mediante FTP/SFTP. Este camiño é moi obvio e enseguida decidimos utilizalo. A súa esencia redúcese no seguinte:

1. No grupo de contornos de desenvolvemento (desenvolvemento/revisión), lánzase un contedor adicional con acceso SSH e reenviando a clave SSH pública do programador que confirmará/despregará a aplicación.
2. Na fase inicial (dentro do recipiente prepare-app) transferir o código a emptyDirpara ter acceso ao código desde os contedores da aplicación e o servidor SSH.

Para comprender mellor a implementación técnica deste esquema, proporcionarei fragmentos das configuracións YAML implicadas en Kubernetes.

Configuracións

1.1. valores.yaml

ssh_pub_key:
  vasya.pupkin: <ssh public key in base64> 

Aquí vasya.pupkin é o valor da variable ${GITLAB_USER_LOGIN}.

1.2. despregamento.yaml

...
{{ if eq .Values.global.debug "yes" }}
      volumes:
      - name: ssh-pub-key
        secret:
          defaultMode: 0600
          secretName: {{ .Chart.Name }}-ssh-pub-key
      - name: app-data
        emptyDir: {}
      initContainers:
      - name: prepare-app
{{ tuple "backend" . | include "werf_container_image" | indent 8 }}
        volumeMounts:
        - name: app-data
          mountPath: /app-data
        command: ["bash", "-c", "cp -ar /app/* /app-data/" ]
{{ end }}
      containers:
{{ if eq .Values.global.debug "yes" }}
      - name: ssh
        image: corbinu/ssh-server
        volumeMounts:
        - name: ssh-pub-key
          readOnly: true
          mountPath: /root/.ssh/authorized_keys
          subPath: authorized_keys
        - name: app-data
          mountPath: /app
        ports:
        - name: ssh
          containerPort: 22
          protocol: TCP
{{ end }}
      - name: backend
        volumeMounts:
{{ if eq .Values.global.debug "yes" }}
        - name: app-data
          mountPath: /app
{{ end }}
        command: ["/usr/sbin/php-fpm7.2", "--fpm-config", "/etc/php/7.2/php-fpm.conf", "-F"]
...

1.3. segredo.yaml

{{ if eq .Values.global.debug "yes" }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Chart.Name }}-ssh-pub-key
type: Opaque
data:
  authorized_keys: "{{ first (pluck .Values.global.username .Values.ssh_pub_key) }}"
{{ end }}

Preme final

Despois diso só queda transferir variables necesarias gitlab-ci.yml:

dev:
  stage: deploy
  script:
   - type multiwerf && source <(multiwerf use 1.0 beta)
   - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
   - werf deploy
     --namespace ${CI_PROJECT_NAME}-stage
     --set "global.env=stage"
     --set "global.git_rev=${CI_COMMIT_SHA}"
     --set "global.debug=yes"
     --set "global.username=${GITLAB_USER_LOGIN}"
 tags:
   - build

Voila: o programador que iniciou a implementación pode conectarse polo nome do servizo (como conceder acceso ao clúster de forma segura, xa dixemos) desde o teu escritorio a través de SFTP e edita o código sen esperar a que se entregue ao clúster.

Esta é unha solución completamente funcional, pero desde o punto de vista da implementación ten desvantaxes obvias:

• a necesidade de refinar o gráfico Helm, o que dificulta a súa lectura no futuro;
• só pode ser utilizado pola persoa que despregou o servizo;
• cómpre lembrar de sincronizalo co directorio local co código e comprometelo a Git.

2. Telepresencia

Proxecto Telepresencia coñécese desde hai moito tempo, pero nós, como din, "non chegamos a probalo seriamente na práctica". Non obstante, a demanda fixo o seu traballo e agora estamos encantados de compartir a nosa experiencia, que pode ser útil para os lectores do noso blog, especialmente porque aínda non houbo outros materiais sobre a telepresencia no hub.

En resumo, todo resultou non ser tan asustado. Colocamos todas as accións que requiren a execución por parte do programador nun ficheiro de texto do gráfico Helm chamado NOTES.txt. Así, despois de implantar o servizo en Kubernetes, o programador ve instrucións para iniciar o ambiente de desenvolvemento local no rexistro de traballos de GitLab:

!!! Разработка сервиса локально, в составе Kubernetes !!!

* Настройка окружения
* * Должен быть доступ до кластера через VPN
* * На локальном ПК установлен kubectl ( https://kubernetes.io/docs/tasks/tools/install-kubectl/ )
* * Получить config-файл для kubectl (скопировать в ~/.kube/config)
* * На локальном ПК установлен telepresence ( https://www.telepresence.io/reference/install )
* * Должен быть установлен Docker
* * Необходим доступ уровня reporter или выше к репозиторию https://gitlab.site.com/group/app
* * Необходимо залогинится в registry с логином/паролем от GitLab (делается один раз):

#########################################################################
docker login registry.site.com
#########################################################################

* Запуск окружения

#########################################################################
telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=/tmp/app --docker-run -v `pwd`:/app -v /tmp/app/var/run/secrets:/var/run/secrets -ti registry.site.com/group/app/backend:v8
#########################################################################

Non nos deteremos en detalle nos pasos descritos nesta instrución... coa excepción do último. Que ocorre durante o lanzamento de Telepresence?

Traballando con Telepresencia

No inicio (usando o último comando especificado nas instrucións anteriores), configuramos:

• espazo de nomes no que se está a executar o microservizo;
• nomes do despregamento e do contedor no que queremos penetrar.

Os argumentos restantes son opcionais. Se o noso servizo interactúa con e para a API de Kubernetes Creouse a conta de servizo, necesitamos montar certificados/fichas no noso escritorio. Para iso, use a opción --mount=true (Ou --mount=/dst_path), que montará a raíz (/) do contedor Kubernetes ao noso escritorio. Despois diso, podemos (dependendo do SO e de como se lance a aplicación) usar as "claves" do clúster.

En primeiro lugar, vexamos a opción máis universal para executar unha aplicación: nun contedor Docker. Para iso usaremos a chave --docker-run e monte o directorio co código no contedor: -v `pwd`:/app

Teña en conta que isto supón a execución desde o directorio do proxecto. O código da aplicación montarase no directorio /app nun recipiente.

Seguinte: -v /tmp/app/var/run/secrets:/var/run/secrets — para montar o directorio co certificado/token nun contedor.

Esta opción vai finalmente seguida da imaxe na que se executará a aplicación. NB: Ao construír unha imaxe, debes especificalo CMD ou ENTRYPOINT!

Que pasará exactamente a continuación?

• En Kubernetes, para a implantación especificada, o número de réplicas cambiarase a 0. No seu lugar, lanzarase unha nova implantación, cun contedor substituto. backend.
• No escritorio lanzaranse 2 contedores: o primeiro con Telepresence (proxy as solicitudes de/a Kubernetes), o segundo coa aplicación que se está a desenvolver.
• Se executamos no contedor coa aplicación, todas as variables ENV transferidas por Helm durante a implantación estarán dispoñibles para nós e todos os servizos tamén estarán dispoñibles. Só queda editar o código no teu IDE favorito e gozar do resultado.
• Ao final do traballo, só tes que pechar o terminal no que se está a executar Telepresence (rematar a sesión con Ctrl+C) - Os contedores Docker pararanse no escritorio e en Kubernetes todo volverá ao seu estado inicial. Todo o que queda é comprometerse, emitir o MR e transferilo para revisar/fusionar/… (dependendo dos seus fluxos de traballo).

Se non queremos executar a aplicación nun contedor Docker, por exemplo, non desenvolvemos en PHP, senón en Go, e aínda así a construímos localmente, lanzar Telepresence será aínda máis sinxelo:

telepresence --namespace {{ .Values.global.env }} --swap-deployment {{ .Chart.Name  }}:backend --mount=true

Se a aplicación accede á API de Kubernetes, terás que montar o directorio de claves (https://www.telepresence.io/howto/volumes). Hai unha utilidade para Linux raíz:

proot -b $TELEPRESENCE_ROOT/var/run/secrets/:/var/run/secrets bash

Despois de lanzar Telepresence sen a opción --docker-run todas as variables de ambiente estarán dispoñibles no terminal actual, polo que a aplicación debe ser iniciada nel.

NB: Cando use, por exemplo, PHP, debe lembrar de desactivar varios aceleradores de op_cache, apc e outros para o desenvolvemento; se non, editar o código non levará ao resultado desexado.

Resultados de

O desenvolvemento local con Kubernetes é un problema cuxa solución vai crecendo en proporción á difusión desta plataforma. Recibindo solicitudes relevantes dos desenvolvedores (dos nosos clientes), comezamos a resolvelos cos primeiros medios dispoñibles, que, con todo, non se demostraron a longo prazo. Afortunadamente, isto fíxose evidente non só agora e non só para nós, polo que xa apareceron medios máis axeitados no mundo, e a Telepresencia é a máis famosa delas (por certo, tamén hai patíbulo de Google). A nosa experiencia de usalo aínda non é tan grande, pero xa nos dá motivos para recomendalo aos nosos "colegas da tenda": probalo!

PS

Outros da serie de consellos e trucos K8s:

• «Consellos e trucos de Kubernetes: páxinas de erro personalizadas en NGINX Ingress»;
• «Transferir recursos que traballan nun clúster á xestión de Helm 2»;
• «Sobre a asignación de nodos e as cargas nunha aplicación web»;
• «Acceso a sitios de desenvolvemento»;
• «Acelerar o arranque para grandes bases de datos».

Fonte: www.habr.com