标签归档：PHP

从 LAMP 到 Docker based PaaS 工具

从 LAMP 到 Docker based PaaS 工具

3条回复

在 白宦成简史 当中，我写到过，我从 2013 年就开始写博客，至今已经 11 年有余。而我和互联网、编程的缘分，也从 2013 年开始。

在 2013 年的时候，我主要是使用 WordPress 建站（现在也还在用，比如本站）。所以，从哪个时候开始，我开始接触 LAMP、LNMP 这些个概念，并在过去的若干年里，使用了不少「一键安装包」来部署我的网站。

我用的一键安装包 / 控制面板不算少：LNMP.org 、OneInStack（从它还是 LinuxEye 的时候开始用），LAMP.sh等一键配置包，AMH、WDCP、AppNode、Webmin、BT、VestaCP 、Virtualmin等等一系列控制面板。

如果说这些工具有什么相同点，那便是都提供了十分方便的 LAMP / LNMP 的配置方式，让彼时不够专业的我、主要是用别人开发好的应用的我能够快速部署一个基于 MySQL + PHP 的应用，让它 Run 起来。

而随着时间的流逝，我已经不再是曾经的我了。我不再局限于使用别人写好的程序，我开始自己写；我不再局限于使用 PHP 来编写程序，我同样会使用 Python、Ruby、Golang 、Node.js 来编写应用程序；所有的这些，都告诉我，我需要在现有的框架和程序上去做很多额外的配置，比如，我需要在 LNMP 的基础之上，配置 NPM，以完成 Node.js 的构建；我需要在系统上配置 Docker ，以便于去运行某些需要复杂配置的环境。

曾经那些可以帮到我的程序已经不再能帮到我了，如今的他们，成了我的累赘。我开始需要为了他们去多做一些事情了。

如今的我，更需要的是一个能够基于 Docker 来运行的管理工具，能够帮助我完成不同环境的配置、管理的能力。我需要的是一个类似于 Heroku 的管理工具，能够让我把更多的精力放在把事做好上。

我试用了

最终，选择了 CapRover ，主要原因有几个：

  1. 支持基础的 Docker 管理功能：这样意味着我其实可以在网页端管理这些资源。
  2. 使用 Nginx ，并集成了 Let’s Encrypt：我的应用都希望有 HTTPs 的能力，所以默认集成了 Let’s Encrypt 可以帮助我解决不少的问题。我也不需要自己去维护一个 Traefik 来解决请求转发的问题（我没有使用 Rancher / Kubesphere 之类的容器管理平台也是这个原因）
  3. 提供了一些一键配置的 Sample：这意味着我把一些我常用的应用迁移过去的时候，可以抄袭一下其官方推荐的配置，可以降低我的使用门槛。
  4. 足够久远：CapRover 作为一个从 2017 年就开始运作的工具，代表着有足够多的 issue 可以供我参考 / 使用，可以减少我踩坑的概率。
  5. 提供了 CLI 来进行部署：对于一个经常需要部署的人来说，提供 CLI / Github Action 可以帮助我快速实现多种不同需求下的部署，帮助我来提升效率。

种种的这些，让我最终从过去的 LNMP，跳船到了 Docker Base PaaS 工具上。

使用 Laravel Envoy 进行项目部署

使用 Laravel Envoy 进行项目部署

发表评论

在大型企业当中，往往会有各种各样的 CI & CD 工作流来完成项目的部署，而对于我自己的项目而言，我也希望能够有这样顺畅的交付体验，因此，我也为自己的业务加上了类似的方案，以实现顺滑的开发体验。

不过，我没有做的那么重，没有上 Ansible，也没有封装 Docker，就是标准的 LNMP 环境。只不过，我在标准的环境上加入了 Laravel Envoy — 一个快速部署工具。

什么是 Laravel Envoy

Envoy 是 Laravel 团队开发的一个在远程服务器上执行某些命令的工具，因为他同样使用 Blade 语法，因此在 Laravel 项目中接入非常方便。

