joe di castro

Fabric & Rsync para realizar Backups

2011-07-13T20:21:00+02:00

En el anterior articulo empleaba fabric y rsync para sincronizar un directorio local y uno remoto en ambas direcciones. Además le añadía las funcionalidades de logger y notify para proporcionar información sobre el proceso durante y después de su ejecución. Y comenzaba el articulo recordando a lftp-mirror, el script que había creado para realizar la sincronización a través de FTP. Pero lftp-mirror realiza algo más que la sincronización, pues también permite realizar el archivado del directorio local en ficheros comprimidos y lanzar varias tareas en una sola ejecución.

Ahora he añadido esta funcionalidad al fichero fabric creado anteriormente. Así empleando este fichero podemos realizar el Backup periódico de varios servidores en una sola operación y de forma completamente automática (basta con programar su ejecución). Se sincronizan los dos directorios y se crea un archivo comprimido del directorio local por cada día de la semana. De este modo siempre tenemos una copia del estado del directorio remoto de los últimos siete días. Y al final del proceso en nuestro correo, un email con el informe del resultado por cada una de las tareas ejecutadas.

En este fichero, rsync_fabric.py, disponemos de tres posibles tareas:

$ fab -l

     A Fabric file for sync two directories (remote ⇄ local) with rsync.

Available commands:

    backup  Sync from remote to local & archive the local directory.
    down    Sync from remote to local.
    up      Sync from local to remote.

Con la primera realizamos el backup (sincronización + archivado) y con las siguientes solo la sincronización desde o hacia el servidor. Una de las ventajas de fabric es que nos permite concatenar tareas fácilmente desde la línea de comandos, así podemos lanzar varias sincronizaciones de forma simultanea. Para poder realizar esto, creo una configuración de sincronización por defecto y después creo una función para cada una las tareas adicionales que simplemente redefinen los valores de estas variables globales. Por ejemplo:

# Variables globales de sincronización predefenidas
env.host_string = "username@example.com"
env.remote = "/my_directory"
env.local = "/home/my_user/backups/my_directory"

# Redefinimos estas variables para otra configuración de sincronización. Por 
# supuesto, pueden tratarse de servidores distintos.
def _databases():
    global env
    env.host_string = "username@example.com"
    env.remote = "/databases"
    env.local = "/home/my_user/backups/databases"

Veamos ejemplos de como podemos utilizar estas tareas:

# "Si queremos sincronizar el contenido local hacia el remoto, por ejemplo 
# para subir los ficheros al servidor por primera vez. Empleando los valores 
# por defecto. El modificador -w lo empleo para que no se detenga en los 
# errores, que de ocurrir, los veremos luego en el informe final."
$ fab -w up
[localhost] local: rsync -pthrvz --delete /home/my_user/backups/my_directory/ 
 username@example.com:my_directory

Done.
# "Pero también podemos especificar una tarea distinta a la por defecto de 
# este modo. Sincronizando desde el servidor a nuestro directorio local las 
# bases de datos."
$ fab -w down:databases
[localhost] local: rsync -pthrvz --delete username@example.com:databases/ 
/home/my_user/backups/databases

Done.
# "Y por supuesto, podemos realizar varias tareas a la vez."
$  fab -w down backup:databases
[localhost] local: rsync -pthrvz --delete username@example.com:my_directory/ 
/home/my_user/backups/my_directory
[localhost] local: rsync -pthrvz --delete username@example.com:databases/ 
/home/my_user/backups/databases

Done.

No empleo contraseña alguna, ni en el fichero ni en la línea de comandos, podría hacerse perfectamente, pero prefiero emplear una clave RSA pública autorizada para las sesiones SSH en el servidor. Es bastante más seguro y cómodo. En los ejemplos no se ve la salida de rsync, pues es capturada (así como los erores) para ser mostrada a posteriori en los informes.

Un ejemplo de informe sería el siguiente:

START TIME =====================================================================
                                                    miércoles 13/07/11, 19:48:55
================================================================================

SCRIPT =========================================================================
fab (ver. Unknown)
Fabric Rsync
http://joedicastro.com

