Bien hasta ahora hemos estado haciendo todo en nuestro entorno local de pruebas, veamos como podemos trabajar con un entorno en cloud desde nuestro terminal con kubectl

Kubectl es una herramienta de linea de comandos para trabajar con cualquier tipo de cluster de kubernetes, en nuestro caso nos hemos creado un minientorno de pruebas usando minikube. Al hacer la instalación de minikube y kubectl automáticamente se configura para que estemos usando ese entorno por defecto (el de minikube) pero nosotros podemos cambiarlo en cualquier comento.

Para ver la configuración que tenemos actualmente podemos ejecutar el comando

kubectl config view

Esto nos debe mostrar algo similar a

En esta configuración tenemos 4 cosas importantes:

• clusters: Información de todos los cluster que tenemos configurados, con su certificado, su dirección o hostname  y el propio nombre que le hemos dado al cluster en cuestión
• contexts: Todos los contextos que tenemos configurados. Esto puede parecer redundante, pero no es así, realmente nosotros trabajamos a través de los contextos y estos apuntan a un cluster en específico. Esto es así porque podemos tener distintos usuarios de acceso según el contexto y podemos querer configurar un namespace diferente del de por defecto (namespace es solo una separación lógica de objetos dentro de kubernetes)
• current-context: El contexto seleccionado actualmente
• users: Usuarios con sus nombres y sus métodos de acceso.

Estos serían los puntos relevantes que tenemos que tener en  cuenta a la hora de intentar conectarnos a otro cluster.

Como tal kubectl nos provee de los comandos necesarios para cambiar el contexto, ver el contexto actual, configurar nuevo cluster, cualquier cosa que necesitemos realmente. Por ejemplo:

kubectl config current-context

Estos serían todos los comandos bajo config

Visto más o menos que nos ofrece kubectl para seleccionar una configuración u otra veamos como hacer despliegue de kubernetes en Google

Hacia Google Cloud

Google cloud es el servicio cloud que mejor funciona con kubernetes (nació allí por lo que tiene sentido no?). En este sentido es el servicio con el que más rápido podremos configurar nuestro cluster de kubernetes, vamos a por ello:

Primero sería darnos de alta en google cloud, si no tenéis cuenta sería el momento de hacerlo. Una vez que tengamos nuestra cuenta lo que debemos hacer es instalar la linea de comandos de google (gcloud). Buscar en internet como realizar esta instalación en el caso de que no uséis brew para instalar paquetes, si lo tenéis solo es necesario hacer

brew install google-cloud-sdk

Para empezar, lo primero que tenemos que hacer una vez instalado es iniciar la configuración de nuestro servicio:

gcloud init

Con este estableceremos una configuración nueva o seleccionaremos una existente si ya la tenemos, aquí cada uno puede configurar lo que quiera y como quiera. Como tal yo tengo un proyecto creado que es: kuber-project-example

Si en algún caso os falla cualquier comando, puede ser por la versión que ha instalada brew del SDK, seguir estos pasos:

• Cambiar versión de python de la console

export CLOUDSDK_PYTHON=python2

• Actualizar los componentes

gcloud components update

Con esto ya os funcionaria todo (o debería). Continuemos:

Ahora lo que haremos será seleccionar ese proyecto como base para el resto de comandos

gcloud config set project kuber-project-example

Y también es necesaria tener una región de computo configurada

gcloud config set compute/zone us-west1-a

En este punto puede que os pida seleccionar una cuenta de facturación (por si te vuelves loco creando cosas jajajajaja). Esto lo más fácil es irse a la consola de google, irse al menú de facturación y seleccionar una de las cuentas (o crearla)

Una vez seleccionada una cuenta en la consola de google, volvemos a ejecutar el comando, nos pedirá habilitar la API de "compute.googleapis.com", la habilitamos(tardará un poco) y ya nos confirmará que la configuración se ha actualizado o añadido

A continuación creamos nuestro cluster de kubernetes que también puede que nos de error porque necesitamos habilitar el servicio de contenedores en nuestro proyecto

gcloud container clusters create ninja-cluster --num-nodes=1

Por lo que si nos aparece este error habilitaremos ese servicio también

gcloud services enable container.googleapis.com

Y ya si todo va bien y no nos pide nada más ejecutamos de nuevo

gcloud container clusters create ninja-cluster --num-nodes=1

Y ya cuando termine el proceso nos confirmará los datos pertinentes según lo que hayamos solicitado

Ahora lo siguiente es configurar nuestro kubectl local para que apunte a este cluster.... que lo podíamos hacer a mano, pero en esta caso google nos provee de un comando mágico que nos añade la configuración a la kube config

gcloud container clusters get-credentials ninja-cluster

Básicamente es solicitarle las credenciales sobre un cluster en específico y listo

Veamos la config

kubectl config view

Como vemos ahora tenemos otro cluster, otro contexto y otro usuario y si nos fijamos en nuestro current-context ya no estamos en minikube si no en el de google

Veamos que tenemos ahora con nuestro comando para ver los nodos

kubectl get nodes

Ahora tenemos nuestro nodo de cluster de kubernetes que le hemos indicado que cree. Probemos ahora a crear un deploy, usaremos el de ejemplo de kubernetes que es una imagen básica de google

kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0

Y comprobemos que nos ha creado

Como tal podemos ejecutar en este caso todos los comandos que hemos ido viendo hasta ahora. Añadamos un service para poder acceder a nuestro deploy, en este caso vamos a añadir un service de tipo LoadBalancer (por fin jejejejje) que esto lo que hará será que google cloud nos creará un balanceador de carga y accederemos a nuestro pod desde él.

Una vez que tengamos ip externa

Ya deberíamos poder acceder a nuestro pod, ojo en este caso tenemos que acceder por IP y al puerto 8080  (si habéis usado mi ejemplo porque el puerto del comando ha sido el 8080)

En este caso podemos comprobar como de facil es trabajar con kubernetes en google cloud y la configuración no es complicada. Si queremos ver que realmente no es mentira podemos irnos a la consola de kubernetes y ver que es lo que tenemos creado

Y ya para aseguraros de que no miento podemos ver que nos ha creado también un balanceador de carga apuntando a nuestro cluster

Creo que queda más o menos claro como trabajar con la cloud de google y kubernetes, que es realmente sencillo. Con esto ya podríamos crear infraestructuras tan complejas como quisiéramos que con unos cuantos comandos ya se encarga google de hacerte la magia.

Y hasta aquí la parte de google cloud (NO SE OS OLVIDE BORRAR LAS COSAS DE GOOGLEEEEEE CLOUUUUD JEJEJJEJEJE)

AWS

Para hacerlo en aws...... pues realmente es más fácil que lo veáis directamente de la documentación porque es realmente igual de trivial, lo único que nos ofrece 2 opciones:

1. Usar eksctl: Es una herramienta de línea de comandos específica de Amazon EKS (servicio de kubernetes de AWS) que es bastante fácil de usar y a su vez nos da la opción de crear nuestro cluster con Fargate o no. Ver esta opción
2. Usar el CLI de AWS y la consola de administración: Aquí se hace uso de CloudFormation otro servicio interesante de AWS que nos facilita la orquestación de algunas cosas, esta opción es algo más manual porque es necesario manejar algunos permisos de IAM y cosas así pero se ve algo más de que es lo que estamos montando. Ver esta opción

Ambas opciones realmente son sencillas y para probar son más que suficientes, recomiendo que intentar cualquiera de ellas y ver que es realmente lo que se monta en la consola de AWS (BORRARLOOOOOO que al final cobran por tener el espacio en uso indefinidamente tras el año gratuito)

Bueno y hasta aquí lo que veremos de Docker y Kubernetes por el momento, han sido un montón de posts al respecto espero que os hayan parecido interesantes, se que nos faltaría ver como ser haría con Azure pero realmente es una plataforma que no me gusta mucho (es personal ojo no digo que sea mala ni nada por el estilo) por lo que no lo veremos aquí ni lo comentare, seguro que existe muy buena documentación al respecto para quien esté interesado.

Clausuro esta serie de posts pero no descarto en ningún momento plantear más cosas sobre kubernetes y docker en un futuro cercano, sin mucho más que deciros NOS VEMOS EN EL SIGUIENTEEEEEEE un abraazoooooooo

Hasta ahora hemos planteado nuestro entorno pensando solo en una o varías aplicaciones que realmente funcionan de manera autonóma, es decir, si pensamos en nuestro POD con el fork del juego de SUPER MARIO vemos como realmente no tiene comunicación con nada más y en un primer momento no la necesita (o nosotros a la hora de usarlo tampoco).

Ahora propongo otro escenario, como pudiera ser que tenemos un pequeño portal donde el usuario necesita hacer login antes de poder acceder a nuestro juego. Si lo planteamos como si realmente fueran servicios distintos tendriamos por ejemplo:

• Lo que es el front, que no sería más que una miniweb con un login y a lo mejor una lista de posibles juegos.
• Puede que un microservicio que gestionaría los usuarios y nos permitiría hacer login o un microservicio que fuera realmente la API con la lista de juegos disponibles
• Y por dejarlo simple un microservicio que sería el fork de nuestro juego de SUPER MARIO y otro que puede ser un fork del SONIC por ejemplo.

Es posible que este escenario no tenga ningún sentido ojo, por el tema de la autenticación y demás, es solo para que entendamos que tendríamos varios microservicios distintos que gestionar. Esto con los objetos y configuraciones que hemos visto hasta ahora puede que lo pudieramos conseguir si tenemos un objeto de tipo SERVICE:NODEPORT por cada microservicio y el microservicio de front sepa donde esta todo (superfeo) o a lo mejor hacerlo con subdominios y con DNS o cosas así (se me están ocurriendo sobre la marcha pueden no tener sentido). El caso es que a no ser que lo gestionaramos en un servicio cloud que nos pudiera hacer el enrutamiento no tenemos una forma clara de hacerlo. Bueno pues para esto tenemos en kubernetes el objeto de tipo INGRESS.

Este objeto lo que hace es definir como se deben gestionar las peticiones que vienen desde fuera de nuestro cluster, es decir, hacia donde debe redireccionar cada petición. Veamos una diagrama de la documentación oficial donde creo yo que se explica bastante bien cual es la tarea de nuestro INGRESS

Este diagrama que vemos resume un escenario típico que tendríamos en producción:

1. El cliente envía una petición que lo primero que hace es llegar al balanceador de carga de nuestro cloud. Este balanceador de carga está manejado por un INGRESS CONTROLLER que es el que se encarga de asegurarse de que se cumplan las reglas que definimos en nuestro objeto INGRESS
2. Según las reglas que hayamos definido nuestro INGRESS CONTROLLER decide a que servicio (objeto de tipo SERVICE) de nuestro cluster debe enviar la petición en cuestión
3. Por último este service envía la petición al primero de sus PODS que este disponible

Un detalle que no hemos dejado claro todavía es que las reglas que definimos en el objeto de tipo INGRESS no son manejadas realmente por kubernetes, si no que necesitamos de un controlador externo (INGRESS CONTROLLER para que las gestione). Como tal existen opciones de configuración de ingress disponibles para NGINX, HAPROXY, TRAEFIK... para la mayoría de los servicios de proxy, uno de los más típicos es el de nginx. En un entorno en cloud seria necesario tener un POD con nginx que sería nuestro INGRESS CONTROLLER.

Comentar que el entorno completo en cloud con su loadbalancer, su ingress y demás no lo veremos de momento, en la documentación oficial viene todo lo necesario creo yo, por ahora con motivos puramente de prueba o académicos usaremos la opción que nos provee minikube para tener nuestro propio INGRESS CONTROLLER.

Veamos lo primero un ejemplo de objeto tipo INGRESS, como no parece existir de momento comando dry-run para verlo, nos tocará copiar un ejemplo como este

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mario-ingress
spec:
  rules:
  - host: mariogame.fulldev.ninja
    http:
      paths:
      - path: /mario
        pathType: Prefix
        backend:
          service:
            name: mario-service
            port:
              number: 8000
  defaultBackend:
    service:
      name: default-service
      port:
        number: 8001

Creo que es bastante intuitivo lo que hace cada cosa pero hablemos un poco en detalle de algunos puntos:

• apiVersion: networking.k8s.io/v1: Aquí si nos fijamos tenemos un cambio respecto a lo que soliamos indicar en el resto de objetos, en este caso debemos especificar que pertenece a la api de networking de kubernetes.
• spec: Como siempre dentro de spec tenemos siempre la definición de lo que queremos hacer.
• rules: Dentro de rules como su propio nombre indica es donde definiremos las reglas que queremos usar dentro de nuestro ingress
  • host: hostname al cual enviará el cliente las peticiones
  • http -> paths: Estos serán los paths que usará nuestro ingress controller para redireccionar la petición a un servicio o a otro.
  • pathType: Como se filtrarán los paths, el caso más típico es el de Prefix que buscará coincidencias en el path completo separandolo por /
  • backend -> service: El servicio que debe responder al path indicado
• defaultBackend: Aquí definimos el servicio por defecto en caso de que no se encontraran coincidencias en el resto de reglas

Como siempre existen muchas más reglas pero estas son las básicas y que me han parecido relevantes para empezar (vuelvo a recomendar leer la documentación oficial)

Una vez visto lo básico, veamos como configurar un ingress controller en minikube (recordemos que en un entorno cloud tenemos que tener nuestro propio pod que haga de controller).
Para ello lo primero es hablar de los addons de minikube. Minikube dispone de ciertos extras que podemos habilitar según nos insterese, uno de ellos es el ingress controller, este ingress que nos provee minikube es una propia intancia de nginx preparada para este uso y que en este caso no podremos ver como uno de los pods que hemos estado viendo hasta ahora (en un momento veremos lo que pasa)

OJO esta parte solo funciona si has iniciado minikube con algún gestor de máquinas virtuales como virtualbox doc oficial. Ver al final del post el apartodo INICIAR MINIKUBE CON VIRTUALBOX o también es posible jugar con este playground

Primero veamos la lista de addons, para ello solo es necesario que ejecutemos este comando:

minikube addons list

Esto nos mostrará una lista de los addons disponibles indicándonos si están habilitados o no (algunos estarán habilitados por defecto según nuestra instalación)

Si os fijáis uno de los addons que aparecen es el de ingress, habilitemoslo

minikube addons enable ingress

Con esto ya tendríamos habilitado nuestro ingress controller con nginx, pero como he comentado no nos aparece como un pod normal en este entorno.

Minikube en este caso lo crea como un pod propio del sistema de minikube por lo que para verlo tendríamos que listar los pods que pertenecen a minikube, para ello

kubectl get pods -n kube-system

Y esto nos listará todos los pods que va creando minikube

Si nos fijamos tenemos uno en específico que se llama nginx-controller.

Bien con esto ya tendríamos nuestro ingress controller, ahora vamos a trabajar con los mismos ejemplos que la documentación oficial (el de mario da algunos problemas con los direccionamientos y por no entrenernos), primero el deploy

example-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: web
    spec:
      containers:
      - image: gcr.io/google-samples/hello-app:1.0
        name: hello-app
        resources: {}
status: {}

El service

mario-service.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {}

Hacemos los create pertinentes que ya hemos visto anteriormente

kubectl create -f example-deploy.yaml
kubectl create -f example-service.yaml

Y por último preparamos nuestro ingress

example-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
    - host: hello-world.info
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 8080

Y creamos nuestro ingress

kubectl create -f example-ingress.yaml

Esto nos creará nuestro ingress tardará un poco en tenerlo todo (fijaos en el ADDRESS)

Como véis tenemos nuestro ingress creado, un detalle para que no nos alarmemos es el warning que aparece. Nosotros en nuestra definición de ingress hemos definido el uso de la api de kubernetes v1, lo que pasa es que el comando get ingress comprueba la existencia de ingress desde la primera versión que tiene disponible, por eso el aviso, no quiere decir que nuestra definición de ingress esté realmente mal.

Bien ahora que ya tenemos nuestro ingress desplegado veamos como podemos acceder a el. La primera intención puede ser intentar acceder por la IP, pero si lo intentamos veremos un 404 de nginx. Esto no es del todo malo, comprobamos que tenemos comunicación con nuestro ingress controller

Para el que no sepa realmente como funcionan los proxys como nginx, lo que hacen normalmente es esperar que el acceso se produzca con un nombre de host específico, es posible que tengamos varios hostname distintos bajo el mismo nginx. En nuestro mismo caso podemos querer tener otro hostname para otro servicio que bye-world.info

Entonces lo que tenemos que hacer es modificar nuestra definición local de redirecciones IP/HOSTNAME, en mi caso lo tengo que hacer en el fichero /etc/hosts

Una vez modificado si accedemos al hostname en cuestión veremos como accedemos sin problema al servicio pertinente

Con esto tendríamos funcionando un ingress controller que puede redireccionar multiples peticiones a distintos servicios basandonse en el nombre del hosts o un path (en nuestro hemos puesto / pero podría ser cualquier otro)

Con esto habríamos visto lo básico para trabajar con ingress, el resto ya es revisar la documentación y ver las distintas opciones que nos ofrece kubernetes para cumplir con nuestras necesidades, sin mucho más terminamos este post, nos vemos en el siguiente un abrazooooorrrr

INICIAR MINIKUBE CON VIRTUALBOX

Esta es una sección para los que hayan estado jugando con el propio driver de docker (el que nos provee docker-desktop) para probar kubernetes que al final llega un punto en el que algunas cosas no funcionan de ninguna forma (depende de las versiones, van incluyendo poco a poco funcionalidades compatibles).

Lo primero que tenemos que hacer es borrar minikube de nuestro entorno, recomiendo borrar todo y hacer una instalación limpia para ello lo primero es:

minikube delete --all --purge

Esto nos borra todo lo que tenemos de minikube

A continuación instalamos virtualbox -> Downlaads

Una vez instalado todo lo que hacemos es arrancar minikube con el driver de virtualbox

minikube start --driver=virtualbox

Esto tardara un rato hasta crea las máquinas virtuales pertinentes

Con esto ya tendriamos arrancado nuestro minikube con un cluster de maquines virtuales. Well done!!!

Hasta ahora en los post anteriores hemos estado trabajando con solo un POD o una instancia de cada POD. Pero para realmente tener ese escenario no necesitamos kubernetes podiamos hacerlo igual con docker o con docker-conpose. Veamos ahora realmente algo de lo que nos ofrece realmente kubernetes que es la posibilidad de gestionar multiples instancias de un mismo POD.

Esto lo hace kubernetes posible haciendo uso de los objetos con tipo Deployment, es un objeto muy similar al POD con el que hemos estado trabajando solo que nos permite indicarle cuantas instancias queremos de un mismo pod. Para ver un ejemplo podemos hacer, como siempre, uso de un comando dry-run:

kubectl create deployment mario-deploy --image=pengbai/docker-supermario:latest --port=8080 --dry-run=client -o yaml > mario-deployment.yaml

Esto nos creará un documento similar a este:

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: mario-deploy
  name: mario-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mario-deploy
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: mario-deploy
    spec:
      containers:
      - image: pengbai/docker-supermario:latest
        name: docker-supermario
        ports:
        - containerPort: 8080
        resources: {}
status: {}

Veamos un poco que es lo que tenemos aquí:

• metadata: Ya hemos visto en el resto de posts que es esto. Contiene labels identificativos que nos pueden ser utiles para hacer referencia desde otros objetos del cluster de kubernetes. Y también tiene su name para identificar este objeto como tal.

Dentro del spec, que recordemos que es donde realmente se define la magia tenemos nuevo:

• replicas: Creo que es autoexplicativo. Podemos indicar la cantidad de instancias que queremos de un tipo de POD.
• selector: Al igual que pasaba con el objeto de tipo service, dentro de este selector indicamos los labels que tienen los pods que debe gestionar este objeto de tipo deployment.
• template: Aquí es donde definimos el POD en cuestión que tiene que usar como plantilla, es decir, usando un objeto de tipo deployment ya no es necesario tener por otro lado un objeto de tipo POD, puede estar definido dentro de esta template (si los comparamos la definión debe ser muy similar)

