Ruby: Usos avanzados

Avanzando con sus despliegues de Ruby

👋 ¡Bienvenido a la documentación de Stackhero!

Stackhero ofrece una solución Ruby cloud lista para usar que proporciona una serie de beneficios, incluyendo:

  • Despliegue su aplicación en segundos con un simple git push.
  • Use su propio nombre de dominio y benefíciese de la configuración automática de certificados HTTPS para una mayor seguridad.
  • Disfrute de la tranquilidad con copias de seguridad automáticas, actualizaciones con un clic, y precios sencillos, transparentes y predecibles.
  • Obtenga un rendimiento óptimo y una seguridad robusta gracias a una VM privada y dedicada.

Ahorre tiempo y simplifique su vida: solo toma 5 minutos probar la solución de Ruby cloud hosting de Stackhero!

Desplegar una rama distinta de main

Hasta ahora, hemos desplegado nuestra aplicación Ruby empujando la rama main usando:

git push stackhero main

Si desea desplegar una rama diferente, puede usar este comando. Reemplace <BRANCH> con el nombre de la rama que desea desplegar:

git push stackhero <BRANCH>:main

Por ejemplo, para desplegar una rama llamada production, ejecute:

git push stackhero production:main

Desplegar etiquetas en lugar de ramas

En algunos casos, puede que desee desplegar una etiqueta en lugar de una rama. Para hacerlo, ejecute el siguiente comando. Reemplace <TAG> con la etiqueta que desea desplegar:

git push stackhero '<TAG>^{}:main'

Por ejemplo, para desplegar la etiqueta v1.0.0, ejecute:

git push stackhero 'v1.0.0^{}:main'

La sintaxis ^{} se utiliza para referenciar el commit al que apunta la etiqueta.

Desplegar un commit específico

Además de ramas o etiquetas, puede desplegar un commit específico. Reemplace <COMMIT_HASH> en el comando a continuación con el hash del commit deseado:

git push -f stackhero <COMMIT_HASH>:main

Por ejemplo, para desplegar un commit con el hash abcde, ejecute:

git push -f stackhero abcde:main

Revertir a una versión anterior

Si su despliegue en producción no funciona como se esperaba, puede revertir desplegando un commit anterior. Primero, use el siguiente comando para ver su historial de commits:

git log

Este comando muestra la fecha, el hash del commit y la descripción de cada commit en su repositorio. Por ejemplo, podría ver una salida como:

commit cccc8b3ebdccb9abc1926ef49ee589dae5c5fe06 (HEAD -> main, stackhero/main)
Author: Developer
Date:   Fri Apr 28 09:36:18 +0000

    Break the code

commit bbbb622301772072c3d82f3cc0d91e29e6e84901
Author: Developer
Date:   Wed Apr 26 12:49:28 +0000

    Update the code

commit aaaa1d8b06535b413e0df8298ccf52339dfef3ff
Author: Developer
Date:   Wed Apr 26 12:44:50 +0000

    Improve the code

Si el commit con el mensaje "Break the code" (hash cccc...) está en producción, y decide revertir al commit anterior "Update the code" (hash bbbb...), ejecute:

git push -f stackhero bbbb622301772072c3d82f3cc0d91e29e6e84901:main

Para evitar desplegar código defectuoso y aumentar la estabilidad de su producción, se recomienda encarecidamente tener un entorno "staging".

Situado entre los entornos "development" y "production", el entorno "staging" proporciona una réplica casi exacta del entorno de producción. Esto le permite probar su código y asegurar su calidad antes de desplegarlo en producción.

Al usar un entorno de staging, puede estar más seguro de la funcionalidad y el rendimiento de su código, asegurando un despliegue en producción más confiable y robusto.

Este tipo de entorno se discutirá más adelante en la documentación.

Configurar un entorno de staging

Un entorno staging es una buena práctica para usar junto con sus entornos development y production. Replica su entorno de producción para que pueda probar actualizaciones y cambios antes de que se publiquen.

Un entorno de staging debe reflejar de cerca el entorno de producción.

Sin embargo, asegúrese de que el entorno de staging use un clon de la base de datos de producción en lugar de la base de datos de producción real.

Si su servicio Ruby está vinculado a una base de datos u otros servicios, reprodúzcalos en el nuevo stack <Project> - Staging.

Para configurar un entorno de staging en Stackhero, siga estos pasos:

  1. En el panel de Stackhero, renombre su stack existente de <Project> a <Project> - Production. Por ejemplo, si su proyecto se llama Chat Bot, renombre el stack a Chat Bot - Production.
  2. Cree un nuevo stack llamado <Project> - Staging. Usando el ejemplo anterior, esto sería Chat Bot - Staging.
  3. Inicie un servicio Ruby dentro del stack de staging.
  4. Recupere el valor del comando git remote y siga las instrucciones en la sección Desplegar en el entorno de staging.

Siguiendo estos pasos, obtendrá un entorno de staging correctamente configurado para probar y verificar actualizaciones antes de que lleguen a producción.

