#capifony

[dot-devolink]

capifony — Automatically set proper permissions

#Capifony, Symfony2 via :

[futuremaik]

Capifony: Install bower components after symfony2 deplyoment

Since most modern frontend frameworks like Foundation 5 use package control systems like bower, there is quite a controversy of how to handle its assets towards versioning and deployment.

In my mind these files should not be checked-in which would unnecessarily increase the size of the repository. So I had to come up with an an idea of how to include the components installation in my deployment workflow with capifony.

Fortunately, this tool has many hooks and can be extended very quick. In my deploy.rb I added the following lines to search for the bower config file and execute the installation command on the remote.

namespace :bower do task :install do desc "Install bower components" run "cd #{deploy_to}current/web && cd $(dirname `find -name .bowerrc`) && bower install" end task :clean do desc "Remove bower components" run "cd #{deploy_to}/current/web && cd $(dirname `find -name .bowerrc`) && rm -rf bower_components" end end after 'deploy:create_symlink', 'bower:install'

[dot-devolink]

capifony — symfony and Symfony2 deployment

#Capifony via :

[netropy-labs-blog]

Desplegando aplicaciones Symfony 2 con Capifony: el recopetín

Si eres de los que pierde mucho tiempo desplegando aplicaciones web entonces Capifony te va a encantar.

Se trata de un paquete de tareas orientadas al despliegue de aplicaciones en diferentes entornos y servidores ya sean locales o remotos. Está basado en ruby

En resumen: con Capifony podrás desplegar tus aplicaciones en múltiples servidores desde tu máquina de una manera muy cómoda y segura. Si algo sale mal, basta con ejecutar un comando para revertir el código del servidor a la anterior release en cuestión de segundos

Quizás quieras utilizarlo en el arranque de una instancia de EC2 para descargar la última versión del código y empezar a funcionar. Todo es posible

 En nuestro caso decidimos darle una oportunidad en un proyecto que estamos ayudando a construir con Symfony 2 y Amazon Web Services. Los resultados han sido más que satisfactorios. Vuela :)

Sin embargo, nos hemos topado con algunos obstáculos y queremos dejar aquí expuesto un resumen de nuestro aprendizaje

No perdáis de vista el site oficial, tiene una guía y consejos interesantes

Haremos varias suposiciones porque se adaptan a nuestro caso particular. Aun así, intentaremos explicar todas las opciones

Usamos Symfony 2 con composer

Nuestro server remoto soporta facl

Usamos Github

Lo primero es instalar Capifony

gem install capifony

Nos situamos en la raiz de nuestro proyecto y ejecutamos el script de inicio

cd /ruta/a/tu/proyecto capifony .

Este comando nos habrá generado un archivo en /ruta/a/tu/proyecto/app/config/deploy.rb que vamos a editar a nuestro gusto hasta dejar algo parecido a esto

set :application, "Tu proyecto" set :app_path, "app" set :web_path, "web" set :domain, "tuservidor.com" # Servidor remoto set :user, "usuario" # Usuario ssh set :scm, :git set :repository, "[email protected]:usuario/repositorio.git" set :branch, "master" ssh_options[:forward_agent] = true default_run_options[:pty] = true set :update_vendors, false set :use_composer, true set :deploy_to, "/var/www/tuproyecto" # Ruta del de set :deploy_via, :remote_cache #set :deploy_via, :copy #set :deploy_via, :rsync_with_remote_cache set :use_sudo, false set :shared_files, ["app/config/parameters.yml"] set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor"] set :writable_dirs, ["app/cache"] set :webserver_user, "www-data" set :permission_method, :acl set :model_manager, "doctrine" # Or: `propel` role :web, domain # Your HTTP server, Apache/etc role :app, domain # This may be the same as your `Web` server role :db, domain, :primary => true # This is where Symfony2 migrations will run set :keep_releases, 3 # Be more verbose by uncommenting the following line # logger.level = Logger::MAX_LEVEL

A continuación, vamos a comentar aquellas líneas menos evidentes

domain es el host al que Capifony se conectará vía ssh mientras que con user configuramos el usuario con que lo hará

