skip to Main Content

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?

2

Answers


  1. 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
    
    Login or Signup to reply.
  2. 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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search