Una aplicación profesional suele tener más de un ambiente. Ambiente local, ambiente de desarrollo, ambiente de pruebas, producción, entre otros, dependiendo la necesidad del equipo y de la organización. Veamos cómo puedes administrar N cantidad de ambientes en NestJS.
Configuración dinámica del entorno
Configuremos la aplicación para intercambiar fácilmente entre diversos ambientes, cada uno con su propia configuración.
1. Archivo principal para manejo de ambientes
Crea un archivo llamado enviroments.ts (o el nombre que prefieras) que contendrá un objeto con una propiedad por cada ambiente que tenga tu aplicación.
Importa en el módulo principal de tu aplicación el archivo principal para manejo de ambientes y, a través de una única variable de entorno llamada NODE_ENV, elegirás qué configuración usar.
NODE_ENV es una variable de entorno propia de NodeJS y del framework Express que se encuentra preseteada en tu aplicación.
Finalmente, para iniciar tu aplicación basta con el comando NODE_ENV=test npm run start:dev o NODE_ENV=prod npm run start:dev para configurar la variable de entorno principal NODE_ENV y escoger qué configuración utilizar.
5. Utilizando las variables de entorno
Puedes utilizar las variables de entorno en tu aplicación de dos maneras. Con el objeto global de NodeJS llamado process:
process.env.DATABASE_NAMEprocess.env.API_KEY
O puedes usar estas variables a través del servicio ConfigService proveniente de @nestjs/config.
import{ConfigService}from'@nestjs/config';@Injectable()exportclassAppService{constructor(private config:ConfigService){}getEnvs():string{const apiKey =this.config.get<string>('API_KEY');const name =this.config.get('DATABASE_NAME');return`Envs: ${apiKey}${name}`;}}
De este modo, configura de la mejor manera que necesites para tu aplicación el manejo de múltiples ambientes, cada uno con su propia configuración.
Cuadro de código para la configuración de ambientes
Esto es necesario si estas usando windows y la terminal powershell, me tardo darme cuenta
Apuntes
Crear archivos env para los distintos ambientes
Ya que configuramos el archivo env que contiene el valor de las variables de entorno para el servidor de desarrollo debemos crear los archivos .env para el servidor de pruebas y produccion.
// .stag.envDATABASE_NAME=my_db_stag
API_KEY=333
// .prod.envDATABASE_NAME=my_db_prod
API_KEY=999
¿Cómo elegir dinámicamente el archivo env?
Nuestro código debe elegir automáticamente que archivo .env debe tomar según en el servidor en el que se este ejecutando. Para ello debemos crear un objeto en donde listaremos todos los ambientes que existen y los ligaremos con su archivo correspondiente.
Podemos indicar en que ambiente se esta trabajando usando las siguientes lineas.
NODE_ENV=prod npm run start:dev
NODE_ENV=stag npm run start:dev
Si estas usando el powershell de windos
$env:NODE_ENV="prod"; npm run start:dev
$env:NODE_ENV="stag"; npm run start:dev
$env:NODE_ENV="dev"; npm run start:dev
En mi caso, ejecutando en windows, para asignar la variable de entorno al ejecutar hago lo siguiente:
>setNODE_ENV=stag&& npm run start:dev
Ojo que se escribe environments y no enviroment (falto una "n")
Saludos!
No me reconoce mis archivos .prod.env y .stag.env ¿qué podría hace?
Aquí está la respuesta:
Nest.Js not accepting any changes
En resumen, solo ejecuta:
npm run build && npm run start
Estoy un poco frustrado, tengo una duda, como puedo hacer para configurar las variables de entorno sin tipado, y además realmente de forma global, es decir, poder usarlas sin necesidad de inyección?, por que hacer eso para variables de entorno honestamente me parece algo absurdo
Hola!
Dos cosas que pienso te pueden aportar:
Tiene mucho sentido ocupar inyeccion porque es uno de los puntos fuertes de Nestjs. Casi todo va inyectado y conservar esa forma de hacer las cosas permite escalar el backend y que el programador que viene detras no la pase tan mal entiendo (Trabajo en un backend que tiene una parte hecha en Nestjs)
En el caso que te menciono, tiene sentido inyectar las variables de entorno porque facilita emplear diferentes variables de entorno dependiendo del ambiente donde haces deploy. Por ejemplo, tengo de 3 a 4 ambientes para pasar de development a prod. Luego, tengo de 4 a 8 configuraciones de ambiente diferente. Al usar la inyeccion, puedo configurar el trigger (GCP en este caso) y con ello el deploy es mas agil (Considera que ciertas partes del codigo a veces no se pueden probar en local y no te queda otra que hacerlo en uno de los ambientes. Y estar cambiando las variables de entorno cada vez se vuelve tedioso)
En el caso que te hablo, las variables no van tipadas (Al parecer no alcanzaron a hacerlo, llegue despues). En ese caso, simplemente escribes las funciones getter en el sevicio de config y, asu vez, le configuras una carpeta con tus archivos .env. Con ello inyectas el servicio y te traes la variable de entorno que necesites (He visto que esa variable queda global en los archivos que se necesitan y asi no andas con la “mochila” de variables para todas partes)
Espero te sirva!
Saludos c:
En caso tal estés usando docker compose para correr tu proyecto y tienes problemas con el cambio de ambiente, revisa la opción env_file. Si estás pasando determinado archivo en esa opción, tomará siempre esas variables de entorno.
En mi caso puse el NODE_ENV=dev en el script de start:dev quedandome
cross-env es una dependencia que me permite declarar variables desde la consola de windows
Lo correcto seria mandar esas configuraciones aun modulo propio.
Me esta llegando undefined, pense que era algo en mi código, clone la rama tal cual y me pasa lo mismo.
ya lo solucione, el archivo env estaba en otro nivel del directorio
Los entornos si me están funcionando sin embargo para la versión de NestJs 11.0.7 tuve que hacer un ligero cambio en app.module.ts para contemplar que process.env.NODE_ENV retorne un undefined
Por si los cambios que haces en tu código no se ven reflejados, intenta hacer:
npm run build && npm run start
Esto me ayudó y espero te ahorre dolores de cabeza.
excelente!
Si alguien le paso que en esta clase el nestjs dejo de mostrarles los cambios hagan esto:
npm run build && npm run start
Lo consegui aqui:
Todo super hasta el momento. :)
Hola, de acuerdo a twelve-factor (https://12factor.net/config) es preferible no agrupar configuraciones en distintos grupos (archivos o entornos), porque esto resulta en una app que "no es fácilmente escalable y la cantidad de archivos de configuración crecerá a través de los diferentes despliegues de la misma a medida que la app vaya creciendo".
.
Así que sugieren usar el mismo archivo (.env por ejemplo) y ya cada despliegue se encarga de configurar sus variables de acuerdo a lo que necesita ese despliegue en particular.
.
¿Qué opinan al respecto de lo que se plantea en twelve-factor? ¿Sería mejor tener una única fuente de configuración pero que cambie su contenido a través de diferentes despliegues? ¿Es mejor manejar diferentes archivos así estos se incluyan o no en los diferentes despliegues de la aplicación?
.
Por mi parte pienso que es mejor tener un único archivo .env y cuando lo pase al servidor de producción pués solo se cambiaría el contenido del mismo.
Yo lo veo más para en desarrollo local, sobre todo en empresas donde tú administras los entornos y no hay nadie por encima ni por debajo de ti, en mi caso los segmentaba en un mismo archivo y comentaba lo que no ocupara, pero cuando esto llega a producción o un entorno ya en la nube, era a través de la herramienta de CI/CD, que le pasaba las variables de entorno, por ejemplo en mi caso trabajando con cloudbuild de Google definía las variables que se utilizarían (aclarando que de igual manera no se pasan los valores planos eso sería mala práctica)
esa config del enviroments como object se llama hash table y les dejo este post muy util si quieren reforzar este conocimiento.