Az ablakokon túl

Tárlatvezetés a fejlesztői környezetemben

Web fejlesztők munka közben; Leonardo da Vinci egyik késői munkája

Néha kihalófélben lévő állatfajnak érzem magam a sok harapott alma között, úgyhogy most mesélek egy kicsit arról, hogy Windows-t használó (web)fejlesztőként hogyan is néz ki a fejlesztői környezetem.

Ahogyan a napsugarak lassan áthatolnak a három rétegű edzett üvegen, az egyik legkülönlegesebb lényt figyelhetjük meg az északi félgömbön - a Scriptor fenestralis-t, ismertebb nevén a Windows-os webfejlesztőt.

Természetes élőhelyük a mesterséges világítás és a hűvös hőmérséklet ideális kombinációja, mely optimális környezetet teremt a szellemi kihívásokkal teli munkához.

Röviden és tömören: egy Windows-os host gép, amin egy Debian alapú virtuális gép fut Hyper-V segítségével. Azon belül pedig Docker-t használok a konkrét projektek futtatására. Nem a technológia csúcsa, de még nem szántam rá magam a komolyabb kísérletezgetésre a WSL2-vel. No de lássuk a részleteket.

A fizikai gép

Korábban VirtualBox-ot használtam, de aztán váltottam Hyper-V-re, mert az már alapból benne van a Windows-ban, csak be kell kapcsolni. Meg gondoltam, ha már hivatalos megoldás, lehet jobban is működik. Nincsen semmi, amivel ezt alá tudnám támasztani, max. az jut eszembe, hogy a gép indulásával együtt a virtuális gép is elindul, de lehet, hogy VirtualBox-ban is lehetne ilyet csinálni.

Hálózat

Ha el akarjuk érni a virtuális gépünket (vagy a virtuális gépünkről az Internetet), akkor be kell állítani neki egy hálózatot. Itt két irányba is mehetünk, használhatunk External switch-et vagy Internal switch-et (van Private switch is, de az nekünk most nem segít).

Az asztali gépem esetében az External switch opcióval mentem, összekötöttem a hálókártyával, amin kapja a gép az Internetet és ezzel nagyjából meg is volnánk. A router számára úgy látszik a virtuális gép is, mintha egy rendes fizikai gép lenne a hálózaton. A MAC címe alapján adtam neki egy fix IP címet a DHCP szerveren és egy hostot a DNS szerveren, ami erre az IP címre oldódik fel (devbox.lan).

Ez egy ritkán mozgatott asztali gép számára elfogadható megoldás lehet, de mi a helyzet mondjuk egy laptop esetén, ahol nem biztos, hogy hozzáférünk minden router-hez, hogy ezt meg tudjuk oldani? Erre lehet megoldás az Internal switch, amit a következő PowerShell parancsokkal konfiguráltam fel:

> New-VMSwitch -SwitchName "Internal" -SwitchType Internal
> New-NetIPAddress -IPAddress 192.168.56.1 -PrefixLength 24 -DefaultGateway 192.168.56.1 -InterfaceAlias "vEthernet (Internal)"
> New-NetNAT -Name "InternalNatNetwork" -InternalIPInterfaceAddressPrefix 192.168.56.0/24

A 192.168.56.0/24-es tartományt használjuk, de DHCP híján nem kapunk belőle automatikusan IP címet, úgyhogy a virtuális gépen belül kell egy fix IP címet megadnunk. Debian esetén valahogy így, a /etc/network/interfaces fájlban:

iface eth0 inet static
  address 192.168.56.101
  netmask 255.255.255.0
  gateway 192.168.56.1

Ha pedig host-ot is szeretnénk neki, akkor azt felvehetjük a C:\Windows\System32\drivers\etc\hosts fájlban:

192.168.56.101 devbox.lan

Néha szükség van rá, hogy a virtuális gép egy portját localhost-on is elérjem (ha valami a virtuális gépen belül a 8080-as porton fut, akkor azt elérjem localhost:8080-on is). Ehhez eleinte a következő PowerShell parancsot használtam:

> Add-NetNatStaticMapping -NatName "InternalNatNetwork" -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.56.101 -InternalPort 8080 -ExternalPort 8080

Ez egy idő után elkezdett nem működni. Nem tudom mi történhetett vele, de némi kutakodás után találtam helyette egy másik parancsot.

> netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=192.168.56.101

Így utólag belegondolva lehet, hogy egyszerűbb lett volna csak simán SSH port forwarding-ot használni. Micsoda megvilágosodások történnek itt bejegyzés írás közben.