Syncing username@example.com:databases to /home/my_user/backups/databases
================================================================================

RSYNC OUTPUT ___________________________________________________________________

receiving file list ... done

sent 20 bytes  received 825 bytes  153.64 bytes/sec
total size is 827.76M  speedup is 979595.42

ROTATE COMPRESSED COPIES _______________________________________________________

Created file:

/home/my_user/backups/databases_13jul2011_19:49_mié.tar.gz

Deleted old file:

databases_13jul2011_19:37_mié.tar.gz

DISK SPACE USED ================================================================
                                                                        1.60 GiB
================================================================================

END TIME =======================================================================
                                                    miércoles 13/07/11, 19:50:02
================================================================================

Que como podemos ver, ha tardado poco más de un minuto en sincronizar 827.56 Megabytes y el total de espacio ocupado por el directorio y los siete archivos comprimidos es de 1.60 Gibibytes (1,72 Gigabytes).

Ventajas

Las ventajas de sincronizarlo con rsync + ssh vs ftp, como ya comenté en el anterior articulo son enormes. Se ahorra muchísimo tiempo y ancho de banda, lo que ayuda a no saturar la red y no tener que planificar con tanto cuidado las ventanas de backup. Por ejemplo he realizado unas pruebas y para las mismas condiciones: mismo servidor, mismo directorio, mismo horario y condiciones de red; la sincronización remoto → local a través de FTP emplea entre 35 y 45 minutos y cuando lo hacemos a través de rsync emplea entre 2 y 4 minutos. Ahí es nada, estamos hablando de un proceso ~13 veces más rápido.

Código

El código del fichero fabric es el siguiente:

#!/usr/bin/env python
# -*- coding: utf8 -*-

import os
import glob
import tarfile
import time
from get_size import get_size as _get_size
from get_size import best_unit_size as _best_unit_size
from logger import Logger as _logger
from notify import notify as _notify
from fabric.api import env, local

LOG = _logger()

#===============================================================================
# RSYNC HOSTS
#===============================================================================

# Your default host. No need any more if only wants a host.
env.host_string = "username@host"
env.remote = "/your/remote/path"
env.local = "/your/local/path"

# If wants to use various hosts, then define the previous variables like this, 
# one function per host. 
def _host_1():
    """Host variables for host_1."""
    global env
    env.host_string = "username@host_1"
    env.remote = "/your/remote/path/in/host_1"
    env.local = "/your/local/path/for/host_1"

def _host_2():
    """Host variables for host_2."""
    global env
    env.host_string = "username@host_2"
    env.remote = "/your/remote/path/in/host_2"
    env.local = "/your/local/path/for/host_2"

# ...
#
# def _host_n():
#     """Host variables for host_n."""
#     global env
#     env.host_string = "username@host_n"
#     env.remote = "/your/remote/path/in/host_n"
#     env.local = "/your/local/path/for/host_n"

#===============================================================================
# END RSYNC HOSTS
#===============================================================================

def _log_start():
    """Create the Start time info block for the log."""
    # Init the log for multiple hosts. Do not repeat the previous logs.
    if LOG.get():
        LOG.__init__()
    LOG.time("Start time")

def _log_end(task):
    """Create the End time info block and send & write the log."""
    _notify("Rsync", "Ended" , "ok")
    LOG.time("End time")
    LOG.free(os.linesep * 2)
    LOG.write(True)
    LOG.send("Fabric Rsync ({0})".format(task))

def _check_local():
    """Create local directory if no exists."""
    if not os.path.exists(env.local):
        os.mkdir(env.local)

def _rsync(source, target, delete):
    """Process the _rsync command."""
    _log_start()
    LOG.header("Fabric Rsync\nhttp://joedicastro.com",
               "Syncing {0} to {1}".format(source, target))
    _notify("Rsync", "Start syncing {0} to {1}".format(source, target), "info")
    out = local("rsync -pthrvz {2} {0}/ {1}".
                format(source, target, "--delete" if delete == "yes" else ""),
                capture=True)
    _notify("Rsync", "Finished synchronization", "ok")
    LOG.list("Rsync Output", out)
    if out.failed:
        LOG.list("Rsync Errors", out.stderr)