Una vez repasadas más o menos las diferencias veamos que pasa, cambiemos la cantidad de replicas a 2 y ejecutemos el típico create

Si comprobamos los pods que tenemos ahora veremos algo distinto

Vemos como ahora ahora los pods se crean de otra manera, contienen el nombre del objeto deploy y además una conjunto alfanumerico, eso convierte el nombre del pod un identificador único. Además de comprobar los pods, ahora podemos usar otro comando específico para deployments

kubectl get deployments

Que como podemos comprar nos muestra cuando pods tiene el deployment, cuandos estan activos y cuantos estan actualizados con la última versión (ya hablaremos de esto). Si ahora nosotros eliminamos uno de los pods, veremos como automáticamente nos crea uno nuevo.

Kubernetes, como siempre, en su ciclo de vida (llamada bucle de reconciliación) comprueba que el estado de los objetos que están en funcionamiento cumple con sus definiones/plantillas y si no, pues actua en consecuencia, en este caso con la creación de un nuevo POD usando la plantilla que tiene el objeto de tipo deployment.

Pero claro ahora mismo hemos definido de antemano el número de replicas que queremos de un mismo POD dentro de la plantilla de deploy, pero... ¿y si tengo que escalar mi aplicación ahora mismo entando en producción? pues para ello tenemos varias opciones:

• Editar el estado actual de nuestro deploy en la API

kubectl edit deploy mario-deploy

Nos aparecerá la definición que está actualmente en la API de kubernetes, lo que podemos hacer es editar el número de réplicas y esto nos debería escalar el número de instancias de pods

• Otra forma es usando el comando scale

kubectl scale deployment mario-deploy --replicas=3

En cualquiera de los 2 casos si comprobamos los pods que tenemos deberían haber aumentado

Y lo mismo podemos hacer para reducirlos, si disminuimos el número de replicas nos eliminará el número de instancias activas

kubectl scale deployment mario-deploy --replicas=1

Comprobamos que empieza con la eliminación de 2 de las instancias y al final nos deja solo con una

Actualizando versiones de nuestra aplicación y rollback

Todo lo que hemos visto en este post está muy bien, pero normalmente ninguna aplicación se mantiene en la misma versión para siempre, como tal, es necesario actualizarla en algún momento, en esta sección veremos como cambiar la versión de nuestra imagen y también como hacer rollback en caso de que algo falle. Todo esto es realmente sencillo gracias a kubernetes.

Primero de todo vamos a seleccionar una imagen que tenga varias versiones, para no complicarnos creando nosotros un contenedor específico me he decantado por usar la imagen oficial de NGINX, como se puede ver entre los tags de versiones tenemos dos que son fáciles de diferencias stable y latest

Primero creemos nuestro deployment con la imagen stable, para ello crearemos un fichero yaml con estos datos

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deploy
    spec:
      containers:
      - image: nginx:stable 
        name: nginx-pod 
        ports:
        - containerPort: 80
        resources: {}
status: {}

Como véis tenemos 2 replicas de la versión nginx:stable, ejecutemos el comando crear y comprobemos que pasa (recomiendo eliminar todo lo que hicimos anteriormente, recordar con kubectl delete ....)

kubectl create -f nginx-deploy.yaml

Ya tenemos nuestros 2 pods que hemos definido en el deploy, ahora comprobemos la versión con la que se han creado con el comando describe

kubectl describe deploy nginx-deploy

Si nos fijamos tenemos dentro de containers la imagen seleccionada que es nginx:stable, ahora veamos las opciones para actualizar de versión

1. Usar el comando apply
   Tenemos la posibilidad de actualizar la configuración actual de un objeto en kubernetes usando el comando apply, modificando nuestro fichero de deploy. Cambiemos la versión en nuestro fichero
   

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx-deploy
  name: nginx-deploy
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-deploy
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-deploy
    spec:
      containers:
      - image: nginx:latest 
        name: nginx-pod 
        ports:
        - containerPort: 80
        resources: {}
status: {}

Y ejecutemos el comando

kubectl apply -f nginx-deploy.yaml

Si ahora ejecutamos nuestros comandos get pods y describe veremos como tenemos otra versión ya desplegada.

2. Es posible, al igual que hicimos antes, usar el comando edit, para modificar el estado actual que está en la api de kubernetes (en teoría funciona pero a mi me da problemas, aviso por si acaso)

kubectl edit deploy nginx-deploy

3. Tenemos la opción de modificar directamente la imagen de un deployment con la opción set

kubectl set image deployments/nginx-deploy nginx-pod=nginx:latest

Este comando indicamos que modifique la imagen dentro del deployment/nginx-deploy de los pods con nombre nginx-pod usando la imagen nginx-latest. Si nos fijamos en nuestra definición de nuestro objeto deployment el nombre que yo le he puesto es el de nginx-pod

Si comprobaramos nuestros ya típicos get pods y describe otra vez veríamos lo siguiente

Otra vez de nuevo nos ha cambiado la versión correctamente.

Como tal tenemos otro comando para comprobar que la actualización ha ido correctamente que es el comando rollout

kubectl rollout status deployment nginx-deploy

Este comando nos confirma que la actualización ha ido correctamente.

Haciendo rollback

Ya hemos visto como actualizar pero... ¿y si todo se ha roto al actualizar y queremos volver atras? Pues en este caso es tan sencillo como...

kubectl rollout undo deployment nginx-deploy

Et voilá

Nuestra versión vuelve a ser la de nginx:stable. Creo que en este caso no tengo mucho más que decir, solo comentar que esto se podría automatizar con los healthchecks que vimos en post anteriores (revisar la doc oficial que yo no he entrado en tanto detalle de momento), esto han sido unos primeros pasos para ver como lo podemos hacer nosotros todo manualmente.

No me enrollo más, espero que os haya gustado este post con el escalado y el rollback de nuestras aplicaciones, sin mucho más nos vemos en el siguienteeeee un abrazoooor

En el post anterior ya incluimos el concepto de service, en este post explicaremos realmente lo que es.

Hasta ahora habíamos estado trabajando con objetos de tipo POD, si hacemos un poco de memoría o volvieramos a probar veriamos como no realmente no podíamos acceder realmente desde nuestro equipo a ningún contenedor a no ser que hicieramos algún mapeo externo de puertos o similar, pues bien para esto son los objetos de tipo de Service, estos objetos entre otras cosas nos permiten exponer hacía afuera los nodos del cluster que nosotros le indiquemos.

Conceptualmente puede ser algún similar a un nginx o por ejemplo si pensamos en cloud podría ser como un API Gateway de AWS (ojo que digo conceptualmente para que entendamos un poco cual es su función). Realmente el objetivo de un objeto service es proveer una dirección o forma estable de acceder a nuestros nodos del cluster, ya que cada vez que se levanten nuestros nodos pueden tener una dirección IP diferente, es más, usar un objeto service realmente no implica necesariamente que expongamos nuestros nodos, podemos simplemente crear una IP interna del cluster para acceder a un conjunto de nodos desde otros nodos, ya depende realmente de nuestras necesidades.

Veamos un ejemplo de configuración de un objeto de tipo service. Para ello lo más fácil es hacer lo mismo que hicimos cuando veiamos los pods, ejecutaremos un comando con el flag dry-run para que no haga nada.

kubectl expose pod/mario-test --port 8080 --type=NodePort --dry-run=client -o yaml > mario-service.yaml

Ya hablaremos sobre los tipos por el momento solo ejecutaremos el comando y abrimos el fichero que nos crea

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: mario-game
    run: mario-test
    tier: games
  name: mario-test
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: mario-game
    run: mario-test
    tier: games
  type: NodePort
status:
  loadBalancer: {}

Vemos como ahora la propiedad kind cambia y ahora es Service, pero hablemos un poco más en específico de lo que estamos viendo.

Primero de todo tenemos metadata, que como información relevante tiene:

• labels: Conjunto de clave valor que en un principio es meramente informativo y que podemos incluir los que queramos. Esto según el caso puede servir como identificador, por ejemplo, en mi caso tiene los mismos labels que mi pod, en vuestro caso puede contener otros si habéis puesto algo distinto en los labels. Podéis hacer la prueba eliminando el pod actual, modificando los labels del fichero pod que estéis usando, creando el pod de nuevo y ejecutando el comando dry-run de nuevo para ver como cambia
• name: El nombre con el que identificaremos el servicio

A continuación tenemos spec que al igual que con los pods es donde esta todo lo importante, es decir, lo que queremos crear realmente o que configuración debe llevar, veamoslo un poco en detalle:

• selector: Empezamos por este porque nos ayuda a saber donde apunta realmente el service. Si nos fijamos en su contenido debe tener lo mismo que los labels que tiene nuestro pod. Esto es porque realmente esta propiedad es la que se usa para filtrar y encontrar los pods en cuestión. Pensemos que realmente todo esto esta pensado para tener varias instancias del mismo pod, entonces como las identifica el service? Hace uso de los labels que le hemos puesto al pod y con eso filtra o busca los contenedores en cuestión.
• type: Como tal es posible crear 3 tipos de servicio.
  • Tipo ClusterIP: Nos proporcionaría una ip fija interna del cluster para todas las instancias de un mismo pod para que el resto de pods puedan hacer uso de ellos
  • Tipo NodePort: Expone hacia el exterior del cluster el conjunto de pods seleccionados.
  • Tipo LoadBalancer: Se usa realmente con kubernetes en producción en algún proveedor cloud que son capaces de hacer uso de esta configuración para integrarlo con sus balanceadores.
• ports: Parte muy importante, en este punto definimos los puertos por los que se puede acceder a nuestro contenedor a través del servicio (bueno y también el protocolo como veis):
  • port: Puerto interno del cluster por el que el resto de pods pueden acceder a la aplicación que se despliegue en el pod (suele coincidir con targetPort)
  • targetPort: Puerto que expone el contenedor o pod de su servicio, este seria al puerto que redireccionará automáticamente el service cuando se accede desde fuera del cluster al pod (suele coincidir con port)
  • nodePort (opcional): Aunque no aparezca ahora mismo tenemos esta opción también que es el puerto que expondra el servicio para acceder al targetPort seleccionado y se usará cuando pongamos el type=NodePort como os podéis imaginar. Tiene un rango específico -> 30000-32767. A no ser que lo queramos tener identificado, podemos dejar que el servicio decida de manera random uno dentro de ese rango.

Estas serían las configuraciones principales o básicas sobre un Service, como siempre recomiendo ver la documentación para ver los detalles y más configuraciones que nos puedieran interesar -> Kubernetes Service

Veamos ahora como funciona todo esto, pero antes de continuar comentar que lo que se explica aquí puede dar algún problema o ser distinto según la configuración con la que tengáis levantado minikube o vuestro servicio de kubernetes que estéis usando, en mi caso el ejemplo para el blog lo estoy haciendo en un mac con Docker Desktop por lo que es necesario hacer algún extra para que funcione el Service.

Primero de todo creemos el servicio:

kubectl create -f mario-service.yaml

Y una vez creado veamos que tenemos

kubectl get svc

Como vemos tenemos dos servicios el de kubernetes que es el de por defecto, (de tipo ClusterIP y es el servicio que comunica con el server master de kubernetes) y el que acabamos de crear mario-test de tipo NodePort, es decir, que "técnicamente" deberiamos poder acceder desde nuestra máquina al contenedor en cuestión al que apunta usando el puerto que ha seleccionado kubernetes automáticamente, en mi caso el 32142

Si intentamos acceder a través del navegador con localhost:32142 deberíamos poder ver el fork de Mario

He comentado antes el "técnicamente" porque es posible (como es mi caso con el entorno de ejemplo) que aún asi no podamos acceder, ahora veremos porque.

Kubernetes como tal no está pensado para funcionar en un portatil o en el equipo típico de sobremesa, es decir, si estas usando la aplicación "Docker Desktop" para jugar con kubernetes (en lugar de simplemente tener el Docker Engine) esto no te va a funcionar, es decir, si no has creado una máquina virtual para esto o no estas usando un servidor real de kubernetes seguirás sin poder acceder. Para poder acceder tendremos que hacer uso de un port-forward. REPITO ESTO NO SE TIENE QUE HACER EN UN ENTORNO EN PRODUCCIÓN A NO SER QUE SEPAS LO QUE HACES, LO HACEMOS POR NECESIDAD EN NUESTRO ENTORNO DE PRUEBAS PARA ACCEDER AL CONTENEDOR

Para este caso no es necesario que tengamos un service creado ni nada (pongo esta opción solo para que podamos acceder a nuestro contenedor, no tiene que ver con nuestro uso de services). Lo que haremos será ejecutar

kubectl port-forward mario-test 8000:8080

Con este comando simplemente hacemos una redirección de nuestro puerto local 8000 al puerto 8080 del pod mario-test. Al ejecutar este comando deberíamos ver algo similar a esto

Y si entramos con un navegador a localhost:8000 veremos como nos aparece la aplicación y en la consola (donde debe permanecer en ejecución el port-forward) esta gestionando conexiones del puerto 8000

Tras el inciso para mostrar como acceder en el caso de que no tengas un entorno similar al de producción de kubernetes, continuamos un poco hablando de los tipos de Service

En el ejemplo anterior hemos visto como sería un service de tipo NodePort, he querido mostrar este ejemplo porque es similar al de ClusterIP pero nos permite comprobar el acceso sin complicarnos creando más pods ni nada así.
Si pensamos en el tipo ClusterIP, nos quedaremos con que nos permite acceder a un conjunto de pods usando una misma dirección IP o nombre de host desde dentro del propio cluster para que puedan tener comunicación entre sí, sobre todo cuando tenemos intención de crear más de una instancia de un mismo pod (que sería para lo que usamos kubernetes realmente creo yo jejejeje). Hago incapié en esto del hostname, como tal el nombre del service es también el hostname que podremos usar para acceder al conjunto de pods dentro del cluster.

Si, por ejemplo, eliminamos el servicio actual

kubectl delete svc mario-test

Cambiamos el fichero del service indicandole que es de tipo ClusterIP

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: mario-game
    run: mario-test
    tier: games
  name: mario-service
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: mario-game
    run: mario-test
    tier: games
  type: ClusterIP <-- cambiamos esta linea
status:
  loadBalancer: {}

Y ejecutamos de nuevo el create

kubectl create -f mario-service.yaml

Veremos como haciendo un get de los servicios tenemos otro de tipo ClusterIP. Como detalle fijarse en que ahora en puertos solo nos aparece uno, es decir, solo nos aparece el puerto interno del cluster, es decir, al que redireccionariamos si usáramos el tipo NodePort.

No me extiendo en esta parte porque no tiene mucho más, si quisierais probarlo solo es necesario crear otro pod, acceder al contenedor y lanzar una petición, como ejemplo rápido

Ejecutamos y nos adjuntamos a la consola

kubectl run --rm -i --tty alpine-pod --image=alpine --restart=Never -- sh

Con esto le indicamos que queremos un pod con el nombre alpine-pod, que use la imagen de docker de alpine. Los extras como el rm que se elimine al terminar la ejecución y el último relevante es el sh para acceder a la consola.

Si todo funciona os aparecera un promt para ejecutar comandos

Ejecutamos

wget mario-service:8080 

Y tenemos que se ha bajado el index.html de nuestro contenedor

(para salir con ejecutar exit vale ;) y veremos como nos aviso de que elimina el pod )

Es una prueba muy rápida pero creo que es suficiente para entender el funcionamiento de un service de tipo ClusterIP, aquí tenemos que plantearnos que en un entorno en producción lo más probable es que tengamos mas de un contenedor del mismo tipo de POD.

Nos faltaría por ver el tipo loadBalancer pero como esta relacionado más con entornos cloud lo veremos más adelante, sin mucho más se termina este post nos vemos en el siguiente un abrazooooor

En este posts veremos 2 configuraciónes básicas para manejar el estado de salud de nuestros pods. Con estas configuraciones kubernetes de manera automática puede por ejemplo reiniciar un pod o no mandarle tráfico.

Para esto tenemos estas 2 propiedades:

• livenessProbe: Si esta sonda falla kubernetes puede por ejemplo reiniciar el pod. Es el típico health que solemos tener en otros servicios. Como tal se puede configurar que tiene que hacer kubernetes cuando la sonda falla, como por ejemplo cuantos errores debe dar antes de reiniciar y cosas así
• readinessProbe: Hasta que esta sonda no funcione kubernetes no enviaría tráfico al POD (no lo añadiría al objeto service que veremos más adelante lo que es) y en el caso de que empiece a devolver errores dejaría de enviarle tráfico (lo quitaría del objeto service)

Para ver como funciona esto, lo primero eliminaremos el pod actual si lo tenemos todavía activo

kubectl delete pods mario-test

Y modificaremos el fichero del POD añadiendo estas propiedades. Primero con la de liveness

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: mario-test
  name: mario-test
spec:
  containers:
  - image: pengbai/docker-supermario:latest
    name: mario-test
    ports:
    - containerPort: 8080
      name: game // <- Esto es nuevo
    resources: 
      requests:
        cpu: 50m 
        memory: 64M
      limits:
        cpu: 50m
        memory: 64M
    livenessProbe:
      httpGet:
        path: /fake
        port: game

  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Antes de hablar de la configuraciónd de la sonda comentar que hemos añadido un nombre al puerto en cuestión del contenedor para que nos sea más fácil hacer referencia a él y no tener que cambiarlo en un montón de sitios si de repente cambiamos el puerto.

Además del nombre del puerto hemos añadido la propiedad livenessProbe, dentro de esta propiedad podemos incluir comandos, peticiones a http y otras cosas que nos pueden resultar útiles para realizar la comprobación del estado de salud (al final del post pondré el link de la documentación para ampliar información). En nuestro caso hemos añadido una petición get a un path /fake que realmente no existe, para que veamos que ocurre.

Guardamos y creamos el pod como hasta ahora

kubectl create -f mario.yaml

Y veamos que pasa si ejecutamos nuestro comando get pods

kubectl get pods

En un principio parecería que todo esta correcto pero si esperamos veremos como se producen cambios, normalmente a los 30 segundos empezaremos a ver diferencias

Vemos como se ha reiniciado una vez y si esperamos 5 loops tendremos este error y también ha cambiado el número de contenedores READY a 0

Por último si comprobamos el describe del pod en cuestión podremos ver el registro de los eventos que se han ido sucediendo

Este sería el caso usando livenessProbe, como tal hemos visto como ha intentando reiniciar cada 30 segundos hasta que ha confirmado que no funciona. Si analizamos el describe un poco más arriba veremos como en la configuración por defecto se comprueba cada 10 segundos con un máximo de 3 fallos hasta que reinicia (estas son serian algunas de los campos que podemos configurar)

Hagamos la prueba ahora usando readinessProbe

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: mario-test
  name: mario-test
spec:
  containers:
  - image: pengbai/docker-supermario:latest
    name: mario-test
    ports:
    - containerPort: 8080
      name: game
    resources: 
      requests:
        cpu: 50m 
        memory: 64M
      limits:
        cpu: 50m
        memory: 64M
    readinessProbe:
      httpGet:
        path: /fake
        port: game

  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Este caso si ejecutamos el get pods podemos ver como ya al inicio cambia un poco, nunca tenemos el pod en READY, si nos fijamos estamos siempre en 0/1

Y trás algunos reinicios, si esperamos 3 minutos tenemos un error

Por último veamos que tenemos en nuestro describe. Primero podemos ver la configuración por defecto (la misma que con liveness):

Y si nos vamos a los eventos que han ido sucediendo tenemos

Vemos como ha intendado varias veces acceder a el y no ha sido capaz devolviendonos el error que ya hemos visto.

