Unix Socket - 什么是socket(套接字)？

        套接字允许在相同或不同机器上的两个不同进程之间进行通信。更准确地说，它是一种使用标准Unix文件描述符与其他计算机通信的方法。在Unix中，每个I/O *** 作都是通过写入或读取文件描述符来完成的。文件描述符只是一个与打开的文件相关联的整数，它可以是一个网络连接、一个文本文件、一个终端或其他东西。

        对于程序员来说，套接字的外观和行为很像底层的文件描述符。这是因为read()和write()等命令使用套接字的方式与使用文件和管道的方式相同。

        socket最初是在2.1BSD中引入的，随后在4.2BSD中被细化为当前的形式。目前大多数UNIX系统版本都提供了套接字特性。

        在CS应用程序框架中使用Unix套接字。服务是一个根据客户端的请求执行某些功能的进程。大多数应用程序级协议，如FTP、SMTP和POP3，都利用套接字在客户机和服务器之间建立连接，然后进行数据交换。

        有四种类型的套接字可供用户使用。前两种纤樱是最常用的，后两种很少使用。

        假定进程只在相同类型的套接字之间通信，但没有限制阻止不同类型的套接字之间通信。

         流套接字 ——保证在网络环境中交付。如果您通过流轮宏套接字发送三个项目“A, B, C”，它们将以相同的顺序到达-“A, B, C”。这些套接字使用TCP(传输控制协议)进行数据传输。如果无法投递，发送者将收到一个错误指示符。数据记录没有任何边界。

         数据包套接字 ——不能保证在网络环境中交付。它们是无连接的，因为你不需要像在流套接字中那样有一个打开的连接——你建立一个带有目标信息的包并将它发送出去。它们使用UDP(用户数据包协议)。

         原始套接字 ——这些为用户提供对底层通信协议的访问，这些协议支持套接字抽象。这些套接字通常是面向数据包的，尽管它们的确切特征取决于协议提供的接口。原始套接字不是为一般用户设计的它们主要是为那些有兴趣开发新通信协议或访问现有协议中一些更神秘的设施的人提供的。

         顺序包套接字 ——它们类似于流套接字，不同的是记录边界被保留。该接口仅作为网络系统(NS)套接字抽象的毁桐丛一部分提供，并且在大多数严肃的NS应用程序中非常重要。顺序包套接字允许用户对一个包或一组包 *** 纵序列(SPP)或网络数据包协议数据报协议(IDP)的报头,通过编写一个标准头，连同任何要发送的数据,或者通过指定一个默认的报头使用所有即将输出的数据,并允许用户接收传入的数据包的报头。

uwsgi监听的socket，可以为socket文件或ip地址+端口号

socket = /www/wwwroot/web/script/uwsgi.sock

socket = :8080

用nginx的时候就配socket , 直接运行的时候配 http

指定IP端口 // 直接外部访问

http-socket = 127.0.0.1:8080

指定项目的目录，在app加载前切换到当前目录

指定项目的application，加载指定的python WSGI模块（模块路径必须在PYTHONPATH里）

相当于master=true，启动一个master进程来管理其他进程，以上述配置为例，其中的4个uwsgi进程都是这高源手个master进程的子进程，如果kill这个master进程，相当于重启所有的uwsgi进程

开启的进程数量（和worker作用相同）

uid = www

gid = www

进程个数

processes = 5

pidfile = /www/wwwroot/web/script/uwsgi.pid

自动移除unix Socket 和 Pid 文件 当服务停止的时候

vacuum = true

序列化接受的内容，如果可能的话

thunder-lock = true

启用线程

enable-threads = true

设置缓冲

post-buffering = 4096

设置静态文件

static-map = /static=//www/wwwroot/mysite/static

使进程在后台运行，并将日志打到指定的日志文件或者udp服务器（不会影响nginx日志的输出）

daemonize = /www/wwwroot/mysite/uwsgi.log

给PYTHONPATH 增加一个目录（或者一个egg），最多可以使用该选项64次。

在失去权限前，将master的pid写到当前文件中

设置默认的通信协议（uwsgi，http，fastcgi）

这个选项会设置harakiri超时时间（可以看wiki首页的相关内容）。如果一个请求花费的时间超过了这个harakiri超时时间戚嫌，那么这个请求都会被丢弃，并且当前处理这个请求的工作进程会被回收再利用（即重启）。

设置用于uwsgi包解析的内部缓存区大小。默认是4k。

如果你打算接受一个拥有很多请求头的大请求，你可以增加这个值到64k。

