Consejos y trucos de Kubernetes: sobre desarrollo local y telepresencia

Cada vez se nos pregunta más sobre el desarrollo de microservicios en Kubernetes. Los desarrolladores, especialmente los idiomas interpretados, desean corregir rápidamente el código en su IDE favorito y sin esperar a que la compilación / implementación vea el resultado, simplemente presionando F5. Y cuando se trataba de la aplicación monolítica, fue suficiente para aumentar localmente la base de datos y el servidor web (en Docker, VirtualBox ...), después de lo cual, disfrute inmediatamente del desarrollo. Con el corte de los monolitos en microservicios y el advenimiento de Kubernetes, con la aparición de dependencias entre sí, las cosas se complicaron un poco . Cuanto más de estos microservicios, más problemas. Para volver a disfrutar del desarrollo, debe levantar más de uno o dos contenedores Docker, y a veces incluso más de una docena ... En general, todo esto puede llevar mucho tiempo, porque también necesita mantenerlo actualizado.

En diferentes momentos, probamos diferentes soluciones al problema. Y comenzaré con las soluciones acumuladas o simplemente "muletas".

1. muletas

La mayoría de los IDE tienen la capacidad de editar código directamente en el servidor usando FTP / SFTP. Este camino es muy obvio e inmediatamente decidimos usarlo. Su esencia es la siguiente:

1. En el pod para entornos de desarrollo (desarrollo / revisión), se lanza un contenedor adicional con acceso a través de SSH y reenvía la clave SSH pública del desarrollador que confirmará / implementará la aplicación.
2. En la etapa de inicio (dentro del contenedor de prepare-app ) transferimos el código a emptyDir para tener acceso al código desde los contenedores con la aplicación y el servidor SSH.

Para una mejor comprensión de la implementación técnica de dicho esquema, daré fragmentos de las configuraciones de YAML involucradas en Kubernetes.

Configuraciones

1.1. valores.yaml

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

Aquí vasya.pupkin es el valor de la variable ${GITLAB_USER_LOGIN} .

1.2. despliegue.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. secret.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 }} 

Toque final

Después de eso, solo queda pasar las variables necesarias a 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: el desarrollador que lanzó la implementación puede conectarse utilizando el nombre del servicio ( ya le dijimos cómo emitir acceso al clúster de forma segura) desde su escritorio a través de SFTP y editar el código sin esperar a que se entregue al clúster.

Esta es una solución completamente funcional, pero desde el punto de vista de la implementación tiene desventajas obvias:

• la necesidad de refinar el diagrama de Helm, lo que complica aún más su lectura;
• Solo uno que haya implementado el servicio puede usarlo;
• debe recordar sincronizarlo con el directorio local con el código y confirmar en Git.

2. Telepresencia

El proyecto de telepresencia se conoce desde hace bastante tiempo, pero en la práctica lo intentó con nosotros, como dicen, "no llegó a nuestras manos". Sin embargo, la demanda ha hecho su trabajo y ahora nos complace compartir experiencias que pueden ser útiles para los lectores de nuestro blog, especialmente porque todavía no había otros materiales sobre Telepresencia en el centro.

En resumen, no fue tan aterrador. Todas las acciones que requieren ejecución por parte del desarrollador, las colocamos en el archivo de texto del Helm-chart, llamado NOTES.txt . Por lo tanto, el desarrollador después de implementar el servicio en Kubernetes ve las instrucciones para iniciar el entorno de desarrollo local en el registro de trabajo 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 ######################################################################### 

No nos detendremos en los pasos descritos en este manual ... excepto el último. ¿Qué sucede durante el lanzamiento de Telepresence?

Trabajar con telepresencia

Al inicio (mediante el último comando especificado en las instrucciones anteriores) establecemos:

• espacio de nombres (espacio de nombres) en el que se inicia el microservicio;
• los nombres de la implementación y el contenedor que queremos penetrar.

