symfony_如何使用Capifony部署Symfony应用

symfony

Say you have a Symfony application. At some point, you would like to deploy it to your server and show it to the world. Of course, you can do it all manually, but these days you can also choose to use a tool like Capifony.

假设您有一个Symfony应用程序。 在某个时候，您希望将其部署到服务器上并展示给全世界。 当然，您可以手动完成所有操作，但是如今，您还可以选择使用Capifony之类的工具。

If you have developed Ruby applications in the past, you are perhaps familiar with Capistrano. Capistrano is a tool to deploy your Ruby application to your server. Capifony has been created on top of Capistrano, and is basically a collection of deployment recipes.

如果您过去曾经开发过Ruby应用程序，那么您可能对Capistrano很熟悉。 Capistrano是将Ruby应用程序部署到服务器的工具。 Capifony是在Capistrano之上创建的，基本上是部署配方的集合。

In this article, we are going to deploy a Symfony application to a server with Capifony.

在本文中，我们将使用一个Capifony将Symfony应用程序部署到服务器上。

Capifony如何运作？ (How does Capifony work?)

Before we start, it’s important to understand how Capifony works. By running the deploy command, Capifony runs certain commands performing different tasks. For example, it will download composer, install the dependencies and clear the cache.

在开始之前，重要的是要了解Capifony的工作原理。 通过运行deploy命令，Capifony运行某些执行不同任务的命令。 例如，它将下载作曲家，安装依赖项并清除缓存。

The directory structure is very important. Capifony needs two directories and one symlink. The first directory it needs is called releases. Every time you deploy, a new directory is created within this directory. Capifony pulls in your git repository and runs all commands on this newly created directory.

目录结构非常重要。 Capifony需要两个目录和一个符号链接。 它需要的第一个目录称为releases 。 每次部署时，都会在该目录中创建一个新目录。 Capifony进入您的git仓库并在这个新创建的目录上运行所有命令。

The second directory is named shared. You can imagine that some directories are shared between releases. For instance, if you allow people to upload images, you want to make sure that these files are shared between releases. These directories and files are typically stored in the shared directory.

第二个目录名为shared 。 您可以想象某些目录在发行版之间共享。 例如，如果允许人们上传图像，则要确保这些文件在发行版之间共享。 这些目录和文件通常存储在shared目录中。

Next to these two directories, we have a symlink called current. This symlink points to the latest successful release. So, when you deploy a new version, a new directory will be created within the releases directory. If all tasks succeed on this directory, the current symlink will point to this new version. You should point your web server to read from this symlink so it always uses the correct, latest version.

在这两个目录旁边，我们有一个名为current的符号链接。 此符号链接指向最新的成功发行版。 因此，当您部署新版本时，将在releases目录中创建一个新目录。 如果所有任务都在该目录上成功执行，则current符号链接将指向该新版本。 您应将Web服务器指向该符号链接以进行读取，以便它始终使用正确的最新版本。

安装Capifony (Installing Capifony)

Let’s cut the theoretic part and dive into deployment. For that, we need to install Capifony. Make sure Ruby is installed on your system before proceeding. You can install the Capifony gem by running gem install capifony.

让我们削减理论部分，并深入进行部署。 为此，我们需要安装Capifony。 在继续之前，请确保在系统上安装了Ruby。 您可以通过运行gem install capifony 。

Within your application directory, run the command capifony .. This command will create a file named Capfile in your root directory and a deploy.rb in your configuration directory. You will alter the deploy.rb file during this article, so make sure you have it open in your favorite editor.

在您的应用程序目录中，运行命令capifony . 。 此命令将创建一个名为文件Capfile在根目录和deploy.rb在配置目录。 在本文中，您将更改deploy.rb文件，因此请确保在您喜欢的编辑器中将其打开。

Now you have to decide what your deploy strategy will be. Either you choose to let your production server access your SCM (Source Control Management) or your local computer pulls in your repository from the SCM and copies it to your production server.

现在，您必须决定您的部署策略。 您选择让生产服务器访问SCM(源代码管理)，或者本地计算机从SCM提取存储库并将其复制到生产服务器。

Within this article, we will look at the first strategy. If you are interested in the second strategy, have a look at the official Capifony website for instructions.

