Deploying WordPress with Capistrano screencast

What I really need to do is get the Wiki going since the README is already massive.

2 Likes

Hello Scott.

It is a very informative screencast for Bedrock and helped me to home in on the basics. When extending Bedrock to include npm install and running it for the first time, I get the following error (extracted only the last few lines).

INFO [f55ebc5e] Running /usr/bin/env composer install --no-dev --prefer-dist --no-interaction --quiet --optimize-autoloader on example.com DEBUG [f55ebc5e] Command: cd /srv/www/example.com/releases/20140519134039 && ( WP_ENV=staging /usr/bin/env composer install --no-dev --prefer-dist --no-interaction --quiet --optimize-autoloader ) INFO [f55ebc5e] Finished in 1.123 seconds with exit status 0 (successful). DEBUG [fa0db4ea] Running /usr/bin/env if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi on example.com.me DEBUG [fa0db4ea] Command: if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi cap aborted! SSHKit::Command::Failed: if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi exit status: 1 if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi stdout: Nothing written if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo "Directory does not exist '/srv/www/example.com/current/web/app/themes/roots'" 1>&2; false; fi stderr: Nothing written

It seems that the composer/npm task is getting invoked before the current symlink is created for the first time.

If I comment out the lines require 'capistrano/npm' and require 'capistrano/grunt' in the Capfile (and the line before 'deploy:updated', 'grunt' in the deploy.rb file) , the remote deployment completes successfully with the current symlink being generated correctly.

Subsequent runs of Capistrano, after the inclusion of the above commented lines, results in a successful deploy as well (albeit after some tweaking of folder permissions through a separate ssh terminal).

Has anyone else run across this issue? Is it related to the permissions of the user (I created a new user called deploy as given in the Capistrano website)?

Thanks in advance.

Ravi

Could you post a Gist of your deploy.rb file? It shouldn’t matter that it happens before the current symlink because the Grunt extension (and npm) are set to use release_path by default which is the direct path to the release like /releases/20140519120005.

Thanks for the quick response. Here is the gist of my deploy.rb file.

Think it might be because of how you’re setting the theme_path variable. In Capistrano, things like release_path aren’t set until a deploy runs so you can’t directly reference it. You need it to be evaluated later so just wrapping it in a lambda (anonymous function basically) works. L21 here: https://gist.github.com/swalkinshaw/17232e86d0b3d709095a