def _compress(path):
    """Compress a local directory into a gz file.

    Creates a file for each weekday, an removes the old files if exists"""
    os.chdir(os.path.join(path, os.pardir))
    dir2gz = os.path.basename(path)
    old_gzs = glob.glob('{0}*{1}.tar.gz'.format(dir2gz, time.strftime('%a')))
    gz_name = "{0}_{1}.tar.gz".format(dir2gz, time.strftime('%d%b%Y_%H:%M_%a'))
    gz_file = tarfile.open(gz_name, "w:gz")
    gz_file.add(path, arcname=dir2gz)
    gz_file.close()
    output = os.linesep.join(['Created file:', '', os.path.join(os.getcwd(),
                                                                gz_name)])
    for old_gz in old_gzs:
        os.remove(old_gz)
        output += os.linesep.join([os.linesep, 'Deleted old file:', '', old_gz])
    return output

def _archive():
    """Archive the local directory in a gz file for each weekday."""
    _notify('Rsync', 'Compressing folder...', 'info')
    LOG.list('Rotate compressed copies', _compress(env.local))
    _notify("Rsync", "Finished compression", "ok")

def _get_diskspace():
    """Get the disk space used by the local directory and archives."""
    gz_size = sum([_get_size(gz) for gz in glob.glob('{0}*.gz'.
                                                     format(env.local))])
    log_size = _get_size(LOG.filename) if os.path.exists(LOG.filename) else 0
    local_size = _get_size(env.local)
    size = _best_unit_size(local_size + gz_size + log_size)
    LOG.block('Disk space used', '{0:>76.2f} {1}'.format(size['s'], size['u']))

def up(server=None, dlt='yes'):
    """Sync from local to remote."""
    globals()["_" + server]() if server else None
    _rsync(env.local, ":".join([env.host_string, env.remote]), dlt)
    _log_end(server)

def down(server=None, dlt='yes', archive=False):
    """Sync from remote to local."""
    globals()["_" + server]() if server else None
    _check_local()
    _rsync(":".join([env.host_string, env.remote]), env.local, dlt)
    if not archive:
        _log_end(server)

def backup(server=None):
    """Sync from remote to local & archive the local directory."""
    down(server, archive=True)
    _archive()
    _get_diskspace()
    _log_end(server)

El fichero siempre actualizado puede ser encontrado en el repositorio Python Recipes que está alojado en github con el nombre rsync_fabfile.py

Sincronizar dos directorios con Fabric y Rsync

2011-07-06T22:02:00+02:00

Anteriormente habíamos visto como sincronizar un directorio remoto y uno local empleando solamente FTP. Ahora vamos a ver la forma de hacerlo empleando ssh y rsync. Para ello vamos a utilizar otra vez Python y una herramienta muy valiosa para cualquier sysadmin que se precie como es fabric (que descubrí gracias a Manuel Viera en esta pregunta en majibu). Evidentemente realizar la sincronización con rsync esta a años luz de hacerlo con FTP, la velocidad de sincronización, el tiempo empleado y la cantidad de datos a mover son mucho menores. FTP es algo que debería utilizarse únicamente cuando no disponemos de acceso via SSH.

La gran ventaja de fabric es que nos permite ahorrarnos el tener que implementar el acceso SSH con paramiko y la entrada de opciones y argumentos con argparse. Gracias a esto los scripts necesarios son mucho más cortos y limpios y su utilización es bastante más sencilla. Fabric ya incorpora una función para emplear rsync, rsync_project, dentro de su modulo de proyectos contribuidos fabric.contrib.project

Una forma de implementar esta sincronización en ambas direcciones empleando esta función predefinida sería esta:

from fabric.api import env, hosts, local
from fabric.contrib.project import rsync_project

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

@hosts(env.host_string)
def rsync_up(dlt="yes"):
    rsync_project(REMOTE_PATH, LOCAL_PATH + "/", 
                  delete= True if dlt == "yes" else False)

