我从来没想过部署一个带React前端的Laravel REST API会这么难。开发本身并不是难点。我的Laravel词汇量还有提升空间,但这只有在我拿到用这套技术栈的项目或工作时才真正重要。真正让一切崩坏的,是部署这一环。
出了什么问题
简单说:迁移、填充器和权限错误吃掉了我两个小时的人生。
我在自己的homelab上跑着一个共享的PostgreSQL实例(Redis也是),这样就不用为每个项目单独起资源。这意味着对这个应用来说,我得手动创建一个新数据库,并修改表的所有权,后端的.env才能真正连接上并顺利跑迁移。它能用,但谈不上优雅。
回过头看,我大概应该写一个像样的.sh脚本来处理数据库和用户的搭建,而不是手动操作。这次已经来不及了,但这条经验会进我的工具箱,留着下次用。
Faker的坑
另一个吃掉大量时间的地方:我在填充器里用了Faker,但它被放在require-dev里,而不是require。这意味着每次我在生产环境里尝试跑填充器都会失败。经过两次重新构建,我才发现这个问题,并把它挪到正确的位置。
总结
- 共享的Postgres和Redis实例能省资源,但会多出一个手动搭建步骤(建数据库、改所有权),这一步很容易一直忘到部署当天才想起来。
- 一个可复用的
.sh脚本,用来配置新的数据库和用户,本可以省下那两个小时里的相当一部分。 - 要仔细核查哪些依赖真的需要发布到生产环境。Faker,以及其他只用于填充或测试的东西,只有在你的生产流程永远用不到它们的情况下,才应该放在
require-dev里。如果会用到,就把它挪上去。
部署当天总能揪出那些开发当天被放过的漏洞。这一次只是揪出的比平时多一些而已。