Popular Tags:

Apuntes de Python 3 (2ª Parte)

11 noviembre 2016 at 17:22 by Adrián Pérez

python3Ya tenemos aquí el segundo post de apuntes de Python 3, que sigue al primero que publiqué hace ya unos meses. Pincha en el siguiente link si te lo perdiste:

Apuntes de Python3 (1ª Parte)

1. Funciones (continuación)

Argumentos de la función (continuación)

Podemos setear un valor por defecto de uno o más argumentos de la función, de tal manera que si al llamar a la función no le pasamos dichos argumentos, éstos tomarán el valor por defecto. Podemos pasarle como valor por defecto, una variable, pero mucho cuidado pues el valor por defecto se seteará en el momento de la definición, con lo que si modificas la variable después de la definición de la función, no variará el valor por defecto del argumento.

>>> def myfunc(a,b=33,c='hello'):
>>>   print(a,b,c)
>>>
>>> myfunc(1,2)
1 2 hello

Respecto a los argumentos al llamar a una función, deberíamos usar "keyword arguments" (aka "kwargs") en lugar de argumentos posicionales. Es más largo pero es mucho más claro.

def myfunc(a,b,c):
   pass
 
myfunc(1,2,3)            #argumentos posicionales
myfunc(a=1,b=2,c=3)      #kwargs

Podemos usar un único argumento al definir la función para capturar cualquier número de argumentos posicionales (un asterísco) o kwargs (dos asteríscos) que se le pasen a la función.

def myfunc(*myargs):     #myargs será una tupla con todos los argumentos posicionales
def myfunc(**mykwargs):  #mykwargs será un diccionario con todos los kwargs

Bash bang commands y más

15 septiembre 2016 at 11:26 by Adrián Pérez

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.

Docker: Gestión y Administración

11 septiembre 2016 at 16:12 by Adrián Pérez

docker

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] <container_name>
</container_name>

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 <container_name>
</container_name>

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.

Apache Maven

30 junio 2016 at 16:51 by Adrián Pérez

maven-logo-black-on-whiteRecupero un post que ha estado en borradores un largo tiempo, pese a que ahora esté de moda Gradle :)

Teniendo en cuenta que vengo del mundo PHP, estaba empezando a documentarme sobre Apache Maven (una herramienta para la gestión -compilación, reporting y documentación- de proyectos Java) y sin tener demasiada idea, me ha parecido que tiene cierta similitud con Apache Ant. Como no podía ser de otra manera, no soy el primero que se ha preguntado en qué se diferencia Apache Ant de Apache Maven, y en StackOverflow dan un par de respuestas interesantes:

"Ant is an imperative build system, whereas Maven is a declarative build system" -> Un script ant le dice a ant qué ha de hacer, mientras que un script maven le dice a maven qué es lo que quieres conseguir, y maven se encarga de hacerlo.

Maven nació con la intención de estandarizar la creación de proyectos Java, definir de forma clara en qué consiste un proyecto determinado, facilitar la publicación de la información del proyecto y permitir la compartición de los ficheros JAR entre diferentes proyectos.

Apuntes de Python 3 (1ª Parte)

28 junio 2016 at 19:41 by Adrián Pérez

python3
Bueno, este artículo contiene una serie de apuntes que me han parecido interesantes, referentes a un curso sobre Python 3. Así pues, no es ni mucho menos, un curso de Python 3, pero con suerte le será de utilidad a alguien (además de a mí mismo). De momento, aquí el primer post que he creado mientras he ido avanzando en el curso.

1. Introducción

1.1. ¿Por qué Python?

  • Escritura eficiente: requiere escribir menos código que otros lenguajes
  • Lenguaje de alto nivel y propósito general
  • Funciona bajo cualquier sistema operativo
  • Popular y gratuito
  • Cercano al pseudo-código, enfatiza la legibilidad

1.2. ¿Qué es Python?

  • Soporta múltiple paradigmas de programación (orientación a objetos, funcional, etc.)
  • Type checking done at runtime
  • Gestión automática de la memoria / garbage collector
  • Modular (core pequeño, extensible con módulos)
  • El código python puede ser paquetizado en un único ejecutable listo para distribuir (ej. dropbox)
  • Open-Source
  • Uno de los objetivos más importantes de los "pythoneros" es que sea un lenguaje divertido de usar
  • Creado por Guido van Rossum (aka BDFL)

Introducción a Docker

30 enero 2016 at 18:34 by Adrián Pérez

aaaaasdddd

He aprovechado las navidades para verme los dos primeros vídeos super didácticos que Docker tiene en su web. Como es un tema interesante, he decidido a hacerme un pequeño resumen.

1. Introducción a Docker

1.1. ¿Qué es docker?

"Docker es una plataforma para desarrollar, enviar y correr aplicaciones usando tecnología de virtualización de containers".

1.2. Ok... ¿Qué es un container?

"La virtualización basada en containers usa el kernel del sistema operativo del host para correr múltiples instancias guest" (llamadas containers). Cada container tiene su propio:

  • root filesystem
  • procesos
  • memoria
  • devices
  • puertos de red

Si estás pensando en que suena a una máquina virtual, en efecto, los containers serían la evolución de las máquinas virtuales, pues a diferencia de éstas, los containers no necesitan un sistema operativo guest instalado en cada máquina virtual, ni un hypervisor, con el consiguiente ahorro descomunal de recursos. Aquí una comparativa entre un servidor físico que aloja máquinas virtuales (izquierda) y otro que aloja containers (derecha) sacada directamente de los vídeos de Docker:

