内容导读：导航目录:1、Docker基础2、详解Docker——你需要知道的Docker进阶知识五3、谁可以简单介绍一下docker到底是干什么用的？4、渗透测试报告自动生成工具Docker基础Docker是一个开源的应...……
导航目录:
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 存储驱动非常简单，只需要修改配置文件即可。
详解Docker——你需要知道的Docker进阶知识五
Dockerfile 是一个文本文件，其中包含了构建 Docker 镜像需要执行的命令序列。使用 docker build 命令从 Dockerfile 中读取指令来构建镜像。
构建镜像时，该过程的之一件事是将 Dockerfile 文件所在目录下的所有内容发送给 Docker 守护进程。所以大多数情况下，更好创建一个新的目录，在其中保存 Dockerfile ，以及构建镜像所需的其它文件。Dockerfile 文件所在目录也被称为构建上下文（context）。
使用 FROM 指令指定一个基础镜像，后续指令将在此镜像基础上运行：
在 Dockerfile 中可以指定一个用户，后续的 RUN ， CMD 以及 ENTRYPOINT 指令都会使用该用户身份去执行，该用户必须已存在。
除了指定用户之外，还可以使用 WORKDIR 指定当前工作目录（CWD）， RUN ， CMD ， COPY ， ADD 指令将在指定的工作目录中执行。
RUN 指令用于执行命令，该指令有两种形式：
例如我们执行更新命令：
CMD 的使用方式跟 RUN 类似，不过在一个 Dockerfile 文件中只能有一个 CMD 指令，如果有多个，则只有最后一个会生效。该指令指定了启动容器时要执行的命令，例如：
可以在 docker run 时指定命令来覆盖默认的 CMD 命令，比如 docker run image echo"hello shiyanlou" 。
CMD 指令还有一种特殊用法。在 Dockerfile 中，如果使用 ENTRYPOINT 指令指定了入口命令，则 CMD 指令的内容会作为 ENTRYPOINT 指令的参数：
ENTRYPOINT 指令会覆盖 CMD 指令作为容器运行时的默认指令，并且该指令不会被 docker run 时指定的指令覆盖，如下示例：
上述文件构建出来的镜像，使用 docker run image 等同于 docker run image ls-a-l 。使用 docker run image-i-s 等同于 docker run image ls-a-i-s 。即 CMD 指令的值会被当作 ENTRYPOINT 指令的参数附加到 ENTRYPOINT 指令的后面，只有 CMD 指令可以被覆盖。
COPY 和 ADD 都用于将构建上下文中的文件，目录等复制到镜像中。使用方式如下：
`` 可以指定多个，但是其路径不能超出构建上下文范围，即必须在 Dockerfile 同级或子目录中。
不需要预先存在，不存在时会自动创建，如果使用相对路径，则 为相对于工作目录的路径。
COPY 和 ADD 的不同之处在于，ADD 可以添加远程文件，并且 `` 可以是 gzip 或 tar 等格式的压缩文件，添加时会自动进行解压。
ENV 指令用于设置环境变量：
VOLUME 指令指定要创建的挂载路径，在容器运行时，将为每个挂载路径创建一个匿名卷并挂载上去：
上述指令将会在容器运行时，创建两个匿名卷，并分别挂载到容器中的 /data1 和 /data2 路径。
学习了上面这些常见的 Dockerfile 指令之后，可以使用这些指令来构建一个镜像。如下所示，构建一个提供 ssh 服务的镜像:
构建镜像
查看镜像
启动容器
查看已经启动的容器
测试远程登录
Compose 是运行由多个容器组成的 Docker 应用的工具，使用 Compose 可以一次启动一组有关联的服务，每个服务由来自同一镜像的单个或多个容器组成。
在复杂应用中，应用一般由多个服务（service）组成，例如一个网站后台通常包含 Web 服务、数据库服务、缓存服务、消息队列服务等。
使用 Compose 的步骤如下：
目前有三种版本的 Compose 文件格式：
下载 docker-compose-Linux-x86_64
下载成功后，为了方便使用，可以将其添加到 PATH 路径下
执行完成后，就能够在终端下直接使用 docker-compose 命令了：
接下来我们将创建一个 Web 应用，该应用包含两个容器：
项目目录结构如下：
首先编辑 app/web/web.py 文件，写入下面的内容：
上述代码创建了一个简单的 Web 应用。该应用会连接 redis 服务，在访问 / 页面时，自动将变量 number 加 1。
编辑 app/web/requirements.txt 文件，输入如下内容：
requirements.txt 文件存放了 Web 应用依赖的第三方库包的名称和版本信息。
编辑 app/web/Dockerfile 文件，添加如下内容
上述 Dockerfile 定义了 Web 应用镜像，该镜像基于 python:2.7 基础镜像，在其基础上安装了应用依赖的库包，并通过 CMD 指令指定了应用的启动命令。
编辑 app/docker-compose.yml 文件：
该 docker-compose.yml 文件定义了两个服务，分别为 web 和 redis 服务，并且配置了 web 服务的端口映射和挂载目录。 depends_on 定义了依赖关系，被依赖的服会先启动。
进入 app 目录，执行 docker-compose up 命令来启动应用：
启动成功后，就可以打开网址 127.0.0.1:8001 来访问 Web 应用了。
另外一些命令：
谁可以简单介绍一下docker到底是干什么用的？
1）测试：Docker 很适合用于测试发布，将 Docker 封装后可以直接提供给测试人员进行运行，不再需要测试人员与运维、开发进行配合，进行环境搭建与部署。
2）测试数据分离：在测试中，经常由于测试场景变换，需要修改依赖的数据库数据或者清空变动 memcache、Redis 中的缓存数据。Docker 相较于传统的虚拟机，更轻量与方便。可以很容易的将这些数据分离到不同的镜像中，根据不同需要随时进行切换。
3）开发：开发人员共同使用同一个 Docker 镜像，同时修改的源代码都被挂载到本地磁盘。不再因为环境的不同而造成的不同程序行为而伤透脑筋，同时新人到岗时也能迅速建立开发、编译环境。
4）PaaS 云服务：Docker 可以支持命令行封装与编程，通过自动加载与服务自发现，可以很方便的将封装于 Docker 镜像中的服务扩展成云服务。类似像 Doc 转换预览这样的服务封装于镜像中，根据业务请求的情况随时增加和减少容器的运行数量，随需应变。
渗透测试报告自动生成工具
公众号：白帽子左一
领取配套练手靶场、安全 *** 课程及工具...
在安服仔的日子里，发现其他人输出的渗透测试报告结果不规范，主要在报告质量、内容、字体、及修复方案中存在诸多问题，而且 大部分安服仔需要对每次的项目结果进行统计整理，方便后续跟踪复测。
因此研发了 Savior—渗透测试报告辅助生成系统 ， 起这个名字也是为了拯救大多数渗透测试工程师，
告别繁琐的渗透测试报告编写过程及漏洞统计过程。
前端 ： Ant Design Pro
后端 ： Django REST Framework
数据库 ： Mysql
用户管理 ： 主要是方便统计漏洞的发现者，后续可能大概也许会添加漏洞统计模块，根据提交数据、漏洞类型、时间等进行统计报表，当前用户管理模块仅允许通过Django后台进行修改，前端只负责展示，主要是我太懒了。
项目管理 ： 根据项目的不同可上传项目的专属渗透测报告模板，并可以根据需要进行模板自定义模板（/Demo/demo.docx）；
模板自定义 ： 不用修改源代码，仅需修改word即可进行模板自定义；
整改建议管理 ： 此平台主要就是为了体现标准化输出，因此可通过内置漏洞描述及修复建议进行快速输出，并支持自定义修改（/Demo/常规WEB渗透测试漏洞描述及修复 *** .docx）；
一键生成： 通过提交报告模块，内联项目模板，快速生成渗透测试报告，真正达到了一键生成，并确保报告内数据准确、字体统一、格式标准；
自动邮件： 在生成报告后可通过用户管理配置的自动邮件发送功能进行邮件通知，可自定义邮件模板，这样再报告给客户的时候就可以直接转发了（暖男功能）；
漏洞统计： 每次渗透过后，需要挨个查找报告进行统计整理，现在只要提交报告后，后台会自动联动；
漏洞报表一键导出
漏洞跟踪： 增加了漏洞状态字段，创建报告后，漏洞状态默认为新增，漏洞管理模块可进行复测，包括已整改、未整改两种状态；
Demo ：
演示账号 ：admin
演示密码 ： Savior@404
首先将代码clone到本地：
Docker部署
我们推荐使用Docker进行部署，相对于源码部署更为简单和快速。
部署前请务必先安装 Docker 及 docker-compose 。
修改配置文件
首先复制根目录的 .env.docker 并重命名为 .env ， 修改其中的Email Settings和initial Administrator配置。
这两个配置分别控制邮件提醒，以及初始管理帐号密码及邮箱。
同时需要注意以下两点：
1. 务必把邮箱修改为自己邮箱，不然可能会出现非预期错误！
2. 如果使用阿里云、腾讯云服务器，请使用 *** tp的ssl协议，两家云厂商默认封禁了25端口。
一键启动
访问 即可看到页面。
修改启动端口
如果想修改启动端口，可以修改docker-compose.yaml文件中web容器的ports。
默认为8000:8000，比如要修改为8080端口可改为8080:8000。
所需环境：
前端环境
环境变量设置 创建字符集为utf-8编码的数据库。
复制**.env.docker为.env**，并配置数据库、邮箱、管理员等信息。
后端环境
源码部署环境：
前台页面 ：
Django管理后台：
其中Savior平台包含两个后台页面。考虑到安全性，目前用户管理、项目管理托管于Django管理后台（主要是这两个模块不会写），其余功能均可通过前台页面实现。
前台页面 ：
Django管理后台 ：
访问Django管理后台： ,
请完善API用户的Name、Avatar、Autosentmail三个字段，分别控制报告的作者、头像（图片Url）、生成报告后自动发送渗透测试报告到邮箱。
访问Django管理后台：
请通过APIProjects进行添加项目，可根据不通项目选择不通的渗透测试报告模板。
参数说明：Project logo（项目Logo）、Project center（项目名称）、Project description（项目描述）、Project template（渗透测试报告模板，目前标准模板可使用Demo/demo.docx，如需自定义模板，请参考模版自定义部分）
访问 可进入Savior平台，通过个人设置整改设置添加漏洞模板可进行设置漏洞类型、漏洞描述、修复建议从而达到标准化。
目前整理了一些通用的修复建议模板，请参考Demo/常规WEB渗透测试漏洞描述及修复 *** .docx。
目前根据我经常使用的渗透测试报告模板生成了一个demo版本（请参考/Demo/demo.docx）。
当然您也可以根据自己的需求进行模板自定义，其中仅需在WORD模板中进行参数替换，目前Savior中具体参数如下：
以下漏洞详情请利用{%tr for vuls in vuls %}{%tr endfor %}进行循环遍历。
如想列出所有漏洞URL,则使用参数{%tr for vuls in vuls %}{{item.vul_url}}{%tr endfor %}
注： Savior平台渗透测试模板遵循Jinja2语法，更多内容请参考
如果我们完善了用户信息、项目管理、整改设置后，就可以通过前端页面进行创建报告，其大概流程如下：首先完善报告的基本信息。
选择漏洞管理的添加漏洞功能。选择漏洞类型后，漏洞名称、漏洞描述、修复建议会根据整改设置进行自动联动，并可根据需求进行自定义修改。
需要注意的是漏洞详情处如果需要插入XSS语句，请进行url编码后进行输入！
注： 未提交前请勿刷新页面，此时漏洞详情保存为前端。提交后会自动生成渗透测试报告并进行下载。
打开报告会提示更新域，更新请选择是，再选择更新整个目录，此问题主要是为了更新目录，不然渗透测试报告中目录无法自动更新。
如果在用户管理打开了Autosentmail功能，渗透测试报告会自动发送至我们邮箱，方便转给甲方爸爸。
访问Savior平台，选择漏洞列表可进行漏洞统计并进行漏洞复测。
其中漏洞包含三个状态（新发现、已修复、未修复）。
通过选择导出数据功能，可将漏洞列表导出为Excle。
用户管理、项目管理迁移至前端
大数据看板
感谢 echo503 提供的项目帮助
感谢 lp0int 提供的项目帮助
项目框架及 Docker 部署参考 Github-Monitor：（ ）
原文地址：