如何使用 Laravel Envoy

1. 安装 Laravel Envoy

Envoy 有多种使用方式，一种是跟随项目的使用方式，即使用 composer require laravel/envoy --dev 来安装，并使用 php vendor/bin/envoy 的方式来运作，这样的好处是你无需污染顶级目录，只在项目层面使用 Envoy 来进行部署。

不过我因为有很多项目，所以我会更加倾向于直接在全局安装 envoy，执行 composer global requre laravel/envoy 实现在全局安装 Enovy。全局安装完成后，当你需要执行命令，只需要执行 envoy run deploy，就能执行当前目录下所定义的命令。

除了全局安装，你也可以考虑使用 Bash alias 来实现类似的效果，将 envoy alias 给 php vendor/bin/envoy 就可以实现即使没有全局安装，也可以实现不需要手动输入前缀的特性。

2. 初始化配置文件

当你需要配置时，你要做的很简单，只需要执行 envoy init 服务器地址/昵称就可以获得一个 Envoy.blade.php 文件，你可以通过修改这个文件的内容，来实现定义不同的工作。同样的，你可以将这个文件纳入到版本控制系统当中，从而实现部署脚本的跟踪和定义，对于后续的持续维护比较有帮助。

因为 Envoy.blade.php 也是采用了 Blade 的后缀，所以也同样适用了 Blade 引擎，你可以通过一个语意更加友好的方式来定义你的脚本。

@servers(['web' => '127.0.0.1'])

@task('deploy')
    cd /path/to/site
    git pull origin master
@endtask

比如，上面的脚本就是一个最基础的脚本，首先定义了这个脚本的命令会在名为 web 的服务器上执行，而这个服务器的地址是 127.0.0.1；并定义了一个任务 deploy。

3. 执行部署命令

当你完成代码的编写，并提交了 Git 之后。执行命令 envoy run deploy ，就会自动的在 web 这个服务器上执行在 deploy 当中执行的命令。

deploy 的命令只要是正常的 bash 命令即可。

高级用法

1. 引入其他任务

因为 Envoy 使用 Blade 语法来编写，你也可以使用 Blade 语法中的命令来引入其他文件的中的任务。因此，你可以将自己常用的命令定义出来，并将其通过 Packagist 发布出去，并在实际应用过程中，引入对应的文件来使用。

@import('vendor/package/Envoy.blade.php')

2. 处理多个服务器

Envoy 支持定义多个服务器以及并行执行，对于架构相对复杂的业务，你可以定义不同的 servers ，并在对应的 task 当中来设定需要在哪些 Server 上执行。定义任务时，如果你传入了 parallel 参数，则可以控制命令同时在多个服务器上并行（该属性为 false 时则是串行（

@servers(['web-1' => '192.168.1.1', 'web-2' => '192.168.1.2'])
 
@task('deploy', ['on' => ['web-1', 'web-2'], 'parallel' => true])
    cd /home/user/example.com
    git pull origin {{ $branch }}
    php artisan migrate --force
@endtask

3. 定义变量或引入其他功能函数

你可以在 Envoy.blade.php 中加入 @setup 来完成变量的定义，并在后续的代码中使用。

@setup
    $now = new DateTime;
@endsetup

也可以直接使用 @include 来引入文件

@include('vendor/autoload.php')
 
@task('restart-queues')
    # ...
@endtask

4. 使用命令行参数

在启动时，如果你使用诸如 --param=value这样的参数来调用，则可以在你的代码中直接读取对应的变量，从而实现执行时带入不同的参数。

更多用法

Envoy 当中还有更多的用法，这里不再一一列举，如果你感兴趣，可以直接参考其官方文档，了解如何使用 Envoy 达成你的部署目标。

总结

在你不是很着急使用 Ansible 或 更重的部署工具的时候， Envoy 是一个不错的选择。特别是你使用 Laravel 进行开发时，Envoy 就是一个有效的工具。

