容器的DNS和主机名

容器启动时会有3个和DNS、主机名相关的文件会被覆盖掉，/etc/hosts、/etc/hostname、/etc/resolvconf

Docker容器启动时会从宿主机复制/etc/resolvconf文件到容器，并删除到无法连接的DNS服务器
/etc/hosts文件中只记录容器自身的主机名和ip：

/etc/hostname文件记录容器的主机名：

version: '3' //docker-compose 版本 3x

services:  //服务的配置信息

    FileServer: //自己定义的服务

        image: nginx:latest  //使用的镜像名

        container_name: 'FileData' // docker容器名

        restart: always //重启策略 always 总是重新启动

        ports: - '8003:8003'  //映射端口信息 宿主端口：容器端口

        volumes: // 定义了卷信息，提供给 services 中的 具体容器使用

            - '/nginx/confd/defaultconf:/etc/nginx/confd/defaultconf' // 用户自己指定的目录:映射目录

            - '/nginx/log:/var/log/nginx'

            - '/file:/usr/share/nginx/file'

            - '/web:/usr/share/nginx/html'    //其他html连接目录

        command: /bin/bash -c "nginx -g 'daemon off;'"  //覆盖容器启动后默认执行的命令

autoindex on; //是否显示文件目录 on显示  off 关闭显示

autoindex_exact_size on; // 显示文件确切大小 on 显示字节单位 off 显示出文件的大概大小，单位是KB或者MB或者GB

autoindex_localtime on; //默认为off，显示的文件时间为GMT时间 ；改为on后，显示的文件时间为文件的服务器时间

charset utf-8,gbk; //显示的字符集

server{ //服务配置

    listen 8003; // 监听端口 ，也可以加上IP地址，如，listen 127001:8080;

    server_name _; //定义网站域名，可以写多个，用空格分隔。

    //匹配规则，在server{}里可以有很多location配置段
    //root/alias 是指定文件路径的两种方式 alias 相当于重定向路径
     //使用alias，目录名后面一定要加“/”

    location / { //location 后面跟的搜索路径

        root /usr/share/nginx/file; //指定文件服务地址 这里的目录是 yml 文件里配置的映射目录

    }

    location /web/{ 

        alias /usr/share/nginx/; //多个location 的时候这里只需要指定映射目录的上级目录就行了

        index indexhtml indexhtm; //配置默认首页

    }

}

可能是以下原因导致jsp文件上传容器无法执行：
缺少必要的依赖库：jsp文件上传需要依赖一些上传组件或框架，如果缺少这些依赖库，容器就无法正确执行上传 *** 作。
容器配置不正确：容器需要正确配置上传文件大小限制、上传文件保存路径等相关参数，否则会造成上传失败。
权限问题：容器运行时的权限问题也可能导致文件上传失败，需要确保容器有足够的权限进行文件上传 *** 作。
程序代码问题：可能是程序代码中存在逻辑错误或者bug导致上传失败，需要检查程序代码进行修复。
针对以上问题，可以尝试以下解决方法：
确认所有必要的依赖库已经正确添加到项目中，并且版本号与容器支持的版本号一致。
确认容器中的上传配置是否正确，并且容器有足够的权限进行文件上传 *** 作。
对于权限问题，可以尝试使用管理员权限启动容器或者修改容器的权限设置。
通过调试程序代码，找到上传失败的原因，并进行修复。可以使用日志记录等方式进行程序调试。
最后，建议在程序开发过程中先进行本地调试，确保上传功能正常后再部署到服务器上。

就是在Docker容器中再次运行一个Docker服务

在一个容器中 *** 作Docker在CI工具中是很常见的, 如构建一个Docker镜像

但由于在容器中运行一个Docker服务会有各种问题, 如镜像文件存储, 嵌套的容器也并不容易维护, 后来便衍生出了另一种更实用的方案: 挂载主机上Docker服务的sock

这样将不会遇到嵌套副作用，并且将在多个调用之间共享构建缓存。

ps: 更多知识请阅读 docker 官方提及的这篇文章: do-not-use-docker-in-docker-for-ci

我接下来要写的也是如何使用它, 并记录我的使用场景

我有一个需求是这样的:

当某个镜像更新之后, 通知docker重新pull并部署 简单的来说就是当容器更新, 就自动运行

以实现更新部署

由于自己编写的程序也运行在Docker中, 而不是宿主机, 所有没办法直接执行以上命令, 这就需要Docker In Docker了

简单来说 你只需要这样:

然后 docker ps 就能看到 宿主机上 的所有容器

如我的就是

当然 这里的stackyaml文件需要在构建这个容器时添加进来 或者 挂载进来, 这肯定难不倒你

如果你要将这段CMD在你的程序中运行也十分简单:

写好程序之后你可以使用这个Dockfile构建你的镜像

而运行这个镜像的stackyaml文件需要配置挂载

你会看到我又挂载了docker文件夹, 这个无关紧要, 在后面的疑难杂症会说到这个问题

此参数是179版本之后新加的, 用于解决deploy不pull最新的镜像的问题 详情看这个ISSUE:
force docker deploy to pull new images

私有仓库必须登录才有访问权限, 所以需要在宿主机上先login, 登录成功后会发现在 ~/docker有新生成的 配置文件
, 其中存储了认证所需要的信息 但在Docker容器中拿不到这个信息所以就会报错

