Posts

Laravel 是 PHP 里非常重要的一个框架，对于一个 PHPer 来讲，就算你没有用过 Laravel 也一定听说过它。 同事用 Laravel 开发了一个项目，需要部署一个测试环境，由于服务器的 PHP 环境不满足他项目的要求，所以需要多加一个 PHP 环境。 为了减少对原有系统的影响和更快的安装，我们决定用 Docker 来部署新项目的 PHP 环境。 本以为整个流程会无比的丝滑，但是在推进的过程中遇到了一些问题，也就有了这篇文章记录一下当时的经历，同时也为后续遇到类似问题的同仁提供解决思路。 整个部署方案如下： Dockerfile 很快就编写好了，本地测试能够成功的构建出 Docker Image。到此一切都很顺利，后续只需要把 Dockerfile 上传到服务器在服务器上把镜像构建出来，用 Nginx 解析一下就大功告成了。 当把代码上传到服务器，开始构建 Docker Image 时，问题出现了。在执行 apt update 的时候出现了下面的错误。 The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131 本地构建好好的，怎么上线就出现问题了呢？简单的用搜索引擎搜索了一下，找了几篇带有"亲测"字样的文章进行验证，却都失败了。 后来我想既然这样问问 GPT 吧，看看它有没有什么高见。GPT 告诉我时因为服务器证书问题导致的，这里我就产生了一个疑问，我构建 Dcoker Image 执行 apt update 应该是在 Docker 环境里执行的呀，为什么会跟服务器证书有关系呢？ 于是我继续追问，它给出了自己的解释，让我开始质疑自己了。 ...

