問題描述

我的 nodejs 項目有以下文件

I have the following file for my nodejs project

FROM node:boron

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install



# Bundle app source
COPY . /usr/src/app

# Replace with env variable
RUN envsubs < fil1 > file2

EXPOSE 8080
CMD [ "npm", "start" ]

我使用 -e 標志運行 docker 容器，提供環境變量

I run the docker container with the -e flag providing the environment variable

但我沒有看到替代品.當 env 變量可用時會執行 Run c 命令嗎?

But I do not see the replacement. Will the Run ccommand be excuted when the env variable is available?

推薦答案

圖像是不可變的

Dockerfile 定義了鏡像的構建過程.一旦構建，圖像是不可變的(無法更改).運行時變量不會被烘焙到這個不可變的圖像中.所以 Dockerfile 是解決這個問題的錯誤地方.

Images are immutable

Dockerfile defines the build process for an image. Once built, the image is immutable (cannot be changed). Runtime variables are not something that would be baked into this immutable image. So Dockerfile is the wrong place to address this.

您可能想要做的是用您自己的腳本覆蓋默認的 ENTRYPOINT，并讓該腳本對環境變量執行一些操作.由于入口點腳本將在運行時(容器啟動時)執行，因此這是收集環境變量并對其進行處理的正確時間.

What you probably want to to do is override the default ENTRYPOINT with your own script, and have that script do something with environment variables. Since the entrypoint script would execute at runtime (when the container starts), this is the correct time to gather environment variables and do something with them.

首先，您需要調整 Dockerfile 以了解入口點腳本.雖然 Dockerfile 不直接參與處理環境變量，但它仍然需要了解該腳本，因為該腳本將被烘焙到您的鏡像中.

First, you need to adjust your Dockerfile to know about an entrypoint script. While Dockerfile is not directly involved in handling the environment variable, it still needs to know about this script, because the script will be baked into your image.

Dockerfile:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]
CMD ["npm", "start"]

現在，編寫一個入口點腳本，它會在命令運行之前完成所需的任何設置，最后，exec 命令本身.

Now, write an entrypoint script which does whatever setup is needed before the command is run, and at the end, exec the command itself.

entrypoint.sh:

#!/bin/sh

# Where $ENVSUBS is whatever command you are looking to run
$ENVSUBS < fil1 > file2

npm install

# This will exec the CMD from your Dockerfile, i.e. "npm start"
exec "$@"

在這里，我已包含 npm install，因為您在評論中詢問了這個問題.我會注意到這將在每次運行時運行 npm install .如果合適的話，很好，但我想指出它每次都會運行，這會給您的啟動時間增加一些延遲.

Here, I have included npm install, since you asked about this in the comments. I will note that this will run npm install on every run. If that's appropriate, fine, but I wanted to point out it will run every time, which will add some latency to your startup time.

現在重新構建您的映像，因此入口點腳本是其中的一部分.

Now rebuild your image, so the entrypoint script is a part of it.

入口點腳本知道如何使用環境變量，但您仍然需要告訴 Docker 在運行時導入該變量.您可以使用 -e 標志到 docker run 來執行此操作.

The entrypoint script knows how to use the environment variable, but you still have to tell Docker to import the variable at runtime. You can use the -e flag to docker run to do so.

docker run -e "ENVSUBS=$ENVSUBS" <image_name>

這里告訴Docker定義一個環境變量ENVSUBS，賦值給當前shell環境$ENVSUBS的值.

Here, Docker is told to define an environment variable ENVSUBS, and the value it is assigned is the value of $ENVSUBS from the current shell environment.

我將對此進行詳細說明，因為在評論中，您似乎對這如何組合在一起有些模糊.

I'll elaborate a bit on this, because in the comments, it seemed you were a little foggy on how this fits together.

當 Docker 啟動一個容器時，它會在容器內執行一個(并且只有一個)命令.該命令變為 PID 1，就像典型 Linux 系統上的 init 或 systemd 一樣.該進程負責運行容器所需的任何其他進程.

When Docker starts a container, it executes one (and only one) command inside the container. This command becomes PID 1, just like init or systemd on a typical Linux system. This process is responsible for running any other processes the container needs to have.

默認情況下，ENTRYPOINT 是 /bin/sh -c.您可以在 Dockerfile 或 docker-compose.yml 中覆蓋它，或者使用 docker 命令.

By default, the ENTRYPOINT is /bin/sh -c. You can override it in Dockerfile, or docker-compose.yml, or using the docker command.

當容器啟動時，Docker 運行入口點命令，并將命令 (CMD) 作為參數列表傳遞給它.之前，我們將自己的 ENTRYPOINT 定義為 /entrypoint.sh.這意味著在您的情況下，這是 Docker 啟動時將在容器中執行的內容:

When a container is started, Docker runs the entrypoint command, and passes the command (CMD) to it as an argument list. Earlier, we defined our own ENTRYPOINT as /entrypoint.sh. That means that in your case, this is what Docker will execute in the container when it starts:

/entrypoint.sh npm start

因為 ["npm", "start"] 被定義為命令，這就是作為參數列表傳遞給入口點腳本的內容.

Because ["npm", "start"] was defined as the command, that is what gets passed as an argument list to the entrypoint script.

因為我們使用 -e 標志定義了一個環境變量，所以這個入口點腳本(及其子腳本)將可以訪問該環境變量.

Because we defined an environment variable using the -e flag, this entrypoint script (and its children) will have access to that environment variable.

在入口點腳本的最后，我們運行 exec "$@".因為 $@ 擴展為傳遞給腳本的參數列表，這將運行

At the end of the entrypoint script, we run exec "$@". Because $@ expands to the argument list passed to the script, this will run

exec npm start

并且由于 exec 將其參數作為命令運行，用自身替換當前進程，當你完成時，npm start 變為 PID1 在您的容器中.

And because exec runs its arguments as a command, replacing the current process with itself, when you are done, npm start becomes PID 1 in your container.

在評論中，您詢問是否可以定義多個 CMD 條目來運行多個操作.

In the comments, you asked whether you can define multiple CMD entries to run multiple things.

您只能定義一個 ENTRYPOINT 和一個 CMD.在構建過程中根本不使用這些.與 RUN 和 COPY 不同，它們不會在構建期間執行.它們在構建后作為元數據項添加到圖像中.

You can only have one ENTRYPOINT and one CMD defined. These are not used at all during the build process. Unlike RUN and COPY, they are not executed during the build. They are added as metadata items to the image once it is built.

只有稍后，當圖像作為容器運行時，這些元數據字段才會被讀取，并用于啟動容器.

It is only later, when the image is run as a container, that these metadata fields are read, and used to start the container.

如前所述，入口點是真正運行的，它作為參數列表傳遞給 CMD.它們分開的部分原因是歷史原因.在 Docker 的早期版本中，CMD 是唯一可用的選項，ENTRYPOINT 被固定為 /bin/sh -c.但是由于這種情況，Docker 最終允許 ENTRYPOINT 由用戶定義.

As mentioned earlier, the entrypoint is what is really run, and it is passed the CMD as an argument list. The reason they are separate is partly historical. In early versions of Docker, CMD was the only available option, and ENTRYPOINT was fixed as being /bin/sh -c. But due to situations like this one, Docker eventually allowed ENTRYPOINT to be defined by the user.

這篇關于如何通過 dockerfile 在 ENTRYPOINT 之前執行 shell 命令的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！