这个命令会允许uWSGI服务器接收最大为32k的uwsgi包，再大的包就会被拒绝。

unix socket是个文件，所以会受到unix系统的权限限制。如果你的uwsgi客户端没有权限访问uWSGI socket，你可以用这个选项设置unix socket的权限。

当在xml配裂敏置文件中只是用这个选项作为一个标识符，那么会将权限设为666，否则就是设置为指定的权限值。

chmod-socket = 755

这个选项将自动给uWSGI的进程设置一些有意义的名字，例如“uWSGI master”， “uWSGI worker 1”， “uWSGI worker 2”。

为所有的socket *** 作设置内部超时时间（默认4秒）。

这个配置会结束那些处于不活动状态超过10秒的连接。

Docker 容器技术目前是微服务/持续集成/持续交付领域的第一选择。而在 DevOps 中，我们需要将各种后端/前端的测试/构建环境打包成 Docker 镜像，然后在需要的时候，Jenkins 会使用这些镜像启动容器以执行 Jenkins 任务。

为了方便维护，我们的 CI 系统如 Jenkins，也会使用 Docker 方式部署。

Jenkins 任务中有些任务需要将微服务构建成 Docker 镜像，然后推送到 Harbor 私有仓库中。

或者我们所有的 Jenkins Master 镜像和 Jenkins Slave 镜像本身都不包含任何额外的构建环境，执行任务时都需要启动包含对应环境的镜像来执行任务。

我们的 Jenkins Master、Jenkins Slaves 都是跑在容器里面的， 该如何在这些容器里面调用 docker run 命令启动包含 CI 环境的镜像呢？

在这些 CI 镜像里面，我们从源码编译完成后，又如何通过 docker build 将编译结果打包成 Docker 镜像，然后推送到内网仓库呢？

答案下面揭晓。

Docker 采取的是 Client/Server 架构，我们常用的 docker xxx 命令工具，只是 docker 的 client，我们通过该命令行执行命令时，实际上是在通过 client 与 docker engine 通信。

我们通过 apt/yum 安装 docker-ce 时，会自动生成一个 systemd 的 service，所以安装完成后，需要通凯渗过 sudo systemctl enable docker.service 来启用该服务。

这个 Docker 服务启动的，就是 docker engine，查看 /usr/lib/systemd/system/docker.service ，能看到有这样一条语句：

默认情况下，Docker守护进程会生成一个 socket（ /var/run/docker.sock ）文件来进行本地进程通信，因此只能在本地使用 docker 客户端或者使用 Docker API 进行 *** 作。

sock 文件是 UNIX 域套接字，它可以通过文件系统（而非网络地址）进行寻址和访问。

因此只要以数据卷的形式将 docker 客户端和上述 socket 套接字挂载到容器内部，就能实现 "Docker in Docker"，在容器内使用 docker 命令了。具体的命令见后面的「示例」部分。

要记住的是，真正执行我们的 docker 命令的是 docker engine，而这个 engine 跑在宿主机上。所以这并不是真正的 "Docker in Docker".

运行过Docker Hub的Docker镜像的话，会发现其中一些容器时需要挂载/var/run/docker.sock文件。这个文件是什么呢？为什么有些容器需要使用它？简单地说，它是Docker守护进程(Docker daemon)默认监听的Unix域套接字(Unix domain socket)，容器中的进程可以通过它与Docker守护进程进行通信。

在容器内部使用宿主机的 docker，方法有二：

容器的启动方式也有两种，如下：

示例命令如下：

必须以 root 用户启动！（或者其他有权限读写 /var/run/docker.sock 的用户） 然后，在容器内就能正常使用 docker 命令，或者访问宿主机的 docker api 了。

docker-compose.yml 文件内容如下：

然后通过 docker-compose up -d 即可后台启动容器。

通过上面的 *** 作，我们在槐宴容器内执行 docker ps 时，还是很可能会遇到一个问题： 权限问题 。

如果你容器的默认用户是 root，那么你不会遇到这个问题，因为 /var/run/docker.sock 的 onwer 就是 root.

但是一般来说，为了铅孙银限制用户的权限，容器的默认用户一般都是 uid 和 gid 都是 1000 的普通用户。这样我们就没有权限访问 /var/run/docker.sock 了。

解决办法：

方法一（不一定有效）：在构建镜像时，最后一层添加如下内容：

方法二：经测试一定有效，在Dockerfile中使用USER参数

这样我们构建的镜像就是root用户了，经测试在docker-compose.yaml文件中user参数并不好用,类似如下

这样我们的默认用户，就能使用 docker 命令了。

参考

---