def rsync_down(dlt="yes"):
    local("rsync -pthrvz {0}:{1}/ {2} {3}".
          format(env.host_string, REMOTE_PATH, LOCAL_PATH, 
          "--delete" if dlt == "yes" else ""))

Y luego solo tendríamos que llamar a la función deseada:

# "Para sincronizar de remoto a local"
$ fab rsync_down

Hay que tener en cuenta un detalle con fabric. Cuando se le pasa un parámetro, este es siempre convertido a una cadena. Luego al pasarle True o False no se convierte en un valor booleano, sino una cadena "True"o "False". De ahí que compruebe si el parámetro coincide con "yes" en vez de un valor booleano.

El problema con la función rsync predefinida de fabric es que esta pensada únicamente para subir archivos a un servidor remoto, es decir, es una sincronización en una sola dirección, por eso implemento la sincronización en sentido contrario sin emplearla y empleando local. La autentificación de la sesión SSH puede realizarse especificando la contraseña dentro del propio fichero, pero va en contra del sentido común emplear un método tan inseguro como este. Lo lógico es emplear autorizaciones de sesiones SSH sin contraseña por medio de una clave pública.

Podríamos prescindir de la librería incorporada dentro de fabric y tendríamos algo como esto:

from fabric.api import env, local

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

def _rsync(source, target, delete):
    """Process the _rsync command."""
    output = local("rsync -pthrvz {0}/ {1} {2}".
                   format(source, target, "--delete" if delete == "yes" else ""))

def up(dlt='yes'):
    """Sync from local to remote."""
    _rsync(LOCAL_PATH, ":".join([env.host_string, REMOTE_PATH]), dlt)

def down(dlt='yes'):
    """Sync from remote to local."""
    _rsync(":".join([env.host_string, REMOTE_PATH]), LOCAL_PATH, dlt)

Pero... un momento, si estamos empleado un comando local, no empleamos rsync_project y empleamos una clave pública para el acceso SSH, entonces no estamos empleando paramiko, ¿de que nos sirve emplear fabric?. Bueno, en realidad rsync_project también emplea local, por lo que no emplea paramiko. Pero las ventajas vienen de que, por ejemplo, este mismo script se podría modificar fácilmente para ejecutar rsync en el servidor en vez de en nuestra maquina local, empleando run en vez de local. Además podemos emplear el mismo fichero para añadir varias tareas más a realizar en el servidor, aparte de la sincronización. Podríamos prescindir de fabric y hacer esto mismo con un script con un número similar de líneas, pero esto nos permite centralizar todas las tareas más comunes sobre ese servidor en un único fichero. Por ejemplo podríamos añadir una tarea para hacer un respaldo previo de una base de datos en el servidor, empleando un comando remoto en el servidor, luego hacer la sincronización separada de la BDD y el resto de ficheros y finalmente eliminar ese respaldo. Puede haber cientos de razones para preferir emplear fabric antes de un script independiente para la sincronización.

Ejecución desatendida de la sincronización

Si queremos programar esta tarea, no sería mala idea que nos avisara de cuando comienza a ejecutarse y del resultado de la misma. Para ello puedo emplear Logger y notify, para implementar esta funcionalidad.

from logger import Logger as _logger
from notify import notify as _notify
from fabric.api import env, local

env.host_string = "username@host"
REMOTE_PATH = "/your/remote/path"
LOCAL_PATH = "/your/local/path"

def _rsync(source, target, delete):
    """Process the _rsync command."""
    log = _logger()
    log.header("Fabric Rsync\nhttp://joedicastro.com",
               "Syncing {0} to {1}".format(source, target))
    log.time("Start time")
    _notify("Rsync", "Start syncing {0} to {1}".format(source, target), "info")
    output = local("rsync -pthrvz {0}/ {1} {2}".
                   format(source, target, "--delete" if delete == "yes" else ""),
                   capture=True)
    _notify("Rsync", "Finished", "ok")
    log.list("Output", output)
    if output.failed:
        log.list("Error", output.stderr)
    log.time("End time")
    log.send("Fabric Rsync")

