This is my first deployment. I did a cap deploy:setup which worked fine.
Then, when I try to execute cap deploy:update I run into error messages. Something along the lines of
rm: cannot remove `/var/www/app_name/current': Is a directory
Here is my capfile and directory permissions.
http://pastie.org/1189919
In general, what is the best practice as far as deployment user and permissions are concerned? Should I use root or create a different user. If a different user what exact permissions does it need?
Thanks
Did you create the directories within /var/www/app_name, or were they created by capistrano?
Regardless, the issue you have is that /var/www/app_name/current should not be a directory - it should be a symlink to the current release within /var/www/app_name/releases/. The failure is caused when capistrano has finished creating the new release folder within /var/www/app_name/releases/, and is trying to symlink /var/www/app_name/current to it.
You might be able to fix your issues by renaming /var/www/app_name/current (so you have a backup if things go wrong), and creating a symlink from /var/www/app_name/current to the most recent release within /var/www/app_name/releases/, and then doing a cap deploy. (Delete your backup of current if this works).
As far as best practice goes whatever you do, do not use root. Instead, set up a user (or use an existing user) that has only permissions to the required directories (didn't read your scripts closely, but probably just /var/www/app_name.
To deploy a new release you should invoke cap deploy or cap deploy:migrations, not cap deploy:update.
I also have had such errors. A totally normal task of updating source code and restarting the server always seems to have problems at various points of the simple script.
Sometimes it complains that a hash value at github doesn't match some expected value, sometimes it won't update a directory because it already exists, but mostly with it wanting to create things that exist.
Is there no way to force Capistrano and thus the shell commands to just DO IT ? I would at least appreciate it asking me what it should do should it encounter this type of error instead of just failing and rolling back. Especially when it's a simple file operation.
I end up having to delete things manually on the server so that the Capistrano script will run without failing. This is obviously not the way forward.
Related
I've never worked with Capistrano before and currently I am fighting the urge to just scrap it and go back to my old manual ways.
As I understand, Capistrano V3 does not create the initial database because they feel it is the duty of the DB administrator.
So I must be missing something but I have followed their instructions but the initial cap staging deploy fails when it gets to the rake db:migrate step because the database does not exist.
Because of the failure, the symlink for current -> releases never gets created.
Is it just accepted general practice that we SSH into our boxes and cd into the first folder under releases and manually run rake db:create...?
And then from there, am I supposed to just run cap staging deploy again so that it finishes creating the symlinks?
Seems hacky for something that is supposed to make things easier and I am not sure if I am understanding this correctly or not.
Thanks.
It does make sense to leave certain things out of a deployment. As the initial set up and the routine deployments are very separate functions and require different specialties, or in large deployments even different skillsets. That said.. I'm totally with you - on the first deploy having to manually set up the database and certain files (specifically linked files like secrets.yml) is a step that just wastes my time.
I use this plugin:
https://github.com/capistrano-plugins/capistrano-postgresql
just add the require capistrano/postgresql to your capfile as you would any plugin
then run cap staging setup before the first time you run cap staging deploy
To give you some context, I'm trying to use Figaro to safely add in environment variables without having to worry about security risks. The problem is is that I can't seem to get Engine Yard to play nice with production.
I went and did a touch application.yml and then vim application.yml, i, and then command+v to insert that api keys and what not. I know the ENV['VARIABLES'] work because of development and all my rspec and cucumber tests (which utilize the APIs), passed.
When I've got everything ready, I add within the .gitignore:
# Ignore application configuration
/config/application.yml
Afterwards, I deploy the site. I open it up and data isn't going to the APIs anymore. OK...
cd into config and discover application.yml isn't there anymore. Paste it back in... Redeploy the site since now it understands it has to ignore that file and I'm not seeing changes on production. Check back... and its gone again!
Stumped on what's going on.
Simply putting a file into your deployed application's filesystem will not work because you get a clean environment each time you deploy. EngineYard cannot know that you want that particular file copied to that particular location without a little bit of extra work.
Their official recommendation is to put your YAML configuration files in /data/<app>/shared/config and symlink them to /data/<app>/current/config each time you deploy using deploy hooks.
I am using Capistrano 3 to deploy my app to the production server.
My server has system wide install of rvm. There is nothing extra ordinary about the deploy script.
However when i run cap production deploy The deploy script gives out successful messages and seems that deploy went without a problem.
However when I check the latest release folder is not updated and only the repo folder is updated.
This was supposed to be much easier while using Capistrano 2. But the respective commands to create symlinks etc all are shown to be passed in the console log while depoying while in the server nothing is being done.
Am I missing something about the capistrano 3 changes.
Ask if you need more information.
Capistrano 3 changed the symlink task, if you overrode it or called it specifically like deploy:create_symlink, you may want to audit your code.
I would like to run cap development deploy:setup and cap development deploy to setup the dev environment for my rails app. In order to do this, I will have to remove the project folder from the remote machine, is there a way to automate this in some fashion using cap.
I basically want to remove the app folder in remote machine before I do a full deploy.
The Capistrano app folder is structured like this:
releases - Contains separate folders (named using commit IDs or timestamps) for each deployment made so far
current - Linked to the latest deployment folder under releases
shared - Shared logs, gem files, and tmp which are used between deployments
Now do you really want to clean the entire app folder? That could be dangerous since you'll lose logs.
current is just a symbolic link, it points to the latest release only.
If you want to clean up old releases, check this answer. You can set keep_releases to 1.
If you want to delete the shared folder as well, then you have to write your own Capistrano hook as #Strik3r mentioned.
before 'deploy:setup', 'removecode'
task :removecode do
run "rm -rf <path>", :shell => fetch(:rvm_shell)
end
add this code in to your deploy.rb file, this will call before deploy:setup
in this way you can create a task and do what ever you want to do
I'm having an odd and somewhat confusing problem.
I am trying to install Redmine on Heroku. I followed the instructions and well lets say it hasn't been a smooth ride.
I am now trying to do the db:migrate process. (I had to edit all the cruft in the application.rb to get this far, and don't know yet where this will lead.)
In doing the migration however, I get the message
Plugins in vendor/plugins (/app/vendor/plugins) are no longer allowed. Please, put your Redmine plugins in the `plugins` directory at the root of your Redmine directory (/app/plugins)
Through StackOverflow and some other sites, I have found where this message is generated (environment.rb) and have removed the code that generates it.
However, when I push to Heroku and try the migrate again, the same message reoccurs.
I have tried cloning the Heroku repo/app down to a test directory and when I check the environment.rb file, the code is not there, however if I try the migrate (or any rake task for that matter) the message still occurs. Even from the test directory.
I've looked for the same message in other parts of the code, but haven't found it yet. Have I missed something?
There's one of two things at play here
You're not fixing the problem in your code - running it locally in production mode will show this
OR
You're not pushing your code to Heroku correctly. Are you developing on the master branch? Are you developing in a feature branch? If so, are you pushing that branch into master on Heroku? (git push heroku feature_branch:master)
Okay I figured out what was happening. It's amazing what a good nights sleep can accomplish!
It turns out the cruft in the application.rb file that I mentioned earlier was basically the other files in the config directory appended to app.rb. These included the yml files along with other files like environment.rb and routes.rb. And in amongst this crap was the plugin panic code I had deleted from environment.rb
(It finally came to light when running rake after some changes told me that the application was already initialised!)
So I deleted all this appended nonsense from application.rb and viola! working.
I have no idea why this was done this way as redmine works fine (so far) without it.