Docker editing entrypoint of existing container-CodePudding

I've docker container build from debian:latest image. I need to execute a bash script that will start several services. My host machine is Windows 10 and I'm using Docker Desktop, I've found configuration files in docker-desktop-data wsl2 drive in data\docker\containers\<container_name> I've 2 config files there: config.v2.json and hostcongih.json I've edited the first of them and replaced: "Entrypoint":null with "Entrypoint":["/bin/bash", "/opt/startup.sh"] I have done it while the container was down, when I restarted it the script was not executed. When I opened config.v2.json file again the Entrypoint was set to null again.

I need to run this script at every container start. Additional strange thing is that this container doesn't have any volume appearing in docker desktop. I can checkout this container and start another one, but I need to preserve current state of this container (installed packages, files, DB content). How can I change the entrypoint or run the script in other way? Is there anyway to export the container to image alongside with it's configuration? I need to expose several ports and run the startup script. Is there anyway to make every new container made from the image exported from current container expose the same ports and run same startup script?

CodePudding user response：

Docker's typical workflow involves containers that only run a single process, and are intrinsically temporary. You'd almost never create a container, manually set it up, and try to persist it; instead, you'd write a script called a Dockerfile that describes how to create a reusable image, and then launch some number of containers from that.

It's almost always preferable to launch multiple single-process containers than to try to run multiple processes in a single container. You can use a tool like Docker Compose to describe the multiple containers and record the various options you'd need to start them:

# docker-compose.yml

# Describe the file version.  Required with the stable Python implementation
# of Compose.  Most recent stable version of the file format.
version: '3.8'

# Persistent storage managed by Docker; will not be accessible on the host.
volumes:
  dbdata:

# Actual containers.
services:
  # The database.
  db:
    # Use a stock Docker Hub image.
    image: postgres:15
    # Persist its data.
    volumes:
      - dbdata:/var/lib/postgresql/data
    # Describe how to set up the initial database.
    environment:
      POSTGRES_PASSWORD: passw0rd
    # Make the container accessible from outside Docker (optional).
    ports:
      - '5432:5432'  # first port any available host port
                     # second port MUST be standard PostgreSQL port 5432

  # Reverse proxy / static asset server
  nginx:
    image: nginx:1.23
    # Get static assets from the host system.
    volumes:
      - ./static:/usr/share/nginx/html
    # Make the container externally accessible.
    ports:
      - '8000:80'

You can check this file into source control with your application. Also consider adding a third container that build: an image containing the actual application code; that probably will not have volumes:.

docker-compose up -d will start this stack of containers (without -d, in the foreground). If you make a change to the docker-compose.yml file, re-running the same command will delete and recreate containers as required. Note that you are never running an unmodified debian image, nor are you manually running commands inside a container; the docker-compose.yml file completely describes the containers, their startup sequences (if not already built into the images), and any required runtime options.

Also see Networking in Compose for some details about how to make connections between containers: localhost from within a container will call out to that same container and not one of the other containers or the host system.