Docker入门（1）——安装，使用，和镜像基础

最新推荐文章于 2025-03-10 14:09:01 发布

意言堂

最新推荐文章于 2025-03-10 14:09:01 发布

阅读量901

点赞数 1

分类专栏：研发管理文章标签： Docker 容器云计算互联网

本文链接：https://blog.youkuaiyun.com/s_swordman/article/details/88722218

版权

研发管理专栏收录该内容

8 篇文章

订阅专栏

在这里插入图片描述
关于什么是docker，为什么要使用docker，这个文章里面就不提了。这里主要是以实际操作为例，在一台服务器上操练如何安装使用docker的过程。

Docker的基础

Docker环境需要安装在一台Linux服务器上，我们这里用一台CentOS为例，实际上其他发行版也没有问题。
Docker的运行环境一般在线安装比较方便，所以这台服务器最好能联网。
Docker运行环境安装完毕之后，我们就可以在这个环境里面拉取镜像，运行容器了。

Docker安装和基本操作

安装环境

一般用各种docker相关的厂商提供的脚本安装就可以了
rancher提供的脚本
curl https://releases.rancher.com/install-docker/1.12.sh | sh
或者
curl -sSL https://github.com/gitlawr/install-docker/blob/1.0/1.12.6.sh?raw=true | sh
Rancher提供的脚本里面可以指定安装的Docker环境版本，如果要安装最新的版本，也可以用下面的DaoCloud提供的脚本
curl -sSL https://get.daocloud.io/docker | sh

修改镜像库的mirror

安装完Docker环境之后，运行docker version，如果成功安装，应该就可以看到docker的版本号。
然后如果不经过特殊的配置，docker相关的命令拉取镜像的目的地是docker.com的官方镜像库。因为各种网络原因，从Docker官方镜像库拉取镜像会很慢。好在同样很多docker相关的厂商提供了镜像库的mirror。
下面是我用的mirror，以及修改mirror的脚本
配置mirror：curl -sSL https://get.daocloud.io/daotools/set_mirror.sh | sh -s http://13111af8.m.daocloud.io

运行第一个容器

我们可以去docker的官方镜像库浏览页面里面去查找镜像，学习使用方法。
https://hub.docker.com/explore/

这里我们先实现一个小目标，希望用一条语句跑一个mongodb起来。
docker run --name=“ykbmongodb” -p 27017:27017 -v /data/mongo/db:/data/db -v /data/mongo/dbconfig:/data/configdb -d mongo:3.2

我们来分别解析这条语句。

首先docker run就是运行容器，容器是镜像的运行中的实例。也就是说运行一个容器，docker运行环境会先下载对应的镜像。所以docker run的意思就是先检查对应的镜像是否存在，不存在就开始下载镜像，下载好了之后，再运行对应的容器。
最后面的mongo:3.2，mongo表示镜像的名字，这是mongodb的镜像名。3.2表示标签（可以理解为版本号）。如果不写标签，默认会拉取标签为latest的镜像。注意，latest也只是一个标签，不一定保证它真的就是最新的。也就是说，如果你维护一个工具的镜像，每次发布一个新的镜像版本，你需要把latest这个标签赋给这个最新的版本。
name参数表示运行起来的容器的名字，最好是一个有意义的可以理解的名字。如果没有这个参数，系统会默认给一串数字字符组合作为名字。
p这个参数比较关键了，是把容器里面的端口和宿主机（也就是你当前用的这个服务器）的端口做一个映射。比如说，mongodb是需要占用27017作为服务的端口的。容器可以近似的看作是宿主机内部一个类似虚拟机的存在，这就意味着，容器里面的27017和宿主机是不通的，如果需要实现访问宿主机的27017端口就访问到容器的27017，那么就需要实现这样的一个端口映射。
v这个参数在理解了p参数之后就好理解了，就是为了能映射文件和文件夹。注意冒号前面是宿主机，后面是容器内部。v参数通常用于把容器里面的数据或者配置文件暴露到宿主机可以轻易访问的路径下面，便于修改，维护，备份。
其他的各种参数，可以参考docker的文档了。

mongodb的容器运行起来之后，可以用mongodb的客户端尝试连接并写入数据了。

换个姿势再运行一个容器

先看一下现在系统里面有哪些镜像吧，用这个方法
docker images
如果没有意外，现在应该只有一个之前我们拉下来的mongodb 3.2的镜像。

我们再尝试拉取一个nginx的镜像。
docker pull nginx

