1. Dockerfile Run Apt Get Install
2. Dockerfile Install Apt-utils

RUN apt-get update && apt-get -y -no-install-recommends install libxml2-dev && docker-php-ext-install mbstring pdo pdomysql soap && pecl install sqlsrv pdosqlsrv xdebug && docker-php-ext-enable sqlsrv pdosqlsrv xdebug. It’s always advisable to put apt-get update and apt-get install commands on the same line. This is important because of layer caching. Having these on two separate lines would mean that if you add a new package to your install list, the layer with apt-get update will not be invalidated in the layer cache and you might end up in a mess. I started a container and typed the ext-install command into this container. Once I found all the dependencies, I wrote them into the Dockerfile. Example: RUN apt-get update && apt-get install -y libmcrypt-dev && docker-php-ext-install -j$(nproc) mcrypt There is a dependency that libmcrypt-dev needed before you can run docker-php-ext. Sudo apt-get install postgresql-client-12 Running SQL scripts on container startup. In some instances users want to run some SQL scripts to populate the database. Since the environment variable POSTGRESDB allows us to specify multiple database that can be created on startup. This is my entire Dockerfile: FROM ubuntu RUN apt-get update RUN apt-get install -y golang gcc make wget git libxml2-utils libwebkit2gtk-3.0-dev libcairo2 libcairo2.

方法一、docker pull tomcat

查找 Docker Hub 上的 Tomcat 镜像:

可以通过 Sort by 查看其他版本的 tomcat，默认是最新版本 tomcat:latest。

此外，我们还可以用 docker search tomcat 命令来查看可用版本：

这里我们拉取官方的镜像：

等待下载完成后，我们就可以在本地镜像列表里查到 REPOSITORY 为 tomcat 的镜像。

方法二、通过 Dockerfile 构建

创建Dockerfile

首先，创建目录tomcat,用于存放后面的相关东西。

webapps 目录将映射为 tomcat 容器配置的应用程序目录。

logs 目录将映射为 tomcat 容器的日志目录。

conf 目录里的配置文件将映射为 tomcat 容器的配置文件。

进入创建的 tomcat 目录，创建 Dockerfile。

通过 Dockerfile 创建一个镜像，替换成你自己的名字：

创建完成后，我们可以在本地的镜像列表里查找到刚刚创建的镜像：

使用 tomcat 镜像

运行容器

命令说明：

-p 8080:8080：将主机的 8080 端口映射到容器的 8080 端口。

-v $PWD/test:/usr/local/tomcat/webapps/test：将主机中当前目录下的 test 挂载到容器的 /test。

查看容器启动情况

通过浏览器访问

Docker has almost 4 years now. However some developers, especially newbies, still get confused when looking at the instructions that are available for use in a Dockerfile, because there are a few that may initially appear to be redundant (or, at least, have significant overlap) . RUN, CMD and ENTRYPOINT are a good example of this, and in this post I will explain the difference between CMD, RUN, and ENTRYPOINT on examples.

Short version

• RUN executes the command(s) that you give in a new layer and creates a new image. This is mainly used for installing a new package.

• CMD is the default command to be run by the entrypoint. It sets default command and/or parameters, however, we can overwrite those commands or pass in and bypass the default parameters from the command line when docker runs

• ENTRYPOINT is the program to run the given command. It is used when yo want to run a container as an executable.

Long version

1- Layering of Docker images

When Docker runs a container, it runs an image inside it. This image is usually built by executing a series of Docker instructions, which add layers on top of existing image or OS distribution. OS distribution is the initial image and every package is added as a new layer on top of that.

Let us consider the following Dockerfile to build a simple Ubuntu image with an Apache installation:

If we build the image by calling docker build -t med/aboullaite . we get an image called aboullaite, belonging to a repository called med. We can see the history of your image by calling docker history med/aboullaite:

The final image aboullaite consists of six intermediate images as we can see. The first three layers belongs to the Ubuntu base image and the rest is ours: one layer for every build instruction.

2- Shell vs. Exec

All three instructions RUN, CMD and ENTRYPOINT support two different forms: the shell form and the exec form.

When using the shell form, the specified binary is executed with an invocation of the shell using /bin/sh -c.
< instruction > < command >
For example let's consider the following Dockerfile:

You can see this clearly if you run a container and then look at the docker ps output:

Here we've run the aboullaite2 image and you can see that the command which was executed was /bin/sh -c 'ping localhost'.

You may run into problems with the shell form if you're building a minimal image which doesn't even include a shell binary. When Docker is constructing the command to be run it doesn't check to see if the shell is available inside the container, if you don't have /bin/sh in your image, the container will simply fail to start.

A better option is to use the exec form of the ENTRYPOINT/CMD instructions which looks like this:

CMD ['executable','param1','param2']

Note that the content appearing after the CMD instruction in this case is formatted as a JSON array.

When the exec form of the CMD instruction is used the command will be executed without a shell.

Let's change our Dockerfile from the example above to see this in action:

Rebuild the image and look at the command that is generated for the running container:

Now /bin/ping is being run directly without the intervening shell process.

RUN

Dockerfile Run Apt Get Install

As mentioned above, the RUN command is mainly used to install a new package on top of the main OS distribution. When you use the RUN command, it will execute the instruction and will create a new layer.

RUN command can be used in two forms:

CMD

CMD instruction allows you to set a default command and default parameters which will be executed when docker is run. But these commands and parameters can be overwritten by passing the values over the command line.

CMD can be specified in three forms:

Again, the first and third forms should look familar to you as they were already covered above. The second one is used together with ENTRYPOINT instruction in exec form. It sets default parameters that will be added after ENTRYPOINT parameters if container runs without command line arguments.

Let's have a look how CMD instruction works. The following snippet in Dockerfile

CMD echo 'Hello world'
when container runs as docker run -it <image> will produce output

Hello world

but when container runs with a command, e.g., docker run -it <image> /bin/bash, CMD is ignored and bash interpreter runs instead:

root@98e4bed87725:/#

ENTRYPOINT

ENTRYPOINT instruction should be used when you need your container to be run as an executable.
I might look similar to CMD, but in fact, it is different and should be used in a different context

The difference is ENTRYPOINT is that unlike CMD, the command and parameters are not ignored when Docker container runs with command line parameters.

ENTRYPOINT instructions too can be written in two forms:

• Exec form
  Exec form of ENTRYPOINT allows you to set commands and parameters and then use either form of CMD to set additional parameters that are more likely to be changed. ENTRYPOINT arguments are always used while CMD ones can be overwritten by command line arguments provided when Docker container runs. For example, the following snippet in Dockerfile

when container runs as docker run -it <image> will produce output

Dockerfile Install Apt-utils

Hello world

but when container runs as docker run -it <image> Manu will result in

Hello Manu

• Shell form

Shell form of ENTRYPOINT ignores any CMD or docker run command line arguments.

Conclusion

If you want your image to actually do anything when it is run, you should definitely configure some sort of RUN, ENTRYPOINT or CMD in you Dockerfile. However, remember that they aren't mutually exclusive. In many cases you can improve the user experience of your image by using them in combination.

Use RUN instructions to build your image by adding layers on top of the initial image.

Prefer ENTRYPOINT to CMD when building executable Docker image and you need a command always to be executed, and use CMD if you need to provide extra default arguments that could be overwritten from the command line when docker container runs.

Choose CMD if you need to provide a default command and/or arguments that can be overwritten from the command line when docker container runs.