Livewire.js 404 的问题的处理思路和解决方式

Livewire.js 404 的问题的处理思路和解决方式

发表评论

在使用 Laravel Livewire 的时候一个常见问题是生成的 Livewire.js 文件会报错。

一般来说，解决思路有两种

  1. 看看你生成的 URL 是否是正确的。
  2. 看看你的 Nginx 配置是否是正确的。

生成的 URL 是否正常

在 Livewire 的配置当中，存在一个 asset_url 选项，这个选项会用于在页面中嵌入 Livewire.js 文件的功能，因此。如果你在使用过程中，修改了这个值，导致生成的地址是错误的，就有可能报错。

Nginx 配置是否正确

这个问题往往会导致报错的页面是 Nginx 的 404 页面。

在你的 Nginx 配置当中，如果你针对 JS 文件或 CSS 文件有单独处理，你需要将对应的处理注释掉，确保所有请求转发给 Laravel 进行处理。

 # location ~ .*\.(js|css)?$ {
 #   expires 7d;
 #   access_log off;
 # }
Laravel 9 单元测试报错 An email must have a “From” or a “Sender” header

Laravel 9 单元测试报错 An email must have a “From” or a “Sender” header

发表评论

在 Laravel 9 当中，引入了新的 Mailer 组件，随之而来的是一些过去没有的 Bug。

如果你在开发过程中出现了 An email must have a "From" or a "Sender" header 的报错，需要在 PHPUnit 当中配置 MAIL_FROM_ADDRESS 属性，用于通过测试。

<env name="MAIL_FROM_ADDRESS" value="from@example.com" />

来源：https://laracasts.com/discuss/channels/laravel/for-reference-an-email-must-have-a-from-or-a-sender-header

2021 年还在写 PHP 的人

2021 年还在写 PHP 的人

2条回复

PHP 是世界上最好的语言

这是技术圈的一个梗。只要你希望一个社区吵起来，只要抛出 XX 是最好的语言，就可以吵起来。而在这个鄙视链里，最底层的就是 PHP。

为什么会是 PHP？

应运而生的 PHP

PHP 其实是一门非常辉煌的语言，关于他有多辉煌。从 WordPress 的荣耀就可以看出来。 WordPress 这样一个被广泛应用的 CMS 系统便是 PHP 写就的。就连这个博客，也同样是基于 PHP 写成的。

在 PHP 盛行的时代，我们看到了大量的个人站长出现，他们使用一些开源 or 免费提供的 PHP 项目，开发出了一个个网站。我们所熟悉的 Discuz、WordPress、Drupal 、PHPBB等一系列 CMS，都是使用 PHP 开发者的。

这些 PHP 应用程序的诞生，使得 PHP 得以长盛不衰。可以说，只要 WordPress、Discuz、Drupal、PHPBB 这一类程序还在持续迭代，PHP 本身就不会消逝。

Web 友好的 PHP

PHP 之所以被众多开源项目选择，得益于其语言设计。

在其官网的标题中，明确指出，“PHP 是一个 Hypertext Preprocessor”。

更是在官网的显著位置，标注了如下的内容。

PHP is a popular general-purpose scripting language that is especially suited to web development.

Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.

来源: php.net 

PHP  从设计之初，便是一门用于 Web 研发的编程语言，在 Web 2.0 时代，Web 网站大爆发的时代，PHP 自然也因此而大红大火。

PHP 作为一个面向模板输出的语言，在过去的二十多年里，造就了大量的 Web 应用。

LAMP 的助攻

PHP 能流行开来，和他的易于部署也不无关系。LAMP（Linux + Apache + MySQL + PHP）的流行，使得 PHP 的部署十分的简单，一个不太懂 Linux 的人，也可以参考一些简单的教程或使用一些现成的脚本，完成项目的部署。

