docker 文件撑爆服务器根目录处理方案

默认的情况下，docker启动的容器经过日积月累，会产生很多的大文件，大到足以撑满服务器的磁盘空间。这个时候该怎么办呢？答案当然是扩容了。

这里给一个常规的解决思路，给云服务器增加一块大磁盘，然后将docker的文件全部移到新挂载的磁盘里，再为docker创建一个软链接即可。

示例中的磁盘并不是另外加的一块，而且之前就存在的磁盘，但是有一大部分空间未分配。但实际上这跟新加的磁盘处理方案是一样的，下面就以此为例做个简单介绍。

查看磁盘情况

可以看到xvda磁盘有200G的空间，但是只挂载了50G左右的，剩下的都在空闲状态，现在需要将剩下的150G左右的空间给利用上

执行以下命令，建立分区

按提示输入 m 可查看命令帮助
输入 p 查看当前磁柱请情况
输入 n 新建分区，并按提示选择分区类型，及起始和结束扇区
然后输入 w 保存
最后再用 reboot 重启服务器

重启服务器之后，为刚刚建立的分区格式化

可以用以下命令查看下挂载后的结果

之前这台服务器的根目录使用100%的磁盘，经过这个方法处理之后，降到45%了。

dockergitlab服务器挂了准确来说应该是今天升级了阿里云的ECS内存之后重启实例，结果发现所有跟docker相关的东西都坏掉了。docker启动不了，所有镜像都查不到。我们的gitlab是用的docker，所以必须要把这个给弄好。
查看docker相关的文件和镜像容器都在，所以猜测数据可能没受到损坏。具体修复过程分为以下几个阶段：
1、这是由于重启了服务器造成的，所以有可能再重启一次情况会回复，但是重启后结果还是不行。
2、启动docker 的时候执行service docker start指令，显示数据如下图：
docker start/running,process 。这条指令并没有说明docker已经运行，因为我查询所有进程的时候根本没有docker，具体原因可以百度下。
3、找大神帮忙，加入了几个docker群，其中在docker分享群2中几位大神纷纷出来指点。
其中一位说service 只是相当于一个快捷方式，这样启动不了就去docker下直接手动启动。可是我找了半天没找到在哪启动。第二位朋友说dockerd指令，这个是手动启动docker的，可是执行后还是不行，(/dockerd也失败)
提示信息里说可能没有安装docker。可是我重启服务器之前运行了将近半年都是OK的，但是我不排除重启后docker完全损坏，不被识别的可能。
使用uname -a查看内核版本，看看是不是不支持docker。按照他的解释是，他之前遇到过，重启服务器之后内核更新了，导致不支持docker所以这也是一种可能。
查看docker版本：
我这里是162的客户端，
linux内核313

确认了我的服务器内核是支持docker的，所以把这个可能排除。
其中杭州的以为朋友注意到，我上边的错误提示里有一句缺少dockersock文件。所以建议我在相应的目录下简历dockersock。上边提示信息的完整路径是/var/run/dockersock。
按照上边说的建立后，再执行出现以下信息：
这时候注意后边那条提示，shutting down，看到这之后大神给出一条指令sudo apt-get install apparmor，说执行完之后就没问题了。
执行完之后果断docker可以起来了

在top中查询：

消失已久的docker终于出来了，而且docker下以前建立的容器都还在，手动起一下就好。
感谢各位大神的帮助，我的docker又复活了。总之不熟悉这个的朋友最好还是慎用，或者有人指点也好，省的不知道出问题之后该找谁。

截止到22年04月01日为止

portainer 官网提供版本 293
>仓库（Repository）是集中存放镜像的地方，仓库分为公有仓库与私有仓库

一个容易混淆的概念是注册服务器（Registry）。实际上注册服务器是管理仓库的具体服务器，每个服务器上可以有多个仓库，而每个仓库下面有多个镜像。从这方面来说，仓库可以被认为是一个具体的项目或目录。例如对于仓库地址 ldockerpoolcom/ubuntu 来说，dldockerpoolcom是注册服务器地址，ubuntu是仓库名。

