2013-10-23 11 views
12

Mam a playbook to install PythonBrew. W tym celu muszę zmodyfikować środowisko powłoki. Ponieważ kroki shell w ansibl nie są trwałe, muszę poprzedzić export PYTHONBREW_ROOT=${pythonbrew.root}; source ${pythonbrew.root}/etc/bashrc; na początku każdego z moich poleceń związanych PythonBrew-:W Ansible, w jaki sposób używane jest słowo kluczowe environment?

- name: Install python binary 
     shell: export PYTHONBREW_ROOT=${pythonbrew.root}; source ${pythonbrew.root}/etc/bashrc; pythonbrew install ${python.version} 
     executable=/bin/bash 

    - name: Switch to python version 
     shell: export PYTHONBREW_ROOT=${pythonbrew.root}; source ${pythonbrew.root}/etc/bashrc; pythonbrew switch ${python.version} 
     executable=/bin/bash 

Chciałbym wyeliminować ten redundancję. Na Ansible discussion group zostałem przekierowany na słowo kluczowe environment. Spojrzałem na examples in the documentation i nie klika na mnie. Dla mnie słowo kluczowe środowisko nie wygląda tak jak każda inna zmienna.

Szukałem innych przykładów, ale udało mi się znaleźć tylko this very simple example.

Czy ktoś może zademonstrować działanie słowa kluczowego environment w Ansible, najlepiej przy pomocy przykładowego kodu podanego powyżej?

Odpowiedz

15

Nie wiem, czy to będzie wpisuje swoje potrzeby, ale to, jak widzę to:

- hosts: all 
    vars: 
    env: 
     PYTHONBREW_ROOT: "{{ pythonbrew.root }}" 
    tasks: 
    - name: Install python binary 
     shell: pythonbrew install {{ python.version }} executable=/bin/bash 
     environment: env 

    - name: Switch to python version 
     shell: pythonbrew switch {{ python.version }} executable=/bin/bash 
     environment: env 

To po prostu ustawia zmienną o nazwie env i używać go jako środowiska zarówno w twoich poleceń powłoki. W ten sposób polecenie powłoki będzie miało zestaw ścieżek PYTHONBREW_ROOT.

+2

Przynajmniej z bieżącą wersją Ansible ten przykład ** nie działa. Linia 'executable =/bin/bash' musi być w tej samej linii z' shell: ... '. Odpowiednio zaktualizowałem odpowiedź. –

+0

Dzięki za poprawkę :) – magnetik

0

Mam bardzo podobny problem; Chciałbym mieć ansibla, czy to jest coś w wirtualnym Pythonie (po upewnieniu się, że jest ustawione dla mnie, oczywiście).

Oto jeden ze sposobów, w jaki dotychczas wykonałem wstępne warunki środowiskowe; zasadniczo miałem dodać (i ewentualnie usunąć) linii do .bashrc:

tasks: 
    - name: "Enable virtualenv in .bashrc" 
     lineinfile: dest=.bashrc 
        line="source {{ PROJECT_HOME }}/venv/bin/activate" 

    # Put tasks that rely on this environmental precondition here (?) 

    - name: "Disable virtualenv in .bashrc" 
     lineinfile: dest=.bashrc 
        line="source {{ PROJECT_HOME }}/venv/bin/activate" 
        state=absent 

Nie wiem, czy jestem „Spowoduje to źle”, ale dopóki nie zrozumieć to czy ktoś przyjdzie powiedzieć jak to zrobić lepiej, przypuszczam, że to zadziała.

+1

Jest to nieco inny problem. Dla czegoś takiego jak Ansible, zamiast aktywować i dezaktywować virtualenv, po prostu nazywam moje polecenie pełną ścieżką wirtualnego python bin. Na przykład: 'command:" {{PROJECT_HOME}}/venv/bin/python myscript.py "'. To sprawia, że ​​twój skrypt Ansible jest trochę bardziej przejrzysty. Używam virtualenv regularnie, ale w rzeczywistości bardzo rzadko aktywuję go w powłoce. Zazwyczaj po prostu wywołuję python bin z wiersza poleceń. – klenwell

+0

Oczywiście, ale ponieważ ansible ma zależności, które mogą być również w virtualenv, inne polecenia, itp ... Zazwyczaj lubię zawierać tyle, ile mogę w virtualenv i zawsze mam je aktywowane podczas pracy na poziomie aplikacji . –

+0

Możesz zainstalować te zależności w projekcie virtualenv hosta sterowania za pomocą instalacji {{PROJECT_HOME}}/venv/bin/pip ..., ale jeśli są one wymagane na zdalnych hostach, sprawy stają się bardziej skomplikowane, ponieważ #!/Usr/bin/Python znajduje się we wszystkich bibliotekach ansalyla. – bbaassssiiee

Powiązane problemy