在本文中，我们将探讨第一种策略。 如果您对第二种策略感兴趣， 请访问Capifony官方网站以获取说明。

配置项目 (Configure your project)

I am going to use this project and deploy it to a production server. I got the application checked out on my machine, so it’s time to run capifony ..

我将使用此项目并将其部署到生产服务器。 我在计算机上签出了该应用程序，因此该运行capifony . 。

$ capifony .
[add] writing './Capfile'
[add] writing './app/config/deploy.rb'
[done] symfony 2 project capifonied!

When you open up the deploy.rb script, you will see the following content.

打开deploy.rb脚本时，将看到以下内容。

set :application, "set your application name here"
set :domain,      "#{application}.com"
set :deploy_to,   "/var/www/#{domain}"
set :app_path,    "app"

set :repository,  "#{domain}:/var/repos/#{application}.git"
set :scm,         :git
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `subversion`, `mercurial`, `perforce`, or `none`

set :model_manager, "doctrine"
# Or: `propel`

role :web,        domain                         # Your HTTP server, Apache/etc
role :app,        domain, :primary => true       # This may be the same as your `Web` server

set  :keep_releases,  3

# Be more verbose by uncommenting the following line
# logger.level = Logger::MAX_LEVEL

It’s time to change this configuration file. We start off with the top 4 parameters. First off, we define what the name of our application is, what the domain to deploy to is, what the directory will be and where the app path is. If you are using the default Symfony setup, the app path will already be configured correctly. So far my configuration looks like this.

现在是时候更改此配置文件了。 我们从前四个参数开始。 首先，我们定义应用程序的名称是什么，要部署到的域是什么，目录将是什么以及应用程序路径在哪里。 如果您使用默认的Symfony设置，则应用程序路径将已经正确配置。 到目前为止，我的配置看起来像这样。

set :application, "Jumph"
set :domain,      "peternijssen.nl"
set :deploy_to,   "/srv/www/jumph"
set :app_path,    "app"

Let’s configure our repository. Since we are using a git repository, we should set the SCM to git and point the repository to our Github repository.

让我们配置我们的存储库。 由于我们使用的是git存储库，因此应将SCM设置为git并将存储库指向我们的Github存储库。

set :repository,  "git@github.com:jumph-io/Jumph.git"
set :scm,         :git

Up next we define our model manager. In my case I am using Doctrine, but if you are using Propel, you should change the configuration value to “propel”.

接下来，我们定义模型经理。 就我而言，我使用的是Doctrine，但是如果您使用的是Propel，则应将配置值更改为“ propel”。

We can skip the roles. They are just reusing your domain.

我们可以跳过这些角色。 他们只是在重用您的域。

The last setting is the keep_releases setting. With this setting, you can define how many releases you may want to keep, allowing you to rollback to a previous version.

最后一个设置是keep_releases设置。 使用此设置，您可以定义要保留的发行版数量，从而可以回滚到以前的版本。

So far, we changed all the default config variables to the correct values. However, Symfony requires more configuration to be deployed. In my case, I am both using Assetic as well as Composer. This means I have to add the following settings to the file.

到目前为止，我们将所有默认配置变量更改为正确的值。 但是，Symfony需要部署更多配置。 就我而言，我同时使用Assetic和Composer。 这意味着我必须将以下设置添加到文件中。

set :dump_assetic_assets, true
set :use_composer, true

Now we need to configure the shared files. For example, your parameters.yml should be shared between every release. Next to that, it’s wise to also share your uploads, your logs and your vendor between releases. If you are not sharing your vendor between every release, it means your deploy is installing all vendors every single time. To set these shared paths, we just add the following configuration.

现在我们需要配置共享文件。 例如，应在每个发行版之间共享您的parameters.yml 。 紧接着，还应该在两次发布之间共享您的上传，日志和供应商。 如果您不在每个版本之间共享供应商，则意味着您的部署每次都安装所有供应商。 要设置这些共享路径，我们只需添加以下配置。

set :shared_files,      ["app/config/parameters.yml"]
set :shared_children,     [app_path + "/logs", web_path + "/uploads", "vendor", app_path + "/sessions"]

Note that in my case I also moved the session directory outside the cache directory. This way I am able to share this directory between releases and nobody gets logged out on a new deploy. Do note you need to change the configuration within Symfony also to reflect this change.