而更进一步催生 PHP 发扬光大的，则是 cPanel、DirectAdmin、Plesk 等一系列虚拟主机管理系统，他们将 PHP 的易用性进一步提升。用户无需管理服务器，就可以直接部署 PHP 程序，让更多的人开始使用 PHP 所编写的程序。

培训班的热潮

PHP 被广泛应用，自然也被培训班看到，随之而来的，是培训班的介入，大量的非计算机专业的人涌入，通过 PHP，开始了他们的编程之旅。

一方面，客观的增加了 PHP 的开发者，使得 PHP 的市场份额进一步扩大。

另一方面，也降低了整体水平，使得 PHP 的开发者有一部分人真的就只是搬砖。

培训班的涌入所带来的后果，就是其他语言开始鄙视 PHP，觉得 PHP 是一门垃圾语言。然鹅，没有垃圾语言，只有垃圾的用语言的人。

为什么不是 PHP

上述的众多原因，让 PHP 成为一个时代的潮流，也成为鄙视链的底层。

但真正意义上让 PHP 失去生命活力的，是单页应用、MEAN Stack 和云原生的到来。

单页应用

单页应用的到来，使得 PHP 这种以服务端渲染为主流的应用开始慢慢从人们的视野中消失。

大家开始习惯了前后端分离，由前端在浏览器层面进行渲染。

PHP 自带的模板系统就失去了其先天的优势。

MEAN Stack

MEAN（MongoDB、Express、Angular、Node.js）这种架构，彻底让人们看到了 Node.js 的可能性。

前后端统一语言的诱惑自然很难让人拒绝，大家开始选择使用 Node.js 来构建服务端。或使用 Node.js 来完成 BFF 层，这让 PHP 进一步失去其价值。

云原生

云原生的出现，让 Golang 彻底成为一门热门语言，大家开始发现 Golang 这门语言的优势。

相比于 PHP，golang 同样容易上手。此外，作为一门编译型语言，与脚本语言的 PHP 有着无法比拟的性能优势。

Golang，成为培训班的新宠。

为什么 2021 年，还在用 PHP？

我可以同时写 JS、Golang、PHP，所以对于我来说，其实语言并不是问题。

但为什么还是选择 PHP 呢？

原因很明确

  1. 我还在用 WordPress：在 WP 没有完全被替代之前，我大概率会保留一定的 PHP 维护技能（毕竟挂了要自己修）
  2. 生态还算活跃，历史的 package 能用：我一直不是很喜欢 Rails 的原因就是他的生态并不算完善（我是指和中文相关的），这意味着我们做同样的事，需要花费更多的精力。同样，这也是我为什么喜欢 Node.js 的原因。
  3. 方便快捷：PHP 生态发展的足够久，拥有大量各种不同类型的脚手架，你可以快速完成一个项目的开发，这个目前在 Node 和 Golang 之中，还是有一定差距的。

总体来说，我还会继续使用 PHP 的原因很简单，它可以帮助我快速落地项目，让我的想法变为现实。

《良质！PHP企业级系统开发》书摘

发表评论

尽我们最大的努力，开发并交付价值最大化的软件

首先，应该交付。完成交付以后，再考虑代码质量。

完成，完整，完善，完美

开发的顺序，一开始先完成，再完整，再完善，最后是完美。搞错了，就再也搞不出来了。

致力于编写容易理解的代码，专注于软件开发领域，努力创造更大的价值。

创造价值是核心，代码质量不一定是。

做事情，不要急，但要快！

快！=急

选择高起点，并始终以高标准严格要求自己

严于律己，宽以待人。

对于随时发布，我个人觉得是过于随意，缺少严谨性，所以我是不推荐的。由随时发布而产生的间接负面影响，要远大于它的直接正面收获。看似非常快速的发布方式，实际上却让我们不停在原地打转。所以，我不推荐初学者一开始就钟情并习惯于这种发布方式，更不推荐高级资深开发同学固守这种发布方式。如果你当前已经是随时发布，请不要妥协。

随时发布容易成为救火队员。