Fabric: 선택적으로 localhost로 이동하는 경우 ssh 사용을 피하십시오.

James Pearson (xiong.chiamiov) 게시:

irc에서도 언급했듯이 저는 일반적으로 데스크톱 컴퓨터에서 ssh 서버를 실행하지 않으므로 실제로 localhost에 ssh할 수 없습니다.

2009-11-11에 동부 표준시 오후 3시 13분에서

Travis Swicegood ( tswicegood ) 게시:

오늘 저녁에 do 라는 새로운 fabric.operations 함수의 형태로 비슷한 것을 구현했습니다. env.run_as 를 보고 "local"과 같은지 확인하고 run (또는 sudo 대신 local 메서드로 전환합니다. sudo=True 가 kwarg로 전달되는 경우). 또한 로컬 명령이 로컬에서 실행 중인 경우 sudo 접두사로 로컬 명령을 처리합니다.

이것은 run 또는 sudo 의 동작을 변경하지 않고 작동하는 이 문제를 해결하는 일종의 다른 방법입니다. 이러한 변경 사항은 내 저장소 에서 사용할 수 있습니다.

2010-01-11 12:22am 동부 표준시

모건 구스 ( goosemo ) 게시:

나는 이것이 그럴듯하다고 보지 않는다. 로컬로 실행하는 것이 요점입니다. Fabric의 요구 사항 중 하나는 시스템, 원격 또는 루프백에서 실행되는 sshd입니다. 다른 문제는 로컬 변경만 ssh가 필요한 put, get, rsync_project 및 기타 항목을 고려하지 않는다는 것입니다. 그것들을 구현하려고 하면 지금은 fabfile을 bash로 변환하는 영역에 있기 때문에 더 많은 문제를 일으킬 것입니다.

2011년 3 월 오후 11시 14분(동부 표준시)

Jeff Forcier ( bitprophet ) 게시:

나는 이것이 훌륭한 아이디어라고 100% 확신하지는 않지만 많은 사용자가 필요하다고 느끼는 것이 분명합니다. 사용 사례에 대한 다른 설명과 함께 또 다른 요청이 #364로 제출되었습니다.

나는 또한 이것과 관련하여 테스트 실행 티켓을 추가했습니다. 왜냐하면 (요청한 사용자 중 누군가가 이것을 확인할 수 있다면 훌륭할 것이라고 가정합니다) 이 기능의 주요 사용 사례는 테스트/드라이-이기 때문입니다. 달리기.

2011-06-23 11:26am EDT

#538에서 언급했듯이 세 개의 러너를 완전히 정규화하여 서로 바꿔 사용할 수 있게 된다면 쉘 이스케이프가 일관되게 작동하는지 확인해야 합니다. 지금 우리는 쉘 이스케이프 local 하지 않습니다. 하지만 이는 적어도 부분적으로는 쉘 래퍼를 사용하지 않기 때문입니다.

"누군가가 왜 이것을 할까?"라고 궁금해하는 사람이 있다면 대답은 배포 파이프라인이 있는 경우 localhost에 대한 특별한 설정 스크립트를 사용하는 것보다 어떤 환경이든 정확히 동일한 배포 스크립트를 실행하는 것이 도움이 될 수 있다는 것입니다. 대 다른 모든 것.

기능에 대해 +1

+1

+10

+1

+1

당신을 막으려면 OpenSSH 서버가 실행 중인지 확인하면 됩니다. 먼저 sudo apt-get install ssh 를 수행하여 설치되었는지 확인하십시오(그렇다고 생각하더라도). 그런 다음 sudo service ssh start | stop | restart 필요에 따라. 이 스레드에서 배웠습니다 .

+1

내 사용 사례는 간단합니다. 동일한 django-deploy 스크립트를 사용하여 CloudWatch를 통한 cloud-init (로컬 명령 실행의 경우) 및 일반 fab deploy_django -H foo@bar 사용 모두에서 ec2 인스턴스를 구성하고 싶습니다.

+1

이것은 정말 유용할 것입니다. 내가 가지고 있는 한 가지 사용 사례는 방랑자 쉘 프로비저닝 도구를 사용하여 localhost를 ssh할 필요 없이 패브릭을 사용하여 특정 VM을 구성하는 것입니다.

