35

A docker image is actually a linked list of filesystem layers. Each instruction in a Dockerfile creates a filesystem layer that describes the differences in the filesystem before and after execution of the corresponding instruction. The docker inspect subcommand can be used on a docker image to reveal its nature of being a linked list of filesystem layers. ...


27

Docker's EXPOSE documentation addresses this specific point: The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use ...


19

PHP with nginx is usually done using php-fpm which is a separate processus. Keeping the core idea of docker of one process (see end of answer for more details on this point) per container this makes sense to have the nginx process and php-fpm process in separate containers. As the communication between nginx and php-fpm arise through fastcgi the php-fpm ...


13

mkdir dir && cd dir && wget http://google.com && rm -rf dir doesn't do what you think it does. Let's break it down: mkdir dir creates dir. cd dir changes directory into it. wget http://google.com downloads google.com inside dir/. rm -rf dir attempts to delete a directory called dir that's in the current directory. The problem is ...


13

Each instruction you create in your Dockerfile results in a new image layer being created. Each layer brings additional data that are not always part of the resulting image. For example, if you add a file in one layer, but remove it in another layer later, the final image’s size will include the added file size in a form of a special "whiteout" file although ...


10

CMD with brackets is contained within an array. Without brackets, the command is executed as /bin/sh -c mysqld. Best practice afaik is to always use brackets.


8

As stated in the documentation, VOLUME instruction inherits the directory content and permissions existing in the container, so you can workaround the problem with a dockerfile like this: FROM ubuntu:xenial RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -p ubuntu ubuntu RUN mkdir /opt/myvolume && chown ubuntu /opt/myvolume WORKDIR /home/...


6

If one uses a Dockerfile then a colleague could also understand what happened (documentation as code). If one runs a container, enters it, runs commits then it would be hard to understand what packages were installed. Especially after a couple of months.


5

You can get to know if your site is up and running in the following way, Map both the ports of inside container to the host using -p option and try to curl localhost:port Scenario:- Run your container with the following command, docker run -d --name website -p 80:80 -p 22:22 mob Explanation:- -p host_port:container's_port Now, curl localhost:80 or ...


5

Recent Dockerfile spec allows for multiple FROM statements. https://docs.docker.com/engine/userguide/eng-image/multistage-build/ Using this approach, you can retain your compilation results to a pure runtime environment.


4

Building on Xiong Chiamiov's answer, which correctly identified the root cause of the problem - the dir reference by relative path when attempting to empty or delete that directory depends on the working directory at the time, which was not correctly set in the cases mentioned in the OP. So there are 2 solutions available: set the proper working dir prior ...


4

The RUN statements represent each one layer. Imagine that one downloads a package, installs it and would like to remove it. If one uses three RUN statements then the image size will not shrink as there are separate layers. If one runs all the commands using one RUN statement the disk image size could be reduced.


4

Actually, one missing point here is the horizontal scalability. There's an article from Jamie Alquiza long time ago addressed this: http://archive.is/pDzz0 In short, you scale your php-fpm horizontally for reaching higher performance. Scaling Nginx+php-fpm together does not bring you any benefit. I encourage you do some stress testing (e.g. Tsung, Gatling, ...


4

Convert the zip file into a gz file before running docker build, possibly in a wrapper script. Or even go one step further, and extract the archive first, then use COPY to copy the resulting folder contents. When you are using archives from the internet on the other hand, ADD http://somewhere/file.gz /data will extract the downloaded file directly into ...


4

Yes, one would usually have minimal docker images, i.e., one responsibility per image/container, with appropriate networking between them. Yes, images are linear, there is only ever one unbroken line of FROMs. To merge two images, get the two Dockerfiles and see what they are doing; it should be pretty self explanatory. Then you can either craft a single new ...


4

This is done for automation sake. You can have a universal command that runs docker run -P to start a container and the Dockerfile itself is used to specify which container exposes which port. In case you are dealing with dozens or hundreds of containers being built through a pipeline, this is quite useful. Passing external details not contained in ...