def up(dlt='yes'):
    """Sync from local to remote."""
    _rsync(LOCAL_PATH, ":".join([env.host_string, REMOTE_PATH]), dlt)

def down(dlt='yes'):
    """Sync from remote to local."""
    _rsync(":".join([env.host_string, REMOTE_PATH]), LOCAL_PATH, dlt)

De esta forma, nos avisaría con una notificación en el escritorio de su inicio y fin, y al acabarse la sincronización, tendríamos un informe en nuestro correo parecido a este:

SCRIPT =========================================================================
fab (ver. Unknown)
Fabric Rsync

Syncing username@host:/your/remote/path to /your/local/path
================================================================================

START TIME =====================================================================
                                                   miércoles 06/07/11, 21:50:48
================================================================================

OUTPUT _________________________________________________________________________

receiving file list ... done
./
index.php

sent 48 bytes  received 200 bytes  45.09 bytes/sec
total size is 99  speedup is 0.40

END TIME =======================================================================
                                                   miércoles 06/07/11, 21:50:54
================================================================================

Este fichero está disponible en el repositorio Python Recipes alojado en github.

Pelican - Publicación y automatización

2011-06-28T23:54:00+02:00

Una vez que sabemos como instalar Pelican y crear contenido con él, es hora de saber como convertir ese contenido en un blog real disponible en internet. Es decir, saber como publicar ese contenido. Como hemos visto hasta ahora, al constar básicamente de simples ficheros HTML, un servidor de archivos es más que suficiente para servir el blog. Esto nos abre un gran abanico de posibilidades, desde emplear un potente (y barato) servidor de ficheros en la nube como Amazon S3, pasando por las páginas web estáticas que nos permiten repositorios como Bitbucket o GitHub, por los tradiciones hostings compartidos (e.g. este blog), hasta un servidor casero sencillo montado sobre un NAS.

Aún cuando es posible emplear un simple servidor de archivos para alojar el blog, siempre es mejor contar con un servidor web detrás (Apache, nginx, lighttpd, ...) que nos permita hacer redirecciones para nuestras antiguas páginas si ya disponíamos de un blog anterior o manejar los errores HTTP 404 o 403 de forma personalizada.

Publicar el contenido