+1

Fabric에서 이미 이것을 보지 못했다는 사실에 놀랐습니다.

참고: reboot() 와 같은 패브릭 기능을 생각하면 이 기능의 구현이 더 복잡해집니다.

+1

이미 핵심의 일부여야 합니다!

+1

추상적인 관점에서 볼 때 local 는 SSH 기계가 관련되지 않은 run 의 특별한 경우일 뿐입니다.

한 가지 더 지적해야 할 사항(명백할 수 있음): Fabric은 /etc/hosts를 읽은 후 run 를 local 로 변환해야 하는지 여부를 결정할 만큼 충분히 똑똑해야 합니다.

내 말은: 만약 우리가 가지고 있다면

env.host = [ 'mywebserver' ]

/etc/hosts에는 다음이 있습니다.

127.0.0.1 mywebserver

그러면 모든 run 호출은 실제로 local 호출이어야 합니다.

이 개념을 한 단계 더 나아가 원격 호스트가 로컬 머신의 네트워크 인터페이스에 할당된 IP로 확인될 때 run 를 로컬 호출로 취급해야 합니다.
예:
팹 파일:

env.host = [ 'mywebserver' ]

/etc/hosts:

192.168.1.1 mywebserver

ip addr :

[...]
eth0:
  inet 192.168.1.1
[...]

+1

+1:+1:

:+1:

+1

+1

Fabric 2는 pyinvoke/invoke를 사용하므로 매우 쉽게 수행할 수 있습니다. 나는 이것을 할 수 있는 비핵심적인 방법을 위해 Fabric 2를 기다릴 것입니다.

:+1:

+1

:+1:

:+1: 특히 mac 컴퓨터가 로컬 호스트 서버에 대한 원격 액세스를 위해 구성된 SSH 터널을 갖도록 자동으로 설정되지 않으므로 이것을 구현하십시오.

+1

+1 :)

+1 부탁드립니다

:+1:

:+1:

:+1:

우리는 Fab를 사용하여 데비안 패키지를 빌드하고 있으며 이는 추가 복잡성을 추가합니다.

여러분, 안녕하세요.
나는 차이가있는 패브릭 클론을 만들려고합니다.

• run() 함수는 ssh에서 원격 호스트에 연결하는 것과 같이 localhost에서 subprocess.popen과 동일한 방식으로 작동합니다.
• 공장은 openssh 또는 다른 ssh 클라이언트를 사용하므로(이를 위해 구성을 수정해야 함) ssh 소켓의 모든 기능을 사용할 수 있습니다.
• 공장은 비동기 실행을 위해 gevent 라이브러리를 사용합니다.

이 기능이 필요한 경우 살펴볼 수 있습니다.
https://github.com/Friz-zy/factory

이 토론에서 누락된 것이 있을 수 있지만 다음은 localhost 및 원격 시스템 모두에서 fab run 명령과 동일한 코드를 사용하기 위해 수행한 작업입니다.

1. 내 fabfile.py에 env.use_ssh_config = True 를 설정했습니다.
2. ssh 복사 ID 로컬 호스트

로컬 컴퓨터에서 ssh 서버를 실행하지 않는 경우 문제가 해결되지 않습니다.

:+1:

+1

+1 이 기능을 구현하세요 :)

+1

기존 Fabric 스크립트를 사용하여 Docker 이미지를 부트스트랩하는 데 매우 유용할 수 있습니다. 이 기능은 Docker 모범 사례 에 위배되는 컨테이너에 SSH 서버를 설치하는 것을 방지합니다.

+1

+1

+1

@AntoniosHadji가 제공한 답변에 추가하여 다음은 이 작업을 수행하기 위한 전체 지침입니다.

# Generate new SSH key for local usage
ssh-keygen -f ~/.ssh/id_rsa -N ''

# Add server keys to users known hosts (eliminates 'are you sure' messages);
ssh-keyscan -H localhost > ~/.ssh/known_hosts

# Allow user to ssh to itself
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

