This course will be retired on June 1, 2025.
Heads up! To view this whole video, sign in with your Courses Plus account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Setting up your database is something that's unique to your app. It's not practical for Capistrano to do for you by default. You need to provide a task to create the database. If we were doing it manually, we'd change into the app directory and running "rails db:setup" in the "production" environment. We need to create a Capistrano task to do the same thing.
Add the following code to lib/capistrano/tasks/deploy_initial.rake:
namespace :deploy do
desc "Performs first deploy to a server"
task :initial do
before "deploy:migrate", "deploy:create_db"
invoke "deploy"
end
desc "Runs rails db:setup"
task :create_db do
on roles(:db) do
within release_path do
with rails_env: fetch(:rails_env) do
execute :rails, "db:setup"
end
end
end
end
end
The task can then be run with bundle exec cap production deploy:initial.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
In the last video we set up
Capistrano to deploy our RailsApp
0:00
at our production server.
0:03
But unfortunately,
0:05
it's failing with the error database
"guestbook_production" does not exist.
0:06
Just as there are many
different RailsApps,
0:10
there are many different database setups,
each one a little bit different.
0:12
So setting up your database is
something that's unique to your app,
0:15
some early practical for
Capistrano to do it for you by default.
0:19
So we're going to need to provide
our own test to create the database.
0:23
What we need to do is on the remote server
we need to change into the app directory
0:26
and run the rails task db:setup.
0:31
So we're going to create
a Capistrano Task to do this for us.
0:33
There's one more file that the cap
install command created for us.
0:37
It's a sub directory here in the lib
directory for our app called Capistrano.
0:42
And then there's another
subdirectory called tasks.
0:48
Here we an create files that describe
tasks that Capistrano can carry out for
0:51
us on remote servers.
0:55
So I'm going to create a new file
within this tasks subdirectory, and
0:57
I'm going to call it deploy_initial.rake.
1:01
Notice that it's important it
end in .rake and not .rb, or
1:06
Capistrano won't detect it.
1:10
The reason it uses a .rake extension
is because Capistrano is an extension
1:13
of the domain specific language for
rake, which standards for Ruby make.
1:18
Rake is an older library that's used to
build and deploy other Ruby applications.
1:23
So Capistrano tasks get defined in
files with the same extension, .rake.
1:28
So create that file, and
we want to be able to
1:34
run this task from the command line
with a name of deploy:initial.
1:37
So, first thing I'm going to do
is run the namespace method.
1:41
And I'm going to create
a namespace named deploy.
1:47
Many other tasks also exist
within the deploy namespace.
1:52
So this task will just
get added to that group.
1:55
Namespace method takes a block, and
every task that we define within that
1:58
block will get added to
the deploy namespace.
2:03
Now to create our actual task.
2:06
I'm gonna start with a description for
that task, by calling the desc method, and
2:07
the description method takes a string,
which I'm going to say "Runs rails
2:12
db:setup".
2:18
Following your call to description,
2:22
you call the task method
to define the actual task.
2:24
It takes a symbol with the name
of the task you're gonna create.
2:28
And I'm going to name this task create_db.
2:31
The need provided lock to the task method
with the actual statements that will get
2:37
run when it's executing the task.
2:41
I want to execute a command
on the remote server, so
2:44
I'm going to call the execute method.
2:46
This is provided by Capistrano, and
the first argument to execute should be
2:48
a symbol with the name of
the command you want to run.
2:52
We want to run the rails command so
I'm going to say symbol, rails.
2:55
Then you can provide a string
with any arguments that you wanna
2:59
pass to that command.
3:02
So I'm going to have it
run the task db:setup.
3:03
Basically this task as I've defined it
will be the equivalent of connecting to
3:09
the remote server via SSH and
running rails db:setup.
3:13
So I'll go then save that.
3:18
And if we go back to the terminal I can
get a list of all the tasks that have been
3:19
defined for this app.
3:24
I'm running bundle exec cap and
3:26
passing at the -T flag,
to get a list of all the tasks.
3:29
And if we scroll up the list, we can see.
3:36
Our new create_db task here
in the deploy namespace, and
3:42
there is the description we provided for
it, Runs rails db:setup.
3:45
So let's try running this new task now.
3:51
I'm gonna run bundle exec cap.
3:52
Specify the stage which is production.
3:57
And then I'll specify the deploy namespace
and the name of our task create_db.
4:01
But if I try running it we get an error.
4:06
It says that any call to the execute
method should be wrapped in an on scope,
4:10
and it gives an example
of what it's looking for.
4:14
So here within our task that we've
defined, we need to say on roles and
4:17
whatever server roles
we need this to run on.
4:21
Provide a block, and
then we can call our execute command.
4:24
There's a reason it wants
us to specify a role.
4:27
If we ever split our app up to run on
separate app and database servers,
4:30
we only want this task to
run on the database server.
4:34
So we need to go in and specify that
this should run on the db role.
4:36
I'm gonna go back to our editor.
4:40
And here within our task block I'm going
to say that this should only run on
4:44
the roles, and
this will actually be a single role, db.
4:48
The symbol db.
4:52
Then I need to provide a block,
and the statements
4:56
within that block will only run on
servers that match that particular role.
5:02
So let's save that.
5:07
Go back to our shell and
try running the deployment command again.
5:08
It fails again.
5:13
This time saying it could not locate
the Gemfile or bundle directory.
5:14
And the reason it can't find the Gemfile
is because it hasn't changed into the app
5:19
directory prior to trying
to run the bundle command.
5:22
So, to fix this, we're gonna go
back into our task in the editor.
5:26
And surrounding the call the execute,
we're going to call the within method.
5:30
Within takes an argument,
5:34
the string representing the path
that you want it run within.
5:36
So, we're going to call
the release_path method here, which
5:39
is a Capistrano method representing the
directory that we're releasing our app to.
5:46
Within takes a block and everything within
that block our execute command here,
5:52
will be executed within
the directory we specified.
5:57
So the net effect here is that we'll
change into the release path and
6:01
then execute this command.
6:05
That should fix the error we were seeing.
6:06
Okay so let's save this and
try running our deployment command again.
6:09
This time it fails with another error.
6:14
It says directory does not exist.
6:16
Home deploy guest book current.
6:18
The problem is that we set our task up
to run within the release path, but
6:21
the release path doesn't exist at
the time that our task is running.
6:25
What we really need is to run this
task after the app is cloned but
6:29
before the deploy migrate task runs.
6:32
A normal Capistrano deployment actually
consists of a bunch of sub-tasks
6:35
that run one after the other.
6:40
There's a task that runs when
the deployment is just starting.
6:41
There's another that runs while
the app code is being updated, yet
6:45
another that runs while the app
is being published, and
6:48
a couple more tasks that run as
the deployment is finishing.
6:52
If you run bundle exec cap -T, capital T,
6:56
to get a list of the tasks,
you can find still other hooks.
7:00
These are tasks that kicked off during
various parts of the deployment,
7:08
including the migrate and
7:12
migrating tasks which happen when
the database is being migrated.
7:14
So we're going to set up a deploy initial
task that sets the deploy create db
7:19
task to run before
the deploy migrate task.
7:24
And then i'll kick off
a normal deployment.
7:27
So here within the deploy namespace,
we're gonna create another task.
7:30
We'll add a description for it first.
7:34
This task is going to perform
our first deploy to a server.
7:37
And since it's our first deploy,
we're going to know that we need to create
7:41
the database, which is why we'll
be kicking off the create_db task.
7:45
So performs first deploy to a server.
7:49
Now for the actual task.
7:57
Would call it deploy initial.
8:00
Task method takes a block with the actual
statements that should be run when it's
8:05
kick off.
8:09
And we can use a Capistrano
method called before
8:10
to set up one task to be
run before another one is.
8:13
So before we run the deploy migrate task,
8:17
we're going to wanna kick off
the deploy create db task.
8:22
And now that we've set create_db
to be run before deploy migrate,
8:28
we can safely invoke another task.
8:32
The same deploy task that we've
been running from the command line.
8:36
So let's go back to the command line and
try kicking that task off.
8:40
Bundle exec cap production deploy:initial
8:44
It runs,
checks out the app from get as usual.
8:57
Sets up the directories it needs.
9:02
Runs bundler install,
9:04
which is faster this time since all
the dependent gems are already installed.
9:05
Compiles assets like CSS and JavaScript.
9:10
And that's called by pretty quick but
9:14
it actually invoked our create_db
task here at the bottom.
9:16
Unfortunately while running it,
we got an error.
9:22
We see, Peer authentication failed for
user "jay".
9:25
Well that's strange because it's supposed
to be running as the deploy user,
9:28
that's what has access to our database.
9:32
Here on the next line it says,
Couldn't create database.
9:34
And if we go and look at our database
configuration within our Rails app,
9:38
we'll have a guess as
to what the problem is.
9:42
In the production environment, we
are configured to use the deploy username.
9:44
But up here in development,
9:49
we're set up to use the username jay,
our developer username.
9:51
The problem is we haven't specified
a Rails environment to run our command in
9:54
and so it's running in the development
environment by default and therefore using
9:58
the wrong username and trying to
connect to the wrong database name.
10:02
So we need to set the Rails ENV
environment variable while running
10:07
this command.
10:11
We can do that using
the Capistrano with method.
10:13
With takes a hash with its keys as
the names of environment variables.
10:17
So we're going to specify that
the rails_env environment variable,
10:23
should be set to whatever the value of the
rails_env Capistrano variable is set to.
10:27
We retrieve that using the fetch method.
10:33
And we specify that it should fetch
the rails_env Capistrano variable.
10:38
So that'll set the rails_env
environment variable properly.
10:42
With takes a block, any commands
that you want to execute with those
10:46
environment variables active
should be placed inside it.
10:51
So that's where we place our
execute :rails, "db:setup" command.
10:54
So now for
deploying to a staging environment,
10:59
rails environment will be set staging
it for deploying to production,
11:01
the rails environment
will be set production.
11:05
So let's save this.
11:08
Go back to our console, and
give this command another try.
11:10
cap production deploy initial.
11:16
It will go through the same
steps as before and
11:24
this time when it gets to the create
db_task it runs successfully.
11:27
After the create db task runs
it then runs the migrations and
11:32
then completes the remainder
of the deployment.
11:37
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up