edit: and if I had it set like you did in my screencast then I apologize. Hard to update screencasts with “bug fixes”. However, the README in the npm/Grunt gems reflect using lambda (https://github.com/roots/capistrano-grunt)

1 Like

I fixed the construct of the theme_path variable, as suggested, with the lambda wrapper. But I still get the error from the npm:install task that seems to check for the theme folder structure using the current symlink that does not exist for a first time install. See the following gist of the error message.

“Tasks: TOP => deploy:updated => npm:install
(See full trace by running task with --trace)
The deploy has failed with an error: #<SSHKit::Command::Failed: if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo “Directory does not exist ‘/srv/www/example.com/current/web/app/themes/roots’” 1>&2; false; fi stdout: Nothing written
if test ! -d /srv/www/example.com/current/web/app/themes/roots; then echo “Directory does not exist ‘/srv/www/example.com/current/web/app/themes/roots’” 1>&2; false; fi stderr: Nothing written
”

Anyone else facing this very same issue (on a first time install)? Could it be related to the SSHKit settings or the user permissions on my server root folder?

1 Like

Scott,

I downloaded the video to get help. I am stuck on the deploy step. For now, I am skipping staging and am trying to deploy to production.

When I run bundle exec cap production deploy, it connects to bitbucket just fine and when it starts trying to make the ‘shared’ and ‘releases’ directory, it fails with
"mkdir: cannot create directory ‘/var/www/brandontamm.com/shared’: Permission denied"

Same error for releases directory. I have a user:group deploy:www. The directory I am writing to is owned by www-data:www-data.

I am nervous about changing ownerships without a little guidance - can you help me on this one? All I want to do is deploy code, not manage systems :frowning:

Also - I am a bit confused on the .env file and the environments folder. Where do I change the database and URL - I am assuming I copy/paste the whole block in the .env file so I have one block for development and one block for production? Is there anything to change in the config/environment files?

So you’re deploying with user deploy in group www? /var/www/brandontamm.com obviously needs to share either its user or group owner with the user you’re deploying with.

One solution is just adding the deploy user to group www-data and then you don’t need to change directory permissions.

You probably don’t need to change anything in the environments folder as they’re already set up to read the env vars set from the .env file.

Your local .env file most likely should have development settings. Then on your production server you can just manually create it with prod values. There’s some more info in this issue: https://github.com/roots/bedrock/issues/18

I get this error running bundle exec cap staging deploy:

sudo: no tty present and no askpass program specified

I’m not quite sure what’s causing since I am quite sure the settings and configuration was all taken care of.

Any help and pointers?

Are you using Windows? OS X?

See here: https://groups.google.com/forum/#!topic/capistrano/554ehbCE45o

Hey @swalkinshaw ,

I am using OS X. Thanks for the pointer, Scott. So far can’t figure out how to put this inside:

default_run_options[:pty] = true

any of the deploy.rb or staging.rb. Figuring out as we speak. Will share my findings and solutions if I beat anyone to it. Thanks again!

From the looks of it, my option is to have passwordless sudo or perhaps figure out how to make Capistrano can accept my sudo password. Right now it stops but doesn’t capture when I enter it.

Will update more findings or solutions.

UPDATES:

  • Managed to work it by doing passwordless sudo.

I think I’m close now. It looks like in the docs it says I should point my vhost to /path/to/app/current/web but somehow on my Nginx setup it gives me 500 error code.

I tried /path/to/app/web but that means it doesn’t reflect whatever i’m pushing from local. It’s a bare WP install rather than the one I updated and pushed from local to cloud (my case I’m using Github).

Out of idea I restart server each time I changed any configuration. Will share further findings/solutions.

Scott,

Your video is very well done, however, setting up the remote server’s users/groups/permissions for capistrano and nginx seems to be causing issues for me (and others).

After spending hours to get the ssh keys and users setup on my server, I (and ajmalafif from above) am having issues with capistrano creating and owning files and folders as user ‘deploy.’ However, nginx is setup as www-data:www-data. Deploy does belong to the same group ‘www-data’ .

So, I manually changed ownership of the folders/files to user ‘www-data’ from ‘deploy’ in order to deploy successfully. It worked, but I found that deploys fail to delete releases after the 5th release due to the manual ownership change. Can you provide insight into properly dealing with users/groups/permissions for capistrano and nginx to work together as intended?

Thanks,

Brandon

2 Likes

That’s correct. If you’re getting a 500 error there should be an error somewhere. Check nginx’s error log. Pretty hard to debug otherwise.

1 Like

@swalkinshaw

Thanks I think I got it now. It was the shared/.env file.

There are few gotchas for my specific setup. I keep track of them and gonna share like my DigitalOcean’s list later.

I’m still half way into implement the whole setup (use s3 and cloudfront for assets files) and extra security setup for this EC2 setup. Thanks again that screencast helps bridge a lot of stuffs that isn’t too clear (i’m a visual learner).

Thanks again for help and concern Scott!

btw what the point of having that repo_url? Doesn’t it mean it will only reflect my github repo with specified branch, rather than the repo I cap deploy from local? Somehow I think it’s good practice to reflect on github first rather than what’s on local. I use CircleCI for some Rails project with others, helps on syncronization of our works better (but then again bcos Rails have integration test and all).

Sorry for the delay on this, this thread got buried.

Capistrano’s entire purpose is to deploy a codebase from an SCM (like Git). It will always reflect that repo_url and not what you have locally. I guess I’m confused by your question because whatever you set in repo_url will (most likely) be the local repo you have checked out as well.

I have the same issue. Did you find a solution ?
Thanks
Alex

Blood, sweat and tears

After hours and hours of tackling all sorts of issues, mainly to do with Plesks default permissions on my DV server over at MediaTemple, I have finally managed to do a successful deploy. Yet it never ends.


One final Issue

What I am having trouble with now is getting Capistrano set the application.php to work well with my database. I have added .env to where it should be but the settings are not being translated over.


Debug

These are the only errors I am now receiving:

DEBUG[966c9c4a] Running /usr/bin/env [ -L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env ] on dev.domain.com
DEBUG[966c9c4a] Command: [ -L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env ]
DEBUG[966c9c4a] Finished in 0.533 seconds with exit status 1 (failed).

DEBUG[92249387] Running /usr/bin/env [ -f /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env ] on dev.domain.com
DEBUG[92249387] Command: [ -f /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/.env ]
DEBUG[92249387] Finished in 0.339 seconds with exit status 1 (failed).

DEBUG[f6c86024] Running /usr/bin/env [ -L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/web/app/uploads ] on dev.domain.com
DEBUG[f6c86024] Command: [ -L /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224/web/app/uploads ]
DEBUG[f6c86024] Finished in 0.359 seconds with exit status 1 (failed).

DEBUG[02f255ef] Running /usr/bin/env wp core is-installed on dev.domain.com
DEBUG[02f255ef] Command: cd /var/www/vhosts/domain.com/dev.domain.com/www/releases/20141209142224 && ( WP_ENV=staging /usr/bin/env wp core is-installed )
DEBUG[02f255ef] 	/usr/bin/env: wp: Permission denied
DEBUG[02f255ef] Finished in 0.371 seconds with exit status 126 (failed).

EDIT: a few hours later
As it turns out most the aforementioned failures were actually doing their job. Hours of trial and error and google searching led me here.

The issue that did need a fix however was the permission denied error when attempting to execute /usr/bin/env :wp
To override SSHKit using wp-cli in this folder, I added the following line before
:deploy do :

SSHKit.config.command_map[:wp] = "/usr/local/bin/wp/wp-cli.phar"