deadlime

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.