실제로 이것은 요리를 사용하여 수행할 수 있습니다. 가져오기로 쉽게 수행할 수 있는 cuisine.run 함수를 참조하도록 모든 run 실행을 변경하고 모드를 로컬로 변경해야 합니다.

from cuisine import run, mode_local

mode_local()
print run("echo Hello")

@cgarciaarano

간단한 사용 사례의 경우 다음과 같이 작동합니다.

from fabric.api import run, local
# ...
# in task:
  if env.host is None or env.host == 'localhost':
    run = local

:+1:

ssh가 옵션이 아닐 때 fabfile을 원격 또는 로컬로 실행하고 싶습니다. 여기에는 get/put/exists 등에 대한 로컬 래퍼가 포함됩니다.

:+1: 로컬 및 원격 모두에서 실행되는 fabfile이 있으며 출력 캡처 및 오류 처리와 같은 모든 미묘한 차이점을 처리하기 위해 run/local/get에 대한 자체 래퍼 기능을 해킹하게 되었습니다.

포트 2223에서 127.0.0.2(여전히 기술적으로는 localhost)에서 동적 포트 전달 및 바인딩을 수행하는 ssh 연결이 있는 경우에는 어떻게 될까요? 전체 127.0.0.0/8 클래스를 지원하는 것은 처리하는 것이 좋습니다.

@blade2005 예, 전체 127._._.* 범위는 localhost(127.0.0.0 및 127.255.255.255 제외)를 가리키지만 실제로 localhost를 가리킬 때 포트를 사용하지 않습니까?
따라서 127.*.*.* == localhost 및 ssh는 피할 수 있지만 127.*.*.*:* 는 포워딩된 포트를 가리키고 ssh가 필요하다고 안전하게 가정할 수 있다고 믿습니다.

솔직히, 이 기능은 요리 라이브러리와 유사하게 패브릭을 기반으로 구축된 타사 플러그인으로 더 이해가 될 것입니다. 그런 다음 env 변수를 기반으로 로컬 또는 원격 실행 여부를 알 수 있는 run/get/put/etc에 대한 래핑된 함수를 가져오기만 하면 됩니다. 적어도 이런 식으로 누군가가 이것을 모든 사람이 사용할 수 있도록 시작할 수 있습니다.

나는 로컬에서 뭔가를 구현했고 로컬/런 간에 전환하는 것보다 훨씬 더 많은 작업을 수행했습니다. 접두사, 변경된 디렉토리, sudo 사용자 등을 고려해야 합니다.

다른 2.0 관련 티켓의 맥락에서 이에 대해 간단히 생각하고 " run 가 local 의 리바인딩이 됩니다 " 외에 더 많은 것이 있음을 깨달았습니다.

• local 및 run 또는 put / get 중 하나를 사용하는 모든 종류의 진정한 혼합 모드 작업은 본질적으로 문제가 됩니다. 'local' 및 'remote' "ends"는 이제 둘 다 로컬을 가리킵니다.
  
  
  
  • 나는 그것을 소수의 유스 케이스라고 가정하고(만약 그것이 하나인 경우) "어떤 작업을 호출하지만 run 또는 sudo 가 DoesntMakeAnySenseError 발생시키는 경우에도 여전히 파악해야 합니다.
  
  
  • put / get 는 아마도 shutil.copy 또는 이와 유사한 것으로 바뀔 수 있습니다.
  
  
  • local 는 아마도 변경되지 않을 것입니다(비록 무슨 일이 일어나고 있는지 인쇄할 때 run-except-locally 접두어가 붙은 것과 구별되기를 여전히 원할 것입니다...?)
  
  
  • 위에서 언급했듯이 prefix , cd 등과 같은 다양한 컨텍스트 조작 방법/컨텍스트 관리자는 모두 비슷한 질문에 대한 답변이 필요합니다.
  
  
• 그것은 제쳐두고, 로컬에서 sudo 명령을 실행하는 것은 잠재적으로 엄청난 발판이며 아마도 추가 안전 검사를 원할 것입니다.
  
  
  
  • 그것이 또 다른 가능성인 local 또 다른 바인딩이 되지 않는 한. 크지는 않지만 로컬에서 작동하는 모든 sudo 명령(예: Linux에 배포하고 Linux에서 배포)은 아마도 로컬에서 권한을 유지해야 할 것입니다(예: apt / yum 및 친구, 방화벽 땜질 등).
  
  
