Esta es la segunda 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:

• Parte 1
• Parte 2
• Parte 3

Una vez que se ha creado el Bucket donde podremos depositar nuestros archivos, y que ya tenemos todo lo necesario para poder hacerlo de forma segura (es decir, el nombre del bucket, s3 endpoint, así como nuestra KeyId y ApplicationKey), ahora es necesario hacer que, además de construir el sitio, se pueda subir el resultado hacia nuestro bucket. A eso nos dedicaremos en esta publicación. Para ello no hay nada más que hacer que definir otro trabajo en nuestra “pipeline” (GitLab le llama así a un grupo de trabajos que se ejecutan para un proyecto). Este trabajo se deberá ejecutar justo después de que nuestro trabajo principal, que por ahora solo genera los ficheros HTML de nuestro sitio, termine. El nuevo trabajo tomará los artefactos que el otro había puesto disponibles, y subirá los archivos hacia nuestro bucket S3. Para subir dichos ficheros, necesitaremos de una imagen Docker que lleve incluida la herramienta aws-cli, aplicación oficial para subir archivos hacia servicios S3 y compatibles, como lo es B2. Finalmente, también para subir nuestros ficheros, necesitaremos configurar nuestra pipeline con algunas variables de entorno, donde le podremos indicar las credenciales con las que ya contamos. Y todo esto lo haremos de forma segura, para evitar que nuestras claves (especialmente la App Key) queden expuestas en el proceso.

Nota: En esta serie de publicaciones he utilizado GitLab como plataforma para construir, y ahora subir, los ficheros de la web. Pero no es la única manera de hacer esto. Es perfectamente posible instalar hugo y aws-cli en una máquina (ambos tienen versiones para Windows y Linux), utilizar el comando configure de aws-cli para ingresar tu app key de BackBlaze, etc.

paso 1. Configurar variables de entorno en gitLab

Asumimos que trabajamos con GitLab, y que usamos ya sea GitLab.com o una instancia propia del software, pero en ambos casos con un runner Docker disponible. Lo primero que tenemos que hacer, antes de definir nuestro trabajo para subir archivos, es configurar las variables de entorno que Aws-cli utilizará para iniciar sesión en BackBlaze B2. Esto es más seguro que ingresar las credenciales secretas en cualquier archivo. Para hacer esto, sigue estos pasos:

1. Estando en la página inicial de tu proyecto que aloja el sitio web, ubica y activa el vínculo para ir a la configuración desde el menú del proyecto.
2. Una vez dentro de la configuración, de nuevo en el menú de navegación del proyecto, dentro del apartado “configuración” (que ahora se mostrará como un elemento de lista con otra lista en su interior), ubica y activa el vínculo llamado “CI/CD”.
3. Navega hasta ubicar el encabezado llamado “Variables”. Se mostrará una tabla con todas las variables de entorno que los trabajos pueden usar en tu proyecto. Al final de la tabla, activa el botón llamado “Añadir variable”. Esto mostrará un diálogo modal donde puedes añadir una nueva variable. Las variables tienen la siguiente información que deberás rellenar:
   • clave: El nombre que se utilizará para referenciar esta variable.
   • valor: el contenido de la variable.
   • tipo: Se deja por defecto en variable.
   • environment: Se deja en todos por defecto.
   • proteger variable: Si está marcado, solo se puede usar en pipelines de ramas protegidas. Normalmente suelo desmarcar esto.
   • enmascarar variable: Si se activa, el contenido de la variable no se mostrará en logs, esto es útil para evitar que GitLab muestre nuestra App Key más adelante, por ejemplo.
4. Una vez comprendido lo que hay que hacer para cada variable, procederemos a añadir 4 variables. Dos variables contendrán nuestra App Key (recuerda que tenemos dos datos para la clave, keyId y ApplicationKey), una variable se utilizará para nuestro nombre de bucket, y otra variable será extra e indicará la versión de signature de S3 que utilizaremos para firmar los archivos. A continuación se muestran los detalles sobre qué añadir y cómo nombrar las variables. De manera casi estandarizada, los nombres de todas las variables de entorno van en mayúsculas.
5. Añade la variable que corresponde a nuestra keyID. En clave de variable, llámala “AWS_ACCESS_KEY_ID”. En valor, pega el contenido de keyId y marca la casilla para enmascarar la variable.
6. Añade otra variable para nuestra applicationKey, en clave, llámala “AWS_SECRET_ACCESS_KEY” y en valor, coloca la applicationKey desde tu documento. También enmascara esta variable.
7. Añade la variable de la versión de firma. En clave, llámala “AWS_SIGNATURE_VERSION” y en valor simplemente escribe el número 4. No es necesario enmascarar la variable.
8. Finalmente, añade la variable para indicar el nombre de bucket a donde subiremos el fichero. En mi ejemplo, he utilizado el nombre “S3_BUCKET”, y en valor he colocado “manuelcortez-net”. Tampoco es necesario enmascarar esta variable.

paso 2. Escribir el nuevo trabajo

De nuevo en nuestro repositorio, pero esta vez editando el código fuente, vamos a extender nuestro fichero .gitlab-ci.yml, que es donde definimos los trabajos de nuestra pipeline, para añadir el nuevo trabajo que subirá los ficheros generados por hugo. El trabajo nuevo se llamará simplemente “upload_site”, utilizará la imagen Docker de amazon Aws-cli, y tiene un par de comandos:

variables:
  GIT_SUBMODULE_STRATEGY: recursive

stages:
  - build
  - upload

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