Los argumentos restantes son opcionales. Si nuestro servicio interactúa con la API de Kubernetes y se crea una cuenta de servicio para ello, necesitamos montar los certificados / tokens en nuestro escritorio. Para hacer esto, use la opción --mount=true (o --mount=/dst_path ), que montará la raíz (/) desde el contenedor en Kubernetes a nuestro escritorio. Después de eso, podemos (dependiendo del sistema operativo y la forma en que se inicia la aplicación) usar las "claves" del clúster.

Primero, considere la opción de inicio de aplicaciones más versátil: en el contenedor Docker. Para hacer esto, use el --docker-run y monte el directorio con el código en el contenedor: -v `pwd`:/app

Tenga en cuenta que esto implica comenzar desde el directorio con el proyecto. El código de la aplicación se montará en el directorio /app en el contenedor.

Siguiente: -v /tmp/app/var/run/secrets:/var/run/secrets - para montar el directorio con el certificado / token en el contenedor.

Finalmente, esta opción es seguida por la imagen en la que se iniciará la aplicación. NB : ¡Al construir una imagen, debe especificar CMD o ENTRYPOINT !

¿Qué pasará después?

• En Kubernetes, para la implementación especificada, el número de réplicas se cambiará a 0. En su lugar, se lanzará una nueva implementación, con el contenedor de fondo reemplazado.
• En el escritorio, se iniciarán 2 contenedores: el primero, con Telepresencia (enviará solicitudes de proxy a / para Kubernetes), el segundo, con la aplicación en desarrollo.
• Si exec'nitsya está en el contenedor con la aplicación, tendremos acceso a todas las variables ENV pasadas por Helm durante la implementación, así como a todos los servicios disponibles. Todo lo que queda es editar el código en su IDE favorito y disfrutar del resultado.
• Al final del trabajo, es suficiente simplemente cerrar el terminal donde se está ejecutando Telepresence (finalizar la sesión usando Ctrl + C), los contenedores Docker se detendrán en el escritorio y todo volverá a su estado original en Kubernetes. Todo lo que queda es comprometerse, emitir el MR y pasarlo a revisión / fusión / ... (dependiendo de sus flujos de trabajo).

Si no queremos ejecutar la aplicación en un contenedor Docker, por ejemplo, no la desarrollamos en PHP, sino en Go, y aún la recopilamos localmente, lanzar Telepresence será aún más fácil:

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

Si la aplicación accede a la API de Kubernetes, deberá montar el directorio con las claves . Para Linux, hay una utilidad de prueba :

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

Después de iniciar Telepresence sin la opción --docker-run , todas las variables de entorno estarán disponibles en el terminal actual, por lo que debe iniciar la aplicación en él.

Nota : cuando utilice, por ejemplo, PHP, debe recordar desactivar varios op_cache, apc y otros aceleradores para el desarrollo; de lo contrario, editar el código no producirá el resultado deseado.

Resumen

El desarrollo local con Kubernetes es un problema cuya necesidad de solución está creciendo en proporción a la difusión de esta plataforma. Después de haber recibido solicitudes relevantes de los desarrolladores (de nuestros clientes), comenzamos a resolverlas con los primeros medios disponibles, que, sin embargo, no demostraron su valía a larga distancia. Afortunadamente, esto se ha vuelto obvio no solo ahora y no solo para nosotros, por lo tanto, ya han aparecido medios más adecuados en el mundo, y Telepresence es el más famoso de ellos (por cierto, todavía hay un skaffold de Google). Nuestra experiencia en su uso no es tan buena, pero ya da razones para recomendar "colegas". ¡Pruébelo!

PS

Otros del ciclo de consejos y trucos de K8s:

• " Herramientas para desarrolladores de aplicaciones que se ejecutan en Kubernetes ";
• Consejos y trucos de Kubernetes: páginas de error personalizadas en NGINX Ingress ;
• " Transferencia de recursos que trabajan en un clúster a la gestión de Helm 2 ";
• " Sobre la asignación de nodos y la carga en la aplicación web ";
• " Acceso a sitios de desarrollo ";
• " Acelerar el arranque de grandes bases de datos " .