再看一下现在有哪些镜像，是不是多了一个？

现在用docker run 运行nginx的容器，就会发现不用再拉取镜像，直接运行了，不过我们可以加大一点难度。

我们准备一个叫做index.html的文件，里面的内容随便写，我写的就一句话：
hello world！
把这个文件放在宿主机/data/testnginx文件夹下面。然后执行下面的语句运行nginx容器：
docker run --name mynginx -d -p 80:80 -v /data/testnginx:/usr/share/nginx/html nginx

解析一下这条语句，和前面运行mongodb的相比，最大的区别就是
-v /data/testnginx:/usr/share/nginx/html
实际上就是把本机的/data/testnginx目录和容器里面的/usr/share/nginx/html关联了起来。
注意我们之前已经在宿主机的这个文件夹下面放置了index.html文件，也就是说当容器运行起来的时候，容器里面的/usr/share/nginx/html里面也有了这个index.html文件。
然后我们用浏览器访问一下宿主机的ip，默认80端口，可以看到，实际上我们访问了容器的80端口，并打开了index.html这个页面。

文件（夹）映射，端口映射是运行一个镜像的容器时最重要的参数，需要特别注意镜像的使用说明里面关于这部分的内容。

Docker镜像的基础

经过上面的操作，我们都理解了，在我们操作的这台服务器上，安装了docker运行环境之后，就可以拉取镜像，运行容器。
拉取下来的镜像，也是以专门的数据格式保存在docker运行环境里面的。也就是说，在现在操作的服务器上，找不到一个叫做mongo的镜像文件，或者nginx的镜像文件，可以由用户来复制，编辑。
除去一些特殊的操作，正常情况下，想要在一个docker环境里面添加一个镜像，有两个办法：

和我们上面操作的一样，docker pull
用docker build命令，编译自己的镜像

编译自己的镜像

我们先尝试着编译一个自己的镜像，不要担心，看起来很复杂，其实很简单。
docker build --rm -f Dockerfile -t testbuildnginx:0.1 .
t参数是指定编译之后的镜像名字和标签
f参数指定了一个叫做dockerfile的文件，这个文件告诉了build命令如何编译生成一个新的镜像。
所以可以看到，编译镜像的命令没什么好解释的。关键点都在如何编写这个dockerfile上面。

Dockerfile

Dockerfile就是一个文本文件，以我这个文件为例：
FROM nginx
copy bin/index.html /usr/share/nginx/html
这个dockerfile就包含上面这两行内容。
FROM nginx表示，当前要编译的镜像，以nginx镜像为基础。
copy bin/index.html /usr/share/nginx/html就更好理解了，就是把宿主机上的bin文件夹下面的index.html复制到镜像里面的/usr/share/nginx/html文件夹下面。
所以，在绝大多数情况下，编译一个镜像，都是在某一个镜像的基础上，做一些改动，增加或者删除某些文件，或者安装卸载某个应用，修改某个配置文件。
一般来说，镜像追溯到最后，都是基于某个Linux的发行版本。
对于我们来说，我们一般会基于某个比较稳定的成熟的应用镜像来做自己的镜像。比如说基于nginx，tomcat，jetty。当然也可以基于centos的镜像，再在dockerfile里面写上安装nginx，tomcat，jetty等操作，理论上当然可以，但是没有必要。

运行自己的镜像

像运行别的镜像一样，一旦编译完成，这个镜像就存在在本机的docker环境中了，可以通过docker run的命令运行。
docker run --name mytestbuildnginx -d -p 80:80 --restart=always testbuildnginx:0.1
假设我们当前的产品就是一个简单的html页面，那么完全可以通过Jenkins做一个持续集成的流程，类似这样：

当然，这只是思路之一。是否可以在线上生产服务器上一直运行一个nginx的镜像，通过文件夹映射出来一个文件夹，然后持续集成不停的更新这个文件夹里面的html？当然可以。但这又涉及到是否可以通过镜像发布来做版本管理和控制了。

基础镜像

前面说过，编译镜像的时候，一定是基于某个基础镜像，这个基础镜像可以是官方或者私有镜像库的某个镜像，也可以是自己之前编译出来的某个镜像。也就是说基于A编译出B，再基于B编译C，这样是没有问题的。
通常工作中也会维护自己的基础镜像，在这个基础上编译其他镜像版本。这个情况类似我们有时候会维护一套代码模板，新项目基于代码模板来创建项目。