如何部署Symfony程序
部署Symfony可能是一个复杂和多样的任务,取决于你的程序的设置和需求。本文并非手把手的指南,而是罗列了部署时的常见需求和建议。
Symfony部署基础 ¶
发生在部署Symfony时的典型步骤包括:
- 把你的代码上传到产品服务器;
- 安装三方依赖 (通常透过Composer完成,并且可以在上传程序之前完成);
- 运行数据库迁移(migration)或类似任务,以更新“已改变的”数据结构;
- 清除 (可选地,预热[warming up]) 你的缓存。
部署过程还包括其他任务,诸如:
- 对代码的某个特定版本打上标签,作为你的版本宝库中的一个发布;
- 创建一个临时区域,以构建你的 "offline" 离线已更新设置;
- 运行任意可用测试,以确保代码和/或服务器的稳定性;
- 从
web/
目录删除任何不必要的文件以保持生产环境干净; - 清除外部缓存系统 (像是 memcached 或 Redis)。
如何部署Symfony程序 ¶
部署Symfony程序时有几种方式。始于一些基本的部署策略,然后从那里开始。
基本文件传输 ¶
部署一套程序最基本的方式是通过FTP/scp(或类似方法)手动拷贝文件。其欠点是,比如在升级过程中,你缺少对系统的控制。这种方法也需要你在文传输之后执行一些手动步骤(参考 常见的后部署任务)。
使用版本控制 ¶
如果你使用了版本控制(比如git或SVN),你可以直接把现场安装(live installation)做成你repository的一个拷贝。当你已经准备好升级时,简单到如同从版本控制系统中取出最新的更新一样。
这令你的文件更新变得 更容易,但你仍然需要考虑手动执行其他步骤(参考 常见的后部署任务)。
使用平台服务 ¶
鲜少使用 有相关需求的用户,请参考Symfony官网原文。另,现代云平台,比如微软Azure,都可以一步支持Symfony3+。
不同的服务供应商之间,特殊的部署步骤十分多样化,因此从以下独立文章中查找你所选择的服务:
- Deploying to Microsoft Azure Website Cloud
- Deploying to fortrabbit
- Deploying to Heroku Cloud
- Deploying to Platform.sh
使用构建脚本和其他工具 ¶
有几种工具可以帮助减轻部署时的痛苦。其中的一些几乎是为Symfony的需求而量身定制的:
- Capistrano 配合 Symfony plugin
- Capistrano 是一个Ruby写就的远程服务器的自动化和部署工具。Symfony plugin 是一个简化Symfony关联任务的插件,灵感来自 Capifony (它仅能和Capistrano 2一起工作)
- sf2debpkg
- 帮你为Symfony项目构建一个原生的Debian包。
- Magallanes
- 这个“类Capistrano”部署工具由PHP构建,对PHP开发者来说可以较容易地扩展其需求。
- Fabric
- 这个基于Python的类库提供了一个用来“执行本地或远程命令行以及上传下载文件”的基础套件。
- Deployer
- 这是又一个由原生PHP重写的Capistrano,有一些专门提供给Symfony的功能。
- Bundles
- 有一些 添加了部署功能的bundles 可以直接在你的Symfony控制台中使用。
- 基础脚本
- 你当然可以使用命令行, Ant 或其他任何构建工具,来脚本化部署你的项目。
常见的后部署任务 ¶
在部署了你的真正源代码之后,有一些常见事项需要你来做:
A) 需求检查 ¶
运行以下命令以检查服务器是否满足需求:
1 |
$ php bin/symfony_requirements |
B) 配置app/config/parameters.yml文件 ¶
此文件 不应 被部署,而是被Symfony提供的一个自动工具来管理。
C) 安装/更新vendors ¶
你的vendors(三方包儿)可以在上传源代码之前进行更新(比如更新 vendor/
目录,然后再传源代码)或是到服务器上完成更新。不管哪种方式,只需像往常一样来更新vendors:
1 |
$ composer install --no-dev --optimize-autoloader |
通过构建一个 "class map" 类映射,--optimize-autoloader
旗标大幅改进了Composer的自动加载性能。--no-dev
旗标可确保开发环境的包不被安装到生产环境。
如果在这一步你得到 "class not found" 错误,你可能需要在执行前述命令之前先运行 export SYMFONY_ENV=prod
以便 post-install-cmd
脚本运行在 prod
环境下。
D) 清除Symfony缓存 ¶
确保清除(以及warm-up)了你的Symfony缓存。
1 |
$ php bin/console cache:clear --env=prod --no-debug |
E) 剥离Assetic资源 ¶
如果你使用了Assetic,你需要剥离出assets:
1 |
$ php bin/console assetic:dump --env=prod --no-debug |
F) 其他内容! ¶
- 运行数据库迁移
- 清除APC缓存
- 运行
assets:install
(已经在composer install
过程中被打点好了) - 添加/编辑 CRON 任务
- 发布assets资源到CDN
- ...
程序生命周期:持续整合,质量保证等 ¶
虽然本文覆盖了部署过程的技术细节,但是代码从开发到生产时的完整生命周期可能需要更多步骤(考虑staging部署,QA[Quality Assurance/质量保证],运行测试,等等)
staging、测试、QA、持续整合(continuous integration),数据库迁移以及失败时的向下兼容,统统被强烈建议。有各种简单或复杂的工具,其中的某一款会令你的部署在满足环境需求的过程变得容易(或老练)。
别忘了在部署过程中也牵扯到更新依赖(一般通过Composer),迁移数据库,清除缓存以及其他潜在事项,诸如将资源发布到CDN(参考 常见的后部署任务)。