Propagate log directory to cartridge-cli command

[akudiyar]

In this patch:

• propagate log directory to cartridge CLI so the logs are not created in the local directory
• fix problems with default Dockerfile on RedHat-like systems

[ArtDu]

Isn't it better to install rocks in an image so that the container of this image can be started immediately?

[akudiyar]

I don't completely get what you suggest. The rocks will be installed prior to launching the application according to CMD statement. If the contents of CARTRIDGE_SRC_DIR are not changed, the container will run almost immediately because the cartridge build command will just do nothing and return quickly.

[ArtDu]

I realized that my previous code isn't working as I wanted it.

We specify CARTRIDGE_SRC_DIR in an image assembling phase. So I wanted to build the application(install rocks) in the assembling phase.
But it doesn't work now, because we use COPY(not ADD) to copy files from the directory to a container.

In my conception, it would be great if we can collect rocks in an image-building phase. Then check whether nothing changed on the container starting after an image has been built.

Your changes don't change behavior so that you can merge them.

[akudiyar]

I believe that building the rocks on image building phase is not completely correct since the users can further change the Cartridge app dependencies. That should not lead to rebuilding the image, since only rocks will need to be rebuilt, and this is faster than the whole image rebuild.

[ArtDu]

I realized that my previous code isn't working as I wanted it.

We specify CARTRIDGE_SRC_DIR in an image assembling phase. So I wanted to build the application(install rocks) in the assembling phase. But it doesn't work now, because we use COPY(not ADD) to copy files from the directory to a container.

In my conception, it would be great if we can collect rocks in an image-building phase. Then check whether nothing changed on the container starting after an image has been built.

Your changes don't change behavior so that you can merge them.

I was wrong. Copy work during image building

[ArtDu]

I believe that building the rocks on image building phase is not completely correct since the users can further change the Cartridge app dependencies. That should not lead to rebuilding the image, since only rocks will need to be rebuilt, and this is faster than the whole image rebuild.

And that's why I left 2 lines with cartridge build. The first one in RUN command (during image building). The second one in CMD command(on container starting)

[akudiyar]

We can add one more stage, making COPY + RUN a separate layer that will be rebuilt without all the deps.
Also as an idea of future improvement, we may also specify the deps to be installed by yum in an external file so that we would be able automatically rebuild the whole image too in case if we want an external dependency for our Cartridge app (like a newer SSL library or whatever).

[ArtDu]

I realized that my previous code isn't working as I wanted it.

We specify CARTRIDGE_SRC_DIR in an image assembling phase. So I wanted to build the application(install rocks) in the assembling phase.
But it doesn't work now, because we use COPY(not ADD) to copy files from the directory to a container.

In my conception, it would be great if we can collect rocks in an image-building phase. Then check whether nothing changed on the container starting after an image has been built.

Your changes don't change behavior so that you can merge them.