mirror of
https://github.com/capistrano/capistrano
synced 2023-03-27 23:21:18 -04:00
Move gh-pages site to the docs/ folder
This commit is contained in:
Matt Brictson
parent
2850048c21
commit
9d62e3d7b6
101 changed files with 0 additions and 11811 deletions
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
title: How can I access stage configuration variables?
|
||||
layout: default
|
||||
---
|
||||
|
||||
Configuration variables are access with the fetch method, like so:
|
||||
|
||||
```ruby
|
||||
local = fetch(:configuration_variable, _default_value_)
|
||||
```
|
||||
|
||||
This works fine when accessing configuration variables defined within the same file. For example accessing a previously set configuration variable defined in deploy.rb or accessing a set configuration variable in a stage file.
|
||||
|
||||
The deploy.rb configuration is executed first and then the stage file(s) from config/deploy/*.rb are executed next. This means that the configuration variables set in deploy.rb are available to the stage files, but configuration variables created in a stage file are not available in deploy.rb. To access them they must be lazily loaded in deploy.rb. This works because all configuration variables (from both deploy.rb and the current stage file) have been defined by the time the tasks run and access the variables.
|
||||
|
||||
For example, let's create a configuration variable in the production and staging files and access the current one from deploy.rb.
|
||||
|
||||
config/deploy/production.rb
|
||||
|
||||
```ruby
|
||||
set :app_domain, "www.my_application.com"
|
||||
```
|
||||
|
||||
config/deploy/staging.rb
|
||||
|
||||
```ruby
|
||||
set :app_domain, "stage.application_test.com"
|
||||
```
|
||||
|
||||
These variables are not available in deploy.rb using `fetch(:nginx_port)` or `fetch(:app_domain)` because they are not defined when deploy.rb is executed. They can, however, be lazily loaded using a lambda in deploy.rb like this:
|
||||
|
||||
config/deploy.rb
|
||||
|
||||
```ruby
|
||||
set :nginx_server_name, ->{ fetch(:app_domain) }
|
||||
set :puma_bind, ->{ "unix:/tmp/#{fetch(:app_domain)}.sock" }
|
||||
```
|
||||
|
||||
Now the `:nginx_server_name` and `:puma_bind` variables will be lazily assigned the values set in which ever stage file was used to deploy.
|
||||
|
||||
If you need to create nested hashes, you might find `do/end` syntax more readable:
|
||||
|
||||
```ruby
|
||||
set :database_yml, -> do
|
||||
{
|
||||
production: {
|
||||
host: 'localhost'
|
||||
}
|
||||
}
|
||||
end
|
||||
```
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: How can I check for existing remote file?
|
||||
layout: default
|
||||
---
|
||||
|
||||
The `test` method is best used for file checking with bash conditionals
|
||||
|
||||
```ruby
|
||||
if test("[ -f /tmp/foo ]")
|
||||
# do stuff
|
||||
end
|
||||
```
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: How can I get Capistrano to prompt for a password?
|
||||
layout: default
|
||||
---
|
||||
|
||||
Password authentication can be done via `ask` in your deploy environment file (e.g.: config/environments/production.rb)
|
||||
|
||||
```ruby
|
||||
# Capistrano > 3.2.0 supports echo: false
|
||||
ask(:password, nil, echo: false)
|
||||
server 'server.domain.com', user: 'ssh_user_name', port: 22, password: fetch(:password), roles: %w{web app db}
|
||||
```
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
title: How can I set Capistrano configuration paths?
|
||||
layout: default
|
||||
---
|
||||
|
||||
Capistrano `config` and `tasks` paths can be explicitly defined, like so:
|
||||
|
||||
Capfile
|
||||
|
||||
```ruby
|
||||
# default deploy_config_path is 'config/deploy.rb'
|
||||
set :deploy_config_path, 'cap/deploy.rb'
|
||||
# default stage_config_path is 'config/deploy'
|
||||
set :stage_config_path, 'cap/stages'
|
||||
|
||||
# previous variables MUST be set before 'capistrano/setup'
|
||||
require 'capistrano/setup'
|
||||
|
||||
# default tasks path is `lib/capistrano/tasks/*.rake`
|
||||
# (note that you can also change the file extensions)
|
||||
Dir.glob('cap/tasks/*.rb').each { |r| import r }
|
||||
```
|
||||
|
||||
Here is the corresponding capistrano configuration structure:
|
||||
|
||||
```bash
|
||||
├── Capfile
|
||||
└── cap
|
||||
├── stages
|
||||
│ ├── production.rb
|
||||
│ └── staging.rb
|
||||
├── tasks
|
||||
│ └── custom_tasks.rb
|
||||
└── deploy.rb
|
||||
```
|
||||
|
||||
<div class="alert-box alert">
|
||||
Be aware that you will have to provide an absolute path, if you want your "deploy_config_path" to be "capistrano/deploy.rb".
|
||||
See <a href="https://github.com/capistrano/capistrano/issues/1519#issuecomment-152357282">this issue</a> for more explanations and how to get an absolute path in Ruby.
|
||||
</div>
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
---
|
||||
title: Why does something work in my SSH session, but not in Capistrano?
|
||||
layout: default
|
||||
---
|
||||
|
||||
This is possibly one of the most complicated support questions that can be
|
||||
asked, the only real answer is ***it depends***.
|
||||
|
||||
It's really a question of which *kind* of shell Capistrano is using, it's a
|
||||
matrix of possibilities concerning `login`, `non-login`, `interactive`, or
|
||||
`non-interactive`.
|
||||
|
||||
**By default Capistrano always assigns a `non-login`, `non-interactive` shell.**
|
||||
|
||||
## Shell Modes
|
||||
|
||||
Unix shells can be started in one of three modes, an unnamed *basic* mode,
|
||||
which almost never happens, as a `login` shell, or as an `interactive` shell.
|
||||
|
||||
Depending which mode a shell starts in (and which shell you are using) this
|
||||
will affect which startup (more commonly known as *dot*-files) files, if any
|
||||
are loaded, [here's](#which_startup_files_loaded) more or less the matrix of what is loaded when.
|
||||
|
||||
## What about the Capistrano option to assign a `pty`?
|
||||
|
||||
This option has been hugely misleadingly used, if you ask SSH to provide a
|
||||
`pty` you are effectively telling SSH that *"I'll connect this session to a
|
||||
user terminal"*, thus programs on the receiving end expect that they can prompt
|
||||
for input, and provide coloured output, etc. In short they think they're
|
||||
talking to you over an interactive session, because by assigning a `pty`, Bash
|
||||
has been started in `non-login`, `interactive` mode.
|
||||
|
||||
Read more about this:
|
||||
|
||||
* [In the "Bash Startup Files" section of the Bash
|
||||
manual](https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html)
|
||||
* [At Sam Stephenson's excellent *Unix shell initialization* wiki
|
||||
page](https://github.com/sstephenson/rbenv/wiki/Unix-shell-initialization)
|
||||
* [Interactive and non-interactive shells and scripts
|
||||
documentation](http://www.tldp.org/LDP/abs/html/intandnonint.html)
|
||||
|
||||
## How does what Capistrano does differ from an SSH session
|
||||
|
||||
By default Capistrano prefers to start a *non-login, non-interactive
|
||||
shell*, to try and isolate the environment and make sure that things work as
|
||||
expected, regardless of any changes that might happen on the server side.
|
||||
|
||||
In contrast when you log into a machine with your terminal, into a regular
|
||||
Bash session, the `--login` option to Bash is implied granting you a `login`
|
||||
shell, and because you are in a terminal, ssh asks the ssh server to provide a
|
||||
pty so that you may start an interactive session. Thus you get an `interactive
|
||||
login` shell, the exact opposite of what we need for Capistrano!
|
||||
|
||||
## How can I check?
|
||||
|
||||
I actually had to look this up, most of the time it's common sense, but
|
||||
[stackoverflow to the rescue](http://unix.stackexchange.com/a/26782), let's
|
||||
figure this out!
|
||||
|
||||
First, we'll try a *real* SSH session, logging in via our terminal, and seeing
|
||||
what happens:
|
||||
|
||||
```bash
|
||||
me@localhost $ ssh me@remote
|
||||
me@remote $ [[ $- == *i* ]] && echo 'Interactive' || echo 'Not interactive'
|
||||
Interactive
|
||||
me@remote $ shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'
|
||||
Login shell
|
||||
```
|
||||
|
||||
Contrast that with what happens when we hand the command to run to the SSH
|
||||
command line without logging in first...
|
||||
|
||||
```bash
|
||||
me@localhost $ ssh me@remote "[[ $- == *i* ]] && echo 'Interactive' || echo 'Not interactive'"
|
||||
Interactive
|
||||
me@localhost $ ssh me@remote "shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'"
|
||||
Not login shell
|
||||
```
|
||||
|
||||
Here we can see that Bash is still starting in **interactive** mode when we're
|
||||
just running a single command, that's because the terminal we are using is
|
||||
interactive, and SSH inherits that and passes that on to the remote server.
|
||||
|
||||
When we try the same with Capistrano we'll see yet another set of results; we
|
||||
can have a very simple, Capfile, we don't even need to load the default
|
||||
recipes to test this:
|
||||
|
||||
```ruby
|
||||
# Capistrano 3
|
||||
task :query_interactive do
|
||||
on 'me@remote' do
|
||||
info capture("[[ $- == *i* ]] && echo 'Interactive' || echo 'Not interactive'")
|
||||
end
|
||||
end
|
||||
task :query_login do
|
||||
on 'me@remote' do
|
||||
info capture("shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'")
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
Gives us the following:
|
||||
|
||||
```bash
|
||||
me@localhost $ cap query_login
|
||||
INFO Not login shell
|
||||
me@localhost $ cap query_interactive
|
||||
INFO Not interactive
|
||||
```
|
||||
|
||||
## <a id="which_startup_files_loaded"></a>Which shell startup files do get loaded?
|
||||
|
||||
Best explained with this diagram, yes it's that complicated:
|
||||
|
||||
<figure class="panel">
|
||||
<img src="/images/BashStartupFiles1.png" title="Bash Startup Files" alt="Bash Startup Files" />
|
||||
<figcaption>
|
||||
<p>Source: <a href="http://www.solipsys.co.uk/new/BashInitialisationFiles.html">http://www.solipsys.co.uk/new/BashInitialisationFiles.html</a></p>
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue