dockerengine（dockerengine的配置文件复制在了记事本）

本篇文章给大家谈谈dockerengine，以及dockerengine的配置文件复制在了记事本对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Docker基础
• 2、为什么 yum remove docker* 不会删除 docker-engine
• 3、DooD:Docker+Jenkins
• 4、docker中使用docker
• 5、docker和docker-engine有什么区别
• 6、yum安装docker、docker-engine、docker-ce的区别

Docker基础

Docker 是一个开源的应用容器引擎，基于Go 语言 并遵从 Apache2.0 协议开源。

Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。

容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）,更重要的是容器性能开销极低。

Docker最早是在Ubuntu 12.04上开发实现的；

Red Hat则从RHEL6.5开始纳中对Docker进行支持。

而后Windows和Mac上也相应有了Docker版本支持。

在Docker容器技术出现之前，Linux上是已经有一个docker的工具的，但此docker非彼Docker。

这个docker是一个窗口停靠栏程序，就像苹果的Mac系统中的dock那个程序一样的一个工具。

为了区分开来，我们以Docker和docker来进行区分。

Docker：指容器技术。

docker：指窗口停靠栏程序。

Docker技术出来后，因为Linux系统上已经有了docker这个工具，所以Docker软件名也不能跟人家重名啊，要不然没办法安装。

由于那个时候Docker的官网是docker.io，所以就在软件名称上加了io的后缀，在Ubuntu中就是docker.io，在CentOS中就是docker-io。

但是虽然软件名跟docker程序不一样了，但软件安装后的操作命令还是一样的，都是docker的这个命令，所以要安装Docker软件，要先看看洞备山有没有安装了那个停靠栏程序docker，有的话要先卸载才行，要不然执行的命令是不对的。

这个时期要安装Docker，就要用docker加io后缀的方式来安装。

Docker容器使用docker.io和docker-io为软件名，主要是前期的一段时间。

后来随着Docker的发展，软件包名改成了docker-engine,不同系统中名称达到了统一。

再后来，随着Docker技术的火爆，在征得docker停靠栏程序作者同意下，原先的停靠栏程序docker名称改掉了，改成了wmdocker，Docker容器技术的软件包名才正式成了docker这个名称，Docker软件包的名称又得到了一次完全的统一。

到Docker1.13.1版本之前，Docker软件包的名称有两次变化，从docker-io(docker.io)到docker-engine,再到docker。

Docker发展到1.13.1版本号后，Docker公司把Docker分成了社区版(免费)Docker CE和商业版(付费)Docker EE两种形式，并且版本号命名方式也改了，以前是那种常用的版本号命令方式，比如0.1、0.2、1.0之类的，现在分社区和商业版后，版本号是“年.月”的形式命名的，比如2019年10月发布的，版本号就是19.10。

所以在Docker1.13.1之后，直接是Docker-ce 17.03.0版本了，也就是2017年03月发布的。

现在要安装最新版的Docker软件包，就是使用docker-ce这个名称了，如果是商业版的就是docker-ee了。

目前docker的默认存储引擎为overlay2，不同的存储引擎需要相应的文件系统支持，如需要磁盘分区的时候传递d-type稳健分层功能，即需要传递内核参数并开启格式化磁盘的时候指定的功能。

存储引擎的选择文档

AUFS

AUFSAnotherUnionFileSystem是一种UnionFS。V2版本后更名为 advanced multi‐layered unification fileystem，即高级多层统一文件系统。所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种系统可以一层一层的叠加修改文件。无论底下有多少层都是只读，只有最上层的文件系统是可读写。当需要修改一个文件时，AUFS创建该文件的一个副本。使用CoWCopy-on-Write将文件从只读层复制到可写滚耐层进行修改，结果也保留在可写层、在Docker中。底下的制度层就是image，可写层就是Container。

Overlay

一种Union FS文件系统，Linux内核3.18后支持

Overlay2

overlay的升级版，到目前为止，所有Linux发行版推荐使用的存储类型

devicemapper

是CentOS和RHEL的推荐存储驱动程序，但是依赖于direct-lvm，存在空间受限的问题，虽然可以通过后期配置解决；因为之前的内核版本不支持overlay2（集中在Centos/RHEL7.2之前版本）；但当前较新版本Centos和RHEL现已经支持overlay2。

zfs/btrfs(Oracle-2007)

目前没有广泛应用；这些文件系统允许使用高级选项，例如创建“快照”，但需要更多的维护和设置。并且每一个都依赖于正确配置的后备文件系统。

vfs

用于测试环境，适用于无法适用Cow文件系统的情况。此存储驱动程序的性能很差，通常不建议在生产中使用。

1）overlay存储驱动程序已在Docker Engine-Enterprise 18.09中弃用，并将在以后的版本中删除。建议将overlay存储驱动程序的用户迁移到overlay2。

2）devicemapper存储驱动程序已在Docker Engine 18.09中弃用，并将在以后的版本中删除。建议将devicemapper存储驱动程序的用户迁移到overlay2。

