¿Cómo configurar variables de entorno para despliegues serverless en Node.js?
El uso eficiente de las variables de entorno en Node.js es esencial para manejar configuraciones específicas según el entorno de despliegue. En este artículo, analizaremos cómo puedes aprovechar estas variables para tener configuraciones flexibles y seguras en tus despliegues serverless.
¿Cómo añadir variables de entorno en Node.js?
Para comenzar a trabajar con variables de entorno, necesitas configurar un archivo config.json. Aquí, podrás definir diferentes categorías y agrupar variables que necesites utilizar en tu aplicación. Por ejemplo:
Una vez definida la variable, puedes eliminarla de tu archivo de configuración config.js original y probarla desplegando tu aplicación. Si todo funciona correctamente, significa que el valor se está tomando de las variables de entorno definidas.
¿Cómo probar los despliegues de forma local?
Node.js ofrece una herramienta valiosa para simular los despliegues en la nube a través de un entorno local antes de hacer el despliegue definitivo. Con el comando now dev (parte de Vercel), puedes emular exactamente cómo se comportará tu aplicación en la nube, pero alojada en tu máquina:
now dev
Accede a tu aplicación localmente en http://localhost:3000, donde verás la réplica exacta del ambiente productivo. Esto te permitirá:
Realizar cambios y observarlos en tiempo real.
Probar la interacción con la API local.
Asegurar que cualquier funcionalidad esté operando al 100% antes del despliegue definitivo.
¿Qué ventajas ofrece probar localmente?
La comprobación local permite detectar y resolver errores sin costo ni riesgo en producción. Además:
Permite desarrollar de manera iterativa y segura.
Promueve la eficiencia al permitir pruebas exhaustivas.
Facilita el proceso de debug sin las limitaciones de un entorno en la nube.
En conclusión, el uso de variables de entorno y pruebas locales en Node.js no solo incrementa la seguridad de un despliegue serverless, sino que también fortalece el proceso de desarrollo al ofrecer un entorno que minimiza riesgos y optimiza cada etapa del proceso.
Continúa perfeccionando tus habilidades en el manejo de Node.js y descubre cómo esta práctica puede transformar la manera en la que implementas y gestionas tus aplicaciones.
Es mejor utilizar secrets :)
Además de que no expones dichas variables de entorno directamente en el repositorio. :D
actualmente, y como mencionan los compañeros en los comentarios, NOW es VERCEL.
básicamente es lo mismo, cambia en cosas mínimas.
les dejo mi vercel.json, para las variables de entorno utilice los SECRETS -> https://vercel.com/docs/cli#commands/secrets
tengan en cuenta que si las van a agregar con secrets, tienen que tener el archivo .env con las variables declaradas, también recomiendo que el archivo .env lo agreguen al ++.gitignore++ , ya que si hacen commit de esto, van a estar exponiendo sus variables de entorno.
con versel
versel --prod
y para ver en el entorno local
vercel dev
Yo desplegue mi servidor de mysql en google alguien sabe como puedo saber la dirección ip de mi servicio verce antes now y agregarlo alas white list
Revisa este enlace para la white list, pero antes vale la pena que revises la documenación acerca de los pasos necesarios para habilitar la conexion a mysql desde afuera de google.
Hola, alguien sabe a que pueda deberse el hecho de que funcione en desarrollo y no en producción?
Hola santiago, si ingresas en check the logs de la parte inferior, que información te arroja como posible causa?
Hola felipe, me sale lo siguiente:
Sí se te ocurre que pueda ser me sería de gran ayuda, muchas gracias de antemano!
Excelente clase, y mas con el comando now dev que podemos ver todo en local antes de subir a producción
Es posible hacer el despliegue local con now en un servidor que tenga configurada una ip publica para hacer uso de la aplicacion construida?
Hola @aesn_sas dese que estés muy bien. Es posible que no haya entendido al 100% tu pregunta, sin embargo creo que puedo aportar un poco a tu duda. Now(vercel) es un servicio serverless, es decir, ellos administran la infraestructura y nosotros simplemente nos enfocamos en desarrollar nuestra app. Veo que deseas realizar un deployment en un servidor tuyo, que bien podría ser una máquina virtual de VMWare, Virtualbox, un droplet (digitalocean), etc.
Desafortunadamente con el CLI de now no podrás desplegar allí pero, si lo puedes hacer con git.
Actualmente tengo algunos proyectos en servidores locales en la empresa donde trabajo, también he desplegado en servicios cloud que ofrecen VM como digital ocean.
Mi proceso es el siguiente:
1.- Conocer el OS de mi entorno de producción (Server de destino)
2.- Instalar git
3.- Instalar Nodejs
4.- Crear un repositorio en github (también puede ser gitlab o un bare repo)
5.- Crear una ruta para mi app en el servidor de destino.
6.- Descargo el proyecto al servidor de destino, con un git clone si es desde github o en caso de hacer un bare repo, hago un push a este repositorio y luego un clone interno a la carpeta donde vivirá el proyecto en producción.
7.- Ejecuto npm start
8.- Pruebo que se vea el proyecto:
El puerto dependerá mucho de cómo lo tengas en tu proyecto, por default node usa el 3000 pero bien lo puedes cambiar.
9.- Asignar el dominio. Este punto es algo extenso y depende mucho de la opción de hosting que elegimos, para un droplet de digital ocean, ellos proporcionan una documentación muy buena para distintos OS, para una instancia de VM local, toca añadir algunos registros DNS y configurar el firewall y quizá hasta el SSL. Pero de inicio no te compliques tanto la existencia, si funciona bien por IP, con calma y un poco de búsqueda en google podrás asignarle un dominio.
Dependerá mucho de tu proyecto y su alcance el tipo de hosting a usar, en lo personal uso servidores locales a modo de intranet para el trabajo, y para clientes externos uso servicios serverless, que si bien en un principio no me daban nada de confianza, con el tiempo me he dado cuenta que es la manera más económica de lanzar una app web al mercado, incluso puede ser gratis, con la finalidad de validar el mercado o de mostrar al cliente su proyecto en internet.
Por el momento mis preferidos son:
Firebase ( gratuito hasta cierto volumen de consumo )
Nowsh actualmente Vercel, gratuito, hasta el momento no he llegado a pagar nada por mis apis.
Digital Ocean (Pago económico) Lo uso cuando necesito montar algún stack de tecnologías que de arranque solamente se montar en linux y a mano. Sus VM de 5 USD al mes me han funcionado excelente.
Espero haber aportado algo para resolver tu duda, si en algo más puedo ayudar, puedes escribirme por este medio.
Saludos.
Tengo un problema, no puedo hacer de manera local.
Al momento de hacer la petición de localhost:3000/api/post/ en lugar de recibir una respuesta en json del post. Recibo el script de index-post .
No se cual sea el problema, si alguien tiene una idea o puede solventar la duda muchas gracias.
Dejare el código de mi vercel.json , no arranca mi API con el "builds" , no se porque, por eso esta "build". Los videos deberían actualizarse, hay algunas cosas en al aire.
Hola, por casualidad alguien ha podido desplegar el microservicio mysql en VERCEL? Para toda la API esta funcionando pero el microservicio MYSQL unicamente me corre en localhost. Muchas gracias por su ayuda de antemano! :)
now dev: podemos hacer un despliegue de nuestra APi en local. Podemos hacer el debugger y pruebas antes de desplegar en el servidor real.
Hay que tener en cuenta que cuando desplegamos en local con now dev se tomarán las variables locales que tengamos en nuestro archivo .dev o en nuestras variables de entorno, no se toman en cuenta los secrets, ya que estos son para un ambiente de producción.
Yo manejo las variables de entorno con dotenv, me parece una forma sencilla de organizarlas pues todas se declaran en un archivo que luego dotenv pone directamente en las variables de entorno.
(trabajando en local)
Now ahora se llama Vercel.
Para los que necesiten secretear sus variables en la consola escriben:
vercel secret add NOMBRE_VARIABLE1 VALOR_VARIABLE
Y en su archivo vercel.json
…
“env”: {
“VARIABLE1”: “@NOMBRE_VARIABLE1”,
}
…
Y en su app usan: VARIABLE1, para acceder a su variable.