upload_site:
  image:
    name: amazon/aws-cli
    entrypoint: [""]
  tags:
    - docker
  only:
    - master
  interruptible: true
  stage: upload
  script:
    - aws --version
    - aws --endpoint-url https://s3.us-west-001.backblazeb2.com s3 cp public s3://$S3_BUCKET --recursive

• En este ejemplo, es importante que cambies tu s3 endpoint que aparece en la última línea del archivo al que tienes en tu documento. También, si has utilizado alguna otra clave en el nombre de variable para tu bucket, actualízalo.
• Si la rama principal de tu repositorio no se llama “master”, cambia el nombre en el apartado “only:” para cada trabajo de modo que apunte a la rama principal.

En mi ejemplo, he tenido que cambiar una opción importante en la configuración del sitio para lograr que aws-cli pudiera subir correctamente algunos ficheros. De forma predeterminada, hugo genera archivos con los nombres de las etiquetas y categorías que se utilizan en el sitio web. Al tener mi web en español, algunos de estos archivos incluyen caracteres como letras con acentos. De manera predeterminada, Hugo simplemente se limitará a generar los archivos con los nombres completos de las categorías y etiquetas, por ejemplo, “Tecnología.html”, “Programación.html”, etc. Lo que ocurría al intentar subir el sitio web con esta clase de archivos es que se generaba un conflicto ya que la codificación de caracteres del contenedor de hugo era diferente a la que se usa en la imagen de aws-cli. El error era que los ficheros con caracteres especiales causaban que todo el trabajo se marcara como con errores. La solución para evitar esto era hacer que hugo reemplazara los caracteres especiales en los nombres de ficheros por sus contrapartes en el alfabeto inglés, tal y como lo hacen todos los sistemas de blogs o CMS modernos. Esto se logra editando la configuración del sitio en Hugo, y añadiendo el parámetro “RemovePathAccents = true” en cualquier parte de la configuración. Esto causará que hugo no requiera utilizar caracteres especiales en los nombres de ficheros, ayudando a que no se complique al intentar subir los archivos.

Una vez terminado con este archivo, al enviar tu próximo commit debería empezar el trabajo de generación y subida de tu sitio hacia el bucket de Backblaze b2 que le has indicado. Si algo sale mal en este punto, probablemente tendrás un correo de la instancia de GitLab desde donde podrás revisar el trabajo que falló. Es importante reparar cualquier error en este apartado antes de continuar con el paso siguiente, que es verificarlo todo en B2.

Paso 3. Verificando el Bucket en B2

Una vez más, es necesario entrar en nuestra cuenta de B2 para verificar que todo está funcionando bien y los archivos están donde tienen que estar, pero más importante aún, para conseguir la dirección URL desde donde podremos consultar nuestro sitio web. Posteriormente, utilizaremos Cloudflare para mapear esa URL que nos da B2 a un dominio propio.

Pero hay que ir por partes. Lo primero y más importante es verificar que efectivamente, el Bucket tiene los ficheros que gitLab debería haber subido. Para ello se puede comprobar accediendo directamente a la Página de vista general en Backblaze, y utilizando el menú de servicios, acceder al vínculo llamado “Browse Files”. En la página de “Browse Files” se mostrará una lista con los nombres de todos los buckets creados en la cuenta de B2. Cada nombre de bucket estará representado por un vínculo, al que se deberá acceder para ver los ficheros que este contiene. En mi ejemplo, al acceder a manuelcortez-net, puedo ver todos los ficheros y directorios presentes en dicho bucket.

Ahora bien, una vez localizados los ficheros, es necesario averiguar nuestra URL de consulta. Backblaze B2 le llama a este tipo de direcciones “Friendly URL”. Una URL amigable es la dirección pública desde donde puedes consultar un directorio o fichero dentro del sistema B2. Obteniendo la URL amigable de uno de los ficheros que están ubicados en el bucket, se puede utilizar la mayor parte de esa URL para saber cómo visualizar nuestro sitio web, e indicarlo así en Cloudflare.

Para hacer esto, solo es necesario localizar algún fichero de nuestro bucket recién explorado. Es importante que sea un fichero y no un directorio, ya que los directorios no mostrarían sus detalles de la misma forma como lo hacen los archivos. para mostrar los detalles de un fichero, en el explorador de archivos web de B2, simplemente es necesario buscar el fichero y una vez encontrado, pulsar la tecla intro. Si todo ha funcionado correctamente, se mostrará un diálogo modal con muchos detalles importantes sobre el fichero. De todos esos detalles, lo único que interesa copiar es la URL amigable del archivo. B2 le llama a esto una “Friendly URL”. Normalmente es una dirección URL bastante larga que lleva directamente a un archivo. En mi ejemplo, he utilizado el archivo index.html de mi sitio web, y la URL amigable que me ha arrojado el sistema es la siguiente: https://f001.backblazeb2.com/file/manuelcortez-net/index.html. Si utilizara esta URL y la pegara en la barra de direcciones del navegador, podría ver sin problemas el fichero. Es importante ir a guardar esta dirección URL en un sitio que podamos utilizar posteriormente, ya que de esta dirección dependerá que Cloudflare encuentre nuestro sitio web, una vez realizada la tercera parte de esta serie de artículos.

Conclusión

Llegados a este punto, donde ya podemos generar un sitio de forma completamente automática gracias a los runners de gitlab, y que ese sitio vaya a parar directamente a un bucket en B2, lo único que resta por hacer es proporcionarle una URL que sea fácil de recordar al momento de consultar el sitio. Esto será lo que se hará en la parte 3 de este artículo, utilizando para ello Cloudflare y un worker.