Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

924
Views
¿Cómo incrustar variables de entorno en una imagen acoplable en la canalización de Azure Devops?

Mi requisito es establecer algunas variables de entorno en la imagen de la ventana acoplable creada por la canalización de Azure DevOps.

Esta canalización se usa para entornos de desarrollo/etapa/producción, cada etapa está vinculada a su propio conjunto de variables de grupo, estas variables quiero que estén disponibles en la aplicación nodejs.

Puedo leer las variables dentro de la tubería usando $VARNAME pero no puedo leer lo mismo cuando el código se ejecuta usando process.env.VARNAME.

Entiendo que no es el mejor enfoque, ya que la imagen tendría variables de entorno que potencialmente pueden tener secretos, por lo que también estoy abierto a diferentes ideas.

Lo que he intentado hasta ahora: se agregó ARG en dockerfile ARG VARNAME = algún valor en la tarea de compilación de docker agregada

 - task: Docker@2 displayName: Build docker image inputs: command: build repository: $(imageName) tags: $(Build.BuildId) buildContext: '$(Pipeline.Workspace)/PublishedWebApp' arguments: --build-arg SOMEVAR=anewvalue

Intento acceder a esto como process.env.SOMEVAR en el código nodejs.

De hecho, puedo ver --build-arg en la compilación de la ventana acoplable ejecutada en la canalización, pero en el código nunca aparece.

Lo que busco es un requisito bastante estándar, tenemos múltiples entornos, cada entorno tendrá diferentes claves (diferentes variables de grupo vinculadas a diferentes etapas), ¿cómo paso diferentes claves a la implementación?

over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

Hay algunos componentes por lo que puedo ver que necesitan alinearse:

  1. Está pasando la clave a través --build-arg . Esto es correcto.
  2. Tiene un ARG en el dockerfile para recibir lo que se pasa a través --build-arg . Esto es correcto.
  3. Falta establecer la variable de entorno igual al argumento pasado.
 FROM python:3.7-slim ARG SOME_PASSED_IN_ARG ENV SOMEVARNAME $SOME_PASSED_IN_ARG ...

Accedería a SOMEVARNAME como process.env.SOMEVARNAME desde la aplicación de nodo.

Le doy crédito a @levi-lu-msft en su publicación aquí: https://stackoverflow.com/a/59784488/1490277

En cuanto a las mejores prácticas, es perfectamente aceptable definir variables de entorno lógicas predeterminadas en el contenedor en BUILD (por ejemplo, ENV=PRODUCCIÓN). En EJECUTAR, puede sobrescribir cualquier variable de entorno usando los argumentos pasados:

docker run ... --e SOME_PASSED_IN_ARG=someOtherValue

Algunas prácticas "mejores":

  1. Los contenedores están destinados a ser repetibles. No incruste en la variable de entorno BUILD time que caducará/cambiará con el tiempo. En otras palabras, si decide implementar una versión de hace 3 años y una variable de entorno de tiempo BUILD tiene un valor caducado (por ejemplo, un código de cupón), su entorno podría ser frágil e impredecible.
  2. Nunca incrustes secretos en el contenedor en BUILD. #1 arriba porque pueden cambiar horas extras y también por seguridad. Los valores secretos (p. ej., claves únicas, tokens, etc.) están disponibles para que cualquiera (actor malo o actor de percances) los extraiga simplemente enumerando las variables de entorno de la imagen cuando se ejecuta.
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!