建议使用overlay2存储驱动程序。首次安装Docker时，默认情况下使用overlay2。早期版本，默认情况下会使用aufs。如果要在新版本中使用aufs，则需要对其配置，并且可能需要安装其他软件包，例如linux-image-extra。

对于Docker，支持文件系统是所在的文件系统 /var/lib/docker/。一些存储驱动程序仅适用于特定的后备文件系统。

配置 Docker 存储驱动非常简单，只需要修改配置文件即可。

为什么 yum remove docker* 不会删除 docker-engine

卸载Docker包： $ sudo apt-get purge docker-engine11 卸载Docker包及其以来不再需要使察燃用下面的命令咐唤： $ sudo apt-get autoremove --purge docker-engine11 上面的命令不会移除镜像，容器，卷或者是用户创建的衡没凯配置文件。

DooD:Docker+Jenkins

第一次发布博客。希望可以给需要的朋友们一些帮助。

本文基于64位的CentOS 7.2系统，内核版本如下：

Docker版本如下：

如需安装Docker，请点击： 安装Docker

如需安装Docker加速器，请点击： 配置Docker加速器

其实就是运行一个Jenkins镜像的docker容器，这种方式使用socket套接字（一般默认是/var/run/docker.sock文件）和宿主机进行交互，只限于本地通信。不会去监听任何端口。在创建Jenkins镜像时，可以给jenkins用户赋予sudo权限来调用docker命令；或者将jenkins用户加入到docker组，就可以直接在容器中调闭裤用docker命令，下文会分别讲到两种情况的Dockerfile的写法。不过相比较于不同的宿主机docker组的不同，使用腔态明sudo更具有普适性和可移植性。

顾名思义，就是在Docker容器中重新安装一个Docker应用。容器中安装Docker和宿主机安装的Docker是完全没有关联的两个程序。一般情况下，我们想要的只是一个运行于docker的CI/CD环境，我们需要容器内外只有一个docker engine。 DinD显然比我们想要的要复杂的多，而且可能还有一些意想不到的问题会出现。

更详细的了解，请参考下面两篇文章：

Docker还可以对外暴露Remote API，通过http/https就可以与docker engine进行通信，因为打开Remote API相应的要对外暴露端口，所以相对来说是不安全的。

在Jenkins容器中可以通过配置相应的Docker plugin，并在“系统管理”——“系统设置”——“云”中增添响应的Remote API信息。

详细信息请参考：

进过对比，我使用的是第一种方式：DooD。

注意点：请确保宿主机的doeker server已经开启本地套接字访问和远程通信

默认情况下，Docker守护进程会生成一个socket（/var/run/docker.sock）文件来进行本地进程通信，而不会监听任何端口，因此只能在本地使用docker客户端或者使用Docker API进行操作。

如果想在其他主机上操作Docker主机，就需要让Docker守护进程监听一个端口，这样才能实现远程通信。

目前开启本地套接字访问和远程通信有以下两种方式：

把以下内容添加进json文件中，注意添加前请确认2375端口是否被占用！！伍告！

如下图所示：

以上两种方式都可以通过下面的方式验证 docker remote API的2375端口是否开启

netstat -apn | grep 2375

在本地宿主机上新建一个Jenkins镜像数据的挂载目录，进行Jenkins数据的备份和持久化；因为Jenkins镜像中的Dockerfile中/var/jenkins_home权限为1000:1000，所以此处我们需要修改宿主机上的挂载目录权限，否则会出现权限不足的问题。注意：如果在生产中这样使用，一开始需要给/var/jenkins分配一个合理的容量，否则随着jenkins构建的增多会出现空间不足等问题。如下图：

第一种：在docker容器中，jenkins用户使用sudo执行docker命令

第二种：在docker容器中，jenkins用户可直接使用docker命令

我选用的是第二种，但是因为所在宿主机的不同，docker_gid会有所差异，建议使用第一种方式。

在上一步构建好的Dockerfile所在目录，执行下面的命令构建Jenkins镜像

使用上一步构建好的镜像，启动Jenkins容器，命令如下

使用如下命令查看安装密码，也可直接去看容器里边对应位置的文件（/var/jenkins_home/secrets/initialAdminPassword），或者去宿主机挂载的目录下查看文件（/var/jenkins//secrets/initialAdminPassword）

5.1 docker-client版本问题

Q1:搭建的jenkins容器出现下列错误，在容器中无法正常运行docker命令，可能是docker client的版本问题。

我当时出现问题的版本如下：

A1:该问题，有两种解决办法：第一，卸载重新安装合适的版本，上图这个版本是我使用yum install 安装的版本；第二种，只需安装docker-client。

Docker官网：

Docker社区：

DaoCloud：

DockOne:

Jenkins Base Dockerfile Github:

docker中使用docker

