egy uj alkalmazas telepiteset hogyan szeretned csinalni?

Arra gondoltam, hogy a spamszuromon egy nagyobb rancfelvarrast csinalok, es a piler demonbol kiindulva ujrairom ill. aramvonalasitom az egeszet. Viszont ha elkeszult, akkor a leheto legegyszerubb modon szeretnem utana kozzetenni.

Mert lehet a forraskodot feldobni a github es tarsaira, hozza egy 2 km-es step by step leirassal, aztan sok sikert. De lehet belole csomagokat kesziteni, deb, rpm, ??? (na es pl. freebsd-re?). Sot lehet virtualis gepkent is, amolyan appliance-kent, letolthetove tenni. Vegul manapsag kezd feljonni a docker, aminel linux alapu kontenerkent letolthetove tenni.

A dilemmam csak annyi, hogy a nap 24 oraja keves ahhoz, hogy az elobbiek mindegyiket megcsinaljam, arrol nem is beszelve, hogy egy spamszuronek milyen rugalmasnak kell lennie, hogy minel tobbfele kornyezetben is megallja a helyet. Annyi bizonyos, hogy a forras + 2 km-es leiras az tuti lesz, ill. opcionalisan egy installer shell script, ami bekonfiguralja, amit kell. A csomagok kesziteset inkabb egy jol eltalalt docker kontenerrel, ill. egy OVF image-dzsel helyettesitenem, de ez csak az en preferenciamiat tukrozi.

Az igazi kerdes, amiben most a velemenyetek erdekel, hogy ha most telepitenel egy spamszurot - tokmindegy mit (SA, dspam, bogofilter, ...), akkor egyreszt hova tenned (pl. az MTA-t futtato gepre, vagy egy dedikalt gepre), ill. fizikai gepre tenned vagy virtualis gepbe (ami megeszi az OVF-et), vagy docker kontenerbe?

( csuhi | 2014. 12. 01., h – 20:44 )

Én az MTA-t futtató gépre tenném, és "yum install $alkalmazas" paranccsal szeretném telepíteni. De az se lenne rossz, ha olyan appliance-el érkezne, mint az általam legjobban ismert és használt ClearOS.

Minkettő előnye, hogy a rendszerrel együtt frissül, nem kell külön foglalkozni a frissítésével.

A legnagyobb gép amival dolgozom is max 200 useres és "mezei" pc az alapja, nyilván van az a méret ahol ez harmatgyenge lenne, de nekünk jó ez.

--
http://csuhai.hu

( khiraly | 2014. 12. 01., h – 20:43 )

Docker az arra valo, hogyha mar elfogyott a memoria a szerveredben:)))

Vagy ha minden egy OS alatt van:) (linux ebben az esetben).

En virtualis gepekben gondolkodnek. Abbol is van rengeteg amire lehet csomagot gyartani.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( uid_395 v | 2014. 12. 01., h – 23:53 )

btw, rpm, deb, stb. csomagot nem feltétlen neked kell megírni. Fejlesztőkkel felvenni kapcsolat és akkor ők majd írnak tempalte-et. Ha elterjed a cucc, akkor úgyis átveszik maintainer szinten (már a csomagkészítést).

Azzal úgy sok időt nem kell eltölteni. Viszont ezeknek a fejlesztőknek teljesen jó a sok oldalas részletes doksi, amiből a megfelelő package template-eket elő tudják állítani.

( szollosiimre | 2014. 12. 02., k – 08:58 )

Repo csomagot. Ugyanakkor nem tartom célravezetőnek, ha ez a /optban az ostől független csomagokkal van megoldva.

Szívesen használok virtual appliance-eket. Mivel a hypervisorok elég sokrétűek, ezért az alaprendszert és a mozgathatóságot ( konverterek, kompatibilitási és hypervisor toolok ) érdemes megfontolni.

( tompos v | 2014. 12. 02., k – 09:55 )

Annyira ereztem, h te inditottad ezt a topicot:)

Az altalanos leiras szerintem esszencialis, anelkul nincs buli. Pl. az en se docker, se ovf-et nem hasznalnek.
Masreszt az disztro csomagokat nem helyettesitik a VM-ek, mert mi van, ha a te pancsolt appliance-ed nem passzol az o infrastrukturajaba (viszonylag nagy az eselye).

Altalanosan a velemenyem:

