如果您在本地的env.sh中有环境变量，并且希望在容器启动时设置它，您可以尝试

COPY env.sh /env.sh
COPY <filename>.jar /<filename>.jar
ENTRYPOINT ["/bin/bash" , "-c", "source /env.sh && printenv && java -jar /<filename>.jar"]

该命令将使用bash shell启动容器(我想使用bash shell，因为source是bash命令)，获取env.sh文件(设置环境变量)并执行jar文件。

env.sh是这样的，

#!/bin/bash
export FOO="BAR"
export DB_NAME="DATABASE_NAME"

我添加printenv命令只是为了测试实际的源命令是否有效。您应该在确认源命令正常工作时删除它，否则环境变量将出现在docker日志中。

如果您在本地的env.sh中有环境变量，并且希望在容器启动时设置它，您可以尝试

COPY env.sh /env.sh
COPY <filename>.jar /<filename>.jar
ENTRYPOINT ["/bin/bash" , "-c", "source /env.sh && printenv && java -jar /<filename>.jar"]

该命令将使用bash shell启动容器(我想使用bash shell，因为source是bash命令)，获取env.sh文件(设置环境变量)并执行jar文件。

env.sh是这样的，

#!/bin/bash
export FOO="BAR"
export DB_NAME="DATABASE_NAME"

我添加printenv命令只是为了测试实际的源命令是否有效。您应该在确认源命令正常工作时删除它，否则环境变量将出现在docker日志中。

另一种方法是使用/usr/bin/env的功能:

docker run ubuntu env DEBUG=1 path/to/script.sh

使用-e或——env value设置环境变量(默认[])。

一个启动脚本的例子:

 docker run  -e myhost='localhost' -it busybox sh

如果您想从命令行使用多个环境，那么在每个环境变量之前使用-e标志。

例子:

 sudo docker run -d -t -i -e NAMESPACE='staging' -e PASSWORD='foo' busybox sh

注意:请确保将容器名称放在环境变量之后，而不是之前。

如果你需要设置很多变量，使用——env-file标志

例如,

 $ docker run --env-file ./my_env ubuntu bash

对于任何其他帮助，查看Docker帮助:

 $ docker run --help

官方文档: https://docs.docker.com/compose/environment-variables/

如果你使用“Docker -compose”作为旋转容器的方法，实际上有一种有用的方法可以将服务器上定义的环境变量传递给Docker容器。

在你码头式的写作中。Yml文件，让我们说你正在旋转一个基本的happi -js容器，代码看起来像:

hapi_server:
  container_name: hapi_server
  image: node_image
  expose:
    - "3000"

假设你的docker项目所在的本地服务器有一个名为“NODE_DB_CONNECT”的环境变量，你想把它传递给你的hapi-js容器，你想让它的新名称为“HAPI_DB_CONNECT”。然后在docker-compose。Yml文件中，你可以将本地环境变量传递给容器，并像这样重命名它:

hapi_server:
  container_name: hapi_server
  image: node_image
  environment:
    - HAPI_DB_CONNECT=${NODE_DB_CONNECT}
  expose:
    - "3000"

我希望这能帮助您避免在容器中的任何文件中硬编码数据库连接字符串!

使用docker-compose，你可以在docker-compose中继承env变量。yml和docker-compose调用的任何Dockerfile来构建映像。当Dockerfile RUN命令应该执行特定于环境的命令时，这很有用。

(您的shell已经在环境中存在RAILS_ENV=development)

docker-compose.yml:

version: '3.1'
services:
  my-service: 
    build:
      #$RAILS_ENV is referencing the shell environment RAILS_ENV variable
      #and passing it to the Dockerfile ARG RAILS_ENV
      #the syntax below ensures that the RAILS_ENV arg will default to 
      #production if empty.
      #note that is dockerfile: is not specified it assumes file name: Dockerfile
      context: .
      args:
        - RAILS_ENV=${RAILS_ENV:-production}
    environment: 
      - RAILS_ENV=${RAILS_ENV:-production}

Dockerfile：

FROM ruby:2.3.4

#give ARG RAILS_ENV a default value = production
ARG RAILS_ENV=production

#assign the $RAILS_ENV arg to the RAILS_ENV ENV so that it can be accessed
#by the subsequent RUN call within the container
ENV RAILS_ENV $RAILS_ENV

#the subsequent RUN call accesses the RAILS_ENV ENV variable within the container
RUN if [ "$RAILS_ENV" = "production" ] ; then echo "production env"; else echo "non-production env: $RAILS_ENV"; fi

这样，我就不需要在文件或docker-compose build/up命令中指定环境变量:

docker-compose build
docker-compose up