Publicar el contenido de una web es tan sencillo como volcar el contenido del directorio que nos genera Pelican (en nuestro ejemplo sería myblog.com/site/output/*) en el directorio destino de nuestro servidor web. Dependiendo del método que hayamos elegido para alojar nuestro blog, puede ser tan sencillo como una copia de archivos o emplear FTP (SFTP) ó SSH (SCP, Unison ó rsync). Aquí el tema radica no en la primera vez que vayamos a subir el contenido al servidor, si no en las sucesivas, a medida que vayamos creando contenido nuevo. No tendría ningún sentido volver a subir todo el contenido cada vez, si no solamente el nuevo o el que haya cambiado. Para eso necesitamos sincronizar los dos directorios.

Si solamente disponemos de acceso FTP (o SFTP) a nuestro servidor, entonces tendremos que emplear una herramienta que nos permita la sincronización sobre FTP, como puede ser lftp. Y el proceso se puede automatizar con un script como el que describo en Sincronizar una carpeta local y una remota a través de FTP: lftp-mirror. Si disponemos de acceso a través de SSH, entonces la elección es clarisima, rsync. Más adelante explico una manera de emplearlo de forma automática.

Cualquiera de ambas soluciones nos permite subir el contenido en apenas segundos, (sobre todo en el caso de rsync) cuando se trata de añadir un articulo nuevo, por ejemplo. Y lo mismo a la hora de hacer una rectificación, es tan inmediato como lo pueden ser plataformas como Wordpress, Drupal y similares. Además, con las potentes herramientas que existen para hacer cambios múltiples en varios ficheros de texto a la vez, se pueden realizar tareas casi imposibles con una plataforma de blogs tradicional sin recurrir a consultas SQL en la BDD o a plugins externos. Una de estas herramientas, sin recurrir a find, grep, awk y sed, puede ser regexxer.

Generar el contenido en el propio servidor

Si el alojamiento que hemos escogido nos permite instalar programas python, entonces tenemos la posibilidad de instalar Pelican en el servidor remoto. De esta formar podríamos subir únicamente los archivos markdown o reStructuredText al servidor y generar allí mismo el contenido web. De este modo la cantidad de datos a subir sería ridícula y un simple comando FTP nos serviría. Luego bien podríamos lanzar Pelican a través de una consola SSH o bien dependiendo del servidor, tener un demonio corriendo que cuando detectara un cambio en el sistema de ficheros lanzará un script que generara el contenido con Pelican.

Otra posibilidad que me convence más, es de la poder instalar un repositorio en el servidor con un software de control de versiones, como Git o Mercurial. La idea sería tener un repositorio local, y al hacer un push hacia el repositorio remoto, a través de un hook activar la generación de la página con Pelican. Esto nos permitiría además poder tener varias copias del repositorio (por ejemplo en GitHub o Bitbucket) y por lo tanto de la web, haciendo "innecesarias" las copias de seguridad.

Automatizar todos los procesos

Pero lo ideal es poder automatizar todas las tareas que hemos visto hasta ahora, empleando unos pocos comandos para realizarlas sin esfuerzo alguno (bueno, a menos que tengas tú ghostwriter particular, me temo que los artículos los seguirás teniendo que escribir tú). Para poder realizar esto disponemos de la fantástica y potente herramienta Fabric (el Capistrano para Python) que nos permite ejecutar comandos locales o remotos en múltiples servidores. Esto nos permite hacer despliegues de software sin apenas esfuerzo en distintas máquinas, copiar ficheros o ejecutar tareas repetitivas empleado una corta serie de comandos. Una grandísima herramienta para administradores de sistema y desarrolladores.

Lo único que necesitamos es instalar fabric y crear un fichero llamado fabfile.py donde especificaremos las tareas que queremos programar. Para instalar la última versión estable de fabric, lo mejor es emplear easy_install o pip

$ pip install fabric

Una vez creado el fichero fabfile.py, lo único que tendremos que hacer para ejecutar una tarea del mismo, sería escribir el comando fab seguido del nombre que le hayamos dado a la tarea (este sería el funcionamiento básico). Y la tarea se ejecutaría inmediatamente.

Para comprender mejor como funciona Fabric, muestro aquí el contenido actual de mi fichero fabfile.py

#!/usr/bin/env python
# -*- coding: utf8 -*-

"""
    fabfile.py: A fabric script for generate my personal blog
"""

__author__ = "joe di castro <joe@joedicastro.com>"
__license__ = "GNU General Public License version 3"
__date__ = "28/06/2011"
__version__ = "0.2"

import os
from fabric.api import *
from fabric.contrib.project import rsync_project
from fabric.contrib.console import confirm

PELICAN_REPOSITORY = "git://github.com/ametaireau/pelican.git"
PROD = "joedicastro.com"
PROD_PATH = "/home/joedicastro/webapps/joedicastro"
LOCAL_WEB = os.path.join("~/www", PROD)
ROOT_PATH = os.path.abspath(os.path.dirname(__file__))
ENV_PATH = os.path.join(ROOT_PATH, "env")
PELICAN = os.path.join(ROOT_PATH, "pelican")
CONFIG_FILE = os.path.join(ROOT_PATH, "site/pelican.conf.py")
OUTPUT = os.path.join(ROOT_PATH, "site/output")

def _valid_HTML():
    """Remove the obsolete rel="" and rev="" links in footnotes."""
    for path, dirs, files in os.walk(OUTPUT):
        for fil in files:
            if fil[-5:] == ".html":
                local("sed -i {0} -r -e 's/re[l|v]=\"footnote\"//g' {0}".
                      format(os.path.join(path, fil.replace(" ", r"\ "))))

def _make_env():
    """Make a virtual enviroment"""
    local("virtualenv {0}".format(ENV_PATH))

def _del_env():
    """Delete a virtual enviroment."""
    local("rm -rf {0}".format(ENV_PATH))

def _clone_pelican():
    """Clone Pelican from repository."""
    local("git clone {0}".format(PELICAN_REPOSITORY))

def _install():
    """Install Pelican in the virtual enviroment."""
    with lcd(PELICAN):
        local("{0}/bin/python setup.py install".format(ENV_PATH))

def _browse():
    """Browse the local Apache site."""
    local("firefox -new-window http://localhost/joedicastro.com 2>/dev/null &")

def _gen(autoreload=False):
    """Generate the site from source."""
    local("{0}/bin/pelican {2} -s {1}".format(ENV_PATH, CONFIG_FILE,
                                              "-r" if autoreload else ""))
def _clean():
    "Remove the output folder."
    local("rm -rf {0}".format(OUTPUT))

def _local_deploy():
    """Deploy to the local apache web server."""
    local("rm  -rf {0}".format(LOCAL_WEB))
    local("cp -r {0} {1}".format(OUTPUT, LOCAL_WEB))

def pull_pelican():
    """Update Pelican to last revision from repository."""
    with lcd(PELICAN):
        local("git pull")

def bootstrap():
    """Get Pelican and install it in a virtual enviroment."""
    with settings(warn_only=True):
        _del_env()
    _make_env()
    with settings(warn_only=True):
        _clone_pelican()
    _install()

def regen():
    """Regenerate the site from source."""
    _clean()
    _gen()
    _valid_HTML()
    _local_deploy()

@hosts("my_user@" + PROD)
def publish():
    """Publish into remote web server with rsync."""
    regen()
    _browse()
    if confirm("¿Estas seguro de querer publicarlo?"):
        rsync_project(PROD_PATH, OUTPUT + "/", delete=True)

def new(title):
    """Create a new blog article."""
    local("gedit --new-window {0}/site/source/blog/{1}.md 2>/dev/null &".
          format(ROOT_PATH, title.replace(" ", "\ ")))
    local("firefox --new-window {0}/index.html &".format(OUTPUT))
    _gen(True)

def img4web(delete=True, source=""):
    """Optimize .jpg & .png images and copy them into source pictures dir."""
    local("./img4web.py -d {0} {1} {2}".
          format(os.path.join(ROOT_PATH, "site/source/pictures"),
                 "--delete" if delete else "",
                 "-s {0}".format(source) if source else ""))

Ahora, veremos el funcionamiento básico que nos permite este script. Primero vemos las tareas que tenemos disponibles:

$ fab -l
    fabfile.py: A fabric script for generate my personal blog

Available commands:

    bootstrap     Get Pelican and install it in a virtual enviroment.
    img4web       Optimize .jpg & .png images and copy them into source pict...
    new           Create a new blog article.
    publish       Publish into remote server with rsync.
    pull_pelican  Update Pelican to last revision from repository.
    regen         Regenerate the site from source.

Veamos que hacen cada una de ellas:

bootstrap Si observamos el código, veremos que lo hace es, en este orden: eliminar cualquier entorno virtual previo, crear un entorno virtual nuevo, descargar Pelican desde el repositorio (si no lo hemos hecho anteriormente) e instalar Pelican dentro de este entorno virtual. Y todo esto en un solo paso, casi todos los comandos que explicaba en Pelican - Introducción e Instalación con solo teclear fab bootstrap. Así de fácil. Con este comando podemos tanto crear una instalación de Pelican desde cero, como actualizar la instalación de Pelican después de actualizar este a la última versión con pull-pelican. Siguiendo con nuestro ejemplo, lo que haría este comando es crear los directorios env y pelican dentro de myblog.com con el entorno virtual creado y pelican instalado.
```
$ fab bootstrap
```
img4web Este comando hace uso del script que describía en Optimizar imágenes para la web para hacer precisamente eso, reducir el peso de las imágenes que empleo en los artículos. Lo que hago es a medida que voy escribiendo el articulo es ir guardando las imágenes en el directorio raíz (en nuestro ejemplo, myblog.com/) y cuando lo termino, simplemente ejecuto el comando fab img4web y este me optimiza las imágenes, me guarda las optimizadas en el directorio de imágenes del contenido (myblog.com/site/source/pictures/) y me elimina las imágenes originales del directorio raíz. Cuando termina me muestra un resumen con la cantidad de imágenes procesadas y el ahorro en espacio conseguido. Espacio en disco ahorrado que se resume en menos ancho de banda consumido y en páginas web que se cargan más rápido.
```
$ fab img4web
```
new Con este creo o edito los artículos del blog. Realiza tres funciones: me abre una venta de Gedit con el articulo que le indico con la extensión .md, me abre una ventana de Firefox que me muestra el fichero index.html del directorio del sitio generado por Pelican (myblog.com/site/output/index.html) y finalmente me activa Pelican con la opción autoreload. Luego empleando el plugin Grid de Compiz, divido la pantalla en dos mitades y coloco a la izquierda Gedit y a la derecha Firefox. Esto me permite, como explicaba en De Drupal a Pelican editar el contenido y previsualizar el resultado casi en tiempo real, disponiendo al mismo tiempo de un buen corrector ortográfico.
```
$ fab new:"Articulo de prueba"
```
publish El más importante, el que sube los artículos al servidor web. Publicar el contenido de la web es tan sencillo como ejecutar este comando. Lo que hace es regenerar el contenido (por si hubiera algún cambio sin guardar) y luego mostrarme el resultado en firefox. Pero el resultado que me muestra no es el del directorio de salida de Pelican, si no de una copia que tengo en un servidor Apache local. Esto me permite ver los cambios de manera más fiel a la versión web, puesto que hace uso del fichero .htaccess y de las reglas que tengo establecidas en él. Finalmente me pregunta si realmente deseo publicar el contenido, por si se me hubiera escapado algo. Si le digo que no, aborta la publicación, pero si le digo que si, me sincroniza el contenido de la carpeta local con la remota empleando rsync. De esta manera solo se transmiten los ficheros nuevos, se borran los que se hayan eliminado en local y solo transmite la parte que haya cambiado de los archivos modificados. Gracias a esto, modificar o añadir contenido es cuestión de segundos. Y sencillisimo.
```
$ fab publish
```
pull_pelican Nos sirve para actualizar Pelican a la última revisión disponible en el repositorio oficial. Si después de ejecutarlo, queremos instalar la nueva versión en nuestro entorno virtual para poder emplearla, simplemente tenemos que volver a ejecutar fab bootstrap y todo se realizará de forma automática.
```
$ fab pull_pelican
```
regen El proceso principal, es el que le pide a Pelican que genere el sitio web a partir de nuestro directorio de origen. También realiza varios procesos: primero eliminar el directorio de salida actual (para tener una copia fresca), genera el nuevo contenido, luego procesa los archivos para que validen en HTML5 y finalmente hace una copia del directorio de salida a mi servidor local Apache. El procesar los archivos para validar en HTML5 se debe a que markdown crea unos enlaces rel = "footnote" y rev = "footnote" en las notas al pie que se han quedado obsoletos y no son necesarios. De momento es un post-procesado, pero puede que finalmente modifique Pelican para que se haga en tiempo de generación del sitio. Aunque creo que el rendimiento de esta manera sería menor que emplear el comando sed que ejecuta este proceso, será cuestión de probarlo. También se podría modificar markdown.

Con solo 6 comandos tengo automatizadas todas las tareas básicas para administrar y crear contenido en mi blog. Ni siquiera el potente y buenísimo drush de Drupal me permitía este nivel de automatización (aunque se acercaba bastante). De esta manera solo me tengo que preocupar de crear artículos y de las posibles personalizaciones que le quiera realizar al tema del sitio. Me olvido de todo lo demás, de todo lo que conlleva un CMS. Solo hay una manera de bloguear más cómoda para los que a estos les parezca algo complejo, servicios como Tumblr. Aunque si quieres tener el control sobre tu sitio, no conozco manera más cómoda y con más ventajas que esta.