According to some refs I read (https://dockerlabs.collabnix.com/beginners/difference-compose-dockerfile.html and Dockerfile FROM vs Docker-compose IMAGE), I understand them as:
a. Dockerfile together with {docker build} is the build process, which specifies the basic image to be used and have a temp container created in the building process and RUN any additional steps/commands to the final state and use the final state as the result built image.
b. docker-compose is the run process, which specifies a group of images to download and run each image as a container.

If it is the case,
a. It seems that a series of {docker pull}, {docker run}, {docker exec} and {docker commit} in a script file can replace Dockerfile and docker-compose?
b. Is there any difference if I have 1 docker-compose file compared with 2?

CodePudding user response：

Dockerfile

Dockerfile, instruction to run your application, with the base image as your environment into a configuration file, the way you run your application in local.

Docker Image

Set of layers in the image with all the configurations and application code given in the Dockerfile, which is independent of the machine, to run in any docker environment.

Commad: docker build -t <IMAGE_NAME> <Dockerfile_PATH>

Docker pull is used when the image is already created by someone and we want to use it, like mysql or elasticsearch or openjdk and so on.

Docker pull

Pull the existing image docker the image registry, if the image or any image layer exists in local docker image cache it will not pull again.

Docker run

Run the docker image as a container, which now acts as an isolated environment from the host, it runs with the configuration at Dockerfile.

docker run command is not recommended to run the same command every time you deploy your changes.

docker run, the command also pulls the image if the image doesn't exist in the local registry

Run multiple containers with one command is not possible.

For example, running your nginx application with mysql in one single docker run command is not possible.

Run Nginx

docker run -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro --restart always --log-opt max-size=1g nginx

Run mysql

docker run -p 5432:5432 --restart always --log-opt max-size=1g mysql

Docker Compose

The docker run command as code we configure with the .yml conf is docker-compose with multiple services nginx, mysql

version: '3.3'
services:
    mysql:
        image: MySQL
        container_name: mysql
        ports:
            - '5432:5432'
        restart: always
        logging:
            options:
                max-size: 1g

    nginx:
        image: nginx
        container_name: nginx
        ports:
            - '80:80'
        volumes:
            - '/var/run/docker.sock:/tmp/docker.sock:ro'
        restart: always
        logging:
            options:
                max-size: 1g

Run all containers with one command

• docker-compose -f <FILE_NAME>.yml up -d

Stop all containers with one command

• docker-compose -f <FILE_NAME>.yml down

To understand better about docker run vs docker-compose here is the composeriser link

Docker EXEC

Every container acts as a virtual machine sharing the kernel of the host, to get the ssh access to execute the commands in the container we need to get into the container with exec.

For example, to execute MySQL commands like create the database and create tables or to check any other conf with MySQL container we need to use exec as follows.

docker exec -it mysql bash

mysql>

exec mysqldump --all-databases -uroot -p"$MYSQL_ROOT_PASSWORD" > /some/path/on/your/host/all-databases.sql

CodePudding user response：

docker build is sort of like a sequence of docker run and docker commit. The newer BuildKit backend makes this murkier (the intermediate images aren't directly accessible) but conceptually it's still the same model.

A Docker Compose setup is very similar to a sequence of docker run commands, possibly running docker build first, and possibly also creating other Docker objects along the way (docker network create, docker volume create).

You should pretty much never run docker commit at all. docker exec is an extremely useful debugging tool, but you should use it the same way you'd use a debugger like gdb; it should not be the usual way you interact with a container, and it shouldn't usually appear in scripts.

If you do have a script that docker runs a container, docker execs commands inside it, docker stops it, and docker commits the result to an image, it is almost definitely better practice to rewrite this sequence of steps as a Dockerfile. You can then docker build the image, or include the directory in a Compose build: block and have Compose do that for you.