/etc/systemd/system/docker.service.d/http-proxy.conf如何发挥作用的

/etc/systemd/system/docker.service.d/http-proxy.conf 文件通过 systemd 的 “drop-in” 文件功能发挥作用。这种机制允许你在不修改原始服务文件的情况下,添加或覆盖特定服务的配置。这里是这个文件的作用原理:

1. Systemd Drop-In Files

  • 目的: systemd 允许通过 “drop-in” 文件为现有服务添加或修改配置。这些文件位于特定目录中,可以包含部分服务配置。

  • 位置: 对于 Docker 服务,这些文件应该放在 /etc/systemd/system/docker.service.d/ 目录中。每个文件必须以 .conf 结尾。

2. 如何作用于 Docker:

  • 环境变量设置: 在 http-proxy.conf 文件中,你可以定义 Docker 启动时需要的环境变量,如 HTTP_PROXY, HTTPS_PROXY, 和 NO_PROXY。这些变量会影响 Docker daemon 的运行环境,使其通过指定的代理服务器进行网络通信。

    ini

    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:8080"
    Environment="HTTPS_PROXY=http://proxy.example.com:8080"
    Environment="NO_PROXY=localhost,127.0.0.1"
  • 配置合并: 当 systemd 启动或重载 Docker 服务时,它会读取 /etc/systemd/system/docker.service 文件(这是 Docker 服务的原始配置文件)以及 /etc/systemd/system/docker.service.d/ 目录下的所有 drop-in 文件。这些 drop-in 文件中的配置会叠加或覆盖原始配置文件中的同名选项。

  • 重载与重启: 配置文件更新后,需要使用 systemctl daemon-reload 命令来通知 systemd 重新加载所有配置文件,然后用 systemctl restart docker 重启 Docker 服务,使新配置生效。

3. 具体作用:

  • 代理设置: Docker daemon 在启动时会读取这些环境变量来确定如何进行网络请求。如果你在一个网络代理环境中工作,这些设置确保 Docker 可以通过代理服务器访问互联网上的 Docker 镜像仓库、API 等。

  • 灵活性与维护: 使用 drop-in 文件的好处在于,如果有多个用户或管理员需要对服务进行配置,他们可以各自添加自己的配置文件,而不需直接修改原始服务文件。这种方法简化了配置管理和维护。

  • 安全性: 需要注意的是,代理服务器的详细信息会以明文形式存储在配置文件中,可能存在安全风险。确保这些文件的权限设置正确,仅允许可信的用户访问。

通过这种方法,/etc/systemd/system/docker.service.d/http-proxy.conf 有效地为 Docker daemon 设置了需要的网络代理配置,确保 Docker 能在代理服务器环境下正常工作。

能否在daemon.json中添加代理

在 daemon.json 文件中不能直接添加用于网络代理的配置,如 HTTP_PROXY, HTTPS_PROXY, 或 NO_PROXY。根据 Docker 的官方文档,这些环境变量需要通过 systemd 的方式来配置,而不是在 daemon.json 中设置。

以下是为什么以及如何配置代理的说明:

为什么不能在 daemon.json 中配置代理:

  • Docker daemon 使用的是 systemd 环境中的环境变量来设置代理,而不是通过 daemon.json。因此,daemon.json 用于配置 Docker 的其他设置(如镜像仓库镜像、日志驱动等),但不适用于网络代理配置。

如何配置代理:

  1. 为 Docker Daemon 设置代理:

    • 首先,创建一个目录来存放 systemd 的配置文件:

      bash

      sudo mkdir -p /etc/systemd/system/docker.service.d
    • 然后,在该目录下创建一个以 .conf 结尾的文件,比如 http-proxy.conf:

      bash

      sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
    • 在这个文件中添加以下内容,根据你的代理服务器调整值:

      ini

      [Service]
      Environment="HTTP_PROXY=http://proxy.example.com:8080"
      Environment="HTTPS_PROXY=http://proxy.example.com:8080"
      Environment="NO_PROXY=localhost,127.0.0.1"
    • 完成后,重新加载 systemd 配置并重启 Docker 服务:

      bash

      sudo systemctl daemon-reload
      sudo systemctl restart docker
  2. 验证配置:

    • 你可以通过运行以下命令来检查 Docker 是否使用了你设置的代理:

      bash

      systemctl show --property=Environment docker

      你应该会看到你配置的 HTTP_PROXY, HTTPS_PROXY, 和 NO_PROXY 环境变量。

  3. 注意:

    • 如果你的代理需要认证,确保正确设置用户名和密码,但注意这会将认证信息暴露在配置文件中。

    • 同样的方法也适用于其他环境变量的配置,如 FTP_PROXY。

虽然 daemon.json 不能用于设置网络代理,但它仍然是一个重要的配置文件,用于调整 Docker daemon 的其他行为和设置。确保 daemon.json 文件的格式正确,因为任何格式错误都会导致 Docker 无法启动。

SQL SERVER 2019 数据库迁入 SQL SERVER 2008

最关键的两步

1、要用SQL Server的导入和导出向导

2、要在过程中设置数据源为SQL Server Native Client 10.0

sqlserver

经过验证,以上方法虽未在迁移过程中报错,但还是不能用。

虽然前台可以正常显示,但是后台始终报错,后来通过排除方法,将网站数据库配置为测试服务器上的数据库时可以正常登录后台,由此可以得出这种数据库迁移方案还是不可行的。

解决方法:

思路:因为测试服务器上的数据库是用网站服务器数据库的备份来还原的,所以绝大部分的表格结构都是相同的,无非就是多添加了几个表格或者某个表格多加了几列。在不能进行数据库迁移的情况下,可以先把数据从测试服务器中导入到网站服务器。而后通过在数据导入过程中的报错信息对数据库中的表进行修改,从而适应数据。所以接下来的步骤是:

1、在测试数据库服务器上,选择生成脚本,而且仅导出数据,框架中选择2008,

2、将脚本传到网站服务器,运行脚本。

3、查看报错信息,因为有一部分数据也是重复的,所以会有大量的报错,只能一点点看,在看到“找不到对象”时就应该是网站服务器中缺少相关的表格

4、根据脚本中的信息得到表名,在测试服务器上拿到创建表格的create脚本,复制到网站服务器上运行,从而生成了表格,再将此表的数据单独导入,

5、再次导入全部数据,观察报错信息,发现有两个列在whir_U_SinglePage表上缺少两个列fileTitle、fileSize,方便起见,直接查看测试服务器的表的设计,在网站服务器上手动添加两列。再次导入数据后正常。

6、测试网站后台的登录,后台可以正常进入。

在此以为是网站数据库算是可以了,但今天发现在某些栏目进行更新时报错,说是fileTitle、fileSize列无效,经过耐心的排查,需要在功能模型中的单页图文中将这两列删掉,再从单页图文中通过字段管理增加这两列,再对刚才报错的栏目进行更新时已正常。