2022-02-05 09:00
¡Feliz año a todos! Siento haber tenido que reducir la cadencia de nuevos posts, pero he estado bastante ocupado y he focalizado mis esfuerzos en otros menesteres.
Este año me he lanzado a perfeccionar mi inglés, dedicándole mucho tiempo y esfuerzo. A modo de entrenamiento, añadí a mi feed personal los principales canales de noticias de los proveedores de nube pública más importantes, comencé a leer más libros técnicos en inglés y también me aficioné a podcasts de CICD, Kubernetes, Seguridad, etc.
Mi rutina de aprendizaje ha funcionado y además me ha permitido estar al día en las últimas metodologías y tecnologías del mundo Cloud. Sin embargo, esta nueva información ha terminado provocándome un debate interno bastante fuerte.
Este post va a ser un poco diferente, de opinión, así que recuerda que es mi opinión y que podemos estar en desacuerdo sin que pase absolutamente nada.
2021-11-29 10:00
La seguridad informática está generando una preocupación nunca vista. En pocos años, la complejidad de los ataques se ha disparado, pasando de chantajear compañías para recuperar ciertos datos a atacar las cadenas de suministro digital en una escala nunca antes vista.
Aunque a nivel personal es difícil ser objetivo de ataques tan complejos, siempre es recomendable seguir una serie de buenas prácticas para ser menos vulnerables o para no ser utilizados como un vector para atacar a terceros. Personalmente, recomiendo lo siguiente:
- Asegurarnos que nuestras contraseñas tengan una complejidad y longitud adecuada.
- Que sean únicas. Es una forma de evitar que muchos servicios sean expuestos de golpe (algo posible si un servicio que utilizamos ha sido expuesto).
- Que dichas contraseñas sean rotadas cada X tiempo para evitar que pudiesen ser vulneradas a través de ataques de fuerza bruta.
Todas estas prácticas son muy útiles para usuarios finales de un servicio, pero también aplican de una forma o de otra a los desarrolladores: nuestra aplicación utiliza credenciales de alguna forma para conectarse a una base de datos o acceder a servicios de terceros, etc. Y ahí la cosa se complica puesto que gran parte de las intrusiones o fugas de datos ocurren debido a descuidos: credenciales o contraseñas almacenadas en sitios públicamente accesibles (como repositorios de código o buckets de objetos abiertos a todo el mundo en AWS o GCP), que agravan los problemas de seguridad.
En este post vamos a ver que medidas podemos tomar y que herramientas podemos usar para evitar que se produzcan este tipo de incidentes.
2021-07-11 10:00
Ansible siempre ha sido mi gestor de configuración favorito. Al utilizar yaml, siempre me pareció una herramienta con poca curva de aprendizaje y mucho potencial (no me equivocaba).
Hacía mucho que no escribía sobre Ansible: aunque no he dejado de utilizarlo, mi carrera profesional se ha orientado más hacia contenedores y sistemas serverless. A día de hoy, sigue formando parte de mi día a día a nivel personal puesto que lo sigo utilizando para realizar pruebas y para mantener todos los servidores que administro fuera de mi horario laboral. También mantengo un rol de Ansible para ayudarme en dicha tarea.
A pesar de mi silencio, Ansible ha continuado creciendo y ha sufrido una gran transformación durante estos años, de la cual no he estado desconectado. En este post vamos a revisar cuales han sido dichos cambios y cómo adaptar nuestros playbooks y roles a ellos.
2021-06-13 14:00
Cada vez que se lanza una aplicación al público, ésta sigue un proceso bastante común: se coge el código fuente, se compila o empaqueta, se configura y, finalmente, se despliega y se testea. Sin embargo, es algo que puede ser muy complejo y las interdependencias entre cada uno de los pasos hacen que se pueda tardar horas o días en finalizar. Por ello, la automatización se ha ido abriendo paso para reducir los tiempos y facilitar la vida de operadores y desarrolladores.
Cualquier automatización debe ser iterativa y acumulativa. Se empieza por las partes más sencillas, como la construcción de la aplicación y poco a poco se van integrando más capas. La acumulación de estas automatizaciones en la construcción y despliegue de las aplicaciones, son la base de cualquier sistema de CI/CD (Continuous Integration / Continuous Deployment) actual.
La infraestructura como código recoge estos mismos principios y, como ya comenté en un post anterior, yo ya utilizo un pipeline básico para desplegar mi infraestructura. Hoy vamos a ver cómo crear estos tests y verificar que los despliegues hacen justamente lo que queremos.
2021-05-21 22:00
Hoy se cumplen diez años del ataque informático que sufrió RSA. Dicha empresaba se dedicaba (y dedica) a crear dispositivos para verificar y proporcionar autenticación en dos pasos a aplicaciones y servicios (como Yubico).
Los atacantes obtuvieron las semillas que la empresa usaba para generar sus productos y las utilizó para atacar a terceros. Este tipo de ataques, que atacan a intermediarios para acceder a los datos de clientes finales, son conocidos con el nombre de ataques de cadena de suministro (Supply Chain attacks).
Aunque un ataque puede aprovechar vulnerabilidades no conocidas, la mayoría son conocidas y se ejecutan sobre sistemas desactualizados con falta de mantenimiento. La mejor manera de evitarlos es mantener nuestros sistemas actualizados tan pronto como sea posible.
Cada sistema operativo recibe parches regularmente que nosotros sólo debemos aplicar, pero si somos desarrolladores, los encargados de verificar que nuestra aplicación es segura somos nosotros. Puesto que a medida que nuestra aplicación crece, el número de dependencias se dispara, ¿cómo podemos seguir las actualizaciones de nuestras dependencias de forma eficiente?
2021-05-16 14:00
Los que me conocen saben que siempre intento planificar a medio plazo e invertir mi tiempo para lograr un fin gracias al trabajo duro y la constancia.
Esto hace que en ocasiones, tenga invertir todo el tiempo del que dispongo para conseguir algo en concreto. Es algo que ya ha ocurrido en el pasado varias veces y que ha vuelto a ocurrir por el mismo motivo.
Debido a las ansias de conocimiento y a un cambio de posición laboral, he dedicado unos tres meses (unas 120 horas en total) en prepararme una certificación nueva y por fin puedo decir que soy un Solutions Architect de nivel Professional en Amazon Web Services. Gracias a poder reaprovechar parte del conocimiento que poseía de GCP, he podido realizar algunos atajos, pero igualmente la preparación del examen ha requerido mucho tiempo de estudio debido a la inmensa cantidad de servicios de los que dispone AWS.
Nota del autor: pese a que en el momento de escribir el post, recomendé A Cloud Guru, ahora mismo (en 2023) la mejor plataforma para estudiar AWS es Cantrill, cuyo link dejaré en la documentación del post.
2021-02-16 18:00
Aunque 2020 ha sido un año muy duro en términos sociales, la verdad es que yo he tenido suerte: ni yo ni nadie cercano ha cogido la COVID-19 (toquemos madera), he podido continuar realizando mi trabajo con relativa normalidad y, además he podido profundizar más en algunos de los aspectos de mi carrera profesional.
Uno de estos aspectos ha sido la infraestructura como código. Terraform es una herramienta muy útil y potente, pero como ya sabemos: un gran poder conlleva una gran responsabilidad. Al igual que nos permite crear infraestructuras muy complejas rápidamente, también permita meter la pata de forma estrepitosa si no tomamos las debidas precauciones. Un terraform apply desafortunado puede eliminar toda la infraestructura desplegada y los datos de la aplicación en ella contenida.
En este post vamos a mostrar como evitar este tipo de problemas, refactorizando el código de Terraform actual utilizado en tangelov.me y a crear un proceso automático y un sistema de tests que asegure que la aplicación de cualquier cambio sea segura, incluso en entornos productivos.
2021-01-19 19:00
Cuando decidí comenzar este blog, me puse algunas algunas lineas rojas a la hora de gestionarlo y evolucionarlo. Una se basaba en el respeto a los usuarios, evitando el uso de sistemas de tracking como Google Analytics y obteniendo datos sólo de las peticiones recogidas por los servicios que utilizo en Google Cloud.
Los únicos datos en mi mano son los que dejan las peticiones de los visitantes en el balanceador que tiene incorporado Google App Engine. Gracias a ellos, pude crear un par de informes en Google Data Studio, una herramienta gratuita de visualización de datos, que permite hacer unos informes bastante vistosos y que me permitieron conocer al menos qué posts eran los más visitados.
En aquel momento, mi conocimiento de Data Studio era casi nulo así que el resultado de dicha prueba fue bastante mediocre. A día de hoy, esto ha cambiado y dominio tanto Data Studio como BigQuery con bastante soltura, por lo que decidí darle una vuelta de tuerca y hacer un nuevo panel en condiciones.
En este post, vamos a hablar de toda la infraestructura creada para poder generar dichos paneles, cómo adaptar nuestro código a la versión 0.14 de Terraform y cómo explotar los datos desde Data Studio de forma sencilla.
2021-01-13 22:00
¡La nube está de moda! Desde hace años, pero más desde la pandemia de COVID-19, todo el mundo quiere aprovechar sus ventajas y beneficios (pago por uso, escalabilidad, integraciones, mayor velocidad de desarrollo, etc).
Sin embargo, la forma en la que se usa la nube, puede variar mucho en función de las necesidades de cada cliente o usuario. Mientras unos apuestan por desarrollar todas sus aplicaciones futuras en ella, otros simplemente mueven aplicaciones ya desarrolladas. Por lo que me he encontrado a nivel personal, diría que la forma de uso suele estar entre esos dos extremos: con aplicaciones nuevas y aplicaciones legacy.
Considero que existen tres formas diferentes de llevar aplicaciones a la nube:
-
La primera es llamada Lift and Shift. Este modelo replica en la nube elegida, la infraestructura y la arquitectura de la aplicación legacy. Por ejemplo: si ésta se componía de tres servidores de aplicaciones, en tres máquinas virtuales y un balanceador, los creamos en nuestro proveedor y lo configuramos simulando a nuestro viejo CPD. Aunque es la forma más rápida y económica de utilizar la nube, también es la que menos permite aprovechar sus beneficios.
-
La segunda yo la llamo Mutated infrastructure. En ella se realizan pequeñas adaptaciones a la infraestructura para que ésta pueda integrarse con algunos servicios de la nube. De esta forma, nuestra aplicación puede ganar algunas ventajas como escalabilidad y resilencia. Es un proceso más lento que el primer modelo, pero aporta beneficios inmediatos a un coste relativamente bajo.
-
La tercera es Rearchitecture. Es la forma más laboriosa y requiere modificar partes del código de la aplicación para aprovechar toda la potencia de la nube. Requiere un proceso de reaquitectura de la aplicación completo, que puede ser muy costoso y por ello, no siempre se realiza.
Para los dos primeros casos, solemos partir de modelos basados en máquinas físicas o virtuales y en el tercero, se suele optar o bien por soluciones de tipo PaaS o por fragmentar dichas aplicaciones en contenedores.
Packer es una grandísima herramienta (de la que ya he hablado) para coger dichas máquinas virtuales o físicas y replicarlas en la nube, algo tremendamente útil en una migración a la nube.
En este post, vamos a simular una migración hacia la nube, realizando algunas mejoras y explicando los motivos de la misma. Manos a la obra :) .
2020-11-01 20:00
A finales del año 2018 hice una pequeña retroespectiva sobre qué futuro quería para este blog. En ese momento mis metas se centraron en continuar escribiendo contenido, adaptar más el tema a mis gustos y lograr una mayor interacción con la comunidad (con colaboraciones, habilitando un sistema de comentarios, etc).
Tras realizar varias pruebas, me di cuenta de algunas de las limitaciones que tenía Nikola respecto a otros generadores de código estático: su comunidad es reducida y su desarrollo, sin llegar a detenerse, avanza muy lentamente. A mi pesar, descubrí que algunas de las funcionalidades que deseaba, iban a necesitar mucho trabajo y decidí priorizar la creación de nuevo contenido frente a la funcionalidad.
Esto cambió hace unos meses: recibí un correo de parte de un mibro de Platform9 donde me daba feedback respecto al blog y me hacía una serie de recomendaciones para lograr tener más visibilidad. Tomé nota al respecto y me puse manos a la obra: era el momento de dejar atrás Nikola por otro generador.
A nivel personal, no había utilizado ningún otro generador de código estático, pero tras unas cuantas pruebas rápidas decidí utilizar Hugo, puesto que teóricamente cubría todas las necesidades que había detectado.