ssh_options[:forward_agent] hace que el servidor remoto utilice tu clave local privada para identificarse con Github. Activando default_run_options[:pty] garantizamos que el server pueda preguntarnos por una password u otra información. Puede ser útil en ciertos casos, yo personalmente la tengo activada

Con esta configuración de update_vendors y use_composer indicamos que no utilice bin/vendors sino el Composer para actualizar los vendors de nuestra aplicación

La política de despliegue está manejada por deploy_via y es la que sigue

copy clona el repositorio de github en una release del servidor remoto. En este caso es el servidor remoto el que conecta a Github

remote_cache mantiene actualizado un repositorio en el servidor remoto bajo el directorio shared/cached-copy del despliegue salvo que se le diga otra cosa. Cuando ejecutamos cap deploy se actualiza ese repositorio remoto desde Github y se ejecuta el despliegue. De esta forma sólo se descargan los últimos cambios. En este caso es el servidor remoto el que conecta a Github

rsync_with_remote_cache estará solo disponible instalando el gem correspondientegem install capistrano_rsync_with_remote_cache. Funciona como remote_cache salvo que mantiene una copia local .rsync_cache en en la raiz de nuestro proyecto salvo que se le diga lo contrario y la mantiene sincronizada con la remota. En este caso el equipo local es el que conecta a Github

Desactivar use_sudo evita que la estructura de ficheros desplegada la cree el usuario root sino el usuario con el que conectamos vía ssh

Seguramente queramos que algunos ficheros sean compartidos entre releases, como ficheros de configuración que no están en el repositorio. En ese caso añadiremos esos ficheros a shared_files. Capifony creará un directorio shared en el servidor remoto donde deberemos alojar esos ficheros y en cada release creará enlaces simbólicos hacia ellos. Ojo, si los ficheros no están en el repositorio queda de nuestro lado ponerlos en el directorio correspondiente del servidor remoto antes de hacer nuestro primer despliegue. Ej: parameters.yml

Capifony también permite compartir directorios completos entre releases aplicando lo descrito para el caso anterior. Esto es regulado con shared_children

Por otro lado, hay directorios de cada release en los que el usuario www-data (o equivalente) del servidor remoto tiene que poder escribir. Por ejemplo app/cache. Para eso sirve writable_dirs. Capifony se asegurará de que queden listos para escribir por el usuario indicado en www-data a través de varias opciones de permission_method

acl ejecuta un comando setfacl en el servidor remoto

chmod otorga a los directorios permisos globales de escritura

chown ejecuta un comando chown en el servidor remoto. Es incompatible con tener use_sudo desactivado

Cuando tengamos nuestro fichero deploy.rb listo necesitaremos crear la estructura de directorios necesaria en el servidor remoto. Para ello ejecutaremos

cap deploy:setup

Si todo ha ido bien nuestro directorio de despliegue en el servidor remoto tendrá una esctructura parecida a esta

`-- /var/www/my-app.com |-- releases `-- shared

Dentro todavía del servidor pondremos en su lugar los ficheros que no estén en el repositorio dentro del directorio shared de nuestro despliegue. Ej: shared/app/config/parameters.yml.

Es importante porque Capifony ejecuta tareas de nuestra app de Symfony en el servidor remoto y necesita que esté correctamente configurada

Una vez todo esté listo ejecutaremos en nuestra máquina local

cap deploy cap deploy:set_permissions

Si te ha funcionado a la primera, enhorabuena

Si no, mantén la calma. Consulta la página de Capifony. Presta especial atención a los temas relacionados con conectividad y permisos. Recuerda también que ciertas tareas de Symfony se ejecutan en el servidor remoto y si fallan allí el despliegue se abortará

Espero que este post le haya sido de ayuda a alguien. Si véis algún error en el post no dudéis en comentarlo

Un saludo! :)

[joshuaestes-blog]

Symfony2 Continuous Integration with Jenkins, Ant, and Capistrano