大部分时候，并不需要严格区分这两者的概念。

注册服务器、仓库、镜像关系如下

Docker Engine 是一个开源的容器技术，被用来对你的应用进行容器化构建。

Docker Engine 实际上是一个客户端服务器（client-server）应用：

一个在服务器上长期运行的被称为 dockerd 的进程。

一个指定结构的 APIs，这个 API 被用来与 Docker 守护进程进行通信。

一个命令行界面（CLI）客户端 docker 。

命令行界面（CLI）使用 Docker APIs 来控制和与 Docker 来互相作用。这个使用脚本或者 CLI 命令行来进行控制和执行。 其他 Docker 应用使用下层 API 和 CLI 来对 Docker 来进行控制。

Docker 守护进程创建和管理 Docker 的对象（objects）， 例如 镜像（images），容器（containers），网络（networks），卷（volumes）。

更多的信息和内容，请参考： Docker Architecture。

Docker 用户指南

希望了解更多 Docker 的信息和有关使用和实现的问题和回答，请参考 开始使用 页面中的内容。

安装指南

请参考 installation section 页面中的内容来针对不同平台的 Docker 安装指南。

发行日志

针对当前的版本的修改和历史版本的修改日志，请参考 发行日志页面 页面中的内容。

特性丢弃策略

Docker 容器随着版本的改变和新特性的添加可能随着性能的变化和添加而过期而被替代掉。在已经存在的特性被删除之前，这个特性将会在文档中标记为 “deprecated”。 这个标记将会在 Docker 中至少保持 3 个稳定的版本，除非被明确的表示将会被删除掉。

针对需要删除的特性列表，用户将会被建议先记录下来，并且针对一些被删除的特性，用户在进行版本合并的时候尽量先合并这些新的特性，并尽可能的先替换掉。

完整的需要删除的特性列表，请参考页面： >

Docker 是一个开源的 应用容器引擎 ，让 开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化 。容器是完全使用沙箱机制，相互之间不会有任何接口。

由于本地开发好的程序往往都需要部署到服务器上进行运行，这就导致了程序需要运行在不同的环境上，这通常是一个令人头痛的事情。在过去，开发团队需要清楚的告诉运维部署团队，其所使用的全部配置文件+所有软件环境。不过，即便如此，仍然常常发生部署失败的状况。

于是乎， 虚拟化 技术应运而生。开发团队将开发好的程序在虚拟机上运行，这样就能解决运维的问题。但是由于虚拟机技术过重的特性导致了其 资源占用多、冗余步骤多以及启动慢的缺陷 。而这个时候 一种新的虚拟化技术搭配上容器化的思想 的产品便出现了，而它就是Docker。

下图是虚拟机技术和容器化技术架构的对比。我们可以得出以下总结：

[上传失败(image-efadd2-1643314980201)]
]( >docker运行的java无法请求到别的服务器怎么办
这个其实应该非常少碰到，我碰到了算是巧合，因为默认的系统参数其实是不会出现这种情况的。
两种可能的原因会造成Docker容器内无法访问外部网络：
容器使用了桥接网络但防火墙屏蔽了通信
/etc/sysctlconf系统配置参数问题
我碰到的情况属于第二种，配置参数问题，修正方法：
编辑/etc/sysctlconf
将其中的netipv4ip_forward=0改成netipv4ip_forward=1。
重载配置，之后Docker的容器即可正常通信，如果不行，restart下容器。
sysctl -p

需要使用docker在后台运行一个nginx服务器需要docker容器部署方式。方法如下：
1、docker构建mysql环境+docker构建项目自身环境。
2、Vue项目：使用docker启动nginx服务器方式代理部署。
3、项目使用mysql80作为数据源，部署时需要使用docker构建mysql环境及项目自身环境。
4、连接出现1251错误时：将项目进行打包：“mumu-001-SNAPSHOTjar到此，springboot项目采用docker”方式运行部署结束。
5、使用docker容器方式运行nginx服务器即可。

---