Desplegar en el entorno de staging

Gestionar entornos separados como staging y production es altamente recomendable. Como se explicó en Configurar un entorno de staging, puede desplegar en cada entorno con diferentes remotos de Git.

Comience renombrando el repositorio remoto actual. Por ejemplo, renombre el remoto "stackhero" a "stackhero-production" con este comando:

git remote rename stackhero stackhero-production

A continuación, cree un nuevo servicio Ruby para el entorno de staging. Use el comando "git remote add" proporcionado y modifíquelo como sigue (reemplace <XXXXXX> con el dominio de su servicio):

  • Comando original:

    git remote add stackhero ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

  • Comando modificado:

    git remote add stackhero-staging ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

Ahora puede desplegar en staging usando:

git push stackhero-staging main

O desplegar en producción con:

git push stackhero-production main

Para simplificar aún más el proceso de despliegue, considere usar la versión mejorada del Makefile.

Con este Makefile mejorado, el despliegue en producción o staging se puede realizar fácilmente usando make deploy-production o make deploy-staging.

Versión mejorada del Makefile

A continuación se muestra un Makefile mejorado que acomoda múltiples reglas para tareas comunes:

  • make dev (o simplemente make): Inicia la aplicación en modo desarrollo.
  • make deploy: Despliega la aplicación en el remoto llamado stackhero (ideal cuando tiene una sola instancia de Stackhero).
  • make deploy-production: Despliega la aplicación en el remoto llamado stackhero-production.
  • make deploy-staging: Despliega la aplicación en el remoto llamado stackhero-staging.

Este Makefile está diseñado para manejar casos donde el código ya ha sido desplegado, evitando el error "Everything up-to-date".

Copie y pegue el siguiente contenido en su nuevo Makefile:

# Regla a ejecutar por defecto al invocar "make" sin argumento
.DEFAULT_GOAL := dev


# Stackhero para Ruby ejecutará la regla "run" en su instancia.
# Este es el comando para ejecutar en las plataformas de producción y staging.
run:
  rake assets:precompile
  rake db:migrate RAILS_ENV=production
  RAILS_ENV=production bundle exec puma -C config/puma.rb


# Comando para ejecutar en el entorno de desarrollo
dev:
  RAILS_ENV=development rails server -b 0.0.0.0


# La regla "deploy" despliega en la instancia "stackhero".
# Adecuado cuando solo tiene una instancia.
deploy:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero DEPLOY_BRANCH=main


# La regla "deploy-*" despliega en la instancia "stackhero-*".
# Por ejemplo, ejecute "make deploy-production" para desplegar en "stackhero-production",
# o "make deploy-staging" para desplegar en "stackhero-staging".
deploy-%:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero-$* DEPLOY_BRANCH=main


# Regla de despliegue interno. No modificar.
deploy-script:
  @echo "Desplegando la rama \"${DEPLOY_BRANCH}\" a \"${DEPLOY_REMOTE}\"..."
  @echo

  @if [ -n "$$(git status --porcelain)" ]; then \
    echo "No se puede desplegar porque hay cambios no confirmados:"; \
    echo "\e[0m"; \
    git status -s; \
    echo ""; \
    echo "\e[0;31m"; \
    echo "Puede usar este comando para confirmar los cambios:"; \
    echo "git add -A . && git commit -m \"Su mensaje\""; \
    echo "\e[0m"; \
    exit 1; \
  fi

  @git push --dry-run ${DEPLOY_REMOTE} ${DEPLOY_BRANCH} 2>&1 | grep -q -F "Everything up-to-date"; \
  EXIT_CODE=$$?; \
  if [ $$EXIT_CODE -eq 0 ]; then \
    echo -n "Nada nuevo para desplegar... ¿Forzar el despliegue (esto creará un nuevo commit)? (y/N) "; \
    read answer && \
    case $$answer in \
      y|Y|yes|YES) \
      git commit --allow-empty -m "Force update for deploy purpose to \"${DEPLOY_REMOTE}\"" ; \
      ;; \
      *) \
      echo "¡Nada que desplegar!"; \
      exit 1; \
      ;; \
    esac \
  fi

  git push ${DEPLOY_REMOTE} ${DEPLOY_BRANCH}

Gestión de secretos (variables de entorno)

En algún momento, necesitará gestionar secretos como tokens o contraseñas para bases de datos y servicios de terceros. Es esencial almacenar estos secretos de manera segura. Evite incrustar secretos directamente en su repositorio o código porque esto representa un riesgo de seguridad serio.

Las variables de entorno ofrecen dos beneficios significativos:

  1. Sus secretos no se almacenarán en su repositorio Git, reduciendo el riesgo si alguien accede a su código fuente.
  2. Puede usar credenciales diferentes para diferentes entornos. Por ejemplo, conectarse a su base de datos de producción en producción mientras usa una base de datos de desarrollo durante el desarrollo.

Configurar variables de entorno para el desarrollo

