Javi Moreno Apuntes Fichas de Lectura Archivo Sobre mi
Blog Logo

Javi


5 minutos de lectura

Cuando terminé la primera versión de URLHunter, tenía claro que compartir el código fuente del proyecto era básico. Principalmente por dos razones:
Primero, porque que se aprende mucho viendo el código, quizá mas que siguiendo un tutorial.
Segundo, porque me encantaría que la gente clonara el proyecto, hiciera forks, pull requests y enriqueciera URLHunter con sus aportaciones individuales.

Cuando lo iba a subir a GitHub caí en la cuenta de que los tokens, consumer_keys, etc de Twitter los iba a poder ver cualquiera que echara un vistazo al fichero twitter.rb y no solo eso, si en el futuro decidía incluir un formulario de contacto, integrar New Relic o Google Analytics los usuarios, contraseñas, identificadores únicos serían visibles para todo el mundo. Fue entonces cuando vi la importancia de las variables de entorno a las que hacían referencia en la documentación de la gema de Twitter.

El caso es que, por no hacerlo de primeras, para subir el repositorio a GitHub tuve que crear una rama nueva, cambiar los ficheros, asegurarme de que la rama principal nunca se sincronizaría con GitHub, etc. El problema añadido a esto es que todas los cambios que he ido haciendo al proyecto no los he podido sincronizar con la rama GitHub por falta de tiempo (o pereza, según se mire). En fin, que antes de que la cosa se complicará más había que actuar así que buscando un poco en internet he encontrado este tutorial que es el que voy a seguir para ocultar la información confidencial del proyecto.

La opción que he decidido desarrollar es la tercera, tiene un poco más de trabajo a la hora de desplegar en Heroku pero no es muy significativo.

Lo primero es crear el fichero local_env.yml e incluirlo en .gitignore para que no lo veáis jamás. ;-)

# Rename this file to local_env.yml
# Add account settings and API keys here.
# This file should be listed in .gitignore to keep your settings secret!
# Each entry gets set as a local environment variable.
# This file overrides ENV variables in the Unix shell.
# For example, setting:
# GMAIL_USERNAME: 'Your_Gmail_Username'
# makes 'Your_Gmail_Username' available as ENV["GMAIL_USERNAME"]

# Twitter Variables
CONSUMER_KEY: 'Your_Consumer_Key'
CONSUMER_SECRET: 'Your_Consumer_Secret'
OAUTH_TOKEN: 'Your_Oauth_Token'
OAUTH_TOKEN_SECRET: 'Your_Oauth_Token_Secret'
# New Relic Parameters
NEW_RELIC_LICENSE_KEY: 'Your_New_Relic_License_Key'

En el fichero podéis ver como no solo he creado variables de entorno para Twitter si no también para New Relic, eso es porque al margen de los cambios en el estilo de URLHunter, el uso de los Tweets Embeds y algunas mejoras en la cache también he incluido New Relic para monitorizar su comportamiento y buscar formas de mejorar el rendimiento.

Ahora hay que incluir las variables de entorno en los ficheros correspondientes. El fichero de configuración twitter.rb quedará de la siguiente manera:

Twitter.configure do |config|
  config.consumer_key = ENV["CONSUMER_KEY"]
  config.consumer_secret = ENV["CONSUMER_SECRET"]
  config.oauth_token = ENV["OAUTH_TOKEN"]
  config.oauth_token_secret = ENV["OAUTH_TOKEN_SECRET"]
end

Y en el fichero de configuración de New Relic lo único que hay que tener en cuenta es que hay usar ruby embebido para nombra la variable de entorno:

  # You must specify the license key associated with your New Relic
  # account.  This key binds your Agent's data to your account in the
  # New Relic service.
  license_key: <%= ENV['NEW_RELIC_LICENSE_KEY'] %>

Cargando las variables de entorno.

Para que la aplicación cargue las variables de entorno, tendremos que indicarle en el fichero de configuración que lo primero que tiene que hacer, antes que configurar cualquier otro ajuste es cargar las variables de nuestro fichero. Esto lo tendremos que hacer en el fichero application.rb:

    # Load the environment variables at beginning
    config.before_configuration do
      env_file = File.join(Rails.root, 'config', 'local_env.yml')
      YAML.load(File.open(env_file)).each do |key, value|
        ENV[key.to_s] = value
      end if File.exists?(env_file)
    end

Si hemos hecho todo esto correctamente, al ejecutar la aplicación en local todo debería funcionar perfectamente. El problema nos lo vamos a encontrar cuando despleguemos en Heroku. Heroku se apoya en el fichero git de nuestro proyecto para tomar toda la información. Del mismo modo que el fichero donde hemos incluido las variables de entorno no es visible en el repositorio (GitHub, Bitbucket,...) tampoco lo es para Heroku por lo que las variables de entorno nunca se cargarán al iniciar la aplicación. Hemos de cargar estas variables de forma manual.

$ heroku config:add CONSUMER_KEY='Your_Consumer_Key'

Podemos hacer un fichero bash que ejecutaremos después de hacer el despliegue en heroku. Este script tendría la siguiente estructura:

heroku config:add CONSUMER_KEY='Your_Consumer_Key' CONSUMER_SECRET='Your_Consumer_Secret' OAUTH_TOKEN='Your_Oauth_Token' OAUTH_TOKEN_SECRET='Your_Oauth_Token_Secret' NEW_RELIC_LICENSE_KEY='Your_New_Relic_License_Key';
heroku info --app urlhunter-314159;

Y lo ejecutamos escribiendo en el terminal:

$ sh heroku.sh

Listo. Ya podemos compartir el código fuente del proyecto sin temor a que nadie pueda hacer uso de nuestras claves de terceros.