解决办法是将配置文件挂载进容器

问题描述:

网络结构如下:

客户端 -> 服务器上的Nginx容器 (反代)-> 应用程序

在Nginx中配置了

在应用程序中得到">

在前面已经提到，容器的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。

Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下，kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命容器不与Pod中单个容器的生命周期相关，当容器终止或者重启时，Volume中的数据也不会丢失。

kubernetes的Volume支持多种类型，比较常见的有下面几个：

EmptyDir是最基础的Volume类型，一个EmptyDir就是Host上的一个空目录。

EmptyDir是在Pod被分配到Node时创建的，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为kubernetes会自动分配一个目录，当Pod销毁时， EmptyDir中的数据也会被永久删除。 EmptyDir用途如下：

接下来，通过一个容器之间文件共享的案例来使用一下EmptyDir。

在一个Pod中准备两个容器nginx和busybox，然后声明一个Volume分别挂在到两个容器的目录中，然后nginx容器负责向Volume中写日志，busybox中通过命令将日志内容读到控制台。

创建一个volume-emptydiryaml

EmptyDir中数据不会被持久化，它会随着Pod的结束而销毁，如果想简单的将数据持久化到主机中，可以选择HostPath。

HostPath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上。

创建一个volume-hostpathyaml：

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了，此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。

NFS是一个网络文件存储系统，可以搭建一台NFS服务器，然后将Pod中的存储直接连接到NFS系统上，这样的话，无论Pod在节点上怎么转移，只要Node跟NFS的对接没问题，数据就可以成功访问。

1）首先要准备nfs的服务器，这里为了简单，直接是master节点做nfs服务器

2）接下来，要在的每个node节点上都安装下nfs，这样的目的是为了node节点可以驱动nfs设备

3）接下来，就可以编写pod的配置文件了，创建volume-nfsyaml

4）最后，运行下pod，观察结果

前面已经学习了使用NFS提供存储，此时就要求用户会搭建NFS系统，并且会在yaml配置nfs。由于kubernetes支持的存储系统有很多，要求客户全都掌握，显然不现实。为了能够屏蔽底层存储实现的细节，方便用户使用， kubernetes引入PV和PVC两种资源对象。

PV（Persistent Volume）是持久化卷的意思，是对底层的共享存储的一种抽象。一般情况下PV由kubernetes管理员进行创建和配置，它与底层具体的共享存储技术有关，并通过插件完成与共享存储的对接。

PVC（Persistent Volume Claim）是持久卷声明的意思，是用户对于存储需求的一种声明。换句话说，PVC其实就是用户向kubernetes系统发出的一种资源需求申请。

使用了PV和PVC之后，工作可以得到进一步的细分：

PV是存储资源的抽象，下面是资源清单文件:

PV 的关键配置参数说明：

实验
使用NFS作为存储，来演示PV的使用，创建3个PV，对应NFS中的3个暴露的路径。
1准备NFS环境

2创建pvyaml

PVC是资源的申请，用来声明对存储空间、访问模式、存储类别需求信息。下面是资源清单文件:

PVC 的关键配置参数说明：

实验
1创建pvcyaml，申请pv

2创建podsyaml, 使用pv

PVC和PV是一一对应的，PV和PVC之间的相互作用遵循以下生命周期：

ConfigMap是一种比较特殊的存储卷，它的主要作用是用来存储配置信息的。

创建configmapyaml，内容如下：

接下来，使用此配置文件创建configmap

接下来创建一个pod-configmapyaml，将上面创建的configmap挂载进去

在kubernetes中，还存在一种和ConfigMap非常类似的对象，称为Secret对象。它主要用于存储敏感信息，例如密码、秘钥、证书等等。

1首先使用base64对数据进行编码

2接下来编写secretyaml，并创建Secret

3创建pod-secretyaml，将上面创建的secret挂载进去：

至此，已经实现了利用secret实现了信息的编码。

什么是docker

Docker 最初是 dotCloud 公司创始人 Solomon Hykes 在法国期间发起的一个公司内部项目，它是基于 dotCloud 公司多年云服务技术的一次革新，并于 2013 年 3 月以 Apache 20 授权协议开源，主要项目代码在 GitHub 上进行维护。Docker 项目后来还加入了 Linux 基金会，并成立推动 开放容器联盟（OCI）。

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 *** 作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 07 版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 111 开始，则进一步演进为使用 runC 和 containerd。

Docker 在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等等，极大的简化了容器的创建和维护。使得 Docker 技术比虚拟机技术更为轻便、快捷。

下面的比较了 Docker 和传统虚拟化方式的不同之处。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整 *** 作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。



传统虚拟化



Docker

为什么要用docker

对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。

使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。

而且使用 Dockerfile 使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。

特性容器虚拟机 启动秒级分钟级 硬盘使用一般为MB一般为GB 性能接近原生弱于 系统支持量单机支持上千个容器一般几十个

基本概念

我们都知道， *** 作系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu:1804 就包含了完整的一套 Ubuntu 1804 最小系统的 root 文件系统。

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为容器存储层。

按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入 *** 作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此，使用数据卷后，容器删除或者重新运行之后，数据却不会丢失。

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。

Centos安装docker18

常用的docker命令

常用的docker镜像

redis

mysql

---