Reemplazar un data nodo de Elasticsearch de forma segura

Es probable que en alguna ocasión necesitemos reemplazar uno de nuestros nodos de datos del cluster de Elasticsearch. Una opción (a lo loco, y nada recomendable) sería directamente eliminar el nodo, y añadir uno nuevo, el cual, en algún momento se sincronizará con el cluster. Obviamente lo malo de esta opción, es que el cluster quedará en status yellow o red mientras no termine la sincronización.

Una buena opción (probado en un ES 5.6.3) para hacer de este proceso, un proceso seguro y controlado, es como primer paso, quitar el nodo del cluster, esperar a que los shards (primarios y réplicas) se re-asignen, y una vez tengamos el nodo desacoplado del cluster, reemplazarlo. La idea es continuar con el cluster en “green” durante todo el proceso.

A continuación los pasos.

Continuar leyendo “Reemplazar un data nodo de Elasticsearch de forma segura”

Usa diferentes versiones de terraform con tfenv

Cuando trabajas en grandes entornos gestionados con terraform, es muy probable que tengas que trabajar a su vez con diferentes versiones de terraform, según requieran cada unos de los proyectos.

En lugar de descargar las diferentes versiones que necesitemos, renombrando los ejecutables, moviéndolos a algún directorio dentro del PATH y jugando con enlaces simbólicos, podemos símplemente usar el maravilloso tfenv.

Descarga e instalación

Para empezar a usar tfenv, lo único que necesitaremos será clonar el repositorio (por ejemplo en nuestra home) y crear un enlace simbólico para que tfenv esté disponible en el PATH.

[adri@adri ~]$ git clone https://github.com/kamatama41/tfenv.git ~/.tfenv
Cloning into '/home/adri/.tfenv'...
remote: Counting objects: 716, done.
remote: Total 716 (delta 0), reused 0 (delta 0), pack-reused 716
Receiving objects: 100% (716/716), 102.65 KiB | 0 bytes/s, done.
Resolving deltas: 100% (449/449), done.
Checking connectivity... done.