3

Docker on MacOS runs on a virtual machine (docker-machine), and it's known that docker-machine volume mounts may perform worse than what you'd expect. It becomes worse especially when it comes operations concerning lots of small files, like scanning the filesystem. Official Docker documentation also mentions this, and suggests some workarounds by lowering ...


3

Yes, you are doing the correct approach. Or rather, "a" correct approach, in your specific circumstance. You are proposing to build the image beforehand, not as part of each individual Jenkins job. Then your Jenkins job will consist of running the image; and in that ephemeral state (i.e., inside the container) you are checking out the test script, and ...


3

The ENV keyword will be translated to export command (builin of the shell usually), if you remove the multi-line declaration you end up with this equivalent: export A=123 B=$A What happens here is that when the shell parse the line to give it to export input, A is not yet exported and available as an environment variable. Step by step this will give: You ...


3

There is no meaningful benefit that outweighs having to manage two containers. As long as you have a 1:1 relationship between the processes and they serve a single purpose, put them in the same container.


3

Something like puppet would help automate and configure the Docker Container. CMS is configuration/provisioning and Docker is like you said a virtualization platform. You're trying to compare two completely different things. Here is an article on how to configure puppet with docker, sometimes an example helps. https://puppet.com/blog/building-docker-...


3

In the Dockerfile, the RUN step is performed during the docker build process. The operating system is shared with the host (containers != VMs). The filesystem and rest of the configuration used to define the temporary container is based on the state of the image resulting from the previous step. Each step in the Dockerfile extends the image with additional ...


3

Short version VOLUME instruction and -v dest are used to create unnamed/anonymous volumes, -v scr:dest option is for mapped volume. Long Version Dockerfile's VOLUME does not allow you to specify a host path. On the host-side, the volumes are created with a very long ID-like name, these volumes are often referred to as unnamed/anonymous volumes. Given ...


3

You can do this with BuildKit and the experimental frontend. As of 18.09, BuildKit can be enabled with either: export DOCKER_BUILDKIT=1 for a single shell, or to change the default for the host, you can add to /etc/docker/daemon.json: { "features": {"buildkit": true} } You'll need to reload the docker engine after changing the above. With BuildKit ...


3

Note: Don’t confuse RUN with CMD. RUN actually runs a command and commits the result; CMD does not execute anything at build time, but specifies the intended command for the image. reference


3

TL;DR: RUN performs the step during the image build, CMD is the default command when you start a container. If you define CMD and then start your container with a different command (e.g. docker run $my_image /bin/bash), you'll never see it run since you replaced your chmod command with an empty /bin/bash command. The detailed explanation: The RUN command ...


3

An approach I use in both prod and dev is to run a webhook server ( this one is excellent https://github.com/adnanh/webhook ) which is subscribed to listen to the github.com git push events which are published by github ... then when someone does a push to github.com the webhook launches a rebuild script to issue git pull then recomple the code and issue ...


2

Docker images are after all VM templates, i.e. they have to be more or less self-contained: you get the image, you run the environment with all the dependencies. To approach the challenge operationally, Docker supports reuse of environments through the FROM statement i.e. you could maintain a base image and on top a much smaller image with the app itself. ...


2

The main difference is that docker images are immutable and using is CMS is mutable. Once a docker image has been created it will work on all servers, while running a CMS could fail due to different environments, e.g. internet down, firewall, package repository unavailable. Could a CMS be combined with docker? Yes, to configure docker images using packer ...


2

It is possible that the base image is different on each host. Can you confirm the images for php:5-fpm on each host are identical? If the image from the Mac host is older, try updating it. You may need to update the package name in the dockerfile. If you want to preserve the same behavior on your newer host, make sure you are pulling the image with the ...


Only top voted, non community-wiki answers of a minimum length are eligible