At iostudio we work on many different projects. One of the ways we try to make sure that our quality of code is high is to use [Jenkins](http://jenkins-ci.org/) to make sure all of our projects will build successfully and be able to deploy. All of our new work gets is built using the [Symfony2](http://symfony.com) framework. One advantage that we have found is that we are able to create our own iostudio [Symfony Distribution](http://symfony.com/distributions) that contains all of our build scripts and deployment scripts within. Now let's get down to business and into some code. The directory structure.  If you are familiar with the [Symfony2 Directory Structure](http://symfony.com/doc/master/book/page_creation.html#the-directory-structure) You will notice a few things different. You see some new files (build.xml, Capfile) and directories (build/, config/). The build.xml is an [Ant](http://ant.apache.org/) build file that tells ant that it needs to clean up a few directories and get a few things ready before we start to run some build tests on the project. All the files related to this are kept in the build directory. The Capfile and the config folder are the basis for our deployments using [Capifony](http://capifony.org/) with a [Multistage](https://github.com/capistrano/capistrano/wiki/2.x-Multistage-Extension) deployment. The README.md file contains notes related to the project such as getting the project setup and running such as setting up the database and creating users. (Note: Some of our projects include a bash script that does all of this for you). Before I go too much further I also want to stop for a second and talk about our Framework Bundle. We have our own customized framework bundle defined in composer.json that allows us to include cli commands to things such as create controllers, generate an admin backend, and check to see if the user coming to the site is using on a mobile platform or not. Let's pick apart the build.xml file now. The build file is responsible for cleaning up after old builds, getting things ready for the new build, and running all the tests to make sure everything is good. We also put each task in it's own file and have a task that we can use to updated those files to make sure everything stays in check. First we need to clean up after old builds. Now clean up symfony2 related stuff > **NOTE** notice the line where it copies the parameters.yml.dist to parameters.yml. You database setting for the build server will be located in this file. Now that we have everything built, let's start with doing some lint checks on the php and twig files. [phploc](https://github.com/sebastianbergmann/phploc) [pdepend](http://pdepend.org/) [phpcpd](https://github.com/sebastianbergmann/phpcpd) [phpcs](http://pear.php.net/package/PHP_CodeSniffer) We use the [psr](https://github.com/php-fig/fig-standards) standards here. [phpmd](http://phpmd.org/) [phpunit](https://github.com/sebastianbergmann/phpunit/) So there are most of the build scripts. Each are in it's own file to allow us to run a quick script to update all of these. Now Jenkins needs to be setup. We have our own symfony2 jenkins template that we use that includes all the tools that we use to read the output of all the tests above. We also have some documentation auto generated for us using phpdoc. I have left this script out and you can insert your favorite php documentor for that. There are various tutorials on setting up Jenkins so I will skip that and get into deploying with Capifony. The plugin that we use is the [Post Build Task](https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task) which only runs when everything else is within an acceptable range. ie None of the phpunit tests failed. Let's now go over the Capifony configs. For each deployment we only want to share the logs, the uploads, and the vendor directories. We don't share the parameters.yml file. The reason why the parameters.yml file is not shared is because for each project we maintain a parameters.yml.stage. Stage refers to the capistrano multistage extension. For every project we have at least a beta server and a production server. The configuration for this is setup in the specific files. Allow me to rant for a moment on this. The reason why this are setup like this is so we can look at the parameters.yml.beta file and see how it's setup. Most of the time we use a throw away Google Analytics account on the beta server to avoid beta tests getting into production analytic logs. It's also to avoid having to ssh into the servers and see what is configured there. Once the deployment takes place, we hook into the `deploy:finalize_update` task and do two things. First we have a robots.txt.beta that we copy over to the web folder that tells search engines to keep the beta site out of it's indexes. The other is to copy over the parameters.yml.beta file. # app/config/deploy.rb # ... snip ... before("deploy:finalize_update") do run "if [ -f #{current_release}/web/robots.txt.#{stage} ]; then cp #{current_release}/web/robots.txt.#{stage} #{current_release}/web/robots.txt; fi" run "if [ -f #{current_release}/app/config/parameters.yml.#{stage} ]; then cp #{current_release}/app/config/parameters.yml.#{stage} #{current_release}/app/config/parameters.yml; fi" end # ... snip ... It takes awhile to get all of this setup for each of our clients, but we have found that deploying code reduces the amount of people asking for us to deploy code up for our QA department or for client approval.

[vinh-tran]

Deploying Symfony2 projects on Shared Hosting with Capifony

(copied from http://blog.servergrove.com/2011/09/07/deploying-symfony2-projects-on-shared-hosting-with-capifony/)

This article is meant to help you configure and deploy your projects developed with Symfony2 into a Shared Hosting environment, so if you need to deploy using capifony on a VPS, please read this article.

Pre-requisites

capifony requires you have a ssh connection to your server, so make sure your current hosting plan supports this feature and that you enable shell access for the domain.

Installation

I assume that you already have Ruby & RubyGems installed on your local environment (MacOS X has this out of the box – simply update gems with `sudo gem update –system`).

To install capifony and capistrano, simply run:

gem install capifony

This command will install capifony and it’s dependencies (capistrano for example) to your local host. NOTE: Your local host is the only place where you need to install capifony & capistrano.

It’s also good practice to create and copy the SSH key to speed up the connections to your remote repositories.

Generate key with:

ssh-keygen -t dsa

Next, copy your public key to the remote server that you want to connect to (I am going to assume your SSH user is called `demoUser`):

cat .ssh/id_dsa.pub | ssh [email protected] -p 22123 "cat >> .ssh/authorized_keys2"

Then just try to connect with:

ssh [email protected] -p 22123

If all goes well the remote server will just let you in without password prompt.

You may also install capistrano_rsync_with_remote_cache gem in your local computer. This is not mandatory but it is highly recommended, since it creates a cache on the server which will allow to sync only the files that actually had changed since the last deploy, reducing time and bandwidth spent on remote connections. You can do this by running the command:

gem install capistrano_rsync_with_remote_cache

Create the configuration

capifony needs two files to be located inside the project root in your local machine, Capfile and app/config/deploy.rb. These files are created by capifony itself, by running the following command:

$ cd /path/to/your/project $ capifony .

Configuration

Next we need to configure capifony for our application and server settings.

Repository

In this case we will use git as a repository. You can use a local repository

 set :repository, "file:///path/to/your/local/project/repo" set :csm, git

or use a remote repository instead, like github:

set :repository, "git://github.com/namespace/project.git" set :csm, git

Server connection

These settings are for the ssh connections, used to execute remote commands and by rsync.

set :serverName, "sg111.servergrove.com" # The server's hostname set :domain, "example.com" set :user, "myusername" ssh_options[:port] = 22123

Deploy settings

The following settings define the behavior of capifony.

# Remote location where the project will be stored set :deploy_to, "/var/www/vhosts/yourdomain.com/symfony_projects/" # Deploy strategy set :deploy_via, :rsync_with_remote_cache # Roles role :web, domain role :app, domain role :db, domain, :primary => true # The number of releases which will remain on the server set :keep_releases, 3 set :use_sudo, false # Update vendors during the deploy set :update_vendors, true # Set some paths to be shared between versions set :shared_files, ["app/config/parameters.ini"] set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor"]

Result This is the full configuration file

set :serverName, "sg111.servergrove.com" # The server's hostname set :repository, "file:///path/to/your/local/project/repo" set :domain, "example.com" set :deploy_to, "/symfony_projects/" # Remote location where the project will be stored ssh_options[:port] = "22123" set :scm, :git set :deploy_via, :rsync_with_remote_cache set :user, "myusername" # Roles role :web, domain role :app, domain role :db, domain, :primary => true set :keep_releases, 3 # The number of releases which will remain on the server set :use_sudo, false # Update vendors during the deploy set :update_vendors, true # Set some paths to be shared between versions set :shared_files, ["app/config/parameters.ini"] set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor"]

Remote setup

Once you have fully configured capifony, you need to setup your deployment on the remote server, and this is as simple as running a single command on your local machine. You only need to execute this command once, before your first deploy.

$ cap deploy:setup

Deploy

Same thing with the deploy process.  All the hard work has been done with the configuration so we just need to run the deploy command:

$ cap deploy

This will create a new release of the project in the remote server, and in case they exists, it will remove old releases, keeping the quantity previously configured with :keep_releases.

That’s it, this tool is really simple to use and we can assure that will be very helpful for you.

For further knowledge you can head to the capifony reference.

We want to thank Ryan Weaver from KnpLabs for the configuration reference and Konstantin Kudryashov (aka everzet) for the initial Capifony article (his install steps used in this article).