Blog

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

Si tenemos una AMI que no está encriptada podremos compartirla con otra cuenta de forma directa sin hacer nada especial. Pero si la AMI está cifrada, la cosa se complica, ya que la cuenta de destino no dispondrá de la clave de cifrado para poder descifrar sus snapshots y no podremos compartirla.

Por ello, si necesitamos compartir una AMI cifrada de una instancia EC2 de una cuenta a otra en AWS llevaremos a cabo el siguiente procedimiento:

El pasado diciembre Amazon anunció sus nuevos volúmenes EBS gp3, los cuales ofrecen mejores prestaciones y un ahorro en el coste del 20% respecto a los que se venían utilizando hasta ahora, los gp2. Pues bien, tras probar satisfactoriamente estos nuevos volúmenes en varios clientes, no puedo hacer otra cosa más que recomendar su utilización, pues son todo ventajas y en estos 2 meses y medio que han transcurrido desde el anuncio no he apreciado ningún problema ni efecto secundario.

Uno de los mayores fastidios cuando trabajamos con AWS y nuestra conexión a Internet tiene IP dinámica es que cuándo ésta cambia, automáticamente dejamos de tener acceso a todos los servidores y servicios que habíamos protegido mediante un grupo de seguridad EC2 cuyas reglas sólo permiten el tráfico a ciertas IP’s específicas en lugar de abrir las conexiones a todo el mundo (0.0.0.0/0).

Ciertamente lo más sencillo es siempre indicar en el grupo de seguridad que permitimos el tráfico en un puerto a todo el mundo, de modo que aunque tengamos IP dinámica en nuestra conexión a Internet siempre podremos continuar accediendo aunque ésta cambie. Pero abrir el tráfico a un puerto a todo el mundo no es la forma correcta de proceder desde el punto de vista de la seguridad, pues entonces cualquier atacante podrá tener acceso a ese puerto sin restricciones, y eso no es lo que queremos.

Son muchas las personas y empresas que por la crisis del coronavirus (Covid-19) se están viendo obligadas a adoptar distintas formas de teletrabajo en estos días. Como arquitecto de soluciones en la nube (Cloud Computing) y administrador de sistemas freelance llevo ya muchos años teletrabajando de forma remota satisfactoriamente, por lo que varias de ellas me están pidiendo durante los últimos días consejo sobre qué estrategias seguir y qué aplicaciones útiles manejar para teletrabajar desde casa de forma eficiente. Es por ello que he decidido ir un paso más allá y escribir este artículo en el que recopilo una serie de recomendaciones y de herramientas que espero que sirvan de ayuda a mucha gente que se ve obligada a desempeñar su trabajo a distancia en estos tiempos del coronavirus, aunque también espero que os resulte útil a todas aquellas personas y empresas que veáis una oportunidad en todo esto y optéis por apostar definitivamente por el trabajo en remoto, ya sea de forma parcial o total.

El siguiente procedimiento describe cómo permitir en Linux el uso simultáneo de 2 interfaces de red conectadas a la misma subred de AWS y que la comunicación funcione tanto a nivel interno (máquinas en la misma subred) como externo (ambas interfaces visibles desde Internet). Esto puede ser útil por ejemplo cuando queremos que una misma instancia aloje un servidor web que sirva peticiones http ó https y al mismo tiempo disponga de un servidor de websockets ws:// o wss:// que escuche en el mismo puerto 80 ó 443 respectivamente. Aunque hay otras formas de conseguirlo como configurar Nginx para que sea capaz de discriminar el tráfico web (http) del tráfico de websockets (ws) y actuar como proxy para redirigir las peticiones correspondientes al servidor de websockets, esta otra solución que planteo me parece más sencilla y en cierta medida más eficiente porque no es necesario redirigir el tráfico, lo cual siempre introducirá una pequeña latencia, y permite mantener ambos servidores totalmente independientes dentro de la misma máquina. La única pega es que necesitaremos asignar 2 direcciones IP elásticas (Elastic IP) a la misma máquina en lugar de 1, pero al mismo tiempo esto nos aportará mayor flexibilidad a la hora de establecer reglas en los grupos de seguridad o en las reglas NAT de la subred.

Aunque existen diferentes métodos para realizar copias de seguridad de bases de datos MySQL o MariaDB, el más común y eficiente se basa en el uso de una herramienta nativa que tanto MySQL como MariaDB ponen a nuestra disposición para este cometido: el comando mysqldump. Como su propio nombre indica, se trata de un programa ejecutable desde la línea de comandos que permite realizar una exportación completa (dump) de todo el contenido de una base de datos o incluso de todas las bases de datos presentes en una instancia de MySQL o MariaDB en ejecución. Por supuesto también permite realizar copias de seguridad parciales, es decir, sólo de algunas tablas concretas.

En este artículo voy a hablar de una app para Android que es extremadamente útil para ejecutar comandos de forma remota en un ordenador Linux: Hot Button SSH Command Widget. Esta aplicación nos permitirá lanzar cómodamente cualquier comando que se nos ocurra en un ordenador remoto a través de SSH con sólo pulsar un botón en la pantalla de nuestro móvil o tablet, lo cual no sólo nos facilitará la automatización de tareas repetitivas, sino que además resulta muy interesante desde el punto de vista de la seguridad por los mismos motivos que expuse en mi artículo Desbloqueo automático de pantalla por proximidad de dispositivo Bluetooth, ya que nos permitirá por ejemplo bloquear y desbloquear la pantalla sin tener que escribir nuestra contraseña una y otra vez a la vista de otras personas.

Una de las pocas cosas que no me gustan del servicio EC2 de Amazon Web Services es que todas las imágenes o AMI’s disponibles a partir de las cuales lanzar una nueva instancia requieren un volumen raíz o root volume de un mínimo de 8 ó 10 GB y todos ellos cuentan además con una única partición donde se monta el sistema de ficheros raíz con todos sus directorios.

En mi artículo La importancia de particionar correctamente un disco en Linux ya discutí por qué este enfoque no me parece adecuado y en este artículo voy a abordar cómo dividir dichos volúmenes en varias particiones conservando el tamaño base de 8-10 GB o haciéndolos incluso más pequeños para ahorrar costes en caso de que queramos montar servidores más pequeños que no necesiten tanto espacio de almacenamiento.