我们开发环境Jenkins构建项目时报服务器磁盘空间不足，导致项目自动化构建部署失败，
Docker镜像服务器磁盘空间清理我们做了多次了，之前在清理Docker镜像服务器时走了不少弯路，查了不少Docker镜像服务器空间清理，都大同小异，都是一些如何清理历史镜像文件的文章，而实际按照清理镜像文件进行一顿 *** 作，释放的内存了了，最近一次磁盘空间报警事件，镜像文件清理也就才清理了40M，完全达不到清理磁盘空间的效果。
事实上我们的镜像执行sh脚本本身包含清理垃圾镜像文件的步骤：
因此，重要事情说三遍： 当Docker镜像服务器磁盘空间不足时，首先要考虑的时服务器的日志文件、大文件等等，最后才考虑Docker镜像本身占用的磁盘内存 。
df命令用于查看磁盘分区的使用情况，了解磁盘总量及用量，默认单位为KB。
当磁盘空间报警时，我们可以使用df命令查看磁盘分区使用情况：
注意，使用df -h命令会看到Docker镜像的/var/lib/docker 目录占很多空间，其实这是假象，许多同事初次看到这个接口首先应该就是去考虑如何清理/var/lib/docker，我也不例外。
不要受/var/lib/docker 目录影响，继续分析空间占用情况。
前面通过df命名我们大致了解了我们磁盘分区内存使用情况，使用du命令可以当前目录下文件、目录在磁盘中占用的空间的大小。
来到服务器顶层目录，执行命令：
找到内存使用异常的文件夹，进入其目录依次执行du -sh ，最终找到占用内存的大文件或日志，进行清理。
分享下我在情况过程找到的大文件
通过前面df 和du配合分析清理空间后，基本就能释放服务器磁盘空间，就简单提下Docker镜像清理咯，毕竟网上一大堆。
镜像清理。
批量清除无用的镜像
Docker 是一个开源的 应用容器引擎 ，让 开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化 。容器是完全使用沙箱机制，相互之间不会有任何接口。
由于本地开发好的程序往往都需要部署到服务器上进行运行，这就导致了程序需要运行在不同的环境上，这通常是一个令人头痛的事情。在过去，开发团队需要清楚的告诉运维部署团队，其所使用的全部配置文件+所有软件环境。不过，即便如此，仍然常常发生部署失败的状况。
于是乎， 虚拟化 技术应运而生。开发团队将开发好的程序在虚拟机上运行，这样就能解决运维的问题。但是由于虚拟机技术过重的特性导致了其 资源占用多、冗余步骤多以及启动慢的缺陷 。而这个时候 一种新的虚拟化技术搭配上容器化的思想 的产品便出现了，而它就是Docker。
下图是虚拟机技术和容器化技术架构的对比。我们可以得出以下总结：
[上传失败(image-efadd2-1643314980201)]
]( >不能完全等同。docker容器可以被认为是一种轻量级的虚拟化技术，它可以快速地创建、部署和运行应用程序，而不需要使用完整的 *** 作系统或完整的虚拟机，因此可以更快更容易地实现虚拟化。服务器是指安装在硬件系统上的 *** 作系统，可以用来提供托管服务，如文件服务器、数据库服务器、应用程序服务器等。它可以直接运行应用程序，而不需要使用docker容器。
目录
一、镜像加速
Docker 默认是从官方镜像地址 Docker Hub 下下载镜像，由于服务器在国外的缘故，导致经常下载速度非常慢。为了提升镜像的下载速度，我们可以手动配置国内镜像加速，让下载速度飚起来。
国内的镜像加速选项较多，如：阿里云，DaoCloud 等。
本文主要说说如何配置阿里云的镜像加速。
21 登录阿里云获取加速信息
>Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于go语言并遵从Apache20协议开源。Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化，容器是完全使用沙箱机制，相互之间不会有任何接口。
一个完整的Docker有以下几个部分组成：
Docker核心解决的问题是利用LXC来实现类似VM的功能，从而利用更加节省的硬件资源提供给用户更多的计算资源。同VM的方式不同, LXC 其并不是一套硬件虚拟化方法 - 无法归属到全虚拟化、部分虚拟化和半虚拟化中的任意一个，而是一个 *** 作系统级虚拟化方法, 理解起来可能并不像VM那样直观。所以我们从虚拟化到docker要解决的问题出发，看看他是怎么满足用户虚拟化需求的。
用户需要考虑虚拟化方法，尤其是硬件虚拟化方法，需要借助其解决的主要是以下4个问题：
Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类形
Docker面向对象容器对象镜像类
Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。 客户端和服务端既可以运行在一个机器上，也可通过 socket 或者RESTful API 来进行通信。
Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。 Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。
Docker 特性
在docker的网站上提到了docker的典型场景：
由于其基于LXC的轻量级虚拟化的特点，docker相比KVM之类最明显的特点就是启动快，资源占用小。因此对于构建隔离的标准化的运行环境，轻量级的PaaS(如dokku), 构建自动化测试和持续集成环境，以及一切可以横向扩展的应用(尤其是需要快速启停来应对峰谷的web应用)。
Docker并不是全能的，设计之初也不是KVM之类虚拟化手段的替代品，简单总结几点：
针对1-2，有windows base应用的需求的基本可以pass了; 3-5主要是看用户的需求，到底是需要一个container还是一个VM, 同时也决定了docker作为 IaaS 不太可行。
针对6,7虽然是docker本身不支持的功能，但是可以通过其他手段解决(disk quota, mount --bind)。总之，选用container还是vm, 就是在隔离性和资源复用性上做权衡。
另外即便docker 07能够支持非AUFS的文件系统，但是由于其功能还不稳定，商业应用或许会存在问题，而AUFS的稳定版需要kernel 38, 所以如果想复制dotcloud的成功案例，可能需要考虑升级kernel或者换用ubuntu的server版本(后者提供deb更新)。这也是为什么开源界更倾向于支持ubuntu的原因(kernel版本)
Docker并非适合所有应用场景，Docker只能虚拟基于Linux的服务。Windows Azure 服务能够运行Docker实例，但到目前为止Windows服务还不能被虚拟化。
可能最大的障碍在于管理实例之间的交互。由于所有应用组件被拆分到不同的容器中，所有的服务器需要以一致的方式彼此通信。这意味着任何人如果选择复杂的基础设施，那么必须掌握应用编程接口管理以及集群工具，比如Swarm、Mesos或者Kubernets以确保机器按照预期运转并支持故障切换。
Docker在本质上是一个附加系统。使用文件系统的不同层构建一个应用是有可能的。每个组件被添加到之前已经创建的组件之上，可以比作为一个文件系统更明智。分层架构带来另一方面的效率提升，当你重建存在变化的Docker镜像时，不需要重建整个Docker镜像，只需要重建变化的部分。
可能更为重要的是，Docker旨在用于d性计算。每个Docker实例的运营生命周期有限，实例数量根据需求增减。在一个管理适度的系统中，这些实例生而平等，不再需要时便各自消亡了。
针对Docker环境存在的不足，意味着在开始部署Docker前需要考虑如下几个问题。首先，Docker实例是无状态的。这意味着它们不应该承载任何交易数据，所有数据应该保存在数据库服务器中。
其次，开发Docker实例并不像创建一台虚拟机、添加应用然后克隆那样简单。为成功创建并使用Docker基础设施，管理员需要对系统管理的各个方面有一个全面的理解，包括Linux管理、编排及配置工具比如Puppet、Chef以及Salt。这些工具生来就基于命令行以及脚本。
总结一下虚拟机和Docker的区别：
再正面回答一下“Docker可以代替虚拟机运行生产服务器么”？
应用部署到服务器上的过程： 因为我是做java开发的，就拿一个正常的java项目举例。首先需要在服务器上搭建基础环境：
这只是一个简单的项目的部署前的配置，之后把您的项目打包发送的tomcat，运行即可。那如果有十几个服务器需要部署呢？是不是就要配置环境十多次，那人不是崩溃了。而且还会出现开发那边运行没问题，部署上去有问题的事情。所以这个时候docker出来了。
应用部署到docker上的过程：
两步搞定，不需要配置复杂的环境。如果有十多个容器需要部署怎么办？直接远程下载镜像即可，是不是很简单。
docker适合平台统一在linux的大单位用，服务越多越好，比如几百、几千、几万。配合k8s调度和微服务改造、加上自动化运维，能够实现d性扩容和缩容，达到on demand的效果，典型的用例是互联网内容提供商。
对于一般中小企业，只有几十台服务器的，平台不统一的，投资docker不如虚拟机。
除了不能跨os平台，docker的另一个缺陷是隔离度不够。
先说答案:可以，但是没有必要。
容器技术是虚拟化技术的应用，使用容器代替虚拟机运行程序自然是可以的，容器在持续集成方面相对虚拟机还有一定的优势，但是如果仅仅是为了用容器而用容器，则没有必要。
容器技术最大的优势是容器编排，可以实现线上服务的无缝扩容，缩容，降级，熔断等自动化 *** 作，极大的降低运维成本。所以，如果不用容器编排，则无须急着迁移。
理论上完全可以的，但目前我所接触到的生产方案基本上都是docker在虚机集群上跑。
看系统的要求了。docker不可能完全替代全部,windows服务器不可以，软件系统没有使用docker重新加载的，也是很难的。
用docker需要配合自动化，否则那是给自己找麻烦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; //配置默认首页
}
}
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）