Docker 容器技术目前是微服务/持续集成/持续交付领域的第一选择。而在 DevOps 中，我们需要将各种后端/前端的测试/构建环境打包成 Docker 镜像，然后在需要的时候，Jenkins 会使用这些镜像启动容器以执行 Jenkins 任务。

为了方便维护，我们的 CI 系统如 Jenkins，也会使用 Docker 方式部署。

Jenkins 任务中有些任务需要将微服务构建成 Docker 镜像，然后推送到 Harbor 私有仓库中。

或者我们所有的 Jenkins Master 镜像和 Jenkins Slave 镜像本身都不包含任何额外的构建环境，执行任务时都需要启动包含对应环境的镜像来执行任务。

我们的 Jenkins Master、Jenkins Slaves 都是跑在容器里面的， 该如何在这些容器里面调用 docker run 命令启动包含 CI 环境的镜像呢？

在这些 CI 镜像里面，我们从源码编译完成后，又如何通过 docker build 将编译结果打包成 Docker 镜像，然后推送到内网仓库呢？

答案下面揭晓。

Docker 采取的是 Client/Server 架构，我们常用的 docker xxx 命令工具，只是 docker 的 client，我们通过该命令行执行命令时，实际上是在通过 client 与 docker engine 通信。

我们通过 apt/yum 安装 docker-ce 时，会自动生成一个 systemd 的 service，所以安装完成后，需要通凯渗过 sudo systemctl enable docker.service 来启用该服务。

这个 Docker 服务启动的，就是 docker engine，查看 /usr/lib/systemd/system/docker.service ，能看到有这样一条语句：

默认情况下，Docker守护进程会生成一个 socket（ /var/run/docker.sock ）文件来进行本地进程通信，因此只能在本地使用 docker 客户端或者使用 Docker API 进行操作。

sock 文件是 UNIX 域套接字，它可以通过文件系统（而非网络地址）进行寻址和访问。

因此只要以数据卷的形式将 docker 客户端和上述 socket 套接字挂载到容器内部，就能实现 "Docker in Docker"，在容器内使用 docker 命令了。具体的命令见后面的「示例」部分。

要记住的是，真正执行我们的 docker 命令的是 docker engine，而这个 engine 跑在宿主机上。所以这并不是真正的 "Docker in Docker".

运行过Docker Hub的Docker镜像的话，会发现其中一些容器时需要挂载/var/run/docker.sock文件。这个文件是什么呢？为什么有些容器需要使用它？简单地说，它是Docker守护进程(Docker daemon)默认监听的Unix域套接字(Unix domain socket)，容器中的进程可以通过它与Docker守护进程进行通信。

在容器内部使用宿主机的 docker，方法有二：

容器的启动方式也有两种，如下：

示例命令如下：

必须以 root 用户启动！（或者其他有权限读写 /var/run/docker.sock 的用户） 然后，在容器内就能正常使用 docker 命令，或者访问宿主机的 docker api 了。

docker-compose.yml 文件内容如下：

然后通过 docker-compose up -d 即可后台启动容器。

通过上面的操作，我们在槐宴容器内执行 docker ps 时，还是很可能会遇到一个问题： 权限问题 。

如果你容器的默认用户是 root，那么你不会遇到这个问题，因为 /var/run/docker.sock 的 onwer 就是 root.

但是一般来说，为了铅孙银限制用户的权限，容器的默认用户一般都是 uid 和 gid 都是 1000 的普通用户。这样我们就没有权限访问 /var/run/docker.sock 了。

解决办法：

方法一（不一定有效）：在构建镜像时，最后一层添加如下内容：

方法二：经测试一定有效，在Dockerfile中使用USER参数

这样我们构建的镜像就是root用户了，经测试在docker-compose.yaml文件中user参数并不好用,类似如下

这样我们的默认用户，就能使用 docker 命令了。

参考

[img]

docker和docker-engine有什么区别

When people say “Docker” they typically mean Docker Engine, the client-server application made up of the Docker daemon, a REST API that specifies interfaces for interacting with the daemon, and a command line interface (CLI) client that talks to the daemon (through the REST API wrapper). Docker Engine accepts dockercommands from the CLI, such as docker run , docker ps to list running containers, docker images to list images, and so on.

一般当人们说 “Docker”时， 他们一尺简卜般指的是Docker Engine， 一个client-server 结构的应用， 包含Docker daemon，一个 用来和咐兆daemon 交互的REST API， 一个命令行应用陵穗CLI。 Docker Engine 在命令行中接收并解析、执行docker 命令， 例如: docker run , docker ps等。

yum安装docker、docker-engine、docker-ce的区别

docker CE是社区版本，现在改名叫moby了。EE是商用版本，收虚散费的。有些教程里用的是官方源的docker，似乎消饥就是你说的docker-engine（我平时用apt系的发行版，yum里包的名字不太确定），软件版本已经非常老拿誉返了，不建议从官方源直接装，最好直接用docker的安装脚本操作。安装教本：网页链接（get.docker点com）

关于dockerengine和dockerengine的配置文件复制在了记事本的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。