跳到内容

如何部署 Symfony 应用

编辑此页

部署 Symfony 应用可能是一项复杂且多样的任务,具体取决于您应用的设置和需求。本文不是一个逐步指南,而是一个关于最常见的部署需求和想法的通用列表。

Symfony 部署基础

部署 Symfony 应用时通常采取的步骤包括

  1. 将您的代码上传到生产服务器;
  2. 安装您的供应商依赖项(通常通过 Composer 完成,并且可以在上传之前完成);
  3. 运行数据库迁移或类似任务以更新任何已更改的数据结构;
  4. 清除(以及可选地,预热)您的缓存。

部署也可能包括其他任务,例如

  • 在您的源代码控制仓库中将特定版本的代码标记为发布版本;
  • 创建一个临时暂存区以“离线”构建您更新的设置;
  • 运行任何可用的测试以确保代码和/或服务器稳定性;
  • public/ 目录中删除任何不必要的文件,以保持您的生产环境清洁;
  • 清除外部缓存系统(如 MemcachedRedis)。

如何部署 Symfony 应用

您可以通过多种方式部署 Symfony 应用。从一些基本的部署策略开始,并在此基础上逐步构建。

基本文件传输

部署应用最基本的方法是通过 FTP/SCP(或类似方法)手动复制文件。这种方法有其缺点,因为您在升级过程中缺乏对系统的控制。此方法还需要您在传输文件后采取一些手动步骤(请参阅 常用部署任务)。

使用源代码控制

如果您使用源代码控制(例如 Git 或 SVN),您可以通过使您的在线安装也成为您仓库的副本进行简化。当您准备升级时,从您的源代码控制系统获取最新的更新。当使用 Git 时,一种常见的方法是为每个发布版本创建一个标签,并在部署时检出相应的标签(请参阅 Git 标签)。

这使得更新您的文件更容易,但您仍然需要担心手动执行其他步骤(请参阅 常用部署任务)。

使用平台即服务 (PaaS)

使用平台即服务 (PaaS) 可能是快速部署 Symfony 应用的好方法。有很多 PaaS,但我们推荐 Platform.sh,因为它提供了专门的 Symfony 集成并有助于资助 Symfony 开发。

使用构建脚本和其他工具

还有一些工具可以帮助减轻部署的痛苦。其中一些工具是专门为 Symfony 的需求量身定制的。

Deployer
这是 Capistrano 的另一个原生 PHP 重写版本,其中包含一些适用于 Symfony 的现成配方。
Ansistrano
一个 Ansible 角色,允许您通过 YAML 文件配置强大的部署。
Magallanes
这个类似 Capistrano 的部署工具是用 PHP 构建的,可能更容易让 PHP 开发人员根据自己的需求进行扩展。
Fabric
这个基于 Python 的库提供了一套基本操作,用于执行本地或远程 shell 命令以及上传/下载文件。
CapistranoSymfony 插件
Capistrano 是一个用 Ruby 编写的远程服务器自动化和部署工具。Symfony 插件 是一个旨在简化 Symfony 相关任务的插件,灵感来源于 Capifony(仅适用于 Capistrano 2)。

常用部署任务

在部署您的实际源代码之前和之后,您需要执行一些常见的操作

A) 检查需求

运行 Symfony 应用有一些 技术要求。在您的开发机器中,检查这些要求的推荐方法是使用 Symfony CLI。但是,在您的生产服务器中,您可能更喜欢不安装 Symfony CLI 工具。在这些情况下,请在您的应用中安装此其他软件包

1
$ composer require symfony/requirements-checker

然后,确保检查器包含在您的 Composer 脚本中

1
2
3
4
5
6
7
8
9
10
11
12
{
    "...": "...",

    "scripts": {
        "auto-scripts": {
            "vendor/bin/requirements-checker": "php-script",
            "...": "..."
        },

        "...": "..."
    }
}

B) 配置您的环境变量

大多数 Symfony 应用从环境变量中读取其配置。在本地开发时,您通常会将这些变量存储在 .env.env.local(用于本地覆盖)。在生产环境中,您有两种选择

  1. 创建“真实”的环境变量。如何设置环境变量取决于您的设置:它们可以在命令行中设置,在您的 Nginx 配置中设置,或者通过您的托管服务提供的其他方法设置;
  2. 或者,像您的本地开发一样创建一个 .env.local 文件。

这两种选择都没有明显的优势:使用在您的托管环境中最为自然的方式。

提示

您可能不希望您的应用在每次请求时都处理 .env.* 文件。您可以生成一个优化的 .env.local.php 文件,该文件会覆盖所有其他配置文件

1
$ composer dump-env prod

生成的文件将包含存储在 .env 中的所有配置。如果您只想依赖环境变量,请使用以下命令生成一个不包含任何值的文件

1
$ composer dump-env prod --empty

如果您的生产服务器上没有安装 Composer,请改用 dotenv:dump Symfony 命令

C) 安装/更新您的供应商库

您的供应商库可以在传输您的源代码之前更新(即,更新 vendor/ 目录,然后将其与您的源代码一起传输),或者在之后在服务器上更新。无论哪种方式,都像平常一样更新您的供应商库

1
$ composer install --no-dev --optimize-autoloader

提示

--optimize-autoloader 标志通过构建“类映射”显着提高了 Composer 的自动加载器性能。--no-dev 标志确保开发包不会安装在生产环境中。

警告

如果您在此步骤中收到“class not found”错误,您可能需要在运行此命令之前运行 export APP_ENV=prod(如果您没有使用 Symfony Flex,则为 export SYMFONY_ENV=prod),以便 post-install-cmd 脚本在 prod 环境中运行。

D) 清除您的 Symfony 缓存

确保您清除并预热您的 Symfony 缓存

1
$ APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear

E) 其他事项!

根据您的设置,可能还有许多其他事情需要做

应用生命周期:持续集成、质量保证 (QA) 等

虽然本文涵盖了部署的技术细节,但将代码从开发到生产的完整生命周期可能包含更多步骤:部署到暂存环境、质量保证 (QA)、运行测试等。

强烈建议使用暂存、测试、质量保证 (QA)、持续集成、数据库迁移以及在发生故障时回滚的能力。有简单和更复杂的工具,您可以根据您的环境需求使部署尽可能简单(或复杂)。

不要忘记,部署您的应用程序还包括更新任何依赖项(通常通过 Composer)、迁移您的数据库、清除您的缓存以及其他潜在事项,例如将资源文件推送到 CDN(请参阅 常用部署任务)。

故障排除

不使用 composer.json 文件的部署

项目根目录(其值通过 kernel.project_dir 参数和 getProjectDir() 方法使用)由 Symfony 自动计算为存储主 composer.json 文件的目录。

在不使用 composer.json 文件的部署中,您需要覆盖 getProjectDir() 方法 如本节中所述

这项工作,包括代码示例,均根据 Creative Commons BY-SA 3.0 许可获得许可。
目录
    版本