[adri@adri ~]$ sudo ln -s ~/.tfenv/bin/* /usr/local/bin

Continuar leyendo “Usa diferentes versiones de terraform con tfenv”

Resumen para el AWS Solutions Architect Associate

Tras casi un año acumulando borradores en el blog, por fín publico algo. Dejo aquí el resumen (con notas en inglés y español) que hice para la certificación de AWS Solutions Architect Associate (que me saqué a través del curso de A Cloud Guru). Hice el examen a finales de Octubre de 2017, así que a día de hoy, debería ser útil para aquellos que quieran subir a examinarse en breve.

El resumen consta de las siguientes secciones
1. IAM
2. S3
3. EC2
4. EFS
5. Lambda
6. Route53
7. Databases
8. VPC
9. Application Services
10. Whitepaper: Security
11. Exam feedback
12. Random notes

Al final del post dejo un enlace al resumen en PDF.

1. IAM


  • Users, Groups (users heritage its policies), Roles (for aws resources) and Policies (json)
  • Global
  • Root Account (never use it) + MFA
  • By default new users have no permissions
    • Programmatic access
    • AWS Management console access
  • IAM password policy
  • Roles:
    • AWS Service Role – The usual one, and the one we are interested in
    • AWS service-linked role: for Alexa
    • Role for cross-account access: allow IAM users to access to another AWS accounts
    • Role for identity provider access: grant access from Cognito, or OpenID (facebook, google, amazon), SAML, etc

Continuar leyendo “Resumen para el AWS Solutions Architect Associate”

Here documents (<<), Here strings (<<<) y el comando "read"

bash

<< (Here documents)

Un here document es un tipo de redirección que le dice al shell que vaya leyendo el input que se le está pasando hasta encontrar una determinada palabra clave (‘TAG’ en el ejemplo).

cat >> file << 'TAG'
primera línea
segunda línea
última línea
TAG

Consiste, pues, en un bloque de código cuyas líneas se pasan una a una a un comando o programa interactivo (como ftp o cat). Podemos usar cualquier TAG para indicar el final del bloque que compone el here document, pese a que se suele usar “EOF”, pero podríamos usar cualquier cosa, mientras estemos seguros de que será una cadena de carácteres que no se usará dentro del bloque que queremos procesar.

Un posible uso es el de añadir un bloque de líneas a un fichero. Cabe decir que el here document incluirá los espacios/tabs de inicio de cada línea. Si no es lo que quieres, puedes eliminar los tabs de inicio de línea al procesar el here document añadiéndo un “-” justo tras la redirección y antes del tag (quedaría “<<-“). Aquí un ejemplo manteniendo tabs y usando variables dentro del bloque:

NOMBRE="$1"
cat >> file << EOF
Hola $NOMBRE
este es mi bloque de líneas
que guardaré en file
        esta línea tiene un tab 
  y esta dos espacios
EOF

Continuar leyendo “Here documents (< <), Here strings (<<<) y el comando "read""

Bash bang commands y más

bash
A continuación una serie de comandos útiles en bash, que (por lo menos a mí) me viene bien tener a mano, razón por la cual seguramente este post se actualice varias veces a medida que vaya añadiéndo comandos útiles a mi día a día.

“$?”: Exit code

“$?” Muestra el exit code del comando que se acaba de ejecutar.

[adri@localhost tmp]$ cat test 
#!/bin/bash
exit 0
[adri@localhost tmp]$ ./test 
[adri@localhost tmp]$ echo $?
0
[adri@localhost tmp]$ cat test 
#!/bin/bash
exit 1
[adri@localhost tmp]$ ./test 
[adri@localhost tmp]$ echo $?
1

Ésto se puede usar dentro de scripts en bash, para saber cómo ha acabado la línea anterior del script, lo cual puede resultar muy muy útil.

Continuar leyendo “Bash bang commands y más”

Docker: Gestión y Administración

aaaaasdddd

Tenía pendiente ver el tercer vídeo de self-training que tiene Docker en su web. Como soy mucho de hacer resúmenes de aquello que me parece interesante (para interiorizar y poder volver a consultarlo más adelante), y ya que hice lo propio con la entrada “Introducción a Docker“, con este tercer vídeo no podía hacer menos.

Container troubleshooting

Podemos ver la salida del proceso con PID 1 (correspondiente al “comando” pasado en el “docker run”) con “docker logs”.

docker logs [-f] 

Otra opción, es directamente mapear un directorio del host al directorio de logs de la aplicación que se corre en el container:

docker run -d -P -v /nginxlogs:/var/log/nginx nginx

Con “docker inspect” devolveremos todos los detalles del contendor en un json.

docker inspect 

En /etc/default/docker se define la variable DOCKER_OPTS, la cual controla las opciones de arranque cuando iniciamos docker como servicio. Por ejemplo, podremos cambiar el nivel de log por defecto especificándolo en DOCKER_OPTS mediante la opción “–log-level”, la cual dejará los logs en /var/log/upstart/docker.log. Esta variable nos dará mucha flexibilidad.

Continuar leyendo “Docker: Gestión y Administración”

Instalar JBoss AS7 en entornos Red Hat

JBoss_logoJBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo aquí o aquí. Voy a copiar literalmente una respuesta de StackOverflow que explica la diferencia entre un Servlet Container como Tomcat y un Application Server como JBoss:

A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE – EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology.” por Bozho

Ahora que quizá tenemos algo más claro qué es JBoss y por qué este post no habla sobre Tomcat, faltará ver qué diferencias hay entre la versión de la comunidad y la enterprise (más info aquí). Como es de esperar, la versión de la comunidad siempre irá por delante respecto a la empresarial en cuanto a novedades y funcionalidades, con lo cual no estará tan testeada ni será tan estable como debería ser la versión empresarial, más pensada para alojar aplicaciones críticas.

En esta entrada se instalará y pondrá en marcha la versión de la comunidad.

Continuar leyendo “Instalar JBoss AS7 en entornos Red Hat”

Migrar de Apache/PHP a Nginx/PHP en CentOS

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la “guía definitiva”.

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Continuar leyendo “Migrar de Apache/PHP a Nginx/PHP en CentOS”

Algunos apuntes sobre Bash

bashHe querido recoger algunas notas de Bash scripting para no tener que correr a Google (o a cualquier página de StackExchange) cada vez que las dudas me asalten.

/usr/bin/env bash vs /usr/bin/bash

Leí en la siguiente página sobre las “mejores prácticas en Bash” acerca del uso de “#!/usr/bin/env bash” en lugar del habitual “#!/usr/bin/bash” o “#!/bin/bash“. La idea es usar”#!/usr/bin/env bash” pues de esta manera lo que hacemos es buscar en el PATH dónde está bash, el cual es probable se encuentre en ubicaciones distintas en servidores diferentes. Ésto evitará problemas portando scripts a otros entornos. [Más info] [2]

#!/usr/bin/env bash

Corchete simple vs Doble corchete

Básicamente, ambos sirven para evaluar expresiones. “[” es un alias para el comando “test” y tanto uno como el otro están disponibles en el estándar POSIX. “[[” sin embargo es una keyword, no un programa, y se trata una versión mejorada para evaluar expresiones, únicamente disponible en Bash, KornShell y Zsh. Si no estás preocupado por la portabilidad de tus scripts con sistemas donde no cuentes con Bash, es mejor usar siempre el doble corchete, por la funcionalidad extra que aporta (posibilidad de usar && y ||, expresiones regulares, pattern matching, etc.). [Más info] [2]

La siguiente evaluación será “true” pues b és mayor que a, 8 mayor que 4, y abcd entra dentro del patrón “a*”:

if [[ b > a && 8 -gt 4 && abcd = a* ]]; then ...

PD: Dejo un enlace a la wikipedia donde se especifican los nombres en inglés de éstos símbolos, según la zona.

Continuar leyendo “Algunos apuntes sobre Bash”

Configuración inicial de un servidor CentOS

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

Continuar leyendo “Configuración inicial de un servidor CentOS”