Para el desarrollo, cree un archivo .env en la raíz de su proyecto. Este archivo será excluido de Git para que nunca se confirme. Use la gema dotenv para cargar automáticamente el archivo .env.

Primero, agregue la gema dotenv-rails a su Gemfile:

# Gemfile
gem 'dotenv-rails', groups: [:development, :test]

Luego instale la gema:

bundle install

A continuación, cree un archivo .env en la raíz de su proyecto y agregue sus variables:

RAILS_ENV="development"
DATABASE_PASSWORD="secretPassword"
THIRD_API_PRIVATE_KEY="secretKey"
# ...

Finalmente, asegúrese de que el archivo .env sea ignorado por Git:

echo '.env*' >> .gitignore

Configurar variables de entorno para staging y producción

Para staging y producción, el archivo .env no es seguro ni práctico porque no puede almacenarse en un repositorio Git. En su lugar, Stackhero proporciona una solución segura para gestionar variables de entorno directamente en la configuración de su servicio Ruby.

Puede establecer estas variables a través del panel de Stackhero seleccionando su servicio Ruby y haciendo clic en el botón "Configurar".

Acceder a las variables de entorno

En Ruby, puede acceder fácilmente a las variables de entorno usando ENV. Por ejemplo, para recuperar DATABASE_PASSWORD, use:

ENV['DATABASE_PASSWORD'] # => 'secretPassword'

Aquí hay un ejemplo de cómo conectarse a un servidor RabbitMQ usando variables de entorno:

require 'bunny'

class RabbitMQClient
  def initialize
    @connection = Bunny.new(hostname: ENV['RABBITMQ_HOST'],
                            username: ENV['RABBITMQ_USERNAME'],
                            password: ENV['RABBITMQ_PASSWORD'])
    @connection.start
  end

  def publish(queue_name, message)
    channel = @connection.create_channel
    queue = channel.queue(queue_name)
    channel.default_exchange.publish(message, routing_key: queue.name)
  end

  def close
    @connection.close
  end
end

En la plataforma de desarrollo, su archivo .env podría incluir:

RABBITMQ_HOST='127.0.0.1'
RABBITMQ_USERNAME='developmentUser'
RABBITMQ_PASSWORD='developmentPassword'

Para producción y staging, defina sus variables de entorno en el panel de Stackhero bajo la configuración del servicio Ruby como se muestra a continuación:

RABBITMQ_HOST='<XXXXXX>.stackhero-network.com'
RABBITMQ_USERNAME='production'
RABBITMQ_PASSWORD='secretProductionPassword'

Apertura de puertos UDP/TCP

Las aplicaciones Ruby a menudo usan el protocolo HTTP en los puertos 80 (HTTP) y 443 (HTTPS). Si su aplicación necesita puertos adicionales o protocolos diferentes (TCP o UDP), configure la configuración de "Ports Redirections" en su servicio Ruby a través del panel de Stackhero.

Deberá especificar el puerto de entrada (abierto públicamente), el puerto de destino (abierto dentro de su servicio Ruby) y el protocolo (TCP o UDP).

Almacenamiento de archivos

Para almacenar archivos como fotos de usuarios o documentos, se recomienda encarecidamente usar una solución de almacenamiento de objetos. El almacenamiento de objetos le permite compartir archivos entre múltiples servicios e instancias y desacopla la capa de almacenamiento de su código. Esto se considera una buena práctica.

Recomendamos MinIO como una solución sencilla, rápida y poderosa compatible con el protocolo Amazon S3.

Si elige el almacenamiento de archivos local, puede usar el almacenamiento persistente proporcionado con su instancia Ruby. Este almacenamiento local está disponible bajo el directorio /persistent/storage/.

Sin embargo, el almacenamiento de archivos local generalmente no se recomienda ya que puede no ser la mejor práctica para la escalabilidad y confiabilidad a largo plazo.

ADVERTENCIA: ¡Nunca almacene datos fuera de la carpeta /persistent/storage/!

Almacenar datos en cualquier ubicación que no sea la carpeta de almacenamiento persistente puede resultar en la pérdida de datos cuando su instancia se reinicia, actualiza o cuando empuja nuevo código.

Apple/macOS: guardar la contraseña de su clave privada SSH

Si está usando macOS, puede encontrar inconveniente escribir la contraseña de su clave privada SSH cada vez que empuja su código. Aunque la seguridad es esencial, puede mejorar la conveniencia almacenando su contraseña de manera segura en el Llavero de Apple.

Puede ser tentador eliminar la contraseña de su clave privada SSH, pero esto no es aconsejable.

En su lugar, almacene la contraseña de su clave en el Llavero usando el siguiente comando para una clave llamada id_ed25519:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Después de ejecutar este comando, no debería ser solicitado para su contraseña de clave nuevamente. Si usa una clave RSA, sustituya id_ed25519 por id_rsa como se muestra a continuación:

ssh-add --apple-use-keychain ~/.ssh/id_rsa

Other articles for Ruby