Hasta ahora, hemos realizado publicaciones en las que hemos visto a nuestras aplicaciones ejecutándose en un clúster de Kubernetes instalado en nuestra computadora personal. Como ejemplo: Orchestrating Collections of Service with Kubernetes.
En el mismo camino, podemos ver a la aplicación ofrecida en la sección de descarga.
Previamente, debemos descargar el código o clonarlo e indicarle a nuestro archivo hosts cual es la dirección IP del dominio que hemos configurado. Despueś, en nuestro repositorio local, nos posicionamos en la rama denominada beforegooglecloud y ejecutamos el comando indicado a continuación.
skaffold dev
La aplicación se ejecutará en un Cluster de K8s instalado en nuestro ordenador personal.
Vamos a visitar nuestro dominio, el cual hemos configurado dentro de nuestro archivo hosts, proporcionando en la URL una ruta definida en la API con la ruta /api/users/currentuser. En consecuencia, veremos un mensaje que dice ‘Your connection is not private again’.
Esto se debe a que, de manera predeterminada, Ingress-nginx es un servidor web que intentará usar una conexión HTTPS. Desafortunadamente, por defecto, usa lo que se llama un certificado de autofirma. Para resumir, Chrome no confía en los servidores que usan certificados autofirmados. Sin embargo, para estas situaciones hay una solución que permite continuar a pesar del mensaje bloqueante. Simplemente debemos realizar un clic en la ventana del navegador y escribir la palabra thisisunsafe , entonces el navegador le permitirá visitar la página.
Si tenemos muchos pods diferentes ejecutándose dentro de nuestro clúster local y estamos en una computadora antigua, esta máquina comenzará a ralentizarse.
Como solución, podemos crear el entorno de desarrollo a través de Google Cloud y evitar esta sobrecarga en nuestro ordenador personal.
Skaffold realmente será la herramienta que nos permitirá configurar todo en Google Cloud muy fácilmente. En realidad, esta herramienta fue desarrollada por equipos de Google, por lo que Skaffold tiene una integración muy estrecha con Google Cloud.
Esta herramienta no sólo creará todos nuestros diferentes servicios, Deployments y demás, sino que también se encargará de manejar los cambios que realicemos en nuestro proyecto. Debemos saber que hay dos tipos de cambios que podemos realizar en un archivo o proyecto.
Primeramente, si observamos el archivo de configuración de Skaffold, la sección de sincronización define un patrón sobre la ubicación de una lista de archivos.
sync: manual: -src: 'src/**/*.ts'
Cada vez que realicemos un cambio en un archivo cuya ubicación coincida con la definida en ese patrón, simplemente cogeremos ese archivo y lo sincronizaremos con el pod correspondiente dentro de nuestro clúster.
Entonces, en este escenario, no estaremos reconstruyendo ninguna imagen ni nada por el estilo. Solo estaremos cogiendo el archivo con cambios y colocándolo directamente en un pod.
Al realizar un cambio en un archivo que no figura en la sección de sincronización, por ejemplo, package.json, este cambio no se reflejará en el Pod.
Cada vez que realicemos un cambio en el archivo package.json, será una señal de que queremos reconstruir completamente nuestra imagen y luego actualizar le correspondiente Deployment dentro de nuestro clúster.
Skaffold lo detectará y agregará un paso adicional. Se comunicará con un servicio que se ejecuta dentro de Google Cloud llamado Google Cloud Build.
Este servicio tiene que ver con la creación de imágenes de Docker, por lo que Skaffold tomará todo nuestro código fuente de nuestro proyecto y lo cargará en Google Cloud Build junto con el archivo de Docker de ese proyecto específico. Luego, en Google Cloud Build, algún proceso creará la imagen por nosotros.
La razón principal por la que la imagen se crea en Google Cloud es para poder disminuir la cantidad de recursos que se consumen en nuestro ordenador personal. Además, crear la imagen será mucho más rápido porque los servidores de Google Cloud tienen conexiones a Internet extremadamente rápidas.
Primero debemos crear una cuenta en Google Cloud. Si es la primera vez que lo hacemos, obtendremos $ 300 en crédito gratis.
Después de crear el proyecto, la sección de Kubernetes Engine nos permitirá crear un cluster.
Al final del proceso podremos ver todas las características que hemos definido en la creación del cluster.
En nuestro ordenador personal tenemos un cluster de Kubernetes ejecutándose.
En un segundo plano, kubectl usa lo que se denomina un contexto. kubectl lo puede considerar esencialmente como configuraciones de conexión diferente. El contexto puede enumerar algunas credenciales de autorización, algunos usuarios y algunas direcciones IP. Mucha información diferente para decirle a kubectl cómo conectar este contexto o contextos a diferentes clústeres que existen en el mundo.
En este momento, nos estamos conectando a nuestro clúster local a través de un contexto que se creó cuando instalamos por primera vez Docker para Windows, Docker para Mac o Docker para GNU/LINUX en nuestro ordenador.
Pero para seguir avanzando, ahora debemos conectarnos al clúster que hemos creado en la nube. Es hora de agregar un nuevo contexto que le indicará a kubectl cómo conectarse al clúster que acabamos de crear en Google Cloud.
La forma más fácil, para conectarse al cluster, es instalar una herramienta llamada Google Cloud SDK. Esta es una herramienta de línea de comandos que podemos usar para interactuar con Google Cloud automáticamente. El SDK de Google Cloud hace un montón de cosas diferentes, pero una cosa que hace es crear estos diferentes contextos por nosotros automáticamente y actualizar nuestra máquina local enseñándole cómo conectarse a los clústeres que estamos creando en Google Cloud.
Entonces, ahora que tenemos Google Cloud SDK instalado, primero vamos a iniciar sesión en Google Cloud.
gcloud auth login
Después de eso, ejecutaremos otro comando que inicializará el SDK de Google Cloud y le informará un poco sobre el proyecto que estamos tratando de poner en marcha.
gcloud init
Cuando el proceso nos pregunte por el nombre del proyecto, podremos averiguar su nombre tal y como se muestra en la siguiente imagen. En nuestro caso: ticketing-dev-361710
En función de si disponemos o no de suficientes recursos en nuestro ordenador personal tendremos que tomar una decisión.
En nuestro caso hemos optado por la segunda opción, entonces ejecutaremos el comando:
gcloud container cluster get-credentials ticketing-dev
Debo recordar que cuando hemos creado el cluster de Kubernetes le hemos asignado el mismo nombre que al proyecto.
Como podemos ver en la siguiente imagen, ahora en mi ordenador hay dos contextos. El contexto del clúster local y el contexto del clúster creado en Google Cloud. Entonces en cualquier momento podremos seleccionar el que queramos usar.
kubectl config get-contexts kubectl config use-context [context name]
Entonces, de vuelta en mi consola de Google Cloud, vamos a ir al menú en la parte superior izquierda. Luego nos desplazaremos bastante hacia abajo hasta que encontremos en el menú la opción de Cloud Build. Seleccionaremos en el menú Cloud Build y luego el botón Habilitar.
Y eso debería ser todo.
Para que podamos apreciar en detalle los cambios que debemos implementar hemos creado una rama llamada googlecloudcontext. Vamos a decirle a Skaffold que queremos usar Google Cloud Build.
Debemos especificar el id del proyecto y el nombre de la imagen que Google Cloud Build asignará a la misma cuando se construya.
Los formatos que usa Google Cloud Build para decidir cómo llamar a una imagen es siempre el mismo. Siempre será us.gcr.io/nombre-proyecto. Así que vamos a indicar el nombre del del proyecto y luego pondremos el nombre de nuestro directorio de proyecto.
Por otro lado, también debemos comentar el código que hace referencia a la imagen cuando trabajamos en nuestro contexto local y actualizar el Deployment del servicio auth con el nuevo nombre de la imagen.
Configurando ingress-nginx en nuestro cluster de Google Cloud.
En la documentación oficial podemos seguir los pasos a seguir según el sistema operativo que tengamos, en nuestro caso GNU/LINU. Por tanto nosotros hablaremos sobre Minikube. Veremos que hay un poco de configuración adicional que tenemos que aplicar si estamos usando Google Cloud.
Antes de empezar comprobaremos que tenemos seleccionado el contexto de Google Cloud:
kubectl config get-contexts
Primero, nuestro usuario debe tener permisos cluster-admin en el clúster. Esto se puede hacer con el siguiente comando:
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user $(gcloud config get-value account)
Entonces, ingress controller puede ser instalado de esta forma:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.1/deploy/static/provider/cloud/deploy.yaml
Así que los comandos que acabamos de ejecutar crearon dos cosas por nosotros. Primero fue creado un Ingress Controller, que es lo que se ejecuta dentro de nuestro clúster y que tiene algunas de nuestras reglas de enrutamiento vinculadas. Pero también creó algo más llamado Load Balancer.
Load Balancer está vinculado directamente a Google Cloud. Es esencialmente un elemento de Google Cloud que se ejecuta completamente fuera de nuestro clúster. Entonces, cada vez que queramos conectarnos a nuestro clúster , realmente querremos intentar conectarnos a este Load Balancer.
El Load Balancer tiene asignada una dirección IP, tal y como vemos en la siguiente imagen.
Esa es la dirección IP que le tenemos que indicar a nuestro archivo de hosts para poder conectarnos al dominio ticketing.dev definido en nuestro proyecto.
Vamos a reiniciar Skaffold en nuestra terminal. Tan pronto como lo hagamos, Skaffold debería intentar crear la imagen, que indicamos dentro de nuestro archivo de configuración, usando Google Cloud Build. Luego cogerá nuestra auth Deployment y el archivo de configuración del Ingress Service y los aplicará a nuestro clúster remoto.
skaffold run
De hecho, deberíamos poder ver el proceso de creación de la imagen si saltamos al panel de control de Google Cloud Build rápidamente.
Cada imagen se crea y luego se envía a nuestro repositorio de imágenes en Google Cloud. Entonces, todas estas imágenes ahora se envían a este repositorio, ya no estamos haciendo uso de Docker Hub.
Ahora, en teoría, a medida que comenzamos a agregar más módulos, más implementaciones, u otras cosas a nuestro clúster, ya no se va a ralentizar nuestra máquina local porque todo eso va a ser creado en la máquina remota.
Finally we are going to try one more time to visit our URL or our domain that we had set up within our host and we will try to reach our users current user path again.
Finalmente, intentaremos una vez más visitar nuestra URL o nuestro dominio que habíamos configurado dentro de nuestro host, e intentaremos llegar nuevamente a la ruta del usuario actual. Veremos un mensaje que dirá ‘Tu conexión no es privada de nuevo’. Luego, podemos escribir thisisunsafe en cualquier lugar de la ventana y el navegador le permitirá visitar la página.
Perfecto, esto es asombroso.
Manejo de errores en los Microservicios.
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!