Docker Build与Docker Run的区别及容器运行Python脚本相关技术疑问

Great questions—let’s break this down one by one to clear up the confusion:

1. Docker Build vs Docker Run: Core Differences #

These are two entirely separate stages in the Docker workflow:

• docker build: This creates a static Docker image. It executes the instructions in your Dockerfile (like COPY, RUN, ENV) step-by-step, packaging your code, dependencies, and configuration into a reusable image. The result is a file stored locally (or pushed to a registry) that doesn’t run on its own. Example:

  docker build -t my-python-app .
  

• docker run: This starts a dynamic container from an existing image. It creates an isolated runtime environment, sets up networking/storage, and executes the startup command defined in the image (via CMD or ENTRYPOINT). Each docker run creates a new instance of the image. Example:

  docker run my-python-app
  

2. Why Use RUN for Python Scripts When You Can Pass Args at Build Time? #

RUN executes commands during the build phase, not when the container starts. Its purpose is to prepare the image for runtime—think of it as one-time setup work that doesn’t need to repeat every time you start a container:

• Use RUN to install dependencies (e.g., RUN pip install -r requirements.txt): This saves time later, since every container started from the image will already have the dependencies installed.
• Use RUN for preprocessing tasks (e.g., compiling static assets, generating config files from build args): The results are baked into the image, so containers don’t waste resources redoing this work.

If you want x.py to run every time the container starts, don’t use RUN—that would only execute it once during build, and the result would be static in the image. Instead, use CMD or ENTRYPOINT for runtime execution.

3. Running x.py with Build-Time ENV Variables Every Time the Container Starts #

To make x.py use environment variables set during build, follow these steps:

1. Define a build argument and save it as an environment variable in your Dockerfile:

   # Accept a build-time argument
   ARG APP_ENV=production
   # Save it as an ENV variable (persists in the image)
   ENV APP_ENV=$APP_ENV
   
   # Copy your script into the image
   COPY x.py /app/
   WORKDIR /app
   
   # Define the startup command to run x.py
   CMD ["python", "x.py"]
   

2. Build the image with your desired argument:

   docker build --build-arg APP_ENV=staging -t x-app .
   

3. Every time you start a container from this image, it will use the APP_ENV value set during build to execute x.py. If you ever need to override it temporarily, you can pass a runtime env var:

   docker run -e APP_ENV=development x-app
   

4. Docker Swarm: Will It Skip Running x.py? #

No—you’re not missing a key point, but let’s clarify how Swarm works:

• Swarm is an orchestration tool that manages running containers, not just building images. When you deploy a Swarm service:
  1. If you specify a pre-built image (e.g., image: x-app), Swarm pulls the image onto target nodes (if not already present) and starts containers from it. These containers will execute the CMD/ENTRYPOINT defined in the image—so x.py will run.
  2. If you use Swarm’s build option in the service definition (to build the image directly on nodes), Swarm will first run docker build on the nodes, then immediately start containers from the newly built image—again, executing x.py via CMD/ENTRYPOINT.

The confusion might come from thinking Swarm only handles "building nodes"—but Swarm’s job is to ensure your desired number of containers are running, and those containers will always execute their startup command. The only time x.py wouldn’t run is if your Dockerfile doesn’t define a CMD/ENTRYPOINT, but that’s a Dockerfile issue, not a Swarm one.

内容的提问来源于stack exchange，提问作者Baily