Estas han sido dos configuraciones básicas que podemos hacer, en la documentación oficial tenemos más información sobre la configuración, a que afecta realmente cada caso y otro probe más que es el de startup, recomiendo encarecidamente leerla y hacer más pruebas para ver las posibilidades que nos ofrecen los checks de estado de salud sobre nuestros pods.

Y hasta aquí este post, nos vemos en el siguiente un abrazoooorrrrr

En el post anterior vimos una configuración muy básica de los pods, pero como os imaginaréis tenemos más posibilidades interesantes que estaria bien que tuvieramos en cuenta. Una de ellas es la configuración/limitación de recursos.

Cuando usamos pods pero no indicamos ningún límite de recursos de hardware, nos encontrariamos con estos 2 escenarios:

• Tener unos límites definidos por defecto dentro del cluster de kubernetes
• Usar los recursos sin límite (no recomendado para nada, si sabemos de sobra que no usaremos en ningun caso todo el hardware disponible nos podemos arriesgar, pero si tenemos intención de aumentar contenedores en el futuro esto puede convertirse en un problema importante)

Lo ideal es siempre definir unos recursos específicos para cada elemento, así kubernetes puede distribuir los contenedores y los recursos de manera mucho más eficiente.
Para ello podemos/tenemos que añadir dos nuevas propiedades en nuestros pods, veamos un ejemplo.

Como usaremos el mismo pod que hemos estado usando actualmente lo primero que haremos será borrar los pods que tenemos actualmente, para ello es suficiente con ejecutar el siguiente comando por cada pod que queramos eliminar:

// para obtener los pods actuales
kubectl get pods 

// para eliminar un post específico
kubectl delete pods nombreDelContainer

Como vemos en la imagen la consola nos confirma su eliminación.
Ahora añadamos las opciones para limitar o específicar los recursos:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: mario-test
  name: mario-test
spec:
  containers:
  - image: pengbai/docker-supermario:latest
    name: mario-test
    ports:
    - containerPort: 8080
    resources: 
      requests:
        cpu: 50m 
        memory: 64M
      limits:
        cpu: 50m
        memory: 64M
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Si nos fijamos en nuestro fichero pod hemos añadido nuevas propiedades dentro de resources, hemos añadido:

• requests: Con esta opción le indicamos a kubernetes el mínimo de recursos que debe tener nuestro contenedor. Esto es muy útil para que kubernetes lo situe donde más le convenga.
• limits: Como su nombre indica este es el límite que le estamos indicando a kubernetes que puede usar nuestro contenedor. IMPORTANTE: si el contenedor se pasa de recursos es posible que kubernetes decida parar el contenedor

Para ver en detalle las opciones de CPU y MEMORIA recomienda leerse la documentación al respecto Assign cpu resource y Manage resources containers

En nuestro ejemplo le estamos limitando al uso de *50 milliCPU * y 64Mb, si por ejemplo le indicaramos algo que no tuviera disponible nuestro cluster, kubernetes lo que haría sería esperar a tener esos recursos disponibles para arrancar el contenedor en cuestión.

Ahora arranquemos nuestro pod:

kubectl create -f mario.yml

Y si hacemos un describe de nuestro pod

kubectl describe pods mario-test

Podemos ver como todo ha funcionado correctamente y nuestro pod tiene configurado sus recursos.

Ahora cambiemos la configuración para que veamos que pasa cuando le ponemos una cantidad de recursos que no puede asumir. Por ejemplo en mi caso le ponemos que use 64Gb (que mi maquina actual no los tiene)

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: mario-test
  name: mario-test
spec:
  containers:
  - image: pengbai/docker-supermario:latest
    name: mario-test
    ports:
    - containerPort: 8080
    resources: 
      requests:
        cpu: 50m 
        memory: 64G
      limits:
        cpu: 50m
        memory: 64G
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

Si ahora borramos el pod que tenemos y creamos este nuevo veamos lo que pasa:

Nuestro pod se queda con un estado pending permanente, y si vemos la descripción del pod nos indicara el estado y la información de porque no se esta ejecutando, en este caso por falta de memoria

Como vemos con estas simples propiedades dentro de los pods podemos limitar o indicar los recursos que nuestro contenedor o pod usará (con requests) y la cantidad de hardware que queremos que use como máximo (con limits).

Y hasta aquí lo referente a lo básico de sobre los recursos de nuestros pods, recomiendo leer la documentación para poder hacer un selección más específica de los recursos que queremos que usen nuestros contenedores, sin mucho más nos vemos en el siguiente, un abrazooooooooo

Bien en el post anterior vimos la primera de las opciones para compensar el problema del maximum call stack que nos podía dar la recursividad. En este post veremos algunas otras opciones para tener en nuestro arsenal, que cumplen (más o menos) con la resolución de nuestro problema aunque alguna sea bastante lenta y tengan el handicap de que debemos controlar la asincronía.

Usando setTimeout

En este caso vamos a jugar con el conocido setTimeout, en este punto es mejor que estemos familiarizados con el event-loop (recomiendo leer estos posts)

Usaremos este ejemplo, cambia un poco lo que teniamos antes, pero es por intentar seguir con el mismo concepto del sumatorio

let accum = 0
let number = 5

function addTo () {
	if (number === 0) { 
		console.log(accum)
		return
	}
	
	setTimeout(() => {
		accum = number + accum
		number--
		addTo()
	}, 0)
}


function finish () {
  console.log('Finished')
}

addTo()
finish()

Como vemos tenemos nuestra función addTo que si el número no es 0 pasa por un setTimeout con 0. Esto aunque no podamos verlo en la aplicación que lo incluye dentro de la task queue lo que hace es incluir el método en la timers queue y se ejecutaría según el ciclo de vida habitual de node cuando pase por los timers resueltos.

Veamos un poco lo que pasa cuando ejecutamos esto dentro de jv9000 (OJO que esto no funciona en la web tengo un fork modificado para permitir esto y otras cosas)

1. Incluye en el call stack la primera ejecución de addTo
   
   

2. Como number no es 0 se ejecuta el setTimeout, es decir, incluye la función anónima dentro de la timers queue, que para nosotros en nuestro visualizador esta dentro de la task queue
   
   

3. Importante, el paso anterior ha pasado como a un segundo plano dentro del event loop, por lo que para nosotros ha terminado la ejecución de addTo por lo que ya la podemos sacar del call stack
   
   

4. El loop continua y le toca a la función finish.
   
   Importante en este punto darse cuenta de que ha entrado la función finish al call stack se ha ejecutado y ha salido, sin que todavía hayamos tocado lo que tenemos dentro de task queue
   
   

5. Una vez ejecutada la función finish ya le toca el turno a comprobar task, al ver que tenemos algo lo pasa al call stack y lo ejecuta
   
   

6. Al ejecutarlo dentro del call stack, lo que tenemos de nuevo es otra ejecución de addTo, que repite la operación incluye en la task queue la función anónima del timeout
   
   

Y el proceso se repite n veces hasta que se cumple el number === 0

Donde terminaría nuestra ejecución. Como vemos aquí tenemos otro caso donde evitamos que la cola de llamadas se llene.

Usando setImmediate

Usando setImmediate es similar al setTimeout pero tiene menos pasos, en el caso anterior nuestra ejecución pasa por incluirse en la cola de task, comprobar el tiempo, ver que ha terminado incluirlo en el call stack y ejecutarlo. Al final son bastantes pasos. Sin embargo el setImmediate tiene su propia cola y se ejecutan al momento tras los eventos de I/O por lo que puede ser más rápido en un entorno recursivo. Veamos rápidamente la diferencia:

let accum = 0
let number = 5

function addTo () {
	if (number === 0) { 
		console.log(accum)
		return
	}
	
	setImmediate(() => {
		accum = number + accum
		number--
		addTo()
	})
}


function finish () {
  console.log('Finished')
}

addTo()
finish()

1. Al igual que antes se ejecuta la primera vez addTo
   
   
2. Al igual que antes pasa al finish, pero fijemonos que no tenemos en la cola de task, es decir, no estamos pendientes de que realmente termine nada.
   
   
3. De repente, si continuaramos ejecutando vemos como ha desaparecido todo y de repente aparece un método anónimo en nuestro call stack, que no es otro que la ejecución de lo que tenemos dentro del setImmediate
   
   
4. Y al igual que antes, este ejecutaría de nuevo nuestra función addTo
   
   

Este proceso se repetiría, veriamos como entra anonymous, luego addTo, termina addTo y desaparece, termina anonymous y desaparece, y en el siguiente ciclo todo se repite, hasta que coincide con number===0 que hace que se termine

Como vemos es bastante similar al proceso con setTimeout pero con menos pasos, esto no quiere decir que tenga que ser siempre más rápido, a fin de cuentas, ambos pasan por el event loop casi de la misma forma.

Usando process.nextTick

Por último veremos como será nuestra solución usando process.nextTick(). En este caso todo es igual que con setImmediate:

let accum = 0
let number = 5

function addTo () {
	if (number === 0) { 
		console.log(accum)
		return
	}
	
	process.nextTick(() => {
		accum = number + accum
		number--
		addTo()
	})
}


function finish () {
  console.log('Finished')
}

addTo()
finish()

En este ejemplo me ahorraré las imágenes ya que visualmente sigue el mismo proceso que setImmediate:

1. Se ejecuta la primera vez addTo
2. A continuación finish
3. Anonymous (lo que está dentro de nextTick)
4. addTo....
5. y el proceso se repite

Usando process.nextTick, tenemos otra solución pero en este caso, el beneficio es la velocidad, si echamos un vistazo a como se procesan las colas:

Podremos ver como nextTick se ejecuta tras cada hito dentro del loop, lo que significa que no tenemos que repetir el ciclo de vida del loop para volver a encontrarnos con el nextTick, como ocurre con los timers o el setImmediate.

Con esto de la recursión realmente lo que quería era mostrar un poco como solucionar problemas de maximum call stack y que se viera un poco que ocurre por dentro del event loop que no está de más tenerlo a veces en cuenta cuando tenemos ciertos problemas.

En siguientes posts de esta serie empezaremos con los algoritmos de búsqueda. Otro tema bastante interesante creo yo. Sin más, nos vemos en el siguiente un abrazoooooo

Ya vimos en el post anterior cual es el problema principal que podemos tener en JavaScript a la hora de usar la recursividad. En un primer momento lo más probable es que nunca nos encontremos con este problema a no ser que trabajemos con una gran cantidad de datos, pero aún así, creo que ver como se soluciona este problema puede hacernos entender algunas cosas del funcionamiento de Javascript y como podemos usarlas para cualquier otro problema que nos encontremos.

Para resolver el problema de "Maximum call stack..." existen varias formas, veremos la mayoría aunque alguna puede que no me guste mucho.

Vamos con la primera Trampoline

Trampoline

Esta se fue extendiendo como una buena posibilidad para resolver el problema, pero personalmente a mí no me convence demasiado, creo que nos salimos un poco de la pureza del concepto de la recursividad pensando en su planteamiento más funcional. Veamos el código en cuestión:

const trampoline = (fn) => (...args) => {
  let result = fn(...args)
  while (typeof result === 'function') {
    result = result()
  }
  return result
}

function addTo(number, accum = 0) {
	if (number === 0) {
		return accum
	}
	return () => addTo(number - 1, number + accum)
}

function finish () {
  console.log('Finished')
}

console.log(trampoline(addTo)(5))
finish()

Más de uno se hará una idea de lo que realmente estamos haciendo en este caso y como cambia con respecto al ejemplo del post anterior sobre recursividad.
En este ejemplo tenemos una función addTo que no se llama a si misma, si no que, según el caso llama a una función anónima que la vuelve a llamar. Pero claro no podemos llamar solo a la función addTo ya que en la primera ejecución simplemente devolvería una función que no se ejecuta y terminaría nuestro programa. Lo que hacemos es crear una función trampoline que encapsularía cualquier otra donde queramos usar la recursividad. Esta función lo que hace es controlar si la respuesta es una función que debemos que espera ejecutarse o no, en resumen, trampoline es una función que se encarga o de devolver un resultado si se ha cumplido nuestro caso base o de ejecutar de nuevo la función, veamos ahora lo que pasa en nuestro call stack.

1. Se ejecuta trampoline
   
   

En cuanto a ejecutar, me refiero a, entre en el call stack y se ejecuta directamente.
Esto es una función con currificación, si nos fijamos lo que le pasamos como parámetro a trampoline es la función que queremos ejecutar, es decir, addTo.

2. Se ejecuta trampoline(addTo)(5)
   
   

Entra trampoline(addTo)(5) al call stack y comienza a ejecutarse, aquí como tenemos un bucle while donde se ejecutan otros métodos, veremos como el call stack crece

3. Se ejecuta por primera vez addTo con el valor 5
   
   

Como vemos estamos dentro de trampoline(addTo)(5) ejecutando addTo(5, 0)
Como el valor no es cero retorna la función anónima que ejecutaria de nuevo addTo

4. Se ejecuta la función anónima que a su vez ejecuta addTo(4, 5)
   
   

Esto devuelve de nuevo una función anónima, pero como tal su ejecución termina por lo que addTo sale del call stack

Y lo mismo sucede con la función anónima que su ejecución ha terminado y sale del call stack

5. Como el resultado de todo esto sigue siendo una función nuestro trampoline vuelve a ejecutar la función anónima que ha recibido
   
   

Donde a su vez se ejecuta addTo(3, 9)

6. Este proceso se repite hasta que el parámetro number === 0 donde termina la ejecución de la función anónima dentro de trampoline
   
   

7. Se ejecuta el resultado de console.log(trampoline(addTo)(5)) que nos muestra 15
   
   

8. Se ejecuta finish()
   
   

Entra dentro del call stack

9. Ejecuta el console.log dentro de la función finish
   
   

Y la ejecución de nuestro programa o script termina

Como vemos esto es un truquillo que hace que no saturemos el call stack de ejecuciones pendientes, que cubre la necesidad que tenemos aunque como digo no es algo que me convenza mucho.

Esta es una de las formas que tenemos para evitar el Maximum call stack, en los siguientes post veremos otras posibles soluciones, algunas más sencillas otras más complejas, pero nos serviran para entender del todo como funciona el call stack.

Nos vemos en el siguiente un abrazoooooo

En este post hablaremos que son los pods y como podemos trabajar con ellos.
En el anterior post ya usamos un pod aunque realmente todavía no sabíamos nada de ellos. Si recordamos un poco cuando hicimos el run donde le indicabamos el nombre de la imagen que queriamos desplegar, lo que hizo por debajo kubernetes fué crear algo bajo el namespace pod/mario-test, ¿verdad?... pues bien para resumir lo que sería realmente un pod es una aplicación o servicio que puede tener uno o más contenedores y/o volúmenes de disco. Estos contenedores o aplicaciones están funcionando bajo el mismo namespace de networking, es decir, el conjunto de contenedores tiene la misma IP pero internamente dentro del POD los contenedores son capaces de comunicarse entre sí solo usando localhost: (es como si estuvieramos usando docker-compose con varios contenedores). La ip que reciben es privada y solo se puede acceder a través de otros PODS. Técnicamente hablando esto se conoce como que el pod esta funcionando dentro de su propio cgroup.

Un POD es la unidad mínima de recursos que podemos tener dentro de kubernetes, es decir, al menos necesitaremos un POD para poder ejecutar un contenedor. Cuando se crea un pod, kubernetes lo asigna a uno de los nodos del cluster que tengamos dependiendo de los recursos disponibles y los deseados. En kubernetes cada Pod tiene su propio ciclo de vida y podemos escalarlo o hacer lo que queramos con ellos por lo que se suele desplegar un POD por aplicación.

La declaración de un POD tiene un estilo similar a cuando trabajamos con recetas de docker-compose, es un yaml con un estilo similar a

apiVersion: v1
kind: Pod
metadata:
  name: example-app
  labels:
    app: example-app
    version: v1
    role: backend
spec:
  containers:
  - name: java
    image: companyname/java
    ports:
    - containerPort: 443
    volumeMounts:
    - mountPath: /volumes/logs
      name: logs
  - name: logger
    image: companyname/logger:v1.2.3
    ports:
    - containerPort: 9999
    volumeMounts:
    - mountPath: /logs
      name: logs
  - name: monitoring
    image: companyname/monitoring:v4.5.6
    ports:
    - containerPort: 1234

Donde como vemos tenemos la versión de la api, el tipo(pod obviamente), metadatos y spec donde declaramos los containers y su configuración deseada (esos campos son los mínimos necesarios). OJO esto es una forma declarativa de decirle a Kubernetes que es lo que queremos, luego el en su ciclo de vida, cuando toque comparará el estado actual con el deseado y hará los cambios necesarios para cumplir con lo solicitado, como por ejemplo en el caso de que no existan los contenedores los creará al igual que vimos en el post anterior.

Esto es realmente lo que hace kubectl cuando le enviamos el comando en el post anterior:

kubectl run mario-test --image=pengbai/docker-supermario:latest --port=8080

Usemos un truco para poder ver que es lo que realmente hace el comando, si ejecutamos este comando:

kubectl run mario-test --image=pengbai/docker-supermario:latest --port=8080 --dry-run=client -o yaml

Deberiamos ver algo como esto:

Esto es lo que realmente esta enviando el comando, donde a modo de resumen rápido tenemos lo siguiente:

• apiVersion: versión de la api de kubernetes
• kind: como sabemos estamos ahora mismo trabajando con Pods
• metadata.creationTimestamp: Como realmente no ha sido creado no nos aparece ningún timestamp (supongamos que esta es la especificación que mantiene kubernetes para comparar con la que le mandemos nosotros por eso tiene timestamp)
• metadata.labels: Aquí podemos incluir todo tipo de información útil, como el entorno, al final lo utilizariamos para identificar de alguna manera este POD, su finalidad....
• name: Identificador único del POD
• spec: Donde realmente se encuentra toda la información de los contenedores o lo que sea que este incluido en este pod

Para terminar de comprobar que no estoy mintiendo hagamos lo siguiente, vamos a crear un fichero yaml con esta configuración y lanzarsela a kubernetes a ver que pasa. Para ello lo primero creamos el fichero (OJO con el nombre que tiene un 2):

kubectl run mario-test-2 --image=pengbai/docker-supermario:latest --port=8080 --dry-run=client -o yaml > mario.yaml

Esto nos creará un fichero con la configuración que acabamos de ver, podemos comprobarlo con:

cat mario.yaml

Ahora le indicamos a kubernetes que cree lo que dice el fichero:

kubectl create -f mario.yaml

Nos indica que ya esta creado

Aunque realmente esa es la respuesta de kubernetes al comando, realmente lo creará cuando este en la fase de reconciliación de su ciclo de vida y vea que algo no cuadra entre lo que tiene y lo que se supone que debe tener según nuestros comandos.

Si ahora ejecutamos:

kubectl get pods

Podemos ver como tenemos otro contenedor creado con el nombre que le hemos indicado

Si por algún motivo no sabemos realmente que es lo que tiene un pod en cuestión podemos ver toda la información relevante usando el comando:

kubectl describe pod mario-test

Con esto veremos toda la información posible:

Como el nombre, el nodo donde se encuentra, su estadom la IP..... incluso si nos vamos al final de lo que nos ha mostrado la consola podremos ver un listado de eventos con lo que ha ido pasando con este pod

Bueno y hasta aquí este post de introducción a los PODS, en el siguiente podremos ver algo vas información y configuraciones más avanzadas, nos vemos un abrazoooooor

Hablemos ahora de la Recursividad. A la gran mayoría por lo menos nos tiene que sonar ¿no?... por lo menos nos habrán dicho que es muy chula, que mola usarla, que porque no lo pruebas... pues bien he de coincidir con casi cualquier cosa buena que se diga sobre este concepto, aunque claro lo suyo es usarlo cuando toque y tenga sentido (pero eso es otra historia).

Por ahora veremos que es esto de la recursividad, para que nos sirve y cual es el problema que nos generará a la larga (y como resolverlo) esto en nuestro querido Javascript.

Recursividad

