Esta es la primera parte sobre una serie de publicaciones que inicié detallando los pasos que he seguido para publicar un sitio web estático utilizando para ello Cloudflare y B2, junto con los runners de GitLab, que se encargan de construir y subir los ficheros del sitio. Puedes encontrar las otras partes de esta serie en los siguientes vínculos:
Después de haber migrado este sitio a Hugo, he leído en algún sitio (o tal vez en Twitter, no lo tengo claro ahora mismo) una idea sobre alojar y servir la totalidad del sitio web desde un servicio al estilo S3. Existen muchos servicios que ofrecen compatibilidad con la API de S3 ahora mismo (entre los que está, por supuesto, el propio S3). En esta publicación pretendo explicar, a grandes rasgos, el proceso que he seguido para configurar uno de estos servicios de almacenamiento de objetos y Cloud Flare para poder tener un sitio web sin la necesidad de un servidor web.
¿Por qué hacer todo esto?
Cuando se trata de desplegar un sitio hecho con algún generador estático, siempre se recomienda utilizar plataformas como Netlify, GitHub pages o alguna plataforma similar. Y ciertamente están bastante bien. Aunque en mi caso he decidido probar a alojar la web en un bucket de Backblaze B2 como un experimento para otro proyecto que tengo en mente, además que esta es una forma bastante interesante de mantener el mismo nivel de control y privacidad sobre los ficheros del sitio web. También otra pregunta común que puede surgir es, en un mercado en el que conseguir un servidor VPS es tan barato (los hay desde los 3 dólares), ¿En verdad vale la pena mantener una configuración de este tipo? ¿cuál es el sentido de todo esto? Y pese a que aún no podría emitir una opinión desde la experiencia personal, sí creo que hacerlo así puede aportar cosas interesantes, como las siguientes:
- No es necesario mantener un servidor web completo: Lo único que necesitarás para poder proporcionar acceso a un sitio web, una vez terminada la fase de configuración, es continuar actualizándolo. Para esto solo es necesario generar el sitio y cargarlo al bucket de BackBlaze. No necesitas servidores, ni sistemas operativos, ni actualizaciones, configuraciones adicionales, ssl, etc. De todo esto se encargará cloudFlare y Backblaze será el depósito donde se almacena el sitio web. Pero no solo Backblaze, porque estas instrucciones servirían prácticamente con cualquier servicio de almacenamiento de objetos que permita mostrar HTML. Para servir un sitio que solamente consta de ficheros estáticos, tal vez no sea una buena idea dedicar los recursos de un servidor web.
- Velocidad: Entre el sistema de cache de cloudflare y la baja latencia que tienen sus centros de datos con Backblaze, será más rápida la resolución de las páginas del sitio.
- costo: Backblaze B2 es un sistema de almacenamiento de objetos que permite crear buckets. Un bucket es como un directorio que puede contener más directorios y archivos. Por cada Gigabyte almacenado, Backblaze cobra $0.005 dólares por mes. Eso es mucho más barato que alojar una web en un VPS, y cumple con la misma función.
Pasos necesarios
Primero que nada, es necesario contar con un sitio estático (de cualquier tipo, únicamente tiene qué ser estático) que ya se pueda generar en un directorio local, por ejemplo. en mi caso llevo un par de meses utilizando Hugo, así que fue con este generador con el que terminé por hacer estos ajustes. También es necesario tener cuentas en Cloudflare, y haber añadido previamente un dominio con ellos (necesitarás cambiar los servidores DNS a los de CloudFlare para que pueda tomar control del dominio); así como en backblaze b2. En este punto, en lugar de Backblaze se podría usar prácticamente cualquier otro sistema de almacenamiento de ficheros que permita consultar los archivos mediante una URL Pública.
paso 1. Punto de partida
Al iniciar con estos ajustes, tenía una configuración sencilla. Tengo los ficheros de mi sitio web alojados en un repositorio de GitLab, que construía el sitio web cada vez que se hacía un commit utilizando el comando “hugo” en los runners de gitLab que estaban disponibles en mi instancia. Los runners que se utilizan para el sitio son los runners docker, que presentan exactamente el mismo tipo de configuración que los que puedes utilizar en gitLab.com, por ejemplo. Cada vez que se ejecuta un trabajo (llamado job en GitLab), el runner crea un contenedor docker con la imagen que se le solicita, clona el repositorio, y ejecuta los comandos dentro del apartado “script” que defines en el fichero donde están especificados los trabajos. El host docker se ejecuta en Linux, así que no es posible utilizar contenedores Windows, aunque para esta tarea no es necesario. Una vez que el sitio ha sido generado, el paso final del trabajo es dejar los archivos HTML que se crearon listos para que otro trabajo los tome y haga algo con ellos, presumiblemente subirlos a algún sitio para que se puedan consultar. Esto se hace definiendo la carpeta donde se guardan los archivos html generados como un artefacto. En GitLab, los artefactos son los archivos que te interesa pasar a otros trabajos, para que puedan operar con ellos. En este ejemplo, se utilizarían solo dos trabajos: el primero construiría el sitio web, y el segundo tomaría los archivos generados y haría algo con ellos. Para dar una mejor idea, y sin intención que esto sea una introducción a los runners de GitLab, que son ya muy complejos, aquí está el fichero .gitlab-ci.yml, que estaba en el repositorio de mi sitio web antes de iniciar con la configuración para servirlo mediante CloudFlare y Backblaze.
# Archivo para generar el sitio web utilizando los runners docker de GitLab.
# Establecer estrategia para que git, al clonar el repositorio, también clone los submódulos de forma recursiva.
# de otro modo, los temas de hugo pueden fallar, ya que ellos recomiendan usar submódulos git.
variables:
GIT_SUBMODULE_STRATEGY: recursive
# Definir los estados de este proyecto. Cada trabajo puede estar asignado a uno de estos
# Todos los trabajos de cada estado deben haberse completado antes de empezar con el siguiente.
stages:
- build
- upload
# Generar los ficheros HTML a partir del repositorio, utilizando el runner docker y la imagen de hugo de GitLab.
make_site:
tags:
- docker
stage: build
only:
- master
interruptible: true
image: registry.gitlab.com/pages/hugo:latest
script:
- 'hugo'
artifacts:
paths:
- public
expire_in: 1 day
Hay alguna otra configuración de este trabajo que me he dejado sin comentar, pero a grandes rasgos esto se ejecuta cada vez que a GitLab le llega un nuevo commit en la rama master, crea el contenedor docker, clona el repositorio incluyendo submódulos, y construye el sitio web. Después, copia los archivos que se encuentran en el directorio “public” a la cache de artefactos de GitLab, desde donde otro trabajo, que generaremos después, los tomará y colocará en el bucket de backblaze.
Paso 2. Creando el bucket en BackBlaze
Lo primero que hay que hacer es crear el bucket en B2, y configurar este como público. También es importante generar una clave de acceso, lo que nos permitirá subir los ficheros desde GitLab de forma segura a nuestro bucket recién creado. Para crear el bucket, se puede hacer mediante estos pasos:
- En la Página de buckets de B2, Localiza y activa el vínculo llamado “Create Bucket”. Esto abrirá un diálogo modal desde donde podremos configurar los aspectos más importantes de nuestro nuevo bucket. De las opciones más importantes a tener en cuenta, están las siguientes:
- Bucket Unique Name: Los buckets deben tener un nombre único en toda la región donde son creados. Esto significa que si yo utilizo el nombre de mi bucket nadie más en toda la región de Backblaze puede crear un bucket con el mismo nombre. Los buckets deben tener un nombre con un mínimo de 6 caracteres, y solo puedes utilizar las letras del alfabeto inglés, números y guiones. Como estamos configurando el sitio web manuelcortez.net, me he decidido por crear el bucket llamado manuelcortez-net.
- Files in Bucket are: Aquí puedes especificar si los ficheros de este bucket serán públicos o privados. Para que puedas servir un sitio web deben ser públicos.
- El resto de las opciones puedes dejarlas como están.
- Cuando hayas terminado, ubica el botón llamado “Create bucket” y púlsalo para terminar con la creación.
- Al terminar de crearlo, se cerrará el diálogo modal y volveremos a la página de los buckets. Aquí se mostrará una lista desde donde podremos ver el bucket que hemos creado, junto con alguna información que será importante más adelante. La lista de buckets se muestra justo debajo del vínculo para crear más de ellos.
- Es posible que sea deseable cambiar las opciones de ciclo de vida de los archivos de nuestro nuevo bucket. De manera predeterminada, Backblaze guardará todas las versiones de un mismo archivo que sean subidas. A lo largo del tiempo, eso significa que tendremos muchas copias de nuestros ficheros, lo que no será necesario, ya que el propio git nos puede servir mejor a la hora de regresar a un estado anterior del repositorio. Para cambiar esto, justo después de la información del bucket, se mostrará una lista de enlaces con varias opciones. Ubica la opción llamada “Lifecycle Settings” y accede a ella.
- Una vez que estás en esta sección, se te mostrarán varios botones de opción con la posible configuración del ciclo de vida de los ficheros en tu bucket. Si deseas mantener solo la última versión de los archivos, selecciona la opción " Keep only the last version of the file" y pulsa el botón “Update Bucket”.
- De vuelta en la lista de buckets, localiza la información del que utilizarás y busca la línea llamada “S3 endpoint”. Copia la línea que hay debajo de esta y pégala en un documento que tengas al alcance, junto con el nombre de tu bucket. La línea es una dirección URL, que sirve para identificar la región a donde vamos a decirle a GitLab que suba nuestro sitio web más adelante. El endpoint puede verse algo parecido a esto: s3.us-west-001.backblazeb2.com.
paso 3. Creando la clave de aplicación en BackBlaze
El siguiente paso es crear la clave de aplicación dentro del mismo Backblaze. Esta clave será nuestras credenciales para poder subir los ficheros utilizando los datos que ya tenemos, tales como nuestro nombre de bucket y el endpoint de s3. Para crear la clave:
- En la Sección app keys de Backblaze, Se mostrará una lista de todas las claves que has creado. Si no hay ninguna creada, puedes hacer tu primera clave utilizando el vínculo llamado “Add a New Application Key”, lo que abrirá otro diálogo modal donde podemos configurar lo siguiente:
- Name of Key: El foco del sistema por defecto cae aquí. Especifica el nombre de la clave. Los caracteres válidos nuevamente son las letras del alfabeto, números y guiones. Este nombre será útil principalmente al mostrarlo en la lista de claves.
- Allow access to Bucket(s): En este cuadro combinado, puedes elegir a qué bucket se le dará acceso a esta clave. Como regla general, es recomendable que cada clave tenga acceso solo a un bucket. Es más seguro y si en algún momento tu clave se viera comprometida, sería más fácil eliminarla de la lista sin temor a que la clave se hubiera podido usar sobre otros buckets.
- Type of Access: El modo de acceso para esta clave. Por defecto el modo es lectura y escritura, lo que permitirá que quien sea que use esta clave puede leer, escribir y eliminar ficheros del bucket. A no ser que haya una muy buena razón para cambiar esto, se debería dejar tal y como está.
- El resto de las opciones puedes dejarlas como están. Cuando hayas terminado con las opciones, pulsa sobre el botón “Create New Key”.
- Una vez creada tu nueva clave, aparecerán sus datos a continuación. Es muy importante que puedas copiar los datos de tu clave, porque parte de esta información no se volverá a mostrar nunca más. Comienza buscando un mensaje que dice algo parecido a lo siguiente:
“Success! Your new application key has been created. It will only appear here once.”
Una vez encontrado, copia las líneas que se encuentran debajo de “keyID:” y “applicationKey:”. En términos simples, keyId sería tu usuario, y applicationKey sería tu contraseña para poder subir ficheros. De nuevo, copia estos datos y pégalos en tu documento de referencia.
Después de estos datos, deberías tener un documento con información parecida a esta:
Nombre de bucket: manuelcortez-net
S3 endpoint: s3.us-west-001.backblazeb2.com
keyID: 001f24eXXXX
applicationKey: K001hgpMXXXX
Y así, casi terminamos por completo con BackBlaze. Pero por ahora ha sido todo. En futuras publicaciones continuaremos con los detalles sobre lo que tenemos que hacer de lado de GitLab para subir el sitio a B2, y también en cloudflare, para poder conectar un dominio a nuestro Bucket.
Mastodon