Konténerek

Linux-haladó

Sziasztok!

Szubjektív véleményeket szeretnék megtudni a különböző konténer megoldások használóitól. Ki, mit választott és miért? Minden ami pro és kontra, de valóban a használóitól szeretném megtudni, nem pedig a szomszéd Pistike hallomásait.

Miért is? Szóval mostanában játszadozom a konténerekkel (itthon és felhőben is) és annyi féle van, hogy Dunát lehet vele rekeszteni. A Docker például nekem nem esik kézre így most az nspawn/mkosi-val készítek konténereket, eddig megelégedéssel, de gondolom nem véletlen, hogy ennyi különböző megoldás van. Van hátránya élesben nspawn konténer(eke)t nyílvánosan elérhetővé tenni?

  • 377 megtekintés

( zeller | 2021. 12. 18., szo – 13:00 )

Nálam docker, illetve a jövőben várhatóan podman. Ezt a szteroidokkal feltuningolt chroot-ot (nspawn) még nem néztem...

A podmant-t nem veséztem ki a választás közben, „nafogdmegasörömmajdmostmegnézem” :)

Az nspawnban az overlay ami megfogott. Van egy alapkép amit overlayen keresztül felszerelek egy új konténerbe, ebben a konténerben csak a változások lesznek eltárolva, az alapkép felhasználható további konténerek létrehozására. Építettem egy nagyon minimális alaprendszert ami mindennek az alapja. A többi konténerben pedig csak az kerül eltárolásra ami az ő futásához még kell az alapon felül. Helyspórolós, eddig meg vagyok vele elégedve. Tud valamelyik még ilyet?

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Az lxc-n belegabalyodtam a hálózatba. Igaz, nem is fordítottam nagyobb figyelmet rá, mert az nspawn-ban elsőre sikerült minden. Mondjuk az lxc dokumentációban keresni kell ezt az overlay lehetőséget, míg az nspawn doksik elég hamar, már a kezdetekkor erre vezetnek. Egész konkrétan csak így, hogy megemlítetted és célirányosan keresem, így kaptam rá találatot az nspawn leírások amikbe belebotlottam pedig kis híján ezzel kezdték. Jó ez, további input :) lesz mit olvasgatnom.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

( kruska v | 2021. 12. 18., szo – 14:14 )

Én LXD/LXC (Ubuntu) konténereket használok webes megoldásokhoz, illetve Libvirt/LXC-t SLES alatt. 

Mindkettővel produktív üzemben mennek nagy terhelésű rendszerek, nginx/PHP-FPM/MySQL/Memcached/Tomcat stb illetve igazi SAP ERP nagy (4-5T) adatbázissal, jelentős erőforrásigénnyel.

Mindkét megoldás teljes OS-t ad, tehát belülről úgy néz ki, mint egy VM, csak gyorsabb, és a telepítése picit trükkös. 

Mit takar a trükkös telepítés?

Annyi a különbség, hogy itt értelemszerűen nem egy normális OS install-t viszünk végig interaktívan. 

LXD-nél az "lxc launch" + konténer beindítása után konzolról belépve kell beállítani a hálózatot (pl. netplan), vagy előtte belemásolni a rootfs-be a konfigfilet.

SLES-nél pedig nekünk kell előkészíteni a rootfs-t, ott még annyi sincs mint LXD-ben hogy lehúzol egy alap image-t. Én így csinálom:

#!/bin/bash

# parameterkent az uj hostnevet kell atadni
ROOTFS=/srv/lxc/$1

# Atmasoljuk a hostrol a repository beallitasokat
mkdir -p $ROOTFS/etc
cp -rp /etc/zypp $ROOTFS/etc

# Megfrissitjuk a repo-kat (always trust-ot kell mindig valaszolni)
zypper --root $ROOTFS refresh

# Minimal install
zypper --root $ROOTFS install -t pattern minimal_base
zypper --root $ROOTFS install yast2 yast2-network

# Nehany init
echo "ttyS0" >> $ROOTFS/etc/securetty
echo "root:xxxxxxxxxxxxx" | chpasswd -R $ROOTFS

Ezután már beindul a konténer; konzol, network, update és mehet a konfigurálás már SSH-n.

Nyilván itt nem applikációs konténerről van szó, tehát pl. a host egyik interfészét belerakjuk egy bridge-be, amit elér az LXC, így kap egy rendes IP-t a fizikai hálózatról, semmi NAT meg portforward bohóckodás.

Ez hasonlít az mkosi-s alapképhez! Az igazság az, hogy lusta dög vagyok és nem ment elsőre az lxd hálózat. Előtte már csináltam egyetlen egy konténert a gentoo alaprendszer fordításhoz amit nspawnal indítottam és mivel ott a hálózat gyakorlatilag a systemd hálózati konfigurációkkal megy, plusz korábban építettem kíváncsiságból egy routert banana router boardra -kizárólag systemd hálózatkezeléssel- nem is keresgéltem tovább az lxd irányában. A scripted a telepítéshez nem bonyolultabb az mkosi beállításánál, köszönöm, hogy megosztottad. Jó látni, hogy valójában a lustaságom miatt nem foglalkoztam eleget más megoldással...

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Érdemes pici időt rászánni és küzdeni vele, mert ha sikerül jól összelőni, nagyon stabil és erős cuccok ezek, bátran lehet rápakolni éles dolgokat.

LXD-nél a hálózat címszavakban, ahogy én csinálom:

1. Létrehozni hoston a bridge-t

/etc/network/interfaces:

auto br2
iface br2 inet static
        bridge_ports eno2 (melyik host ethernet kerül bele)
        bridge_fd 0
        bridge_maxwait 0
        address x.x.x.x
        netmask 255.255.255.0

Értelemszerűen a sima ethernet port konfigját ki kell venni.

2. LXD-nek megadni ezt a bridge eszközt.

devices:
  eth2:
    name: eth2
    nictype: bridged
    parent: br2
    type: nic

Innentől úgy viselkedik a konténer eth2 interfésze, mintha a host "eno2" interfészével együtt egy közös switchbe lenne kötve, tehát ha van a host hálózatán egy DHCP szerver, akkor a konténer is tud kérni onnan IP-t stb.

Hmmm...

Nekem a Gentoo és az Arch Wiki az első ha valamit be kell állítanom, azok alapján mindig sikeresen elkonfiguráltam a hálózatot :) Nem tudnám megmondani, hogy mit-hova-miért-hogyan, de a végére általában egy teljesen használhatatlan hálózat lett az eredmény, mert hol ez, hol az nem ment többé :) Mintha ez:„Értelemszerűen a sima ethernet port konfigját ki kell venni.” nem lett volna meg, bár nem most volt... No kipróbálom ezt is! Köszönöm!

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt