Tmux a gyakorlatban: helyi és beágyazott távoli tmux munkamenetek

Megbeszéljük a tmux szolgáltatásait, azok relevanciáját a helyi és távoli forgatókönyvek szempontjából, valamint a tmux beállítását és konfigurálását a beágyazott munkamenetek támogatására

Ez a tmuxom első része a gyakorlati cikkek sorozatában. A tmux v2 használatáról és konfigurálásáról, a helyi és távoli tmux munkamenetek használatáról és arról, hogy miként lehet támogatni egy olyan forgatókönyvet, amikor egy távoli tmux munkamenetet fognak beágyazni egy helyi tmux munkamenetbe.

Mielőtt elkezdené olvasni, íme egy működő példa a gépemről. Van egy helyi tmux munkamenet OSX-en az iTerm2-en belül (teljes képernyős módban fut). A helyi munkamenetnek 2 ablaka van: „zsh” és „node”.

A „zsh” ablak két ablaktáblára oszlik: mindkét panelen SSH-t adunk a távoli gazdagépeknek (CentOS7 és Ubuntu14), és ott ugrunk a távoli tmux munkamenetekre.

Az Ubuntu14 távoli munkamenetet tartalmazó alsó panel további 2 panelre oszlik, és 3 ablakunk van: shell, mon és naplók.

Ha kíváncsi vagy, hogyan működik együtt, folytassa az olvasást.

Jellemzők

Először nézzük át gyorsan a tmux jellemzőit és előnyeit, hogy megértsük azok relevanciáját a helyi vagy távoli forgatókönyvek szempontjából. Tisztáznunk kellene magunknak, miért van szükségünk erre a „beágyazott tmux in tmux” dologra, mert első ránézésre elég őrültnek tűnik.

  1. A terminál multiplexelés, az úgynevezett windows, több ablakra osztja az ablakot. Ennek értelme van a helyi környezet számára, amikor úgy dönt, hogy feltölti a terminálemulátorát, amely egyébként nem támogatja a fent említett funkciókat. Például az iTerm vagy a Terminator már képes multiplexálni egy terminált.
  2. Állítsa be és indítsa el a tmux munkamenetet egy előre konfigurált ablakokkal és ablaktáblákkal, azok elrendezésével és a parancsokkal, amelyek elkerülik a fáradságot, hogy újra és újra beállítsák őket a semmiből. Például:

    - „dev” munkamenet, amely tartalmazza a „# 1: shell” ablakot, 2 ablaktáblával ad-hoc használatra

    - „# 2: figyelés” ablak htopés sysdigablaktáblák

    - „# 3: napló” ablak journalctlés tail -f app.logablaktáblák

    - „# 4: csomópont” ablak nodekiszolgáló fut

    A tmux segítségével szkriptet írhat ennek elérése érdekében, és ha a konfiguráció-szerű megközelítést részesíti előnyben, akkor nézze meg a tmuxinator-ot. Ez mind a helyi, mind a távoli forgatókönyv szempontjából releváns.

  3. Tartsa fenn a munkaállapotát, így később leválaszthatja és folytathatja azt az állapotot, amelyikkel távozott. Ha helyben dolgozik több projekttel, akkor projektenként több tmux munkamenetet állíthat be, és könnyedén válthat kontextusban

    A távoli gépen leválhat a munkamenetről egy munkanap végéig, és este visszatérhet ugyanahhoz a munkamenethez otthonról.

  4. Túlélje a hirtelen kapcsolatot. Ez az egyik legfontosabb jellemző. Tegyük fel, hogy SSH-t használ a távoli gazdagépen, és ott egy régóta tartó folyamat van. Ha az SSH-kapcsolat megszakad vagy fizikai hálózat leesik, a SIGHUP jelet a távoli héjra küldi, és azt, valamint az összes alárendelt folyamatot leállítják. A Tmux ellenállóvá teszi távoli folyamatait az ilyen kockázatokkal szemben.

Kevésbé fontos jellemzők, amelyek még említést érdemelnek:

  1. Miután beállította a tmux környezetet, kevésbé függ a szülő terminál emulátortól és annak egyedi szolgáltatásaitól , és ha másik terminál emulátorra vált, kevesebb gondot okoz. Tekintettel arra, hogy iTerm2 vagyok OSX felhasználóként, áttérhetem a Terminatorra vagy a Linux konzolra azáltal, hogy telepítem a tmux konfigurációmat, és megszerezhetem ugyanazt az ismert környezetet, amelyet már megszoktam.
  2. Ossza meg távoli munkamenetét kollégájával, így valós időben együttműködhet. Azt hiszem, a való világban ritkán használják, de klasszul hangzik. Igen, páros programozás és egyéb klasszikus divatszavak. ?

Végül tehát a tmux két fő dologért felel :

  1. Terminál multiplexelés, munkamenet / ablak / ablaktábla kezelése
  2. Tartsa fenn a munkamenet állapotát, és élje túl a távoli forgatókönyvek lekapcsolását

Ahol a tmux valóban ragyog, az (2). Az (1) kapcsán egyesek azzal érvelnek, hogy a tmux megtöri a Unix filozófiáját, mert 2 dolgot próbál meg csinálni ahelyett, hogy egyet csinálna és jól csinálná, és ez (1) nem jelenthet tmux felelősséget.

Beágyazott helyi és távoli munkamenetek

Tehát, mindezek figyelembevételével, egyesek inkább a tmuxot használják a helyi gépen csak a terminál emulátoruk tetején, és elsősorban multiplexeléssel és ablakkezeléssel töltik fel. Azok az emberek, akik idejük nagy részét távoli gazdagépeken töltötték, kihasználják a munkamenet tartós jellegét és a hálózati lekapcsolásokkal szembeni ellenállást.

De vajon a helyi és távoli eseteknek ki kell-e zárniuk egymást? Kombinálhatom őket? Igen, törvényes, hogy SSH-t kell adni egy távoli gazdagépnek, és ott indítani a tmux munkamenetet, miközben már lokálisan tmux környezetben van.

Ezt hívják beágyazott munkameneteknek, de bizonyos akadályokkal jár:

Először is szembe kell néznie a kérdéssel: Hogyan tudja irányítani a belső munkameneteket, mivel az összes kulcskötést a külső munkamenetek elkapják és kezelik?

A legelterjedtebb megoldás a prefixkétszeri megnyomás (az előtag egy billentyűkapcsolás, amely a tmux-ot parancs üzemmódba helyezi, általában ez az C-b, de vannak, akik inkább a képernyőszerűvé alakítják át C-a). Az első előtag billentyűleütését a külső munkamenet fogja el, míg a másodikat a belső munkamenethez továbbítja. Nincs szükség további lépések elvégzésére, és ez a dobozon kívül működik.

A gyökérgomb-kötéseket azonban - amelyeket globálisan hallgatnak, nem parancs módban - továbbra is csak a külső munkamenet ragadja meg. És azt tapasztaltam, hogy nagyon idegesítő a dupla sajtó prefix. Számomra még bosszantó, ha egyszer megnyomom, az iTerm2-ben nincs olyan, hogy parancs mód, és csak a “ ⌘⌥→” gombot nyomom meg a jobb oldali panel kiválasztásához, ahelyett, hogy két külön billentyűleütést küldenék C-a RightArrow.

Egy másik megoldás az, ha 2 külön előtagot állít be például C-begy helyi munkamenethez, míg C-aegy távolihoz. Az alábbi konfigurációval ez azt jelenti, hogy C-ahelyben lenyomva alapértelmezett előtagot C-bküld a távoli munkamenetnek. Itt megtalálta ezt a megoldást.

set -g prefix C-bbind-key -n C-a send-prefix

De valóban úgy érzi, hogy:

A jobb megoldás az lenne, ha ugyanazt a kulcstáblát használnánk mind a helyi, mind a távoli munkameneteken - külön előtagok nélkül vagy kétszeresen nyomva az előtagot -, és a belső munkamenetnél kikapcsolnánk az összes billentyűkötést és előtagkezelést a külső munkamenetben. Hitelek és ez a Github-kérdés.

Tehát, amikor a belső munkamenetben fogok dolgozni, akkor csak a külső munkamenetben F12nyomom és váltom az OFFüzemmódot. Amikor ez megtörténik, a külső munkamenet megjeleníti a OFFvizuális jelzőt az állapotsorban, és megváltoztatja az állapotsor vizuális stílusát, hogy tovább hangsúlyozza, hogy a munkamenet OFF módban van.

Itt van egy összefoglaló a működő tmux konfigurációomból, amelyet nemrég készítettem (csak a releváns darabokat tartalmazza):

F12Alapvetõen a gyökérkulcs-tábla kulcskötését állítjuk be . Megnyomásakor beállítjuk az előtagot None, átkapcsoljuk az aktuális offkulcstáblát, majd megváltoztatjuk az állapotsor stílusát, és a tmux-ot kényszerítjük az állapotsor frissítésére. Egy további lépés megtörténik az aktuális ablaktábla másolási mód törlésére, ha van ilyen. Amint átálltunk a kulcstáblára offés kikapcsoltuk az előtagkezelést, a külső munkamenet egyáltalán nem hallgat semmilyen billentyűleütést. Minden billentyűleütés átkerül a belső munkamenetre anélkül, hogy a külső megállítaná őket.

Ez nagyon jó, de valahogy vissza kell térnünk, és a külső munkamenetet vissza kell állítanunk normál üzemmódba. Ezért állítunk be egy kulcskötést F12a kulcstáblázatban off, amely visszafordítja a kezdeti F12gombnyomás hatását .

Ezenkívül konfigurálunk egy vizuális indikátort az állapotsorhoz, amely bekapcsol, amikor az aktuális kulcstábla van off, és másként elrejt.

Összegzésképpen elmondható, hogy ennek a konfigurációnak a birtokában beállíthat egy helyi munkamenetet 1 ablakkal, 2 ablaktáblával, amelyek beágyazott távoli munkameneteket tartalmaznak a különféle gazdagépeknek (lásd a kép elejét a bejegyzés elején).

Távoli specifikus munkamenet konfiguráció

Az előző példában észreveheti, hogy a külső munkamenet állapotsora felül helyezkedik el, ahol a belső munkamenet állapotsora van alul. Ez szép vizuális megkülönböztetést nyújt, és nem teszi az állapotsorokat egymásra.

De hogyan lehet különböző feltételes alapú konfigurációkat alkalmazni?

Nos, ez meglehetősen egyszerű. A SSH_CLIENTkörnyezeti változó létezésével felismerhetjük, hogy a munkamenet távoli vagy lokális-e .

if-shell 'test -n "$SSH_CLIENT"' \ 'source-file ~/.tmux/tmux.remote.conf'

A ~/.tmux/tmux.remote.conffájl pedig azt a konfigurációt tartalmazza, amely csak a távoli munkamenetre lesz alkalmazva. Ott megváltoztatjuk az állapotsor helyzetét, és eltávolítunk belőle néhány kütyüt (például órát és akkumulátort), mert ezek csak ugyanazokat a modulokat replikálják a helyi munkamenetből.

Szóval ennyi. Ha mindezt működés közben szeretné látni, nézze meg a tmux-config tárat.

Források és linkek

tmux / tmux: tmux forráskód - //github.com/tmux/tmux

Tmux használata távolról egy helyi Tmux munkameneten belül Egyszerűen Ian - //simplyian.com/2014/03/29/using-tmux-remotely-within-a-local-tmux-session/

Beágyazott tmux - //stahlke.org/dan/tmux-nested/

az összes billentyűkapcsoló be- és kikapcsolása · 237. szám · tmux / tmux - //github.com/tmux/tmux/issues/237

samoshkin / tmux-config: Tmux konfiguráció, amely feltölti a tmux-ot, hogy hangulatos és hűvös terminál környezetet teremtsen - //github.com/samoshkin/tmux-config