Containers_VS_VM

Así pues, los containers usan el kernel del sistema operativo para crear entornos aislados en los que correr una aplicación y todas las librerías de las que depende.

Integración Continua vs Continuous Delivery vs Continuous Deployment

7 mayo 2015 at 10:53 by Adrián Pérez

delivery

Bueno, lo primero es lo primero: este post no es la verdad absoluta, así que si vienes en busca de iluminación, espero que esta entrada sirva como punto de partida, pero te recomendaría leer todo lo posible sobre este tema, empezando por consultar los enlaces del final del post.

Por mi parte, con esta entrada he querido resumir los conceptos principales de cada una de estas prácticas, para intentar aclarar(me) con las diferencias entre ellas.

Integración Continua

Los equipos de desarrollo de software que trabajan en un mismo proyecto, suelen encontrarse a menudo con los siguientes problemas:

  • Merge conflicts: dos programadores modifican el mismo fichero o incluso la misma línea, lo cual da lugar a conflictos que deben resolverse y que pueden llegar a ser un quebradero de cabeza.
  • Compile conflicts: si por ejemplo un programador usa el método foo() y alguien elimina ese método, ésto no dará problemas al hacer el merge, pero a nivel de compilación dará error porqué no encontrará ese método.
  • Test conflicts: un ejemplo de test conflict sería cuando tu código depende de otro que ha cambiado (y ahora funciona diferente), lo cual haría que tu código no esté funcionando como esperabas y por tanto tu código no pase los tests.

La integración continua es una práctica de desarrollo de software que pretende minimizar este tipo de conflictos, permitiendo a las desarrolladores desarrollar, en lugar de perder su tiempo solucionando conflictos. La idea básica es que los desarrolladores commiteen los cambios muy frecuentemente (al menos una vez al día) para que en caso de conflicto se puedan solucionar de forma más rápida y sencilla, pues el propio programador tendrá el código que acaba de commitear “fresco” en su cabeza, y además no tendrá que preocuparse de investigar grandes cantidades de código, pues al commitear muy frecuentemente sabe que ha cambiado poco código desde su anterior commit.

La integración contínua, pues, consiste en automatizar los tests y los builds de tu software muy frecuentemente. A no ser que seas el único desarrollador en un proyecto, no hay razón por la que no quieras usar integración continua.

Instalación de Zabbix

22 marzo 2015 at 19:35 by Adrián Pérez

zabix¿Por qué Zabbix?

Acostumbrado a Nagios, lo primero que busqué en Google para documentarme sobre Zabbix, fue la cadena "Zabbix vs Nagios" (hay un debate muy interesante en reddit). En cualquier caso, aquí hacen una buena comparación entre ambos sistemas de monitorización.

Tras unos días con Zabbix, mi primera impresión es que la configuración vía web de Zabbix quizá sea más amigable que la configuración vía archivos de Nagios, aunque sin duda (y quizá por pasar varios años con Nagios) ésta última resulta más sencilla que no la de Zabbix, que requiere de múltiples configuraciones para poder monitorizar un elemento (el ítem en sí, su triger, el action asociado, la aplicación del ítem, etc.).

Un punto a favor de Zabbix es que parece que la comunicación cliente servidor no ocasionará los problemas que alguna vez me he encontrado con Nagios, de falsos positivos debidos a timeouts en la conexión SSH entre el servidor Nagios y el host a monitorizar (Nagios requiere de plugins adicionales para monitorizar vía NRPE).

A favor de Nagios, pero, está la gran cantidad de plugins que la comunidad ha puesto a nuestra disposición en Nagios Exchange, a primera vista mucho más completos que los plugins de Zabbix.

Componentes de Zabbix

Zabbix consta de un seguido de componentes que interaccionan entre sí:

  • Zabbix agent: el agente (o cliente) de Zabbix se instala en aquellos elementos a monitorizar. El agente se encargará de recoger información del sistema y de las aplicaciones y se las hará llegar al Zabbix server. El Zabbix agent puede recoger datos:
    • de forma pasiva: el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato.
    • de forma activa: en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server.
  • Zabbix server: el servidor de Zabbix y por tanto la pieza principal. Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc. El servidor por tanto, es el repositorio central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidos de los agentes.
  • Proxy (opcional): se trata de un "recolector de datos" que se situa entre el servidor y los agentes. Si se tiene por ejemplo servidores repartidos en 5 datacenters, cada datacenter podría tener su propio proxy encargado de recoger los datos de los agentes de su datacenter, para posteriormente, hacerle llegar los datos al Zabbix server. Todo proxy requiere de su propia base de datos.
  • Java Gateway (opcional): permite monitorizar aplicaciones JMX (Java Management eXtensions) como WildFly/JBoss, Tomcat, Weblogic o Websphere. Zabbix Java Gateway usa la "JMX Management API" para recoger los datos de las aplicaciones JMX remotas monitorizadas.

Fuentes:
https://www.zabbix.com/documentation/2.2/manual/concepts

Instalar JBoss AS7 en entornos Red Hat

24 febrero 2015 at 19:54 by Adrián Pérez

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.

Migrar de Apache/PHP a Nginx/PHP en CentOS

24 febrero 2015 at 12:49 by Adrián Pérez

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