在实际的项目部署中，我们有时候会遇到在一个服务器上部署多个 php 环境的情况。遇到这种情况，我们可以在同一物理机上装多个 php-fpm 监听不同端口，Nginx 根据不同的 Vhost 去找不同的 php-fpm 解析。 上述方法虽然可以，但是在项目管理上并不是很友好，比如我需要在某个项目执行 PHP 脚本，那还需要写 /path/php script.php 这样的话就需要每个维护项目的人都十分清楚，哪个项目应该用哪个版本的 PHP 去执行相应的脚本。 其次，如果某天需要把某个项目迁移到其他服务器了，我们还需要在新机器上安装 PHP 环境。 如果用 docker 进行部署，就不会有上面的问题，我们只需要写一次 Dockfile 可以在任何服务器上构建出相同的 php-fpm 环境，从而让迁移更简单，如果需要执行脚本，只需要进入对应的容器，直接执行 php script.php 即可。 php-fpm 官方镜像介绍 在 [php Tags | Docker Hub](https://hub.docker.com/_/php/tags 找到你所需的基础镜像的 tag 扩展安装 Docker PHP 安装有三种方式 Core Extensions： FROM php:8.2-fpm RUN apt-get update && apt-get install -y \ libfreetype-dev \ libjpeg62-turbo-dev \ libpng-dev \ && docker-php-ext-configure gd --with-freetype --with-jpeg \ && docker-php-ext-install -j$(nproc) gd PECL extensions : ...

Dockerfile 是用于构建镜像的脚本文件。在某些情况下，需要在基础镜像上加装一些软件，就需要使用 Dockerfile 来构建出自己所需的镜像。 指令介绍 指定基础镜像 ( FROM ) # 不指定版本则默认拉去 latest FROM nginx # 指定版本 FROM nginx:1.25.3 执行命令 ( RUN ) FROM nginx Run apt-get update \ && apt-get install -y --no-install-recommends git vim libpng-dev libjpeg-dev libfreetype6-dev 声明容器运行时监听的端口号（ EXPOSE ） FROM nginx Run apt-get update \ && apt-get install -y --no-install-recommends git vim libpng-dev libjpeg-dev libfreetype6-dev EXPOSE 80 设置工作目录 ( WORKDIR ) FROM nginx Run apt-get update \ && apt-get install -y --no-install-recommends git vim libpng-dev libjpeg-dev libfreetype6-dev EXPOSE 80 WORKDIR /var/www 复制文件到容器目录 ( COPY ) FROM nginx Run apt-get update \ && apt-get install -y --no-install-recommends git vim libpng-dev libjpeg-dev libfreetype6-dev WORKDIR /www COPY . /www EXPOSE 80 入口点 ( ENTRYPOINT ) ENTRYPOINT 和 CMD 两个指令十分相似，都是通过指定容器运行的脚本/命令。具体区别可以查看扩展阅读。 ...

Docker 可以理解为一个轻量级虚拟机，你可以在一台物理机上，装 N 个系统，每个系统部署不同的服务。 Docker 有几个非常重要的概念：镜像、仓库、容器。 镜像：可以理解为操作系统的系统盘，用于给容器安装系统用的，你也可以基于别人的镜像创建自己的镜像。 仓库：用于存储镜像的仓库 容器：相当于虚拟出来的一台台主机，他有存储、网络、系统等关键要素。你可以在容器里部署任何你想要部署的服务。 镜像操作 你可以创建 ( docker build )、删除 ( docker rmi )、下载 ( docker pull ) 镜像 设置镜像源 Docker 官方镜像仓库，在国内下载比较慢，可以通过国内的镜像源来加速镜像下载。本文介绍 Windows 通过 Docker Desktop 换源，如果你是其他系统，可以自行搜索。 复制下面信息到 Docker Desktop 设置 "registry-mirrors": [ "https://hub-mirror.c.163.com", "https://mirror.baidubce.com" ] 创建镜像 ( docker build ) 前提是要有构建镜像所需的 Dockerfile，关于 Dockerfile 后面会有专门的文章进行讲解。 docker build -t image_name . 下载镜像 ( docker pull ) 这里就会通过仓库下载镜像到本机。 docker pull ubuntu 删除镜像 ( docker rmi ) docker rmi image_name 容器操作 容器操作分为：启动（ docker run ），停止 ( docker stop )，删除 ( docker del )，执行 ( exec )、查看日志（docker logs）。 ...

开闭原则-对扩展开放，对修改关闭。 开闭原则要求在扩展新功能时应当避免对旧代码的改动。但现实的开发中，新增功能多数情况下都要涉及到旧代码的改动，这主要是因为在业务刚开始推进的时候并不能很清晰的看出业务的拓展方向，因此通常情况下都不会进行预留扩展的设计（避免过度设计）。 当扩展需求出现时，就是开始重构原有代码的时机，而开闭原则就是指导重构的主要思想，在重构过程中，应将此次扩展的业务方向做一个通用方案的处理，保证下次再出现同类型的扩展可以做到不改动或少改动旧代码。 依据开闭原则做架构设计时，我们应该清楚要保护什么，可以通过分层来决定保护级别，最高层的保护级别最高，最低层的保护级别最低。低层级的改动不会影响高层。 层级的划分可以根据业务来划分，核心业务逻辑应该是最高等级，其他层级根据与核心业务的关联程度依次向下划分等级。这样的划分逻辑我们能够保证核心业务规则不会因为其他相关模块的改动而受影响。 接下来通过《架构整洁之道》(clean architecture) 中的一张图来解释一下分层设计 图 8.2 < I > 表示接口，< DS > (data struct) 表示数据类，数据类的特性是第一次访问的时候会创建类，后续则是对该实体的读操作（实体类特性也是如此）。空心箭头表示对应接口的实现，实心箭头表示依赖关系， A->B 则是 A 依赖 B，A 知道 B 的存在，B 对 A 一无所知。 正是由于依赖的这种特性，我们可以把被保护的代码，写到被依赖的类中，这样被依赖的类不会以为依赖方代码的改动而受影响。 上图中：Interactor > (database) > Controller > Presenter 关于图 8.2 调用链路如下： 这种设计 Controller、Presenter、Database 任何模块代码的改动，都不会影响 Interactor ，从而达到了对 Interactor 代码的保护，如果某天对 Presenter 中的 PDF View 进行改动出现了 bug，仅仅印象 PDF View 这一个功能，把 bug 进行最大程度的隔离，实现功能的稳定。 总结 开闭原则保证了程序的扩展性，同时用分层的思想设计架构，通过依赖保护核心业务逻辑，避免核心逻辑的频繁改动，隔离低层代码的改动影响高层。 如果你对架构设局同样感兴趣，推荐给你一本书《架构整洁之道》(clean architecture) 。这本书对架构设计的讲解十分深刻，相信你也一定会有所收获。