I wonder what happened in cold start? Is the docker pull image a part of the cold start latency?
If I already have an image downloaded in my disk. Say a simple image to run a C++ fibonacci program. Here is my dockerfile:
FROM gcc:10
RUN mkdir /usr/src/myapp
COPY fib.c /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc fib.c -o fib
CMD ./fib
So which lines were executed in the container startup phase, and which lines of this dockerfile run in execution phase. I though at least the CMD ./fib (execute the compiled binary ./fib) is run during the execution phase. Not sure with the other lines.
After docker run, I used docker inspect command to get more information about time. I found the Created time and StartedAt time. I thought the subtraction of StartedAt and Created time is cold start latency, but I am not sure with that.
Because I have tried to change from COPY fib.c /usr/src/myapp to COPY a much larger file (1GB) to the /usr/src/myapp directory. I got a larger docker image, but the subtraction of StartedAt and Created time bacially does not change. I also dont notice any time difference when docker run these two images.
I apologize for the lengthy post, and thank you so much for saving this Docker newbie
if ENTRYPOINT is set, but CMD is not -> whatever in ENTRYPOINT is declared
if ENTRYPOINT is not, but CMD is set -> whatever in CMD is declared
if ENTRYPOINT and CMD are not set -> the container will die immedatly as no process will keep it running
If ENTRYPOINT and CMD are set -> ENTRYPOINT will be started and CMD will be a parameter to ENTRYPOINT. (not sure though, if I remember this correctly…)
The commands after the image name in docker run will be passed as parameter to whatever ENTRYPOINT/CMD you use.
Not sure though, why you discuss a Dockerfile and respecting declarations.
I know both ENTRYPINT and CMD both work as a command line for running a program, but I would like to test the cold start time that is the time spent in creating the container. I dont know how to measure it, so I gave an dockerfile example. Let me make this dockerfile simpler:
FROM ubuntu
COPY fib /Users/test/fibonacci
WORKDIR /Users/test/fibonacci
CMD ./fib
I think when I docker run this image, there should be two phases, the first phase is spinning up a container, the second step is running the program i want that is a simple program like a helloworld or a ./fib.
I am not sure how to reliably messure the starting time.
A container is nothing else than a fenced process on the host’s kernel. The container’s filesystem is nothing else than a merged filesystem (preferably overlayfs) that uses the image layers for lower (readonly) dirs and adds an upper dir for the containers write layer - it should take close to no time to make it available. Though, publishing ports can be time consuming when many ports are published. A container does not boot - it starts and ends with the process you start in ENTRYPOINT/CMD.
Thank you! I am still confused with the relation between the dokcer image and docker run:
(1) If a container is a process that starts and ends with ENTRYPOIT/CMD, then what are the command lines before the ENTRYPOINT/CMD: they dont belong to this process? They can all be called as cold start part then.
(2) when we run dokcer run, is it like a program executing from the first line to the end of the dockerfile, that is FROM ubuntu in our example?
(3) A container does not boot, so what is under the hood when execute COPY, RUN apt-get install and so on.
I have tried to COPY a much larger file, so the build process takes longer, but when I docker run that image, the time spent on docker run does not change, so obviously the docker run does not copy the file, the file is already in the image (disk). I guess it just isolate the file by a filesystem namespace. But what if I docker run the same image concurrently at the same time, anyway, there is only one image stored in disk, mutil containers cannot share the file I guess, so there should be real time-consuming copies of the file?
(4) If both (1) and (2) correct, can I put a timestamp at the beginning of the dockerfile, and another timestamp right before the ENTRYPOINT/CMD. The difference between the two timestamps is the latency to instantiate a container that I want to measure:slight_smile:
The Dockerfile contains the set of instructions that declare metadata, copy files from host into the image (COPY/ADD) and execute commands (every RUN instruction) and further details (CMD/EXECUTE/PORT/EXPOSE and more) while building(!) the image. Building an image has nothing to do with “cold start”. It feels like you are barking up the wrong tree.
Thank you Metin! Sorry for not checking the mail in time, so now I see maybe only CMD/ENTRYPOINT are executed in Docker run.
Do you think if there any execution time difference between the docker run for the first time and docker run after a docker run. (cold vs warm I guess)
I am not able to make you understand that docker containers do not suffer cold/warm starts. Containers are not FAAS service like AWS Lambdas,where the cold start problem realy is a thing. Just because FAAS generaly tends to package things in containers, the problem still does not originate in Docker. It originates in a cloud providers FAAS implementation.
I see. I now know there is no cold start thing in a locally running container. Do you know if there are any materials to help me understand more about the FAAS cold start process?
Because so many people are talking about cold start, but I never found it clearly explained.