No me voy a extender en explicaciones técnicas en este caso (profundizaré más en el post de la línea de javascript funcional), por lo que, en palabras simples, es la capacidad de una función de llamarse a si misma. Esto es más un concepto de programación funcional, pero debido a que las funciones en javascript se pueden tratar como cualquier otro objeto (ciudadano de primera clase), es decir, que se puede pasar por parámetro, retornar dentro de otra función.... y todo lo que se nos ocurra, podemos hacer uso de la recursión también.

Algunos ejemplos de su uso podrian ser: Recorrer un sistema de ficheros (abrir primera carpeta, recorrer lo que hay dentro y si encuentra una carpeta la abre y recorre...y asi sucesivamente), se suele ver en la típica resolución de problemas sobre los números de Fibonacci (que es y ejemplos aquí) o en general cualquier problema que requiera repetir lógica sobre un mismo elemento (y no necesitemos o no tenga sentido funcional que usemos un bucle de los habituales)

Veamos cuales son los detalles de una función recursiva. Ya hemos comentado que en la teoría se supone que es una función que se llama a si misma, como por ejemplo

function addTo (number) {
	return number + addTo(number - 1)
}

addTo(10)

La teoría de la función sería que queremos sumar los números desde 0 hasta el número dado. Visualmente tiene sentido, ¿no?, sumamos el número que recibimos primero que sería el 10 y luego llamamos a la misma función para que use el 9 y así sucesivamente. Pero claro si nos fijamos bien aquí tenemos un problema, si ejecutaramos esto tendriamos un bucle infinito porque en ningún momento le indicamos cuando tiene que parar. Lo que le falta a esta función es lo que se conoce como caso base.

El caso base es la unidad mínima que debe devolver una función recursiva, si pensamos en lo que queríamos hacer que era sumar del 0 al 10, en este caso nos falta indicarle que cuando llegue a 0 nos devuelva el número, este sería nuestro caso base, siempre debe tener un caso base.

function addTo(number) {
	if (number === 0) {
		return number
	}
	return number + addTo(number - 1)
}

addTo(10)

Si ahora ejecutamos esto todo iria bien y nos debería devolver 55. Esto es un caso muy sencillo para explicar que es la recursión pero veamos rápidamente que es lo que lo pasa por debajo.

Para ello lo primero es repasar que es el call stack. El call stack o pila de llamadas (lo defino a mi rollo por simplicicad) son las funciones que se tienen que ejecutar (con estructura LIFO) dentro de un Task del event loop. En el próximo post profundizaremos más en que es cada cosa y el flujo que sigue el eventloop, con lo que nos tenemos que quedar ahora mismo es que el call stack es el trabajo que tiene pendiente javascript para poder pasar a la siguiente tarea (es decir que nuestro thread esta bloqueado hasta que termine).

Para verlo bien vamos a usar una herramienta que me he encontrado (grandisima ayuda para entender esto visualmente ya lo veremos, agradecer a los creadores) que es jsv9000. Esta herramienta nos permite comprobar visualmente lo que pasa dentro de nuestro eventloop en cada una de sus Queues.

Lo que haremos será añadir el código siguiente y darle a run:

function addTo(number) {
	if (number === 0) {
		return number
	}
	return number + addTo(number - 1)
}

function finish () {
  console.log('Finished')
}

addTo(5)
finish()

Lo que hace la herramienta es indicarnos en que puesto está nuestro código y que ha ido pasando por dentro paso a paso, por lo que tenemos que ir dandole a step. Si le damos 6 veces (como le hemos indicado que hasta 5 y empezamos en el 0) vemos como el código lo único que ha hecho es incluir 6 llamadas en el call stack de la función de suma en la fase de evaluación

Si le continuamos dando a step vemos como se va vaciando el call stack de la función y lo siguiente es el método finish que nos muestra el resultado del console.log. En este caso lo que vemos es que nuestra función recursiva va acumulando llamadas en el call stack hasta que llega al caso base y empieza a devolver datos y a vaciar. Si lo queremos ver más claro añadimos unos logs

function addTo(number) {
	if (number === 0) {
	  console.log(0)
		return number
	}
	const result = number + addTo(number - 1)
	console.log('result: ', result)
	return result
}

function finish () {
  console.log('Finished')
}

addTo(5)
finish()

Y podemos ver en acción realmente donde estamos

Una vez entendido esto, ahora os planteo el gran problema que resolveremos en próximos posts. Cambiemos el código por lo siguiente pero no recomiendo ejecutarlo en la herramienta que tardaría muchisimo, ejecutarlo en la consola del navegador, en un fichero de node o donde más os guste

function addTo(number) {
	if (number === 0) {
		return number
	}
	return number + addTo(number - 1)
}

console.log(addTo(100000))

Fijaos el número que he puesto 100000, esto nos debe dar un error como el siguiente:

Es decir hemos llegado al límite de acciones posibles dentro de la pila de llamadas, si nos planteamos lo que ocurria con 5, que teniamos 6 inclusiones el call stack, ahora tendríamos 100001 (se que este número es muy grande pero depende de lo que estemos haciendo o donde puede ser mucho menos, realmente insisto en que es un error muy habitual). Este problema viene dado porque javascript no es un lenguaje orientado a este tipo de funciones, pero siempre podemos encontrarle solución, en los próximos post veremos como podemos solucionar esto de muchas maneras, mientras tando plantear vosotros posibles soluciones. Nos vemos en el siguiente un abrazoooooor

En este punto vamos a ver lo primero como seria lanzar o desplegar una aplicación usando kubernetes, para ello vamos a usar una imagen de docker pública (agradecer a los creadores, el contenido de esa imagen no tiene nada que ver conmigo) que contiene una versión de un juego de nuestro querido fontanero MARIO (Mas info). Para lanzarla lo que hacemos es:

kubectl run mario-test --image=pengbai/docker-supermario:latest --port=8080

En este comando lo que hacemos es indicarle a kubernetes que queremos arrancar un contenedor o un servicio con nombre mario-test con la imagen en cuestión que vemos en dockerhub y que esta aplicación escucha en el puerto 8080 (esto depende de cada imagen, en nuestro caso es ese, mirar la información de cada imagen para saber cual es el puerto que realmente escucha).
Al ejecutarse lo que hace es descargarse la imagen de docker hub y arrancarla.

Si todo va bien la respuesta seria algo similar a esto:

Podemos ver el estado de este contenedor con:

kubectl get pods

Por el momento no nos preocuparemos con que significa cada comando, lo que queremos hacer es comprobar como es empezar a trabajar con kubernetes.
Como vemos en la imagen tenemos un algo llamado pod con el nombre mario-test, este nombre es necesario para poder realmente acceder a nuestro contenedor.
En el comando que hemos lanzado para instanciar la imagen en cuestión, le hemos indicado el puerto por el que trabaja realmente el contenedor pero como tal nosotros no tenemos acceso a ese puerto, debemos hacer lo que se conoce como un port-forwarding para sincronizar un puerto de nuestra máquina con el puerto del contenedor, para ello ejecutaremos lo siguiente:

kubectl port-forward mario-test 8000:8080

Aqui lo que le indicamos es que sincronice nuestro puerto 8000 con el 8080 del contenedor o aplicación con el nombre mario-test. Si todo va bien veremos algo como:

Y si ahora nos vamos a nuestro navegador e intentamos acceder a localhost:8000, nos debería aparecer nuestro juego

Ojo tenemos que tener en cuenta que el comando de port-forward se queda ejecutandose hasta que lo paremos

Si nosotros paramos el comando en cuestión veremos como ya no podemos acceder a nuestra página con el juego de mario.

Este post ha sido solo un post introductorio para que veamos como seria desplegar una imagen básica usando kubernetes. En los próximos post entraremos más en detalle en como funciona todo esto y haremos muchas más cosas viendo todas las capacidades de kubernetes, un abrazooooo nos vemos en el siguiente.

Este patrón como su nombre indica se basa en "mover una ventana", es decir, tratamos con los datos que estan dentro de esa ventana ignorando el resto, y vamos deslizando la ventana con los siguientes datos.
Veamoslo con un ejemplo. Dentro de un array queremos obtener la suma mayor entre "n" de esos números consecutivos, es decir, si por ejemplo queremos saber cual es la suma mayor de 2 números consecutivos de este array:

[1,4,2,6,3,9]

Tendremos que sumar:

• 1 + 4
• 4 + 2
• 2 + 6
• 6 + 3
• 3 + 9

Por eso he comentado que es como mover una ventana o una caja donde solo entran 2 números y sumamos cada vez que cambia uno de los números.

Veamos el posible acercamiento mas habitual o sencillo (el que solemos hacer primero) aunque sería el más lento

// arr: el array a comprobar
// num: número de elementos en el subarray, de cuantos números queremos realizar el cálculo
function maxSubarraySum (arr, num){
    if (num > arr.length) return null;
    
    var max = -Infinity;
    for(let i = 0; i < arr.length - num + 1; i++){
        temp = 0;
        for (let j = 0; j < num; j++){
            temp += arr[i+j];
        }
        if (temp > max) {
            max = temp;
        }
    }
    return max;
}

Como vemos tenemos un "nested loop", y lo que hacemos es recorrer cada número en el primer loop y en el segundo sumamos los "n" números siguientes.

Es relativamente fácil pero tenemos una complejidad temporal de O(n^2)

Ahora veamos como sería usando el Sliding Pattern

function maxSubarraySum (arr, num){
    let maxSum = 0;
    let tempSum = 0;

    if (arr.length < num) return null;

    for (let i = 0; i < num; i++){
        maxSum += arr[i];
    }

    tempSum = maxSum;

    for (let i = num; i < arr.length; i++){
        const leftLeg = arr[i - num];
        const rightLeg = arr[i];
        tempSum = tempSum - leftLeg + rigthLeg;  
        maxSum = Math.max(tempSum, maxSum);
    }

    return maxSum;
}

Esto ya tiene algo más de "chicha", así que vayamos por partes

for (let i = 0; i < num; i++){
   maxSum += arr[i];
}
 tempSum = maxSum;

Sumamos los números que estarían inicialmente en la ventana, es decir desde "n" hasta 0 y lo establecemos en una variable que usaremos de comodín para ir moviéndonos (tempSum)

 for (let i = num; i < arr.length; i++){
     const leftLeg = arr[i - num];
     const rightLeg = arr[i];
     tempSum = tempSum - leftLeg + rigthLeg;   
     maxSum = Math.max(tempSum, maxSum);
 }

A continuación recorremos empezando por "n", es decir, después de sumar los "n" primeros números, y el paso sería elimino el primero y añado el siguiente, (para clarificar con el ejemplo de la ventana he creado leftLeg como limite o pata izquierda de la ventana y rightLeg como el derecho ) siendo más específico lo que hacemos es restarle a tempSum el primer número dentro de nuestra "ventana o cajón", que seria leftLeg y le añadimos el siguiente que esté fuera, es decir rightLef. Y vamos comparando con el valor anterior y metiendo el mayor dentro de la variable maxTemp

Siguiendo con el ejemplo de antes con este array, usando 2 valores consecutivos:

[1,4,2,6,3,9]

Los pasos serían:

• En el primer loop, se suman los 2 primeros, con un resultado de 5 y se asigna a la variable tempSum.
• En el segundo loop se le resta a tempSum el 1, se le suma 2, lo que nos daría 6 y así sucesivamente
• 6 - 4 + 6
• 8 - 2 + 3
• 9 - 6 + 9
• Lo que nos daría 12

Otro ejemplo algo más complicado.

En este caso la idea es encontrar el mínimo número de elementos necesarios del array que su suma sea igual o superior al número dado. Veamoslo con números primero, tenemos este array:

[2,1,6,5,4]

Y queremos saber cual es la menor cantidad de números de ese array que su suma sea igual o mayor que 9. En este caso serian necesarios 2 números (5+4).

Antes de ver el ejemplo, os cuento lo que haremos:

1. En este caso empezaremos a sumar desde 0, creando nosotros la ventana, hasta que la suma sea mayor o igual que el número que buscamos.
2. Cuando la suma sea mayor o igual veremos cuantos números hemos necesitado, lo apuntaremos y empezaremos a mover la ventana (recordar restando el primer número y sumando el siguiente)

function minSubArrayLen(nums, sum){
    let total = 0;
    let start= 0;
    let end = 0;

    let minLen = Infinity;

    while (start < nums.length) {
        //Si la ventana actual no es mayor o igual que el número dado movemos la ventana a la derecha, es decir ampliamos la ventana
        if (total < sum && end < nums.length){
            total += nums[end];
            end++;
        } 
        //Si la ventana actual suma al menos la suma dada entonces podemos reducir la ventana
        else if(total >= sum){
            minLen = Math.min(minLen, end - start);
            total -= nums[start];
            start++;
        } //Si el total actual es menor que lo que necesitamos pero hemos llegado al final, necesitamos el break para no un infinite loop
        else {
            break;
        }
    }

    return minLen === Infinity ? 0 : minLen;
    
}

Otro ejemplo más

En este caso queremos contar los carácteres del substring mas largo con carácteres distintos, es decir, buscamos un substring sin que se repita ninguna letra. Aquí usaremos una mezcla entre el frequency counter y el sliding pattern. Básicamente iremos anotando las letras por las que pasamos e ir moviendo la window según se repitan

function findLongestSubstring(str) {
  let longest = 0;
  let seen = {};
  let start = 0;
 
  for (let i = 0; i < str.length; i++) {
		let char = str[i];
    //Comprobamos si ya lo tenemos, y si existe, nuestro start seria el que tenemos anotado ya
    if (seen[char]) {
			start = Math.max(start, seen[char]);
    }
		// Sumamos uno para tener en cuenta el caracter actual
    longest = Math.max(longest, i - start + 1);
		// guardamos el índice con el siguiente carácter si se repite no contarlo, el nuevo esta dentro
		// de la ventana
		seen[char] = i + 1;
  }
  return longest;
}

Este ejemplo es algo más díficil de entender, creo que sobretodo el moviento de la ventana, por explicarlo un poco más supongamos que queremos saber la cantidad de caracteres máximo consecutivo donde no se repite ningún caracter de la palabra ninja (como no...), el resultado sería 4 pero veamos un poco el flujo hasta que cambia (tengamos en cuenta que i y start son las "patas" de la ventana):

• Empieza siendo i 0 por lo que empezamos con la n, como no tenemos nada guardado todavía dentro de seen la variable start se queda con 0, longest sería 1 (tanto i como start son 0) y se guardaría seen.n = 1
• A continuación la i del index es 1, lo que hace que la siguiente letra sea la i. No existe todavía dentro de seen por lo que start todavía seguiría siendo 0, longest pasaría a ser 2 (i es 1 y start 0) y guardamos seen.i = 2
• En la siguiente iteración la i del index es 2, por lo que la siguiente letra es n. En este caso si que tenemos coincidencia dentro seen por lo que start pasaría a ser 1. Aquí es donde está la parte algo más complicada de ver al principio, este paso es el porqué de guardar cada letra con un +1 dentro de seen. Para explicarlo pensemos en el concepto de la ventana, antes de pasar por la modificación del start tenemos que el borde izquierdo (la posición actual del start) esta en la posición 0 y el borde derecho (la i) está en la posición 2, al encontrar coincidencía lo que tenemos que hacer es mover la posición del borde izquierdo para sacar la n de nuestro rango de la ventana por lo que para sacarla sería mover la posición actual del borde izquierdo a n + 1, es decir, movernos al siguiente carácter. Nuestra ventana ahora pasa de estar en nin a in. Hemos movido el start de 0 a 1 por lo que en este caso si la i es 2 entonces longest sigue siendo 2 y ahora como ya existe la n dentro seen pasamos a tener seen.n = 3
• Ahora la i del index es 3, por lo que la siguiente letra es j, como no hemos pasado por ninguna nuestro start no cambia sigue en 1, longest ahora pasaría a ser 3 (i es 3, start es 1) y guardariamos seen.j = 4
• Por último la i del index es 4, por lo que ya estariamos en la última letra que es la a, como no tenemos ninguna start sigue siendo 1, longest ahora pasaría a ser 4 (i es 4 y start es 1) y por último se guardaría seen.a = 5

En este punto terminaría la ejecución y nos devolvería longest que sería 4, es decir, inja. En este ejemplo lo más importante es ver como se mueve la ventana realmente, que lo que hace es ir creciendo hasta que encuentra una repetición y coloca su start a continuación de la repetición para comenzar de nuevo sin incluir ese carácter.

Creo que más o menos con estos ejemplos se entiende cual es el funcionamiento de este patrón de resolución de problemas que puede ser bastante útil si queremos sacar y comparar información entre elementos dentro de un mismo array.

Y hasta aquí este post nos vemos en el siguienteeeee, un abrazooooor

Bien vamos con la última de las características que tiene la programación funcional antes de adentrarnos puramente en propiedades funcionales. En este caso vamos a ver en detalle que es eso de Composición de funciones.

Esto realmente no tiene mucha ciencia, el propio nombre nos indica de que va, se trata de aplicar funciones en cadena para lógicas más complejas. Esto se suele ver en ciertas librerias como composition, pipe, flow..., primero veremos como aplicar esto de forma nativa y ya veremos algún atajo con alguna libreria.

Continuemos con la teoria de uno de los ejemplos anteriores que es la de crear un player inicial para un juego:

const setName = (name) => (player) => {
  player.name = name
  return player
}

const setPowers = (player) => {
  const availablePowers = ['fly', 'invisibility', 'bulletproof', 'superstrength']
  player.powers = availablePowers[Math.floor(Math.random() * availablePowers.length)]
  return player
}

const setWeapon = (player) => {
  const availableWeapons = ['gun', 'katana', 'ninja star', 'grenade']
  player.weapon = availableWeapons[Math.floor(Math.random() * availableWeapons.length)]
  return player 
}

const newPlayer = setWeapon(setPowers(setName('Ninja')({})))

console.log(newPlayer)

Si nos fijamos en el contenido de newPlayer, es donde tenemos nuestra composición de funciones, lo que se suele ver como:

f(g(x))

En este caso puede que sea facil de entender lo que estamos haciendo en este caso, pero si tuvieramos esta forma en soluciones más complejas puede que no nos enteremos de nada, por lo que veamos como ir mejorando nuestra teoria de la composición.

Lo primero que haremos será crear nuestro propio método compose:

const compose = (...fns) => x => {
  return fns.reduce((previous, current) => {
    return current(previous)
  }, x)
}

Este método compose lo que hace es recibir una cantidad n de funciones que debe aplicar sobre un valor inicial x. En este caso lo hace de izquierda a derecha, muchas veces se usa reduceRight para hacerlo de derecha a izquierda, depende de cuales sean los métodos a usar para la composición nos interesa más una dirección u otra (por defecto derecha a izquierda aunque a mí me gusta más izquierda a derecha).

Ahora con esta función compose solo tenemos que usarla:

const compose = (...fns) => x => {
  return fns.reduce((previous, current) => {
    return current(previous)
  }, x)
}

const setName = (name) => (player) => {
  player.name = name
  return player
}

const setPowers = (player) => {
  const availablePowers = ['fly', 'invisibility', 'bulletproof', 'superstrength']
  player.powers = availablePowers[Math.floor(Math.random() * availablePowers.length)]
  return player
}

const setWeapon = (player) => {
  const availableWeapons = ['gun', 'katana', 'ninja star', 'grenade']
  player.weapon = availableWeapons[Math.floor(Math.random() * availableWeapons.length)]
  return player 
}

const newPlayer = setWeapon(setPowers(setName('Ninja')({})))
const otherPlayer = compose(setName('Ninja'), setPowers, setWeapon)({})

console.log(newPlayer)
console.log(otherPlayer)

Como podemos ver ambas funcionan correctamente y es un poco más sencillo de entender lo que estamos haciendo. Recuerdo que este ejemplo es un poco forzado es solo orientativo para ver la funcionalidad compose.

Veamos el ejemplo con Ramda