• sudo 또한 (Jon이 위에서 언급한 것처럼) sudo 사용자, 암호 등이 양측에서 다를 수 있으므로 고유한 로컬 대 원격 구성 벡터를 구성할 가능성을 높여야 합니다.
  
  
  
  • Fab 2의 맥락에서 이 모든 것을 생각하고 있기 때문에 예상되는 호스트별 구성 재정의는 최소한 그 부분을 해결할 것입니다. localhost 컨텍스트는 단순히 적절한 값을 전달받을 것입니다. (게다가 "로컬에서 원격 작업을 실행하기 위한" 전용 Context 하위 클래스로서 필요한 경우 다른 작업도 수행할 수 있습니다.)
  
  

보장 이외의 나는 아직이 특정 티켓의 사용 사례에 못했다 - @ 최대-아놀드 때문에이 시점에서 예상 할 수있다 혼란 문제로 V2 알파와 달렸다에서이 밖으로 시도했다 run 및 local 에는 가능한 유사한 API가 있습니다.

현재 가장 큰 문제는 작업 컨텍스트( c 또는 ctx 또는 이름이 무엇이든 간에) posarg에 바인딩된 개체의 특성과 API입니다. 현재, 그리고 다시 말하지만, 이것은 최종적인 것이 아니라 지금까지의 결과일 뿐입니다.

• 기본적으로 Invoke의 Executor 의해 실행되거나 호스트가 없을 때 Fab 2의 FabExecutor 되면 invoke.Context 이며 로컬에서 실행되는 run , local .
• Fab 2에 실행할 호스트가 있으면 fabric.Connection 되고, run 는 원격으로 실행되고 local 는 Invoke의 run 리바인딩입니다

여기와 연결된 티켓에서 사용 사례를 살펴보는 것을 포함하여 보다 구체적인 생각이 필요합니다. 직접 브레인스토밍:

• 이에 대한 유용한 솔루션(또는 _least_ 설명서)은 다음과 같은 이유로 코어에 거의 확실히 존재해야 합니다(코어 외부에 있는 이전 대화에 따라).
  
  
  
  • 충분히 일반적인 사용 사례입니다
  
  
  • 망하기 쉽습니다
  
  
  • patchwork (née contrib ) 및/또는 invocations (동일한 버전)의 v2 호환 버전을 유용하게 구현하는 데 필요합니다. 특히 얼마나 많은 코드를 공유할 수 있는지 알려주기 때문입니다. 하다. 이러한 종류의 코드베이스에 있는 많은 작업 및/또는 서브루틴은 로컬 또는 원격으로 실행되기를 원할 수 있습니다.
  
  