请注意，就我而言，我还将会话目录移到了缓存目录之外。 这样，我就可以在发行版之间共享此目录，并且没有人注销新的部署。 请注意，您还需要在Symfony中更改配置以反映此更改。

session:
    save_path: "%kernel.root_dir%/sessions/"

配置服务器 (Configure your server)

So far everything is ready for our Symfony application. Now it’s time to configure everything for our server. We do this within the same config file as above.

到目前为止，一切就绪，可用于我们的Symfony应用程序。 现在是时候为我们的服务器配置所有内容了。 我们在与上述相同的配置文件中执行此操作。

When deploying, Capifony runs as root. If you prefer to run it as your own user, you can add the following lines to your configuration.

部署时，Capifony以root用户身份运行。 如果您希望以自己的用户身份运行它，则可以在配置中添加以下几行。

set :use_sudo,      false
set :user, "peter"

It’s also important to make sure your web server user is able to write to certain directories. This can be done by adding the following settings.

确保您的Web服务器用户能够写入某些目录也很重要。 可以通过添加以下设置来完成。

set :writable_dirs,       ["app/cache", "app/logs", "app/sessions"]
set :webserver_user,      "www-data"
set :permission_method,   :acl
set :use_set_permissions, true

Note: You might need to install certain packages on your server. For more information regarding permissions, please check this page.

注意：您可能需要在服务器上安装某些软件包。 有关权限的更多信息，请检查此页面。

Now we can tell Capifony to prepare the directories on your server. We can do this by running cap deploy:setup. Do make sure you have SSH access to the server and the directory is writable by your user of course.

现在，我们可以告诉Capifony在您的服务器上准备目录。 我们可以通过运行cap deploy:setup来做到这一点。 请确保您具有对服务器的SSH访问权限，并且该目录当然是您的用户可写的。

Note: In my case I had to add default_run_options[:pty] = true to my configuration due to a known issue.

注意：由于已知问题，我必须在配置中添加default_run_options[:pty] = true 。

After the command has been run, you will notice it created the releases and shared directories on your server.

运行该命令后，您会注意到它在服务器上创建了releases和shared目录。

Now you should be able to deploy by running cap deploy on your command line. If you bump into any problems, you can add the following line to your configuration file, to get more information about the error.

现在，您应该可以在命令行上运行cap deploy进行cap deploy 。 如果遇到任何问题，可以将以下行添加到配置文件中，以获取有关该错误的更多信息。

logger.level = Logger::MAX_LEVEL

In my case, I was unable to access the git repository due to an invalid public key. Since my local computer can access the repository, I just had to forward my SSH agent to the server. This can be done by adding the following line to the deploy script.

就我而言，由于无效的公钥，我无法访问git存储库。 由于本地计算机可以访问存储库，因此我只需要将SSH代理转发到服务器即可。 这可以通过将以下行添加到部署脚本中来完成。

ssh_options[:forward_agent] = true

Since it’s your first deployment, Capifony will ask you for the credentials of the parameters.yml file. You only have to fill them in once, since we configured the file to be shared across releases.

由于这是您的首次部署，因此Capifony将要求您提供parameters.yml文件的凭据。 您只需要填写一次，因为我们将文件配置为在各个发行版之间共享。

添加其他命令 (Adding additional commands)

If you tried to deploy the repository I mentioned earlier, you will notice it fails when Assetic tries to dump it’s files. This is due to the fact that I am managing my JavaScipt and CSS dependencies through Bower. So before Assetic dumps the files, I should first run bower install.

如果您尝试部署我前面提到的存储库，那么当Assetic尝试转储其文件时，您会注意到它失败。 这是因为我正在通过Bower管理JavaScipt和CSS依赖项。 因此，在Assetic转储文件之前，我应该先运行bower install 。

Capifony by default has no support for bower, so we have to expand the list of tasks that Capifony performs. We add an additional task by adding it to the configuration file.

Capifony默认不支持Bower，因此我们必须扩展Capifony执行的任务列表。 我们通过将其添加到配置文件中来添加其他任务。

before 'symfony:assetic:dump', 'bower:install'

namespace :bower do
    desc 'Run bower install'
    task :install do
      capifony_pretty_print "--> Installing bower components"
      invoke_command "sh -c 'cd #{latest_release} && bower install'"
      capifony_puts_ok
    end