Ablakos alkalmazások

A fizikai gépen fut egy VcXsrv, ami egy Windows-on futó X szerver. A virtuális Linux-on belül indíthatok vele ablakos alkalmazásokat, amiket Windows-os ablakokként lehet használni. Általában az aktuálisan használt IDE ennek a segítségével fut a virtuális gépen belül, mert úgy egyszerűbb elérni benne a Linux-os/Docker-es dolgokat és kevesebb gond van a fájl jogosultságok körül is.

SSH

Egy YubiKey-n tárolt GPG kulcsot használok SSH autentikációhoz. A Gpg4win-ben lévő GPG agent van felkonfigurálva, hogy egyrészt kezelje a YubiKey-t, másrészt kiajánlja a benne lévő kulcsot az SSH agent-ben:

scdaemon.conf
reader-port Yubico Yubi
pcsc-shared
disable-application piv
gpg-agent.conf
enable-ssh-support
enable-putty-support

SSH kliensnek PuTTY van használva (bár a Windows Terminal is egész ígéretes, de legutóbb még nem akart együttműködni a GPG agent-tel) és be van kapcsolva az agent forwarding[1], hogy a virtuális gép is tudja használni a YubiKey-n lévő kulcsot.

Ezen kívül a Linux-os home könyvtáram van felcsatolva hálózati meghajtóként (P:\), hogy egyszerűbb legyen fájlokat mozgatni a két gép között.

A virtuális gép

Ez a rész elég fapados, egy szimpla Debian vagy Ubuntu szerver, amit Ansible segítségével húzok fel. SSH-zás után egy gyári beállításokkal rendelkező Bash fogad (néhány alias-tól eltekintve), ami mellé általában egy Tmux-ot indítok. Ha éppen olyan a hangulatom, akkor a Powerline (és a hozzá tartozó DejaVu Sans Mono betűtípus) segítségével szépítem meg őket egy kicsit.

Samba

A hálózati meghajtó miatt kerül a gépre Samba, ami a neten talált teljesítmény növekedést ígérő beállításokkal lett felturbózva:

/etc/samba/smb.conf
read raw = yes
write raw = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
use sendfile = yes
aio read size = 16384
aio write size = 16384
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes

Docker

Végül, de nem utolsó sorban, a projektek miatt kerül rá még Docker is. Minden más vacak reményeink szerint Docker-en belül fog futni. Ha már Docker, érdemes egy pár szót ejteni a hálózati beállításairól.

Ha hagyjuk szabadon garázdálkodni, akkor van rá egy kicsi esély, hogy előbb-utóbb létrehoz egy olyan hálózatot, ami ütközik valamelyik másik helyi hálózatunkkal és elkezdenek majd emiatt furán működni a dolgok. Ennek megakadályozása érdekében érdemes valami ilyesmit felvenni a beállításai közé:

/etc/docker/daemon.json
{
  "bip": "172.20.0.1/16",
  "default-address-pools": [
    {"base": "172.21.0.0/16", "size": 24}
  ]
}

Így lehet ~250 hálózatunk, hálózatonként ~250 géppel, ami valószínűleg több, mint elég egy fejlesztői gépen, de a default-address-pools részbe fel lehet venni további tartományokat, ha mégis kifutnánk belőle.

Ezzel a tárlatvezetés végére is értünk, remélem élveztétek az utazást. Elég sok mindent érintettünk felületesen, de ez talán elég ahhoz, hogy el tudjatok indulni ezen a rögös úton.
Azért így a végére érve talán már bevallhatom, hogy nem vagyok benne biztos, hogy jó szívvel tudnám bárkinek ajánlani ezt a felállást. Nekem egyelőre még elég kényelmes ahhoz, hogy ne váltsak, de azért nézelődök, hogy milyen alternatívák jöhetnének még szóba.


Jegyzetek

1. Szokták azt mondani, hogy az agent forwarding nem túl jó ötlet, mivel a socket elérhető lesz mások számára is a cél gépen, ha van elég jogosultságuk (pl. root). Ez a veszély esetünkben nem fenyeget.

This post is also available in english: Beyond the Windows

Hozzáfűznél valamit?

Dobj egy emailt a blog kukac deadlime pont hu címre vagy irány a bejegyzéshez tartozó tweet.

Feliratkoznál?

Az RSS feed-et ajánljuk, ha a régi jó dolgokat kedveled, de követheted a blogot Twitteren is.