Начиная с Fabric v1.5+, существует метод remote_tunnel
для решения ситуации с клюквой.
Я использовал простую команду (имя хоста), чтобы проиллюстрировать решение, но вместо нее можно использовать любую другую команду. Как видите, мы вызвали команду для выполнения на remote_machineB с local_machine, используя remote_machineA в качестве узла перехода:
from fabric.api import settings, env, run, remote_tunnel
env.hosts=["user@remote_machineA"]
def funct1():
def func1b(host):
with settings(host_string=host):
run("hostname")
with remote_tunnel(remote_port=22022, local_port=22,
local_host="remote_machineB", remote_bind_address="0.0.0.0"):
funct1b("user@remote_machineA:22022")
Если вы запустите этот потрясающий файл в local_machine, вот что мы получим:
[user@local_machine ~]# fab hostname_check
[user@remote_machineA] Executing task 'hostname_check'
[user@remote_machineA:22022] run: hostname
[user@remote_machineA:22022] rtunnel: opened reverse tunnel: (u'X.X.3.75', 55804) -> ('X.X.3.78', 22) -> ('remote_machineB', 22)
[user@remote_machineA:22022] out: remote_machineB
[user@remote_machineA:22022] out:
Terminated
Для этого очень важно настроить этот демон ssh машины перехода с GatewayPorts yes
. В противном случае удаленный туннель был бы доступен только с локального хоста.
Проверять:
tcp 0 0 127.0.0.1:22022 0.0.0.0:* LISTEN
против:
tcp 0 0 0.0.0.0:22022 0.0.0.0:* LISTEN
Для получения дополнительной информации см. официальную документацию http://docs.fabfile.org/en/latest/api/core/context_managers.html#fabric.context_managers.remote_tunnel
person
Fernando Martin
schedule
17.12.2014