const R = require('ramda')

const setName = (name) => (player) => {
  player.name = name
  return player
}

const setPowers = (player) => {
  const availablePowers = ['fly', 'invisibility', 'bulletproof', 'superstrength']
  player.powers = availablePowers[Math.floor(Math.random() * availablePowers.length)]
  return player
}

const setWeapon = (player) => {
  const availableWeapons = ['gun', 'katana', 'ninja star', 'grenade']
  player.weapon = availableWeapons[Math.floor(Math.random() * availableWeapons.length)]
  return player 
}

const newPlayer = setWeapon(setPowers(setName('Ninja')({})))
// Aquí en lugar de compose usamos el método en cuestión de R que es pipe
const otherPlayer = R.pipe(setName('Ninja'), setPowers, setWeapon)({})

console.log(newPlayer)
console.log(otherPlayer)

Solo tenemos que usar pipe para hacerlo de izquierda a derecha o compose para hacerlo de derecha a izquierda

Un detalle importante a tener en cuenta y que hacemos uso en el ejemplo, es lo que se conoce como programación tacita o point free, este concepto se refiere a la omisión de los parámetros de los métodos cuando lo usamos por ejemplo en una composición como esta que hemos visto, debido a que los valores de retorno de unos métodos son los de entrada de otros por lo que como el proceso se realiza automáticamente lo podemos omitir. En este caso que hemos visto siempre se retorna el mismo objeto, pero pudiera ser cualquier otro caso mientras que se cumpla este concepto:

funcA :: A -> B
funcB :: B -> C

// Esto lo podemos encadenar porque funcB espera como valor de entrada B que es lo que devuelve funcA
funcC:: funcA + funcB :: A -> B -> C

Creo que con esto se entiende más o menos lo básico sobre la composición, en los próximos capítulos veremos elementos más puramente funcionales como pueden ser los Funtores, una abrazooooo

En general ya tenemos una idea de que es Kubernetes, seguro que lo hemos oido o leido en algún momento, en un resumen muy escueto, podemos decir que es una herramienta de instrumentación/orquestación de nodos de Docker, estos pueden estar en uno o varios servidores. Nos provee de una serie de herramientas para poder gestionar nuestros conjuntos de aplicaciones que están funcionando en varios contenedores Docker.

Instalación

En un primer momento comentar que realmente Kubertenes es un servicio que estará funcionando en algún proveedor cloud (AWS/Gooogle/Azure...), por lo que propiamente dicho no tendriamos una instalación. En esta sección veremos como instalar un entorno local de pruebas de kubernetes y las herramientas habituales de gestión de kubernetes (que estas si que se usan en producción)

CLI de gestión kubernetes

El servicio de Kubernetes como tal, dispone de una API para su gestión, es decir, que podríamos usar postman o curl para gestionar nuestro entorno de kubernetes, pero esto en mi opinión para el uso habitual de kubernetes no es necesario. Disponemos de un cli específico llamado kubectl que nos proporciona todo lo necesario para la gestión de cualquier entorno de kubernetes. (Mas info)

Basicamente para su instalación en MacOs por ejemplo solo necesitamos hacer:

brew install kubernetes-cli

Con esto se instalaria el cli que usaremos para trabajar.

Kubernetes en local

A continuación lo que haremos será instalar el servicio local que será nuestro kubernetes, para ello han creado una herramienta llamada minikube que hará las veces de server de kunernetes (Mas info).

Para instalarlo solo tenemos que ejecutar

brew install minikube

Esto instalará lo necesario para que minikube funcione.
A continuación lo que haremos será arrancar minikube para que funcione con kubectl. Para ello es suficiente con ejecutar:

minikube start

Esto iniciará y configurará el entorno de minikube y además hará que funcione con kubectl.
Podemos indicarle también la cantidad de memoria que queremos que use por defecto nuestro servicio de minikube pasandole:

minikube start --memory=4096

Esto haría que use 4Gb por defecto usa 2. Tiene más opciones como indicarle cantidad de CPU y demás. Si queréis ver más opciones lo ideal es mirar la documentación para verlas todas.

Probando que todo ha ido bien

Ahora ya tenemos lo básico para empezar a trabajar. Podemos comprobarlo ejecutando los comandos:

• Ver la versión que tenemos tanto del cliente (lo que seria kubectl) como del servidor (en este caso minikube)

kubectl version

• Ver los nodos que tenemos de kubernetes (donde podemos ver el rol que tiene cada uno, en este caso MASTER)

kubectl get nodes

• Ver el estado kubernetes

minikube status

• Información sobre el cluster de kubernetes

kubectl cluster-info

Con esto ya tendríamos lo básico para empezar a trabajar con kubernetes como si de un entorno de producción se tratara. En el próximo post empezaremos a mandarle instrucciones para ver como responde, un abrazoooooo

Continuemos con nuestra serie de programación funcional, y en este caso seguiremos hablando de sus caracteristicas con Javascript.
En el post anterior hablamos de Inmutabilidad, una característica donde no se mutaban o modificaban los objetos si no que creabamos otros con los cambios aplicados.

Esto es básico por ejemplo para el caso de lo siguiente que queremos hablar que es Funciones puras

Funciones puras

Las funciones puras son aquellas donde los cambios que queramos hacer solo se producen dentro del scope de la función (en su interior básicamente), en ningún caso modifican variables externas. Si tenemos una función que no devuelve nada, que usa this o que no tiene argumentos podemos empezar a sospechar que no es pura. OJO aunque digamos que debemos cumplir este punto en la programación funcional muchas veces no es posible por ejemplo en funciones de IO donde por ejemplo trabajamos con bases de datos, pero en general debemos poder cumplir con este principio.
Veamos un ejemplo del problema y como lo podemos solucionar, seguiremos la teoría del ejemplo anterior

const oldNinjas = ['Ninja1', 'Ninja2']
const newNinja = 'Ninja3'

const addNinja = (actualNinjas, newNinja) => {
  const ninjas = actualNinjas
  ninjas.push(newNinja)
  return ninjas
}

const totalNinjas = addNinja(oldNinjas, newNinja)

console.log(totalNinjas) // result <--["Ninja1","Ninja2","Ninja3"]
console.log(oldNinjas) // result <--["Ninja1","Ninja2","Ninja3"]

Es un ejemplo muy forzado lo sé, pero creo que se puede captar el concepto, aunque le estemos enviando por parámetro los ninjas actuales al ser realmente una referencia modificamos el valor de oldNinjas queramos o no, en este caso vemos como nuestra función no es pura, tiene efectos colaterales que no deseamos. En este caso una posible solución podía ser esta:

const oldNinjas = ['Ninja1', 'Ninja2']
const newNinja = 'Ninja3'

const addNinja = (actualNinjas, newNinja) => {
  return actualNinjas.concat(newNinja)
}

const totalNinjas = addNinja(oldNinjas, newNinja)

console.log(totalNinjas) // result <--["Ninja1","Ninja2","Ninja3"]
console.log(oldNinjas) // result <--["Ninja1","Ninja2"]

Concat es un método de los arrays que realmente no modifica el objeto original, si no que devuelve uno nuevo, con esto cumpliriamos siempre con la funcionalidad en cuestión y no modificamos nada que realmente no queremos. Esta solo es una forma de cumplir con lo que estamos buscando sé que tenemos otras muchas opciones esto es solo a nivel de ejemplo.

Vamos a por la siguiente

Funciones de orden superior

Esto viene también de la mano de las funciones como ciudadanos de primera clase, es decir, las funciones se pueden tratar como cualquier otra variable u objeto del lenguaje y hacen uso de otras funciones.

Estas características estamos usandolas habitualmente en javascript aunque puede que no seamos conscientes del todo, por ejemplo cuando hacemos usos de callbacks o trabajamos con promesas ya estamos haciendo uso de estas características. Veamos un ejemplo sencillo que hace uso de las 2 características

function calculator (number, operation) {
  return operation (number)
}

const plus2 = (number) => {
  return number + 2
}

const squared = (number) => {
  return number**2
}

const twoPlusTwo = calculator(2, plus2)
const threeSquared = calculator(3, squared)

console.log(twoPlusTwo) // 4
console.log(threeSquared) // 9

Como vemos estamos pasando por parámetro las operaciones que queremos realizar y luego ya calculator hace uso de el directamente, creo que más o menos se entiende.

Veamos el siguiente punto.

Currificación y aplicación parcial

A menudo estos conceptos se separan porque puramente hablando no son lo mismo, pero hacen uso de la misma funcionalidad realmente lo que cambia es la manera de aplicarla.
Para hablar de esto (y aunque no quería meterme en tecnicismos) tengo que introducir el concepto de aridad. La aridad de una función básicamente es la cantidad de parámetros que tiene un método:

function calculator (number, operation) // <-- aridad 2

Bien viendo lo que es la aridad ahora veamos una funcionalidad muy util que tenemos con javascript, que viene de la mano de la de las funciones puras. Como hemos comentado ya, es posible que devolvamos funciones y las recibamos por parámetro ¿no?... pues en esto es en lo que se basa tanto la aplicación parcial como la currificación, veamos un ejemplo primero:

function calculator (number) {
  return function (operation) {
    return operation(number)
  }
}

const plus2 = (number) => {
  return number + 2
}

const squared = (number) => {
  return number**2
}

const baseNumber = calculator(2)

console.log(baseNumber) // function (operation) { return operation(number); }

const twoPlusTwo = baseNumber(plus2)
const twoSquared = baseNumber(squared)

console.log(twoPlusTwo) // 4
console.log(twoSquared) // 4

Lo importante ahora mismo es la función calculator, como vemos lo primero que hace la función es devolver otra función, si nos fijamos en el console.log de baseNumber vemos como realmente es una función que espera una operación y simplemente lo que tenemos es ya un número preparado para realizar la operación.

Visto esto veamos lo que es aplicación parcial con un ejemplo

const createPlayer = (name, health) => (weapon) => {
  return {
    name,
    health,
    weapon
  }
}

const playerBase = createPlayer('DevNinja', 1000)

const availableWeapons = ['SuperGun', 'Katana', 'Smoke Grenade']

const playerWeapon = availableWeapons[Math.floor(Math.random() * availableWeapons.length)]

const player1 = playerBase(playerWeapon)

console.log(player1) // { name:"DevNinja", health:1000, weapon:"Katana" }

Vuelvo a comentar que esto es un poco forzado, pero nos vale para el concepto. Si nos fijamos ahora usamos arrow functions que son más comodas para hacer estas cosas.
Pues bien en este caso createPlayer lo primero recibe el nombre y el valor de salud y se queda "a la espera" de que el sistema le aplique un arma al jugador, esto es lo que seria la aplicación parcial, podemos definirlo como una ejecución de una función por pasos, pero como vemos en este caso tenemos una aridad inicial de 2 y luego de 1, esta situación de aridad es la diferencia principal entre aplicación parcial y currificación. La currificación tendría siempre aridad 1, es decir:

const createPlayer = (name) => (health) => (weapon) => {
  return {
    name,
    health,
    weapon
  }
}

const playerBase = createPlayer('DevNinja')

const playerHealh = Math.floor(Math.random() * 1000)
const playerWithInitialHealh = playerBase(playerHealh)

const availableWeapons = ['SuperGun', 'Katana', 'Smoke Grenade']
const playerWeapon = availableWeapons[Math.floor(Math.random() * availableWeapons.length)]

const player1 = playerWithInitialHealh(playerWeapon)

console.log(player1) // { name:"DevNinja", health:428, weapon:"Smoke Grenade" }

Ahora tenemos que siempre trabajamos con una aridad de 1, lo que modulariza bastante el uso de nuestro método createPlayer, haciendo posible que hagamos cualquier operación entre cada paso de la función.

Bueno creo que más o menos se entienden estos conceptos, voy un poco rápido con esto porque existen multitud de ejemplos y explicaciones al respecto por internet, si algo no esta claro recomiendo investigar un poco más, en esta serie nos detendremos un poco en conceptos más complejos como los functores y las monadas que son algo más duros para entenderlos.

Nos vemos en el siguiente donde hablaremos de la Composición de funciones un abrazoooooo Ninjaaas

Continuemos con nuestra serie sobre algoritmos y estructuras de datos, en este caso vamos a ver el patrón Multiple pointers.

Multiple pointers pattern

Este patrón, pensando en arrays, se basa en crear puntos o valores que corresponden a una posición y moverse al principio, el medio o al final según ciertos condiciones. Este patrón es muy eficiente para reducir al mínimo posible la complejidad espacial.

Pensemos lo primero en un ejemplo donde poder usarlo, vamos a crear un método que dentro de un array ordenado nos devuelva la primera pareja que sume 0.

En un primer momento lo que nos vendría a la cabeza sería hacer 2 loops recorriendo dos veces todo:

function sumZero (arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length; j++) {
      if (arr[i] + arr[j] === 0) {
        return [arr[i], arr[j]]
      } 
    }
  }
}

console.log(sumZero([-2, -1, 0, 1, 2])) // [-2, 2]

Este algoritmo tiene una complejidad:

• Temporal O(n^2)
• Espacial O(1)

Que aunque en complejidad espacial no esta mal en temporal se nos puede ir de las manos.

Veamos una solución algo mejor usando este patrón, pero antes de continuar quiero recalcar que esto es posible porque el array esta ordenado, en general muchos de los algoritmos cuentan con esto para poder resolverse (más adelante veremos varios de los mejores patrones de ordenación). Vamos con la solución:

function sumZero (arr) {
  // Establecemos los puntos de inicio (multiple pointers u know)
  let left = 0
  let right = arr.length - 1

  while (left < right) { // para no pasarnos
    let sum = arr[left] + arr[right]

    if (sum === 0) {
      return [arr[left], arr[right]]
    } else if (sum > 0) {
      right--
    } else {
      left++
    }
  }
}

console.log(sumZero([-3, -2, -1, 0, 1, 2, 4])) // [-2, 2]

En esta solución lo que hacemos es ir moviendo nuestros puntos y comprobando si cumple la condición de ser igual a 0. Como es un array ordenado si la suma es mayor de 0 quiere decir que el valor es superior por la derecha del 0 (nuestra variable right) y si el valor es negativo quiere decir que el valor es superior por la izquierda (varible left). Según cual sea de los dos lo que hacemos es ir moviendo nuestros puntos hasta que en algun momento de 0 o hayamos recorrido todos los valores por entre ambos puntos.

Esta solución tiene una complejidad de:

• Temporal O(n), solo recorremos una vez los valores.
• Espacial O(1)

Veamos un ejemplo algo más dificil, en este caso queremos comprobar si un string es una subsecuencia de otro, o más bien si aparece como una secuencia de los carácteres de otro pero de manera ordenada, es decir, si word estaría dentro de hello world en orden (no es word pero el orden es primero w y ultimo d)

function isInString (string1, string2) {
  // Establecemos los puntos de inicio (multiple pointers u know)
  let s1 = 0
  let s2 = 0

  while (s2 < string2.length) { // para no pasarnos
    if (string1[s1] === string2[s2]) s1++
    if (s1 === string1.length) return true
    s2++
  }
  return false
}

console.log(isInString('ninja', 'new in jail')) // true si quitamos lo que sobra n__ in ja__

En este caso tenemos dos strings que debemos recorrer y queremos comprobar si el primero string1 es una subsecuencia del segundo string2. En este caso nuestros puntos los situamos al inicio de cada string y vamos recorriendo, si encontramos una coincidencia de la primera posición del string1 en la primera posición del string2, movemos la posición del string1 si no, movemos la posición del string2 y así sucesivamente una vez que hayamos recorrido todo el string1 quiere decir que ya tenemos coincidencia y devolvemos true, en el caso de que la posición de string2 sea mayor que el tamaño del string2 quiere decir que no tenemos coincidencias por lo que devolvemos false.

Este patrón como vemos es muy util para comparar de alguna forma ya sea un elemento o varios y no tener que recorrerlos todos n veces convirtiendo la complejidad temporal en O(n^x) siendo x la cantidad de veces (o la cantidad de elementos) que tenemos que recorrer un elemento (o varios) al completo. En este caso por ejemplo tenemos una complejidad de:

• Temporal O(n + m). Dos strings que en el peor de los casos recorreremos enteros pero solo una vez cada uno.
• Espacial O(1)

Hasta aquí lo referente a este patrón de resolución de problemas, nos vemos en el siguienteeee un abraazoooo

Empezamos nueva serie donde explicaremos los conceptos básicos de la programación funcional orientados al mundo JavaScript.
Empecemos por lo básico, ¿qué es la programación funcional? Citando directamente a la wikipedia

En informática, la programación funcional es un paradigma de programación declarativa basado en el uso de verdaderas funciones matemáticas. En este estilo de programación las funciones son ciudadanas de primera clase, porque sus expresiones pueden ser asignadas a variables como se haría con cualquier otro valor; además de que pueden crearse funciones de orden superior.

Digamos que es un parádigma donde todo esta basado en algún tipo de función o teoría matemática (su centro fué el cálculo lambda) y nos obliga a realizar abstracciones que no son habituales en paradigmas más habituales como la programación orientada a objetos, pero esto no implica que tengamos que ser licenciados en matemáticas para porder usarlo y beneficiarnos de sus ventajas.

Las carácteristicas y ventajas que se suelen comentar sobre este paradigma:

• En lugar de centrarse en el ¿cómo? se centra en el ¿qué? queremos hacer, lo que hace que nos abstraigamos un poco más del problema que queremos resolver.
• Como su nombre indica está básado en el trabajo con funciones, practicamente todo es una función, y se tiende a la realización de funciones con un trabajo mínimo y específico, por lo que tendremos funciones pequeñas donde por ejemplo si estamos trabajando en un carrito de la compra existirian métodos como sumar precio o añadir descuento, y estos métodos devolverían siempre lo mismo siempre y cuando sus valores de entrada fueran los mismos. Muchos se preguntaran pero con esto ¿cómo contruimos toda la lógica de un carrito de la compra?... esto se basaría en la composición de funciones, es decir, cogemos esas funciones pequeñas que hemos creado y componemos una lógica que cumpla con nuestras necesidades. Siguiendo con el ejemplo del carrito si se añade algo al carrito de la compra tendriamos un método añadir producto que lo que podría hacer sería incluir producto al listado, sumar precio y aplicar descuento. Esto ya lo veremos más adelante.
• Usa lo que se conoce como funciones puras, estás funciones se llaman así porque no tienen efectos colaterales, es decir, no cambián ni hacen nada fuera del propio método (incluso un console.log es considerado un efecto colateral), por eso siempre obtenemos el mismo resultado pasandole los mismos parámetros.
• Al basarse en las funciones puras es un lenguaje muy apto para el paralelismo, ya que no modifica no accede a valores externos no tendremos problemas de race condition o casi cualquier otro que pudiera venir surgido de la concurrencia.
• Las funciones son ciudadanos de primera clase, son funciones de orden superior. Ambos casos están relacionados, las funciones de orden superior se las llama asi cuando son funciones que actuan directamente sobre otras funciones y entedemos funciones como ciudadanos de primera clase cuando las funciones pueden ser tratadas como cualquier otro elemento del lenguaje, es decir se pueden pasar como parámetros o se pueden devolver funciones directamente como resultado.
• Hace uso de lo que se conoce como recursividad, es decir, una función se puede llamar a si misma, por ejemplo para recorrer un árbol de directorios, podemos tener un método que sea abrir carpeta y según vaya recorriendo si el fichero en cuestión no es una carpeta lo devuelve y si es una carpeta se llama de nuevo a abrir carpeta y así hasta que se termina el arbol.
• Todo es inmutable, es decir, no se modifica nada existente se crean elementos nuevos dentro de las propias funciones con los cambios necesarios.
• Suele ser un código más expresivo
• Es un código más facilmente testeable
• Se tiende menos a la repetición de código, ya que todo está planteado como mini funciones con un trabajo en concreto, solo tenemos que reutilizarlas cuando toque o componer funciones que las usen.

Si me pongo podría seguir escribiendo características pero bueno en general creo que nos hacemos una idea de lo que os estoy vendiendo aquí y por mucho que siga hasta que no se vean ejemplos concretos no entenderemos lo que es esto realmente por lo que vamos a empezar hablando de Javascript e Inmutabilidad

Javascript funcional

Primero hablemos un poco del caso concreto de Javascript como lenguaje funcional. Para mi Javascript es de los mejores lenguajes que existen por su versatilidad y sus minimas obligaciones, es decir, podemos hacer lo que nos de la gana. Esto en general suele crear incovenientes porque no tenemos normas que seguir como puede ser establecer un tipo a las variables, como ya sabemos una variable ahora puede ser un número y más tarde convertirse en un string sin ni siquiera hacer un casting de tipos. Esta libertad viene de la mano de multitud de posibles errores si nos descuidamos con estas cosas (que no suelen pasar en otros lenguajes).
Pero gracias a esto podemos programar como más nos convenga o nos guste y combinar soluciones de distintos tipos para nuestro beneficio.
Como sabemos en Javascript practicamente todo es un tipo Object o parte de un tipo Object, incluso las funciones, esto nos permite usar las funciones como cualquier otro objeto: asignarlo a variables, pasarlas por parámetro, devolver funciones como resultado.... como hemos dicho al principio esto es lo básico para que un lenguaje sea funcional por lo que ya tenemos esta posibilidad, veamos como podemos cumplir con las carácteristicas básicas de un lenguaje funcional: Inmutabilidad, Funciones puras, Funciones de orden superior, Uso de currificación y composición de funciones

Inmutabilidad

Veamos lo primero el problema en cuestión

const oldNinjas = ['Ninja1', 'Ninja2']
const newNinja = 'Ninja3'

const totalNinjas = oldNinjas
totalNinjas.push(newNinja)

console.log(oldNinjas) <-- Result: [ "Ninja1", "Ninja2", "Ninja3" ]

Como vemos se ha modificado oldNinjas también, esto es funcionamiento interno de Javascript, digamos que lo que tenemos dentro de totalNinjas es una referencia en memoria a oldNinjas por eso hagamos lo que hagamos con totalNinjas se verá reproducido en oldNinjas, ojo que es un ejemplo un poco forzado para ver el caso concreto, con un oldNinjas.concat no tendriamos este problema.

Suponiendo que tenemos este problema tenemos varias opciones para resolverlo, la primera hacemos un freeze sobre oldNinjas para que no se pueda modificar hagamos lo que hagamos (nos daria error) y a continuación realizamos una copia del array:

const oldNinjas = Object.freeze(['Ninja1', 'Ninja2'])
const newNinja = 'Ninja3'

const totalNinjas = [...oldNinjas] // Copiamos
totalNinjas.push(newNinja)

console.log(totalNinjas) // result --> [ "Ninja1", "Ninja2", "Ninja3"]
console.log(oldNinjas) // result --> [ "Ninja1", "Ninja2"]

Esta sería una opción para cumplir con este principio, otra es usar alguna librería funcional que haga esto por nosotros, a mí la que más me gusta es Ramda, es muy eficiente y cumple más o menos bien con los requerimientos funcionales

const R = require('ramda')

const oldNinjas = Object.freeze(['Ninja1', 'Ninja2'])
const newNinja = 'Ninja3'

const totalNinjas = R.append(newNinja, oldNinjas)

console.log(totalNinjas) // result --> [ "Ninja1", "Ninja2", "Ninja3"]
console.log(oldNinjas) // result --> [ "Ninja1", "Ninja2"]

Esto es un ejemplo de como podemos cumplir con el principio de inmutabalidad necesario en la programación funcional.

Creo que por el momento es suficiente para un único post, continuaremos con los siguientes conceptos en proximos capítulos, cuadaaaos y un abrazooooooo

Antes de nada tenemos un repo con un script para insertar los documentos que usamos de ejemplo:

Mongo_index_explain

En general sabemos que es un índice de mongo pero hablemos un poco más en profundidad. Si no índicamos un índice cuando creamos una colección mongo, por defecto, nos creará un índice con el campo _id de tipo único (no se puede repetir el campo).

Cuando creamos un índice mongo crea otra especie de mini colección solo con los datos que le indicamos en el índice, ordenados de la manera que le indiquemos y apuntando al documento al que hacen referencia. Cada índice tiene una especie de firma, es decir, se le asigna un nombre para identificarlo usando los campos del índice y mongo recorre su lista de indices hasta que encuentra una coincidencia, es decir, si buscamos por dos campos intentará encontrar uno donde coincida la firma de esos campos y si no busca separando los campos hasta que encuentra una coincidencia, si no la encuentra continuará con una búsqueda sin índice.
Pero antes de ver esto vayamos paso a paso.
Mongo sigue la misma teoría que el resto de bases de datos con sus índices, usa lo que se conoce como Binary Tree Sort, es un tipo de algoritmo de búsqueda bastante eficiente para estas cosas Más info

Sintaxis básica de creación de índices

Antes de ver los tipos de índices la sintaxis básica de creación de índices es la siguiente

db.getCollection('index').createIndex({lastName: -1})

Siendo lastName el campo del que queremos el índice y -1 es la ordenación si lo queremos ascendente pondremos un 1, si lo queremos descendente -1

Más adelante veremos las opciones de creación de los índices.

Tipos de índices

Single field (un solo campo)

Como dice el nombre tenemos un tipo de índice donde lo creamos solo con un campo, es decir:

db.getCollection('index').createIndex({lastName: 1})

Veamos un ejemplo con la diferencia de tener un índice a no tenerlo. En la colección de prueba que tenemos vamos a realizar un búsqueda por lastName y veamos lo que tarda. Busquemos con el siguiente comando primero en la colección sin índice:

db.getCollection('noindex').find({ lastName: 'Master'}).explain("executionStats")

Esto nos da que nos ha traido 10 elemento en un tiempo de 4190 ms

Ahora vamos a crear un índice en la colección para ello con este comando:

db.getCollection('index').createIndex({ lastName: 1 })

(más adelante veremos como ver los índices que tenemos y cosas así)

Ahora ejecutemos la misma búsqueda pero dentro de la colección con índice que acabamos de crear:

db.getCollection('index').find({ lastName: 'Master'}).explain("executionStats")

Esto nos da que nos ha traido 10 elementos en un brutal tiempo de 10ms la primera vez y las siguientes a 0ms

Ahora se puede ver un poco la potencia que nos proveen los índices.

Veamos otro ejemplo que no va también, vamos a crear primero un índice de un campo con esto:

db.getCollection('index').createIndex({ city: -1 })

Tenemos una colección donde la gran mayoría de los 2000000 de elementos tienen la misma ciudad, por lo que ahora pasa una cosa curiosa, veamos la búsqueda con indice

db.getCollection('index').find({ city: 'Madrid'}).explain("executionStats")

Tarda unos 8873ms, ahora veamos la búsqueda normal

db.getCollection('noindex').find({ city: 'Madrid'}).explain("executionStats")

Sorprendentemente tarda 3963ms mucho menos

Pero porqué?? Bueno el algoritmo de búsqueda binaria que tienen los índices no es eficiente para este tipo de colecciones donde la mayoria de elementos son iguales, para que este algoritmo haga su magia necesitamos que los elementos a buscar sean la mayoría diferentes, por eso en este caso es más eficiente la búsqueda habitual donde recorre todos y descarta los que no necesita.

Si tenemos esta casuística donde un montón de campos son iguales lo más probable es que filtremos por algún campo más, es decir que creemos un índice de tipo compound (los veremos a continuación), pero si quisieramos realizar una busqueda sin índice, en mongo se conoce como búsqueda natural y aunque no se suele comentar esto mucho por los mares digitales, tenemos la posibilidad de forzarlo, solo tenemos que sugerirlo de esta manera:

db.getCollection('index').find({ city: 'Madrid'}).hint({ $natural : 1 }).explain("executionStats")

hint es uno de los extras que podemos indicar en las busquedas para sugerir un índice u otro según el nombre, podemos ponerlo de la misma manera que pusimos al crear el índice:

db.getCollection('index').find({ city: 'Madrid'}).hint({ city: -1 }).explain("executionStats")

O con el nombre de índice que se crea:

db.getCollection('index').find({ city: 'Madrid'}).hint("city_-1").explain("executionStats")

Los podemos ver por ejemplo desde robo3t

Visto este caso especial pasemos a los índices compuestos donde podemos ver búsquedas eficientes por varios campos

Compound fields (compuesto....o básicamente varios campos)

Los siguientes índices son los que involucran a varios campos dentro de nuestras colecciones, estos siguen un orden según como los escribamos, la sintaxis básica sería:

db.getCollection('index').createIndex({ field1: 1 , field2: -1})

Lo que hace este índice es crear un índice partiendo principalmente del field1 con un orden ascendente y dentro de los field1 que coincidan los ordena según el field2 de manera descendente.

En nuestro caso crearemos un índice por ciudad e email, recordemos que en ciudad tenemos 1999000 veces la misma ciudad y antes ha tardado mogollón

db.getCollection('index').createIndex({ city: -1, email: 1 })

Ahora veamos la búsqueda sín indice:

db.getCollection('noindex').find({ city: 'Madrid', email: 'NinjaMaster@email.com'}).explain("executionStats")

Ha tardado 5112ms que no está nada mal pensando en la búsqueda anterior, pero ahora veamos la búsqueda con el índice

db.getCollection('index').find({ city: 'Madrid', email: 'NinjaMaster@email.com'}).explain("executionStats")

Sorprendetemente ha tardado solo 12ms

Cosas que tenemos que tener en cuenta de los índices compuestos:

• Tienen un límite de 32 campos
• En un principio el orden en que definamos el índice no influye demasiado (menos en los $fullText que usaría como filtro inicial para hacer el de texto) a la hora de buscar pero si a la hora de ordenar nosotros añadiendo un sort a continuación del find. Partiendo del índice que hemos definido anteriormente no seria lo mismo hacer esto:

db.getCollection('index').find({ city: 'Madrid', lastName: 'Master', email: 'NinjaMaster@email.com'}).sort({ city: -1, email: 1  }).explain('executionStats')

Que hacer esto:

db.getCollection('index').find({ city: 'Madrid', lastName: 'Master', email: 'NinjaMaster@email.com'}).sort({ email: 1, city: -1  }).explain('executionStats')

O esto:

db.getCollection('index').find({ city: 'Madrid', lastName: 'Master', email: 'NinjaMaster@email.com'}).sort({ city: 1, email: 1  }).explain('executionStats')

La primera usa el índice directamente y no tiene que hacer nada más:

Las otras dos pasan del índice para hacer la ordenación, la segunda porque directamente ordenamo primero por email y la segunda porque no es ninguna de las opciones factibles en cuanto a dirección un índice usa solo dos tipos de ordenaciones: la misma con la que se ha definido y la que es directamente opuesta, es decir, si definimos un índice con 1,-1,1, usaría el índice para ordenar bajo esa definición o con -1,1-1

Multikey Index (Indice con arrays en resumen)

Este tipo de índice lo crea automáticamente mongo al detectar un campo de tipo array, en un principio podemos pensar que no tiene mucho de especial, pero realmente tenemos que tener en cuenta que el índice creará una entrada por cada elemento del array. Supongamos que además de ciudades tenemos un array de poblaciones donde por ejemplo puede trabajar ese usuario, si alguien de Madrid tiene de poblaciones disponibles Coslada, Vicalvaro, Mordor.... nos creara:

Madrid + Coslada
Madrid + Vicalcaro
Madrid + Mordor
...

Esto es importante a la hora de controlar el tamaño del índice, los índices ocupan espacio.....por si no lo habías pensado y también consumen al rehacerse, cada vez que se escribe se vuelve a indexar

A tener en cuenta:

• Solo podemos tener índices con uno de los valores de tipo array, si intentamos tener dos nos dirá que nos dediquemos a la pintura
• Si tenemos un índice con array e intentamos insertar en otro de los campos del índice un array nos dirá otra vez que lo nuestro es el arte
• Podemos crear índices con campos con arrays de documentos, que funcionarían igual que los arrays normales si le indicamos uno de los campos del documento

db.getCollection('index').createIndex({ 'tags.front': -1 })
db.getCollection('index').find({ 'tags.front': 'Vuejs' }).explain('executionStats')

Si no le indicamos un campo en concreto nos creará un índice pero solo funcionara con documentos completos, no con campos específicos. Borramos el índice anterior y creamos este:

db.getCollection('index').createIndex({ 'tags': -1 })

Ahora realizamos la misma búsqueda anterior:

db.getCollection('index').find({ 'tags.front': 'Vuejs' }).explain('executionStats')

Lo notamos con el tiempo que tarda pero podemos vemos como hace la búsqueda básica con COLLSCAN.
Sin embargo si búscamos un documento al completo:

db.getCollection('index').find({ 'tags': {
					front: 'Vuejs',
					back: 'Node'
				} }).explain('executionStats')

Vemos como tarda bastante menos y además nos indica que ha usado un índice

Indice Full text(o campos con un montón de texto)

El índice de texto es un tipo de indice especial que nos mejora la búsqueda con un conjunto de palabras sobre un número n de campos, es decir, nos busca en todos los campos que tenga el índice. Este índice se puede aplicar en cualquier campo de tipo string o de array con valores de tipo string, donde podemos indicarlo el idioma en cuestión para que ignore palabras comunes como 'y, o, de' en español.
Por defecto se crea con idioma inglés por lo que en nuestro caso lo añadiremos a la hora de la creación del índice.

Para hacernos una idea de que tiene de especial, los índices habituales lo que hacen es crearlo basandose en esto que buscas está en estos documentos, sin embargo este tipo de índice lo que hace es darle la vuelta este documento tiene estas palabras

En este caso los ejemplos son un poco más complicados, las búsquedas especiales por un texto solo funcionan si tenemos un índice, por lo que , por ejemplo, en la colección noindex no podremos hacer esta búsqueda, lo más parecido sería una expresión regular con un find sobre los campos que quisieramos realizar la búsqueda y evidentemente tardará un poco más, veamos un ejemplo. Para la pruebas tener en cuenta que no seria lo mismo que un entorno de producción esto es solo para entender los conceptos, en un entorno real puede tardar más o menos la búsqueda sin índice:

db.getCollection('noindex').find({ firstName: /Juanchu/,
				alias: /Juanchu/,
				bio: /Juanchu/ }).explain("executionStats")

Esto nos da un tiempo de 4429ms que no está nada mal.
Creemos ahora un índice con los campos en formato texto:

db.getCollection('index').createIndex({ bio: 'text', firstName: 'text', alias: 'text' },  { default_language: "spanish" })

Esto tardará un montón, es un índice que tiene que comprobar todas las palabras que tienen nuestros campos de texto, y si no le ponemos el idioma bien....pues más todavía porque almacenará palabras innecesarias.

Ahora que ya tenemos el índice busquemos el mismo concepto:

db.getCollection('index').find({ $text: { $search: "Juanchu" } }).explain("executionStats")

Ahora vuelve a tardar 1ms, bastante mejor ¿no?. En un entorno con más campos se notaría más la diferencia

Para que veamos lo que nos ha encontrado

Con esto tenemos un ejemplo, veamos ahora que epecialidades tenemos con este tipo de índice:

• SOLO ES POSIBLE TENER UN ÍNDICE DE TIPO TEXT, es decir, si queremos añadir campos de texto, tenemos que eliminar el que tuvieramos y hacerlo de nuevo.
• Es CASE-INSENSITIVE
• Se le pueden indicar pesos de importancia a cada campo, esto sumará las veces que aparece la palabra que buscamos en cada campo y documento y nos los devolverá según ese orden si se lo indicamos en la busqueda.
  Creación:
  

db.getCollection('index').createIndex(
   {
     alias: "text",
     bio: "text",
     firstName: "text"
   },
   {
     weights: {
       firstName: 10,
       alias: 5
     }
    },
    { default_language: "spanish" }
 )

Esto crearía un índice con los pesos:
* firstName 10
* alias 5
* bio 1 (by default)

db.getCollection('index').find(
   { $text: { $search: "Juanchu" } },
   { score: { $meta: "textScore" } }
).sort( { score: { $meta: "textScore" } } )

• Los Wildcard indices o índices creados según un patrón de posibles campos, aquí solo podemos ponerlo una vez y lo que haría sería un índice con todos los campos de tipo string (más adelante veremos esto de los wildcard)
• Sí no queremos hacer que ignore las palabras tipo y, o, de que las usa como delimitadores para conjuntos, podemos índicarle language: "none"
• No se puede indicar hint para sugerir un índice a la hora de realizar búsquedas tipo text
• En los índices compuestos podemos tener varios campos de tipo text pero solo podemos tener el resto de campos tipo single, es decir, no podemos tener multikeys o geospatial
• Crear este tipo de índice es muy costoso a nivel de recursos, tanto en ram como en espacio y puede hacer más lenta la inserción de nuevos campos que esten bajo ese índice.

Índice de texto multiidioma

Esta parte require su propio título ya que tiene un poco de miga. Podemos tener colecciones en multiples idiomas y para mejorar la búsqueda bajo estos campos podemos modificar un poco los campos del documento para que mongo haga su magia con las búsquedas, añadiendo solo la traducción pertinente según el idioma que le indiquemos en el índice.
Para esto tenemos que tener un campo language donde indiquemos el lenguaje en cuestión del documento o campo, así a la hora de hacer el índice mongo sabra mejor que tiene que hacer con ese campo. Un ejemplo de documento podría ser este:

{
   _id: 1,
   language: "portuguese",
   original: "A sorte protege os audazes.",
   translation:
     [
        {
           language: "english",
           quote: "Fortune favors the bold."
        },
        {
           language: "spanish",
           quote: "La suerte protege a los audaces."
        }
    ]
}

Si quisieramos tener otro campo como indicador de lenguaje lo podemos indicar a la hora de crear el indice:

db.quotes.createIndex( { quote : "text" },
                       { language_override: "idioma" } )

Wildcard Index (indices sin saber los campos...)

Esto no es muy dificil de entender, queremos crear índices donde el nombre de los campos puede ser dinámico, es decir, puede ir cambiando como puede ser un campo con metadatos que pueden ir variando, en este caso por ejemplo creariamos un índice así:

db.getCollection('index').createIndex( { "user_metadata.$**" : 1 } )

Esto nos crearía un indice teniendo en cuenta que dentro de user_metadata podemos tener de todo tipo de campos:

{
    user_metadata: {
        "clicks": 200,
        "views": 1000
    }
},
{
    user_metadata: {
        "images": 500,
        "favorite_tags": ["games", "dogs"]
    }
}

Si queremos crear un índice por todos los posibles campos, simplemente

db.getCollection('index').createIndex( { "$**" : 1 } )

Un índice de tipo wildcard recorrera todos los nested documents que se encuentre

También es posible indicar este tipo de índice en campos específicos

db.collection.createIndex(
  { "$**" : 1 },
  { "wildcardProjection" :
    { "user_metadata" : 1, "games.rewards_info" : 1 }
  }
)

Para hacerlo usamos wildcardProjection como indicador de lo que queremos hacer. Esto por ejemplo nos haría un índice con todo lo que estuviera dentro de esos dos campos.

También podemos excluir campos:

db.collection.createIndex(
  { "$**" : 1 },
  { "wildcardProjection" :
    { "user_metadata" : 0, "games.rewards_info" : 0 }
  }
)

• Por defecto este tipo de índice omite el campo _id, si queremos añadirlo solo tenemos que indicarlo dentro de wildcardProjection
• No es posible crear indices compuestos usando wildcard
• No pueden ser indices únicos ni tener TTL
• No pueden ser Geoespaciales o Hashed
• Si queremos ordenar con este tipo de índice solo podemos hacerlo usando el campo mediante el que busquemos, es decir, si usamos user_metadata.images para buscar solo podremos hacer un sort en mongo usando ese campo.
• No indexan campos vacios, es decir los ignoran y los guardan en el indice (son lo que se conoce como SPARSE)
• No podemos hacer búsquedas haciendo coincidir un array al completo, solo campos sueltos
• No podemos hacer búsquedas con un not equal null porque no tiene esos elementos y no comprende que hacemos.