end

The task is quite easy to understand. First we define when the task should run. In this case, we want to run it before Assetic dumps its files. Next we define which task it should run.

这项任务很容易理解。 首先，我们定义任务应在何时运行。 在这种情况下，我们要在Assetic转储其文件之前运行它。 接下来，我们定义应运行的任务。

The last thing we need to do is to define this new task. We do so by creating a task within a namespace and write down which command to run. In this task, we first make sure we are in the correct directory and then run bower install.

我们需要做的最后一件事是定义这个新任务。 为此，我们在名称空间中创建一个任务并写下要运行的命令。 在此任务中，我们首先确保我们在正确的目录中，然后运行bower install 。

Additionally, I added some output before and after the command. This way, it will show up in the cap deploy command when running. It gives you some extra feedback as you can see below.

另外，我在命令之前和之后添加了一些输出。 这样，它将在运行时显示在cap deploy命令中。 如下所示，它为您提供了一些额外的反馈。

$ cap deploy
--> Updating code base with checkout strategy
--> Creating cache directory................................✔
--> Creating symlinks for shared directories................✔
--> Creating symlinks for shared files......................✔
--> Normalizing asset timestamps............................✔
--> Downloading Composer....................................✔
--> Installing Composer dependencies........................✔
--> Installing bower components.............................✔
--> Dumping all assets to the filesystem....................✔
--> Warming up cache........................................✔
--> Clear controllers.......................................✔
--> Setting permissions.....................................✔
--> Successfully deployed!

附加命令 (Additional commands)

In the beginning, we decided to keep at least 3 releases. If something should go wrong in the new release, you can rollback by running the command cap deploy:rollback.

一开始，我们决定至少保留3个版本。 如果新发行版中出现问题，可以通过运行命令cap deploy:rollback 。

Additionally you can also activate or deactivate the Symfony maintenance page by either running cap deploy:web:disable or cap deploy:web:enable.

另外，您还可以通过运行cap deploy:web:disable或cap deploy:web:enable来激活或停用Symfony维护页面。

Capifony consists of more commands that might come in handy. For a full list you can run cap -vT.

Capifony由可能派上用场的更多命令组成。 要获取完整列表，可以运行cap -vT 。

完整的配置 (Complete configuration)

As a reference, this is the complete configuration file which we created through this article.

作为参考，这是我们通过本文创建的完整配置文件。

set :application, "Jumph"
set :domain, "peternijssen.nl"
set :deploy_to, "/srv/www/jumph"
set :app_path, "app"

set :repository, "git@github.com:jumph-io/Jumph.git"
set :scm, :git

set :model_manager, "doctrine"

role :web, domain
role :app, domain, :primary => true

set :use_sudo, false
set :user, "peter"

set  :keep_releases, 3

set :dump_assetic_assets, true
set :use_composer, true

set :shared_files, ["app/config/parameters.yml"]
set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor", app_path + "/sessions"]

set :writable_dirs, ["app/cache", "app/logs", "app/sessions"]
set :webserver_user, "www-data"
set :permission_method, :acl
set :use_set_permissions, true

ssh_options[:forward_agent] = true
default_run_options[:pty] = true

before 'symfony:assetic:dump', 'bower:install'

namespace :bower do
    desc 'Run bower install'
    task :install do
      capifony_pretty_print "--> Installing bower components"
      invoke_command "sh -c 'cd #{latest_release} && bower install'"
      capifony_puts_ok
    end
end

结论 (Conclusion)

Capifony makes your life easier if it comes to deploying your Symfony application. Although we have already seen a lot of options Capifony offers, you might want to dig deeper. You can check out their website for more information. Are you using Capifony to deploy your Symfony applications? Let us know if you run into any difficulties or have any questions!

如果要部署Symfony应用程序，Capifony使您的生活更加轻松。 尽管我们已经看到了Capifony提供的许多选项，但您可能需要更深入地了解。 您可以查看他们的网站以获取更多信息。 您是否正在使用Capifony部署Symfony应用程序？ 让我们知道您是否遇到任何困难或有任何疑问！

翻译自: https://www.sitepoint.com/deploy-symfony-apps-capifony/

symfony