• 핵심은 작업이 호출되는 "방법"을 확실히 알지 못할 수 있는 컨텍스트 개체에서 어떤 API를 기대해야 하는지에 관한 것입니다.
• 작업이 생성되는 방식에 따라 달라질 수 있습니다. 즉, @task 및/또는 kwargs의 다른 버전이 동일한 것으로, 사용자가 기대치를 선언할 수 있습니다(즉, "원격 지원 컨텍스트가 제공되기를 정말로 원합니다", "원격 지원 컨텍스트를 제공하지 마십시오." 등)
  
  
  
  • 모호성을 피하기 위해 이것을 _require_할 수 있습니다( ZoP #12 )
  
  
  • 내가 그것에 대해 더 많이 생각할수록 우리는 Fabric이 @task / Task 주위에 자체 경량 래퍼를 성장시키기를 원한다는 것이 분명해 보입니다. pure-Invoke 코드베이스는 @task 를 사용하여 항상 기본 Context 를 제공하는 반면 Fabric 버전을 통해 생성된 작업에는 최소한 Connection 제공하는 옵션이 있습니다
  
  
  • 단점은 위에서 언급한 "로컬에서 원격으로 XOR할 수 있습니다" 유형의 작업입니다. 단일 "명령을 실행하십시오" 옵션만 원하고 두 모드를 동시에 혼합하지 않는 작업. 이것은 "데코레이터가 컨텍스트 유형을 선언함" 솔루션과 잘 작동하지 _않습니다_. 호출하는 사람과 방법에 따라 컨텍스트 유형을 '전환'해야 _필요_하기 때문입니다.
  
  
  • 이것은 실제로 현재 API의 전체 요점 중 하나입니다. 이러한 작업은 ctx.run() 존재하는 한 컨텍스트 하위 클래스에 대해 _신경 쓰지 않습니다_.
  
  
  • 그래서 아마도 @task 의 "기본, 기본 컨텍스트만 필요" 버전으로 장식되기를 원할 것입니다. Fabric(또는 Fabric과 유사한) 호출 관점의 누군가가 이러한 옵션을 제공할 수 있다는 점을 이해하고 작업 Connection 대신의 Context .
    
    
    
    
    
    • 이는 pyinvoke/invoke#170이라고도 하는 작업을 실행하는 방법을 정확히 궁금해하게 만듭니다.
    
    
    
  
  
• 구현에 관계없이 다음과 같은 작업을 수행하는 사용자의 발총 가능성을 최소화해야 합니다.
  
  
  
  • local 가 존재하지 않을 때 예상(Invoke를 통해 실행되는 패브릭/연결 예상 코드)
  
  
  • run 원격 run 컨텍스트가 대신 제공될 때 로컬에서 실행될 것으로 예상(Fabric을 통해 실행/컨텍스트 예상 코드 실행)
  
  
  • 여기에 Max의 추가 설명이 있는 다른 항목이
  
  
• 훨씬 오래된 의견에서 볼 수 있듯이 여기의 하위 사용 사례는 Connection('localhost').run('foo') 에 해당하는 v2가 _SSH를 사용하지 않고_ 대신 Connection('localhost').local('foo') 와 똑같이 작동하기를 기대하는 사용자입니다.
  
  
  
  • 저는 _추측_합니다. localhost 온전성 검사를 시도하는 모든 사람에게 불쾌한 발판처럼 느껴지기 때문에 실제로 이 작업을 수행하고 싶지 않습니다. 그냥 나에게 너무 마법처럼 느껴집니다. 그러나 나는 아마도 옵트인 기반으로(예: ssh.localhost_becomes_subprocess = True 또는 무엇이든 같은 구성 옵션을 설정하는) 논쟁에 열려 있습니다.
  
  

현재 여기에서 나의 유일한 사용 사례는 템플릿을 로컬로 렌더링할 수 있는 upload_template() 입니다.

물론 다음과 같이 할 수 있습니다.

#http://matthiaseisen.com/pp/patterns/p0198/
import os
import jinja2


def render(tpl_path, context):
    path, filename = os.path.split(tpl_path)
    return jinja2.Environment(
        loader=jinja2.FileSystemLoader(path or './')
    ).get_template(filename).render(context)

하지만 로컬에서 렌더링할 수 있는 옵션이 없는 이유는 무엇입니까?

필자의 경우 이 기능의 주요 용도는 로컬 테스트를 위해 애플리케이션 구성을 로컬 시스템에 배포하는 것입니다.

배포 시 대상 서버에 렌더링되는 settings.py.j2 가 있고 거기에 settings.py 라는 이름이 지정되고 jinja가 없는 python 코드만 포함되어 있다고 가정합니다.
이제 로컬에서 테스트하고 싶지만 settings.py.j2 에서 렌더링해야 하기 때문에 아직 로컬에는 settings.py 가 없습니다.
따라서 앱을 시작할 수 없으며 로컬 테스트를 위해 별도의 settings.py 수동으로 만들어야 합니다.

이것은 매우 피곤하며 더 쉬워야 합니다.

예를 들어, Ansible에서는 단순히 "로컬 연결"을 사용하고 ssh를 시도하지 않고 로컬 호스트에서 렌더링한다고 작업에 알릴 것입니다.

Fabric에서 이 기능을 사용할 수 있을 때까지는 물론 몇 줄의 코드에 불과하므로 위에 붙여넣은 솔루션을 사용할 것입니다. imho보다 쉬워야합니다. 패브릭이 저를 위해 쉽게 만들어야 하는 그런 종류의 물건인 것 같아요.

@fninja 아직 upload_template 자체를 이식하지 않았지만 이 문제 영역에 속한다는 데에는 확실히 동의합니다. 아마도 Jinja 래핑 렌더링 단계와 일부 문자열 업로드 단계를 분리하여 이를 처리할 수 있습니다. 특히 후자는 "FLO를 put " 형식으로 이미 존재하기 때문입니다. 예:

from StringIO import StringIO # too lazy to remember the newer path offhand
from somewhere.jinja_wrapper import render
from invoke import task

<strong i="9">@task</strong>
def render_settings(c):
    rendered = render('settings.py.j2', {'template': 'params'})
    c.put(StringIO(rendered), 'remote/path/to/settings.py')

그러나 Connection 메소드 또는 Connection 인수를 취하는 서브루틴이 될 upload_template 에 대한 더 짧은 1-스톱 유사체를 위한 여지가 여전히 있을 수 있습니다.

어느 쪽이든, 정확히 이런 종류의 일을 처리하는 방법에 대해 더 많은 질문을 제기합니다. 예를 들어 Invoke 전용 Context 객체에는 put / get . 추가할 가치가 있습니까? 이 티켓의 맥락에서 Fabric 사용자에게는 충분히 의미가 있습니다(그러면 upload_template 또는 w/e는 두 경우 모두 단순히 put 를 호출할 수 있음). 그러나 순수 Invoke 사용자에게는 기이합니다. API의 쓸모없는 부분.

이것을 핵심 기능으로 만들기 위해 +1

#1637의 교차 기둥. 그냥 아이디어:

from fabric import task, local

<strong i="6">@task</strong>
<strong i="7">@local</strong>
def build(ctx):
    with ctx.cd('/project/dir'):
        ctx.run('build > artifact.zip')

<strong i="8">@task</strong>
def deploy(conn):
    build(local(conn))

    with conn.cd('/remote/path'), local(conn).cd('/project/dir'):
        conn.put(remote_path='build.zip', local_path='artifact.zip')

기본적으로 local() 는 데코레이터/컨텍스트 관리자/함수로 작동하고 Connection 를 Context 있습니다.

언급하지 않은 또 다른 사용 사례: 재사용 가능한 함수 라이브러리 구축. 제 경우에는 대부분 git 명령입니다. run 와 local 함수 매개변수(v1에서)의 차이점을 숨기는 지나치게 단순한 dorun 했습니다. 어떤 함수가 선택되었는지는 매개변수로 전달됩니다. 예를 들어 git checkout 는 다음과 같습니다.

def git_checkout(branch, remote='origin', run=run):
    """Checkout a branch if necessary."""

    if branch == git_current_branch(run=run):
        return
    elif branch in git_local_branches(run=run):
        dorun('git checkout ' + branch, run=run)
    else:
        dorun('git checkout -t -b {0} {1}/{0}'.format(branch, remote), run=run)


def git_current_branch(run=run):
    """Get the current branch (aka HEAD)"""

    output = dorun('git name-rev --name-only HEAD', run=run)
    return output.strip()


def git_local_branches(run=run):
    """Get a list of local branches; assumes in repo directory."""

    output = dorun('git branch --no-color', run=run)
    branches = {l.strip().split(' ')[-1]
                for l in output.strip().split('\n')}
    return branches

다음과 같습니다.

from fabric.api import run as run_remote, local as run_local

def dorun(*args, **kwargs):
    """Work around the fact that "local" and "run" are very different."""
    kwargs.setdefault('run', run_remote)
    run = kwargs.pop('run')

    if run == run_local:
        kwargs.setdefault('capture', True)
    elif 'capture' in kwargs:
        del kwargs['capture']

    return run(*args, **kwargs)

sudo 어떤 일이 발생하는지 전혀 모르고 ~remoteuser 를 확장하여 경로를 생성하는 것과 같이 쉽게 처리할 수 없는 문제가 있습니다.