Fabric: Adicionar contexto de tunelamento ao Fab

Criado em 19 ago. 2011 · 13Comentários · Fonte: fabric/fabric

Descrição

Isso seria muito útil para mim porque tornaria muito fácil
para, por exemplo, conectar-se a um servidor MySQL remoto usando minha linha de comando
Cliente MySQL.

Poderíamos usar uma declaração de contexto "com", algo como:

with tunnel(local=3307, remote=3306):
    local('mysql --port=3007 --host=localhost' mydb < db/dbdump.sql')

Isso eliminaria a necessidade de fazer upload do arquivo de despejo mysql para o servidor
apenas para poder executar a importação.

Outra aplicação poderia ser a administração de servidores web Cherokee.

O administrador da web Cherokee por padrão só é acessível a partir do servidor que
está em execução. Então você quer acessar o administrador que você precisa encapsular
no servidor e acesse a interface de administração usando uma porta local.
Isso também pode ser simplificado com essa funcionalidade.

with tunnel(local=9090, remote=9090):
   sudo('cherokee-admin')
   prompt('Stop cherokee admin?')

Essa última linha manteria o túnel aberto até que fosse fechado, fornecendo entrada.

Originalmente enviado por Taras Mankovski (tarasm) em 2009-11-02 às 09:30 EST

Relações

Relacionado ao nº 38: Implementar tunelamento

Feature Network

Fonte

bitprophet

Comentários muito úteis

939 ainda está em um bucket de lançamento, acabei de retirá-lo do próximo 1.11 porque precisava cortar _algumas_ coisas, mas terá prioridade para o próximo ciclo de recursos. (E parece que o nº 1218 substitui o nº 939, então provavelmente vou acabar mesclando isso e creditando o nº 939 no changelog.)

bitprophet em 9 abr. 2016

👍3

Todos 13 comentários

Jeff Forcier ( bitprophet ) postou:

(descrição modificada para que os blocos de código fossem recuados :))

em 2009-11-02 às 09h35 EST

bitprophet em 19 ago. 2011

Seria incrível se o túnel também suportasse o contrário. Significa ouvir no remoto e encaminhá-lo para localhost/outro host:port disponível localmente.

munhitsu em 9 jan. 2012

@munhitsu Não tenho certeza de como isso é um caso de uso para o Fabric especificamente. Você pode elaborar?

bitprophet em 11 jan. 2012

Imagine uma configuração DMZ que não tenha um acesso http/proxy de saída.
Toda a implantação passa pela malha.

Nesse caso, poderíamos usar a malha para encapsular o proxy local por meio do ssh, para ficar temporariamente acessível para o host que está sendo provisionado na DMZ. No momento, estou abrindo um túnel ssh separado no segundo console, para que o tecido funcione dentro do "contexto" desse túnel.

exemplo de uso:

with rev_tunnel(local=8080, remote=8080):
    sudo("http_proxy='http://localhost:8080' apt-get install -y puppet")

munhitsu em 11 jan. 2012

OK, então é uma configuração de túnel reverso bastante padrão, afinal, eu acho, e seu desejo é: Fabric é que ele lide com o túnel versus você ter que executar, por exemplo local(ssh -R ...) .

Eu discuti se isso realmente vale a pena entrar no núcleo, mas realmente faria muito sentido se ele fosse suportado no Fabric propriamente dito; as outras soluções são hacky (por exemplo, algum thread ou subprocesso executando ssh - como fazer isso bem, certifique-se de desligar quando Fab fizer isso, etc) e eu vejo a validade do caso de uso (compartilhando local recursos com a extremidade remota durante a execução.)

O principal obstáculo é que não tenho certeza se a biblioteca SSH suporta isso ainda; nós teremos que descobrir isso e alguém teria que implementá-lo se isso não acontecer. (Acho que seria uma boa adição à referida biblioteca, no entanto, em vez de solidificar a solução alternativa ssh -R acima mencionada.)

EDIT: # 38 discute implementação e correção e tal. Pode ser melhor fechar isso e simplesmente observar que, quando implementado, deve ser possível acionar com um gerenciador de contexto, se possível.

bitprophet em 11 jan. 2012

Concordo plenamente que implementá-lo para que entremos, saiamos de contextos ou, pior ainda, vários níveis de contextos é complicado.

Em relação ao EDIT: Qualquer coisa que nos mantenha mais perto de ter essa funcionalidade é uma boa ideia.

munhitsu em 17 jan. 2012

Por enquanto, deixarei isso em aberto, apenas para manter as coisas granulares. Atribuído a 1.4 para não esquecer, no entanto. As chances são de que eu tente nocautear isso enquanto estou fazendo o #38. Será atualizado aqui quando estiver no master, obrigado.

bitprophet em 18 jan. 2012

Na verdade, isso não está tão relacionado ao nº 38 quanto eu pensava, pois suas alterações são apenas sobre o gateway do próprio tráfego SSH, não encapsulando portas adicionais através da conexão SSH. Isso exigirá uma solução diferente (ou pelo menos adicional). Punting por agora, desculpe :) (Significado: ainda aberto, só não vai chegar em 1.5.)

bitprophet em 5 nov. 2012

Recentemente, precisei dessa funcionalidade para sincronizar com um servidor rsync remoto cuja porta não pode ser acessada diretamente e descobri que o código de demonstração forward.py do paramiko tem um código de exemplo que eu poderia usar, então criei uma solução que funcionou bem para mim e enviou como um patch para forward.py aqui: https://github.com/paramiko/paramiko/pull/504/

Poderíamos adicionar ForwardServer desse patch e ter um local_tunnel() que simplesmente retorna uma instância de ForwardServer . Conforme recomendação do @bitprophet no pull request, trabalharei em um patch para o Fabric.

haridsv em 7 abr. 2015

Eu realmente não percebi, mas já existe um patch para local_tunnel() , embora eu não tenha certeza sobre seu status. O que devo fazer?

haridsv em 7 abr. 2015

@haridsv Se você puder, testá-lo e mencionar que você o usou com sucesso, nesse patch (# 939), ajudaria, caso contrário, tenha paciência :) obrigado!

bitprophet em 4 mai. 2015

Existe algum plano para resolver este problema? Existem duas solicitações de pull pendentes que juntas resolvem isso, mas elas não foram analisadas? Alguma maneira de acelerarmos isso?