- altalanos telepitesi leiras kell
- disztro csomagok jo ha vannak, de ha a fenti megfelelo minosegu, akkor nem annyira lenyeges, plane ha a csomag minosege viszont pocsek (tipikusan az upgrade korul szokott menni a benazas -> jobb, ha a csomag egyszeru es kesz, nincs pl. debconf-fal osszebarmolva, ha vki nem tudja, hogyan kell igazan jol csinalni)
- nem feltetelenul kell repository, eleg ha van 1 .spec file meg egy ./debian/ konyvtar (meg amihez meg ha akarsz csomagot..)
- egy docker kontener osszehozasa viszonylag gyerekjatek, szerintem egyszerubb, mint egy csomag (viszont csak docker szerveren fog tudni..).

Ha az infrastrukturaban tudok barmit segiteni, keress meg (CI, build). Szerintem van feles kapacitasom:)

Ha appliance-t (is) akar csinalni, inkabb OVF. A Docker meg nincs annyira elterjedve, raadasul nagyon sok helyen inkabb rendes virtualizacio van, nem pedig LXC alapu tortenet.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Az LXC kozelebb all logikajaban a BSD jailekhez, mint a HW-es virtualizaciohoz. Marpedig a jail-eket nem szokas teljes erteku virtualizacionak tekinteni.

Nagyon sok helyen HW-es virtualizacio van, vagy paravirtualizacio (Xen es tsai), az LXC relative keves helyen van jelen, a Docker kapcsan kezdett el most terjedni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> Az LXC kozelebb all logikajaban a BSD jailekhez, mint a HW-es virtualizaciohoz. Marpedig a jail-eket nem szokas teljes erteku virtualizacionak tekinteni.

Most a "teljes" virtualizaciot allitod parhuzamba a "normalis" virtualizacioval.
Az elsot ertem, bar ott is helyesebb mondjuk HW virtualizaciokent hivatkozni ra. A masodik viszont ertelmezhetetlen (szerintem).

K. sok helyen van OS szintu virtualizacio, legfeljebb te nem ismered:)

En ugy tudom, a HW virtualizacio azt jelenti, hogy maga a proci kepes szetosztani az eroforrasait, es igy tamogatja a virtualizaciot, nem pedig a szoftvernek kell kulonfele eszkozoket emulalni (SW virtualizacio, ilyen peldaul a KVM nelkuli QEmu, a Bochs es mas ilyenek). A kontener-szeru virtualizacioknak (LXC, Docker, Jail) pont az az elonyuk, hogy nem kell virtualizaciokepes hardver ala, egy Celeron procival is el lehet intezni, hiszen ezek inkabb eroforras-szeparaciok, semmint valodi virtualizaciok (sokkal kevesbe valasztodik le a virtualizalt rendszer a gazdageprol, kozos marad a kernel, a halozati stack, ilyesmi). Tagabb ertelemben persze ezek is virtualizaciok, de eleg tagra feszitett ertelemben a Java VM is virtualizacio.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

> En ugy tudom

En ugy, hogy nincs egyetemesen elfogadott (pl. rfc) definicioja, de cafoljatok meg.

> HW virtualizacio azt jelenti, hogy maga a proci kepes szetosztani az eroforrasait

Szamomra azt, hogy a fizikai hardvert virtualizalja (~sajat kernel).

> semmint valodi virtualizaciok

Ezzel a reszevel van problemam. Amikor azt irod, hogy "valodi" meg "rendes" virtualizacio. Szamomra ezek a fogalmak ertelmezhetetlenek.

> Tagabb ertelemben persze ezek is virtualizaciok, de eleg tagra feszitett ertelemben a Java VM is virtualizacio.

Persze, hogy azok, miert ne lennenek? Hol volt lefektetve, hogy szukebb ertelemben kell ertelmezni a virtualizaciot?
Sot, meg egy egyszeru chroot is virtualizacio.

A "virtualizacio" szo, amikor altalanossagban hasznaljuk, inkabb egy picit szukebb ertelmezesi tartomannyal bir. Egy jail-t vagy egy chroot-ot jelen kontextusunkon kivul nekem eszembe nem jutna "virtualizaciokent" emlegetni, mert abban az ertelmezesi tartomanyban, amit a "virtualizacio" szo a common sense-ben alapbol jelent, a chroot nem minosul virtualizacionak,
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()