HASHED INDEX

En estos índices lo que hace Mongo es convertir el valor del campo en un hash único y lo almacena. Este formato puede ser útil, en general para ahorrar espacio o para temas de sharding (comprime los documentos hijos en un hash), ya que en lugar de almacenar el campo almacena un hash. Luego Mongo por si mismo hace su magia y cada vez que busques va convirtiendo el directamente el valor de los campos, es decir, nosotros no tenemos que hacer nada.

db.getCollection('index').createIndex({ alias: 'hashed' })

Importante:

• No admiten búsquedas por rango solo exactas
• No admiten coumpound index

OTROS INDICES

• 2D: Indices basados en coordenadas de planos 2d
• 2Dsphere: Indices en formato Tierra, es decir, pone un plano en formato esfera para gestionar las coordenadas
• geoHaystack: Indices especializados en planos 2d de tamaño pequeño

PROPIEDADES DE LOS INDICES

• TTL: Propiedad de single field index donde indicamos un tiempo de vida al índice para que elimine los documentos de la colección, util para colecciones de logs y cosas así. El valor que indiquemos no se puede cambiar, para cambiarlo tenemos que borrar el indice y crearlo de nuevo

db.eventlog.createIndex( { "lastModifiedDate": 1 }, { expireAfterSeconds: 3600 } )

También es posible indicar una hora de expiración si el propio campo es de tiempo

db.log_events.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

Esto haría que este documento:

db.log_events.insert( {
   "expireAt": new Date('July 22, 2013 14:00:00'),
   "logEvent": 2,
   "logMessage": "Success!"
} )

Desapareciera a esa hora.

• Unique: Campos o combinaciones de campos que no se pueden repetir

db.members.createIndex( { "user_id": 1 }, { unique: true } )

db.members.createIndex( { groupNumber: 1, lastname: 1, firstname: 1 }, { unique: true } )

Este índice si no existe un campo lo guardará como null y no se podrá repetir

• Partial Index: Podemos crear indices que solo esten referidos cuando se haga un tipo de filtro, es decir, que solo se indexará algo si el documento cumple con el filtro que se le indica, es decir, si creamos este índice:

db.restaurants.createIndex(
   { cuisine: 1, name: 1 },
   { partialFilterExpression: { rating: { $gt: 5 } } }
)

Solo indexará cuando rating sea mayor que 5 (pero solo mayor que 5, no vale luego buscar por un mayor de 8), esto hace que consuma menos recursos el indice.

• Case Insensitive: Podemos crear indices con case insensitive, indicando el locale y el strength que queremos que use para la parte insensitive

db.fruit.createIndex( { type: 1},
                      { collation: { locale: 'en', strength: 2 } } )

Para ver la diferencia en la comparación Pulsa aquí

• SPARSE INDEX: Con la opción sparse le indicamos que no guarde en el índice los documentos que no contengan el campo que le indicamos.

db.addresses.createIndex( { "xmpp_id": 1 }, { sparse: true } )

Tenemos que tener cuidado porque este tipo de indice puede no devolver todos los resultados, si usamos un filtro que contenga xmpp_id nos ignorará los que no lo tengan y si buscamos también por otro campo no nos aparecerá

• Index intersection: Intersección de índices, resumiendo esta funcionalidad, si mongo cree que funciona puede hacer uso de dos indices para hacer una búsqueda. Por poner un ejemplo, si tenemos dos single index uno con ciudad y otro con población, si buscamos por ambos puede mezclar los indices para mejorar la búsqueda, pero solo la búsqueda no lo usaria por ejemplo si buscamos por ciudad y luego queremos hacer un sort por población.

• background: Propiedad recomendada para que la colección no se bloquee mientras se rehacen los indices (aún así ojo con los campos que se tenga prevista un nivel alto de escritura)

db.addresses.createIndex( { "xmpp_id": 1 }, { background: true } )

Trabajando con indices

Ver indices de una colección

db.getCollection('index').getIndexes()

Esto nos muestra algo similar a esto:

[
    {
        "v" : 2,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "indexninja.index"
    },
    {
        "v" : 2,
        "key" : {
            "_fts" : "text",
            "_ftsx" : 1
        },
        "name" : "TextIndex",
        "ns" : "indexninja.index",
        "weights" : {
            "alias" : 5,
            "bio" : 1,
            "firstName" : 10
        },
        "default_language" : "english",
        "language_override" : "language",
        "textIndexVersion" : 3
    },
    {
        "v" : 2,
        "key" : {
            "lastName" : -1.0
        },
        "name" : "lastName_-1",
        "ns" : "indexninja.index"
    },

Con la type_version del indice, la key por la que se ha realizado, el name que tiene el indice y el ns, es decir, la colección a la que pertenece

Eliminar un índice

db.getCollection('index').dropIndex("lastName_-1")
db.getCollection('index').dropIndex( { lastName: -1 } )

Esto nos devolvería algo similar a esto:

/* 1 */
{
    "nIndexesWas" : 5,
    "ok" : 1.0
}

Donde nos índica el número de indices que coincidian con esa condición y el resultado

Eliminar todos(o varios indices)

Para eliminar todos los indices:

db.getCollection('index').dropIndexes()

Y a partir de la versión 4.2 de mongo podemos indicarle un array con los nombres de los indices que queremos eliminar

db.getCollection('index').dropIndexes(["TextIndex", "lastName_-1"])

Ver el uso actual de los indices

db.getCollection('index').aggregate( [ { $indexStats: { } } ] )

Con esto podemos ver si se usan mucho o poco los indices actuales. Esto nos devuelve algo similar a esto:

/* 1 */
{
    "name" : "TextIndex",
    "key" : {
        "_fts" : "text",
        "_ftsx" : 1
    },
    "host" : "83165c61f9de:27017",
    "accesses" : {
        "ops" : NumberLong(2),
        "since" : ISODate("2020-01-12T11:18:17.642Z")
    }
}

/* 2 */
{
    "name" : "_id_",
    "key" : {
        "_id" : 1
    },
    "host" : "83165c61f9de:27017",
    "accesses" : {
        "ops" : NumberLong(0),
        "since" : ISODate("2020-01-12T10:22:38.796Z")
    }
}

También podemos ver que se ha usado en cada query que realizamos con el comando que estamos usando continuamente (además de mogollón de información relativa a la query)

db.getCollection('index').find({ city: 'Madrid', email:'NinjaMaster@email.com' }).explain("executionStats")

Y si por ejemplo queremos ver info extra cuando tenemos una busqueda con multiples condiciones, como un poco el orden de filtro que ha seguido con:

db.getCollection('index').find({ city: 'Madrid', email:'NinjaMaster@email.com' }).explain("allPlansExecution")

Esta query ademas de lo anterior nos devuelve:

"allPlansExecution" : [ 
            {
                "nReturned" : 5,
                "executionTimeMillisEstimate" : 0,
                "totalKeysExamined" : 5,
                "totalDocsExamined" : 5,
                "executionStages" : {
                    "stage" : "FETCH",
                    "nReturned" : 5,
                    "executionTimeMillisEstimate" : 0,
                    "works" : 6,
                    "advanced" : 5,
                    "needTime" : 0,
                    "needYield" : 0,
                    "saveState" : 0,
                    "restoreState" : 0,
                    "isEOF" : 1,
                    "docsExamined" : 5,
                    "alreadyHasObj" : 0,
                    "inputStage" : {
                        "stage" : "IXSCAN",
                        "nReturned" : 5,
                        "executionTimeMillisEstimate" : 0,
                        "works" : 6,
                        "advanced" : 5,
                        "needTime" : 0,
                        "needYield" : 0,
                        "saveState" : 0,
                        "restoreState" : 0,
                        "isEOF" : 1,
                        "keyPattern" : {
                            "city" : -1.0,
                            "email" : 1.0
                        },
                        "indexName" : "city_-1_email_1",
                        "isMultiKey" : false,
                        "multiKeyPaths" : {
                            "city" : [],
                            "email" : []
                        },
                        "isUnique" : false,
                        "isSparse" : false,
                        "isPartial" : false,
                        "indexVersion" : 2,
                        "direction" : "forward",
                        "indexBounds" : {
                            "city" : [ 
                                "[\"Madrid\", \"Madrid\"]"
                            ],
                            "email" : [ 
                                "[\"NinjaMaster@email.com\", \"NinjaMaster@email.com\"]"
                            ]
                        },
                        "keysExamined" : 5,
                        "seeks" : 1,
                        "dupsTested" : 0,
                        "dupsDropped" : 0
                    }
                }
            }, 
            {
                "nReturned" : 0,
                "executionTimeMillisEstimate" : 0,
                "totalKeysExamined" : 6,
                "totalDocsExamined" : 6,
                "executionStages" : {
                    "stage" : "FETCH",
                    "filter" : {
                        "email" : {
                            "$eq" : "NinjaMaster@email.com"
                        }
                    },
                    "nReturned" : 0,
                    "executionTimeMillisEstimate" : 0,
                    "works" : 6,
                    "advanced" : 0,
                    "needTime" : 6,
                    "needYield" : 0,
                    "saveState" : 0,
                    "restoreState" : 0,
                    "isEOF" : 0,
                    "docsExamined" : 6,
                    "alreadyHasObj" : 0,
                    "inputStage" : {
                        "stage" : "IXSCAN",
                        "nReturned" : 6,
                        "executionTimeMillisEstimate" : 0,
                        "works" : 6,
                        "advanced" : 6,
                        "needTime" : 0,
                        "needYield" : 0,
                        "saveState" : 0,
                        "restoreState" : 0,
                        "isEOF" : 0,
                        "keyPattern" : {
                            "city" : -1.0
                        },
                        "indexName" : "city_-1",
                        "isMultiKey" : false,
                        "multiKeyPaths" : {
                            "city" : []
                        },
                        "isUnique" : false,
                        "isSparse" : false,
                        "isPartial" : false,
                        "indexVersion" : 2,
                        "direction" : "forward",
                        "indexBounds" : {
                            "city" : [ 
                                "[\"Madrid\", \"Madrid\"]"
                            ]
                        },
                        "keysExamined" : 6,
                        "seeks" : 1,
                        "dupsTested" : 0,
                        "dupsDropped" : 0
                    }
                }
            }
        ]

Recomendable que los índices entren en la RAM, asi nos evitamos tener que tirar de disco para consultarlos

Para ver lo que ocupan los indices solo tenemos que lanzar el comando

db.getCollection('index').totalIndexSize()

El resultado está en bytes

Ver toda la info posible de una colección

db.getCollection('index').stats()

Antes de empezar a ver algoritmos complejos o las estructuras de datos entremos un poco en el área de la resolución de problemas que, aunque no te lo creas, existen algunos patrones típicos que podemos usar para resolver problemas y que pueden ser bastante útiles en nuestro dia a dia o por lo menos a la hora de hacer entrevistas. Aquí veremos algunos de estos patrones para que nos hagamos una idea y luego simplemente sería ir buscando más. Empecemos.

Resolución de problemas

Antes de entrar a ver patrones, vamos a comentar un poco algunos conceptos importantes.
Empecemos por preguntarnos, ¿qué es un algoritmo?... Por ponerlo simple podemos definirlo como un proceso o serie de pasos que tenemos que seguir para completar una tarea específica o para resolver un problema (algo así podría valer ¿no?).
Y esto ¿por qué es importante?... si lo pensamos detenidamente los desarrolladores realmente lo que hacemos es resolver problemas (muchos de estos los generamos nosotros mismos pero eso es otro tema) y aunque en nuestro día a día realmente puede que no necesitemos usar procesos complejos para nuestro trabajo, siempre estamos haciendo uso de algoritmos y como casi siempre en programación, alguien ya se ha encontrado con el problema que tenemos actualmente y puede ser que exista una manera mejor o más eficiente para resolver un problema en el que, por ejemplo, estemos usando bucles anidados o cosas similares (ya hemos visto que eso es kaka). Básicamente podemos entender que los algoritmos son como nuestras bases para ser mejores programadores y resolutores de problemas. También que aunque en vuestro dia a dia al final no hagáis uso de esto, siempre os podrá venir bien para las entrevistas o para las pruebas técnicas, que ahora cada vez más están recurriendo a este tipo de pruebas y muchas contienen problemas que podéis resolver con este tipo de patrones.

Best Practices

Como en la mayoría de entornos a la hora de resolver problemas tenemos unas best practices reconocidas (que realmente no usamos) y que podemos usarlas en última instancia si no somos capaces de resolver el problema que tenemos entre manos. Esto sería lo que llamaríamos Idear un plan de resolución de problemas, luego tenemos la otra opción que es dominar los patrones de resolución de problemas y aplicarlos directamente (ya llegaremos a esto demomoento empecemos con nuestro plan).

Pasos básicos para resolver un problema

Estos serían los pasos básicos que podemos seguir para resolver un problema:
1. Entender realmente el problema
2. Revisar ejemplos concretos de este problema
3. Descomponer el problema en problemas más pequeños y asumibles
4. Resolver o simplificar
5. Revisar y refactorizar

1. Entender el problema
Para ver si realmente entendemos el problema podemos hacernos algunas preguntas básicas:
* ¿Puedo replantear el problema con mis propias palabras?
* ¿Cuáles son realmente los inputs?
* ¿Cuáles son los outputs que debería devolver la solución del problema?
* ¿La salida puede ser determinada con los elementos que recibe el problema?¿Tenemos toda la información que necesitamos para resolver el problema?
* ¿Como debo identificar los datos importantes que son parte del problema?

Lo primero seria resolver preguntas de este tipo para poder hacernos una idea de lo que necesitamos y donde tenemos las mayores dificultades con este problema.

2. Buscar ejemplos
Si no tenemos ejemplos con la entrada y los resultados que deberíamos obtener, podemos tener tests o historias de usuario, pero al final, necesitamos algún tipo de pista de que es lo que necesitamos conseguir.
A continuación podemos plantearnos empezar creando nosotros mismos ejemplos simples (podemos incluso simplificar un poco el problema ignorando algunas de sus condiciones) e ir avanzando añadiendo dificultad hasta tener toda la complejidad que el problema realmente tiene. OJO no se nos pueden olvidar ejemplos con entras vacías o erroneas.

3. Descomponer el problema
En este punto debemos escribir los pasos que necesitamos tomar para resolver el problema, y sí escribir aunque parezca una tontería esto nos ayuda a plantear la resolución del problema correctamente viendo posibles fallos en nuestro planteamiento antes de escribir una sola línea de código. Al escribir los pasos, los estamos descomponiendo en otros más pequeños que son más sencillos de enfrentar.

4. Resolver el problema/Simplificando el problema
Ahora llega el punto de realmente resolver el problema. A la hora de intentar resolverlo nos daremos cuenta donde realmente estará el núcleo de la difilcutad que tenemos para llegar a revolver el problema. En este punto lo que debemos hacer es ignorar esa dificultad, es decir, simplificamos el problema y lo resolvemos de esta manera. Una vez que esté resuelto volvemos a incorporar esa dificultad a nuestra solución.
Aunque no lo parezca, este proceso ayuda muchas veces a resolver nuestro problema.

5. Revisar y refactorizar
En este punto lo que tendríamos que hacer sería comprobar, lo primero, si nuestra solución realmente funciona en todos los casos y luego ya hacernos preguntas de este estilo:
- ¿Podemos llegar a la misma solución de otra manera?
- ¿Podemos usar este algoritmo para resolver otros problemas?
- ¿Podemos mejorar el rendimiento de nuestra solución?
- ¿Cómo han resuelto el problema otros desarrolladores?

Con un plan o estrategia similar a estos 5 puntos podemos acercarnos más a una solución a nuestro problema.

Y a continuación esta estrategia la complementaremos con nuestro conocimiento en algunos patrones típicos de resolución de problemas.

Common problem solving patterns

Existen multitud de patrones de resolución de problemas:
- Frequency Counter
- Multiple Pointers
- Sliding Window
- Divide and Conquer
- Dynamic Programming
- Greedy Algorithms
- ....

Aquí comentaremos algunos que están en el nivel correcto sencillez/utilidad pero en esta página GeeksForGeeks tenemos todos los patrones o algoritmos que podamos necesitar (es muy completa).

Vamos a empezar viendo el que se conoce como Frequency Counter

Patrón FREQUENCY COUNTER

Este patrón es relativamente sencillo y tiene una función muy específica "Contar las veces que algo se repite o aparece". En un primer momento podemos pensar en la utilidad de esto, veamoslo con un ejemplo.

Queremos un método que compruebe si un string es un anagrama de otro, es decir, queremos saber si ambos strings se pueden formar con las mismas letras. Una forma fácil es contar las veces que existe cada letra en ambos strings y comparar, veremos dos acercamientos posibles de este patrón

function validAnagram(string1, string2){
    
    //Comprobamos si el tamaño es el mismo,si no, terminamos antes de empezar
    if (string1.length !== string2.length){
        return false;
    }
    
    const frequency1 = {};
    const frequency2 = {};
    //Recorremos ambos strings y guardamos en un objeto siendo la letra la key y el valor el número de veces que aparece
    for (let char of string1){
        frequency1[char] = ++frequency1[char] || 1;
    }
    
    for (let char of string2){
        frequency2[char] = ++frequency2[char] || 1;
    }

    //Recorremos y comprobamos. Si en algún caso las cantidades no coinciden entonces no es un anagrama uno de otro
    for (let char in frequency1){
        
        if(frequency1[char] !== frequency2[char]){
            return false;
        }
    }
    return true;
  }

Esta es una solución válida, que excepto que tenemos 3 búcles for, no está mal. Veamos otro posible acercamiento en este caso son solo 2 búcles

function validAnagram(string1, string2){
    //Comprobamos si el tamaño es el mismo,si no, terminamos antes de empezar
    if (string1.length !== string2.length){
        return false;
    }
    const letters = {};
    
    for (let i = 0; i < string1.length; i++){
        letters[string1[i]] = ++letters[string1[i]] || 1;
    }
    
    for (let i = 0; i < string2.length; i++){
    //Si es 0 o no existe no es un anagrama.
        if(!letters[string2[i]]){
            return false;
        } else {
            letters[string2[i]] -= 1;
        }
    }
    return true;
}

En este caso tenemos otra solución que tiene un búcle for menos y también nos funciona. Por si a alguien no le queda claro lo que estamos haciendo es restando las coincidencias del segundo string con el primero dentro de nuestro objeto letters y en el caso de que intentemos acceder a un valor que ya es 0 o que no exista es señal de que no es un anagrama.

Bueno y hasta aquí el patrón de Frequency Count, básicamente contamos dentro de un objeto CLAVE-VALOR los elementos que nos interesen, sencillo ¿verdad?

Nos vemos en el siguiente, un abrazooooooorrrrrrrr.

Hablemos de algoritmos, eficiencia y esas cosas, es decir, hablemos de cosas 'chungas'.
Para medir la eficiencia de los algoritmos no usamos el tiempo propiamente dicho (como podríamos pensar en un primer momento), si lo midiéramos mediante algo temporal, como segundos, milisegundos o cosas así los datos no serían fiables, ya que dependen del hardware y de lo que esté haciendo en ese momento el ordenador.
En su lugar usamos 2 tipos de medidas:

• Time complexity (complejidad temporal).
• Space complexity (complejidad espacial) o también lo podríamos llamar Auxiliary Space complexity (luego hablaremos de esto).

Y para cualquiera de estos tipos de medida usamos lo que se conoce como Big O notation o notación de Landau. No vamos a entrar en la matemática específica de esto, si queréis saber más tenéis más información aquí. En nuestro caso valdrá con que tengamos este diagrama como referencia

Siendo O(1) lo mejor y O(n^2) lo peor. Con esto como base empecemos.

TIME COMPLEXITY

Al contrario de lo que indica su nombre no es una regla de medida temporal, lo que hace es medir la efeciencia basándose en el número de operaciones simples que realiza la función, entendiendo por operaciones simples: =, +, -, *, /, %, <, >.

Veamoslo mejor con algunos ejemplos simples:

function addUpTo(n) {
    let total = 0;
    for (let i= 0; i <= n; i++) {
        total += i;
    }

    return total;
}

Veamos cuantas operaciones tenemos aquí:

1. let total=0: Primera asignación que ocurre solo 1 vez.
2. let i=0: Segunda asignación que ocurre solo 1 vez.
   3 y 4. i <= n: Que se divide en 2 comparaciones 1 por el < y otra por el = y esto se haría n veces.
   5 y 6. i++: Esto es una suma y una asignación a i que se produce a su vez n veces.
   7 y 8. total += i: Y esto es igual que el anterior una suma y una asignación que se produce n veces.
   
   
   

En este caso tenemos 2 operaciones simples que se producen solo 1 vez y luego 6 operaciones que se producen n veces, es decir, que dependen de n, por lo tanto ¿cual creéis que será el TIME COMPLEXITY en este caso? Pensemos que son todo operaciones simples pero que dependen de n, por lo que en este caso nuestro valor será O(n).

Vayamos ahora con otro ejemplo:

function addUpToV2(n) {
    return n * (n + 1) / 2;
}

Es la misma función, es decir, hace lo mismo, nos devuelve la suma de todos los valores menores que n incluido n. Veamos las operaciones:

1. n+1: Operación suma que se produce 1 vez.
2. n * (resultado de lo anterior): Multiplicación del resultado anterior que se produce 1 vez.
3. resultado anterior/2: División del resultado anterior que se produce solo 1 vez.

En este caso tenemos solo 3 operaciones pero además estas operaciones solo se producen una vez, es decir, no dependen de n, por lo tanto, en este caso el valor sería O(1) puesto que pasemos el número que pasemos a n siempre es constante la cantidad de operaciones que se realizarán.

Otro ejemplo:

function countUpAndDown(n){
    console.log("Hacia arriba...");
   
    for (let i = 0; i < n; i++) {
      console.log(i);
    }

    console.log("En la cima \n Bajando...");
    for (let j = n -1; j >= 0; j--) {
        console.log(j);
    }
    console.log("Bajamos!!");
  
}

En este caso tenemos 2 bucles que como ya hemos visto cada una sería O(n), es decir, O(2n). Es 2n porque depende 2 veces de n, pero al medir la complejidad siempre ignoramos los valores numéricos constantes por lo que volvemos a tener una función con un valor de 0(n).

Y ahora vamos con el último ejemplo con las medidas simples de medida (de momento no entramos a las medidas logarítmicas).

function printAllPairs (n){
    for (let i = 0; i < n; i++) {
        for (let j = 0; j < n; j++) {
            console.log(i,j);
        }
    }
}

Aquí tenemos otro par de bucles, pero en este caso son 2 bucles anidados, es decir, uno dentro de otro, por lo que sería un n veces del bucle interior, por cada n veces del bucle superior, es decir, n*n o n^2, resumiendo en este caso tendríamos la peor medida de todas O(n^2).

Hasta aquí de momento en cuanto al Time Complexity, más adelante volveremos a ello, ahora vamos a por el Space Complexity

SPACE COMPLEXITY

Cuando hablamos de la complejidad espacial, nos referimos a cuanta memoria necesitaremos para ejecutar nuestra función. Al igual que con la time complexity, se usa para medir O, lo único que en este caso lo que diferenciamos será:

• Valores primitivos: number, boolean, undefined y null. Estos valores son siempre constantes en cuanto a su tamaño por lo que ocuparán O(1).
• Objetos y arrays: Que en este caso se miden en O(n) siendo n la cantidad de keys en los objetos y siendo n el tamaño de array.

En este caso la diferenciación es simple, si no tiene arrays u objetos será O(1), si tiene n arrays u objetos O(n) y si tiene arrays u objetos anidados entre sí sería O(n^x) siendo x la cantidad de anidación que tengamos, es decir, si tenemos un array de 3 dimensiones tendremos un O(n^3), si tenemos uno de 2 O(n^2).

Esto en cuanto a la parte simple del space complexity y del time complexity, evidentemente todo esto tiene algo más de chicha cuando entramos en los resultados intermedios de la gráfica (si, esos que contienen logaritmos). Hagamos un repaso de los logaritmos

LOGARITMOS

Hablemos ahora de los logaritmos, puesto que aunque no los hayamos visto todavía en algún ejemplo si que forman parte de las mediciones de eficiencia de los algoritmos. Si os fijáis en la gráfica inicial están presentes en las mediciones intermedias.

Pues veamos, ¿qué es un logaritmo? Para ponerlo simple es lo contrario que un exponente, es decir, ¿cuál es el resultado de 2^4? (2 elevado a 4)?
16
Por lo que entonces sería:

Una definición más específica sería:
Un logaritmo es la cantidad de veces que tengo que dividir un número por 2 (si es de base 2) hasta tener un valor menor o igual a 1. En nuestro caso serían 4 las veces que tenemos que dividir 16:

1. 16 / 2 = 8
2. 8 / 2 = 4
3. 4 / 2 = 2
4. 2 / 2 = 1

Y a la hora de hablar de logaritmos, por defecto siempre hablamos de logaritmos base 2, por lo que lo podemos omitir (y así es como lo vemos en las gráficas).

Bueno y hasta aquí lo básico, nos vemos en el siguiente, un abrazooorrrrr.

La idea es ir empezando a ver como sería un entorno real de desarrollo con Docker teniendo:

• Nuestro entorno de desarrollo: Un entorno donde creamos las cosas.
• Entorno de test: Tras el desarrollo, pasamos nuestro código al entorno de test donde, como su propio nombre indica, probamos que todo funciona.
• Entorno de producción: Tras pasar los tests pertinentes automáticamente el proyecto pasaría a producción.

Este workflow es lo que comunmente se conoce como Integración Continua, Continuous Integration o CI. Para este proceso usaremos herramientas o servicios como Github o Travis CI y desarrollaremos con ReactJS (no importa que no sepamos usarlos veremos lo necesario para entender lo que estamos haciendo).

Entorno de desarrollo

Empecemos por el primero de los entornos, el entorno de desarrollo. Lo que buscamos en este entorno es que nuestros cambios mientras estamos desarrollando se sincronicen automáticamente con el contenedor de desarrollo (esto en varios casos es innecesario pero lo veremos igualmente con los fines didácticos que nos ocupan).
Pensando en el objetivo de este entorno, ya hemos visto que si realizamos cambios en nuestro código tenemos que volver a realizar un build y luego arrancar un contenedor nuevo con la imagen que nos crearía el build anterior. Esto realmente no es lo que estamos buscando, es poco eficiente y tendríamos demasiadas imágenes de contenedor.

En docker existe una forma de solucionar esto, vamos a introducir algo que no hemos visto todavia: Los Volúmenes.
En docker un volumen no deja de ser una referencia al filesystem del contenedor y puede ser una referencia, como un mapeo (al igual que los puertos) de una carpeta local a una del contenedor, o un 'no lo toques' (que básicamente es mapea todo menos esto). Lo vamos a probar directamente, primero de todo vamos preparar un proyecto para trabajar con el, empecemos por crearnos un proyecto de ReactJS.

Para trabajar con react usaremos un paquete de npm que nos instala un proyecto básico inicial, lo instalamos con

npm -g install create-react-app

Una vez instalado ya podríamos crearnos un proyecto

create-react-app frontWeb

Esto nos creará un proyecto de react dentro de una carpeta llamada frontWeb. Para probar si funciona solo tenemos que entrar en la carpeta y ejecutar con:

npm start

Bien ya tenemos nuestra web de react, vamos ahora con la parte del entorno de desarrollo de docker.
Para ejecutar nuestro entorno de desarrollo en un contenedor solo necesitamos que tenga node instalado, es decir, que es similar a lo que hemos creado anteriormente.

Antes de continuar comentar que aunque vamos a trabajar casi todo el rato con comandos de docker-compose todo lo que hagamos a partir de ahora se puede hacer con comandos docker run también, pero realmente son comandos muy largos y poco útiles a la larga. En caso de necesidad siempre podemos buscar cual es el flag del comando para ponerlo directamente sin usar un dockerfile.

Continuemos, volvamos al principio, hemos dicho que queríamos un entorno de desarrollo donde nuestro contenedor se actualice automáticamente según vayamos haciendo cambios en local, para ello vamos a hacer uso de lo que en docker se conoce como volumenes.
Lo primero nos crearemos dentro de nuestra carpeta de proyecto de react un fichero dockerfile pero esta vez pondremos:

Dockerfile.dev

Como es normal aunque no lo hayamos visto a docker se le puede indicar el fichero dockerfile a usar cuando hacemos un build, solo tenemos que usar el flag -f, por ejemplo (ojo al punto del final)

docker build -f ./Dockerfile.dev .

Lo mismo con los ficheros para docker-compose, por lo que realmente no tendremos ningún problema y podemos tener varios dockerfile distintos según nuestro entorno.
Sabiendo esto continuamos con nuestro fichero Dockerfile.dev

FROM node:alpine

WORKDIR '/app'

COPY package.json .
RUN npm install

COPY . .

CMD ["npm", "start"]

Misma teoria que anteriormente, copiamos el package.json primero por posibles cambios solo del resto y no tener que hacer otra vez el npm install todo el rato cada vez que hagamos un build.
Ya tenemos nuestro fichero dockerfile, ahora como la idea es usar docker-compose para todo necesitamos crear el fichero docker-compose.yml

version: '3'
services:
    web_react:
        build: 
            context: .
            dockerfile: Dockerfile.dev
        ports:
            - "3000:3000"

Antes de continuar, vemos que ahora donde tenemos puesto build ahora hemos añadido 2 propiedades:

• context: Indicamos el contexto desde(path) desde el que trabajara el build del docker-compose.
• dockerfile: Nombre del fichero dockerfile que queremos usar.

Continuemos, ahora vamos a hablar del concepto de Volume (por fin ;) ), primero añadamoslo al fichero

version: '3'
services:
    web_react:
        build: ./Dockerfile.dev
        ports:
            - "3000:3000"
        volumes:
            - /app/node_modules
            - .:/app

Si nos fijamos en lo que hemos puesto, tenemos realmente dos conceptos distintos dentro de volumes:

• .:/app: Hablemos primero del segundo, este es similar al concepto de mapear puertos, básicamente le estamos indicando que mapee todo el contenido de la ruta actual de mi equipo local, al path /app del contenedor, lo que funcionaría similar a un acceso directo a los ficheros de la carpeta local de nuestro equipo.
• /app/node_modules: Si nos fijamos en esta línea no tenemos ':', eso es porque aquí le estamos indicando que haga como un marcador de la carpeta node_modules del contenedor, es decir, usa la del contenedor, no la toques y dejala donde está (esto hace que la carpeta se mantenga aunque hagamos el paso anterior).

Ahora que ya sabemos lo que hemos puesto, viene la pregunta del ¿por qué?....bien, si pensamos en el proceso que hemos añadido en el Dockerfile.dev, tenemos una parte donde instalamos los paquetes que están indicados en el package.json, es decir, queremos que los descargues e instales de nuevo cuando hagamos un build de la imagen del contenedor, y no pasamos la carpeta local node_modules (que es donde instala las dependencias), que de hecho la vamos a eliminar para que veamos como funciona, si, eliminarla.

Ya que hablamos del Dockerfile.dev, alguno se puede preguntar si hacemos la refencia o linkado de nuestra carpeta local, ¿para qué hacemos el COPY?....bueno, esto es para prevenir creaciones para producción usando los mismos Dockerfiles, realmente en nuestro caso actual no lo necesitamos pero para producción siempre es mejor para evitar errores, ya que un contenedor en producción NO DEBE hacer referencias a carpetas locales de ningún sitio solo tiene que tener sus propios ficheros.

Ya tenemos todo ahora nos situamos en la ruta donde tenemos el fichero docker-compose.yml y ejecutamos:

docker-compose up

Si todo va bien deberíamos ver algo como esto en la consola

Y si accedemos en el navegador a:

localhost:3000

Deberíamos ver

Bien como tal ya tenemos todo funcionando, pero realmente lo que queremos es poder desarrollar en local y que se actualice el contenedor , ¿no?... pues vamos a probarlo.
Nos vamos a nuestra web de react, y dentro de la carpeta src modificamos el fichero App.js y ponemos lo que queramos:

 <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <p>
            Hola ninjaaaaasssss
          </p> //<-- Esta es la linea que cambiamos
          <a
            className="App-link"
            href="https://reactjs.org"
            target="_blank"
            rel="noopener noreferrer"
          >
            Learn React
          </a>
        </header>
      </div>

Y una vez que guardemos el documento automáticamente se debería actualizar el navegador y mostrar

¡¡¡PERFECTO!!!... ya tenemos nuestro entorno de desarrollo funcionando.

Empecemos con el entorno de TEST

TEST

Por defecto react viene ya configurado con 1 test para poder probar, solo tenemos que hacer

npm run test

o

npm test

y automáticamente nos pasaría los tests

Bien, pues ahora queremos esto pero en un contenedor, como opción rápida podemos ejecutar una imagen creada con el mismo dockerfile pero cambiando el comando de arranque (esto es solo para que veais que funciona).

Por si no la tenemos creamos el build de la imagen, yo la voy a taggear para poder identificarla

docker build -f ./Dockerfile.dev . -t test_react

Esto nos devuelve una imagen con ese nombre

Ya la tenemos, ahora solo vamos a realizar un run habitual cambiando el comando de arranque

docker run -it test_react npm test

Le he añadido -it para poder trabajar con la consola de test y como algo nuevo si nos fijamos hemos puesto cosas tras el nombre de la imagen, básicamente todo lo que ponemos a continuación del nombre de la imagen a ejecutar lo toma como comando de arranque para el contenedor. Si lo ejecutamos nos devuelve

Otra opción es añadirlo a nuestro docker-compose añadiendo otro servicio pero con la misma teoría, compartiendo o mapeando ficheros entre el equipo local y el contenedor, teniendo 2 contenedores funcionando uno para las pruebas en desarrollo y otro probando los test. El problema de este acercamiento es que no tenemos control sobre la consola de test por lo que no podemos hacer mucho más que ver como pasan los tests cada vez que hacemos un cambio en los ficheros.
Vamos a probarlo, cambiamos nuestro fichero docker-compose

version: '3'
services:
    web_react:
        build:
            context: .
            dockerfile: Dockerfile.dev
        ports:
            - "3000:3000"
        volumes:
            - /app/node_modules
            - .:/app
    test_react:
        build:
            context: .
            dockerfile: Dockerfile.dev
        volumes:
            - /app/node_modules
            - .:/app
        command: ["npm","test"]

Como véis hemos añadido otro servicio (contenedor ya sabéis), en este caso se llama test_react, que usa el mismo dockerfile y mapea de la misma forma los volumenes. Despues de eso si que tiene cambios, hemos quitado el mapeo del puerto porque ya no lo necesitamos y como extra nuevo hemos añadido la propiedad command que básicamente lo que hace es cambiar el comando de inicio del contenedor.
A continuación si ejecutamos nuestro docker-compose up, nos crea dos contenedores y como podremos ver el log ambos funcionan correctamente, y si cambiamos algo en los ficheros se actualizan ambos, tanto el de desarrollo como el que pasa los tests.

Ninguno de los casos es muy ideal pero son funcionales y puede que en algún caso nos pueda servir para algo, más adelante veremos un entorno de test más 'real' por el momento esto es más que suficiente, a continuación empezaremos a hablar un poco de PRODUCCIÓN

PRODUCCIÓN

Pasemos ahora a producción, la intención es crear un contenedor que nos devuelva nuestra aplicación ya preparada para producción, para el que no lo sepa, una app de react la preparamos para producción ejecutando el comando:

npm run build

Y este comando nos deja unos ficheros típicos de web (html, js y css), es decir, ficheros estáticos. Estos ficheros los deja en una carpeta llamada build dentro de nuestro proyecto.

Ahora necesitamos para producción un servidor web, los más utilizados son Apache o Nginx, aunque podríamos hacerlo con NodeJS, Go, Ruby, etc..... con casi todos los lenguajes tenemos alguna opción para hacerlo. En nuestro caso usaremos un contenedor con Nginx.

Si miramos la documentación del contenedor oficial podemos ver que los ficheros los sirve desde el path /usr/share/nginx/html. Sabiendo esto entonces básicamente lo que tendriamos que hacer sería copiar nuestros ficheros de producción en esa ruta del contenedor de nginx... pero claro se supone que no tenemos en local los archivos, veamos como podemos hacerlo con el entorno que tenemos ahora.

Nos vamos a crear un nuevo dockerfile con esto

FROM node:alpine as builder
WORKDIR '/app'
COPY package.json .
RUN npm install
COPY . .
RUN npm run build

FROM nginx
COPY --from=builder /app/build /usr/share/nginx/html

Empecemos por la primera linea:

FROM node:alpine as builder

Introducimos algo nuevo en este punto, básicamente lo que estamos haciendo es indicarle al proceso que añada como una referencia al resultado del build de ese contenedor con nombre builder, pero puede ser cualquier otro. Esta referencia solo está disponible en el contexto de la ejecución de docker build.
El resto del primer contenedor es algo que ya hemos visto, vayamos con el segundo

FROM nginx
COPY --from=builder /app/build /usr/share/nginx/html

Aquí empezamos con el segundo contenedor. Vemos como la instrucción COPY tiene algo nuevo

--from=builder

Como os podéis imaginar tiene que ver con la instrucción as builder del primer contenedor, aquí le estamos diciendo que del primer contenedor se copie la ruta /app/build y la pegue en /usr/share/nginx/html
Bien pues vamos a ejecutar nuestro nuevo build

docker build .

Una vez terminado

Tenemos ya construido una imagen con supuestamente nginx y nuestra app en producción. Por último nos faltaría crear un contenedor con esa imagen, pues vamos a ello

docker run -p 3500:80 --name webpro idImagen

Como extra he añadido --name que lo que hace es taggearnos el contenedor con un nombre que podamos gestionar de manera más comoda que un ID numérico

Se puede ver al principio el comando y a continuación un log (el de nginx) una vez que intentamos acceder a la página

Y como podemos ver ya tenemos nuestro entorno para producción que básicamente es el build del dockerfile una vez que hemos terminado de desarrollar.

En próximos posts veremos una forma más profesional de hacer todo esto con Integración Continua gracias a TravisCI y GitHub.

Empecemos con cosas más complicadas, ahora vamos a preparar un entorno que se comunique entre sí y en el que podamos crear varios contenedores que se comuniquen entre con un solo comando.
Para poder hacer esto, empezaremos a ver algo que se llama docker-compose, esto son otra serie de comandos pertenecientes al entorno de Docker, en el que básicamente se busca un fichero docker-compose.yml con las instrucciones que se deben seguir.
Lo primero, en nuestra carpeta visits donde hemos creado anteriormente nuestro dockerfile con nuestra aplicación en NodeJS, nos creamos el fichero docker-compose.yml y vayamos poco a poco

version: '3'
services:

• version: Hace referencia a la versión de la composición, esto le indica a docker, cuando ejecutamos comandos del CLI de docker-compose, si es versión más actual de docker-compose (a fecha de este texto es la 3).
• services: Dentro del fichero, la propiedad services hace referencia a los contenedores, no a un servicios, dentro de este apartado indicaremos todos los contenedores que crearemos mediante esta composición.

version: '3'
services:
  redis-server:
    image: 'redis'
  node-app:
    build: .
    ports:
      - "4001:8081"