Egy fura problemam van. Van nekem egy ProFTPD szerverem, bezarva egy Docker kontenerbe. Van hozza konfigom is, meg minden. Nagyon szepen dolgozik, majdnem mindent megcsinal, amit kerek tole, egyvalamit nem: nem logol a STDOUT-on kivul mashova (ugye a Docker miatt --nodaemon kapcsoloval fut).
Kiprobaltam pontosan ugyanezt a konfigot pontosan ugyanigy futtatva a ProFTPD-t, de nem Dockerben, hanem egy normalis virtualis gepben, es gyonyoruen irja mind az xferlogot, mind pedig a proftpd.log -ot (a sajat logjat), plusz irkal az STDOUT-ra is. A log mappan joga van neki irni, a logfajlokhoz ugyszint van joga.
Kicsit elakadtam, hogy merre tudnam tovabb keresni a megoldast. Ha kell, tudok adni konfigot is, de eleg biztos vagyok abban, hogy ez nem konfig issue.
Ja, plusz egy info: mind a Docker kontener, mind pedig a EC2 instance egy Debian Jesse volt.
Update: Par kerdest gyorsan tisztaznek:
- Az STDOUT-ra kerulnek logok, ezek mar feldolgozasra is kerulnek, am az atvitelek ebben a logban nem kerulnek megemlitesre. Kilepes, belepes, invalid password, started, stopped, minden van, atvitel nincs.
- A kerdes kizarolag a TransferLog iranyitasarol szol. Nem szeretnem STDOUT-ra rakni (ott van mar mas (konkretan a ProFTPD main logja), mas formatumban, jo lenne nem keverni a kettot, raadasul az a log mar feldolgozasra kerul), pipe-ba vagy fajlba szeretnem iranyitani, akkor is, ha ez utobbi Docker kornyezetben nem ajanlott. Ha ra tudom venni, hogy logolja _valahova_ a TransferLogot, akkor a kesobbiekben mar el tudom iranyitani, ez mar nem okoz gondot. Mivel a ProFTPD dokumentacioja szerint a TransferLog szamra nem lehet atadni kozvetlen syslog szerver kapcsolodasi parametereket, igy a kozeptavu tervek kozott vagy valami named pipe alapu megoldas, vagy direkt log processing szerepel, ezt majd meg eldontom. Ha mar van egy logfajlom, azt mar milliofelekeppen fel tudom dolgozni, amig azonban ilyenem nincs, nem tudok vele semmit se tenni. Kerem, hogy ne foglalkozzunk azzal, mit fogok kezdeni ezzel a loggal. Egyelore legyen.
Hozzászólások
Ha szeretned latni a logjaid, hasznalj mondjuk logspoutot (https://github.com/gliderlabs/logspout), a kontenerbe ne loggolj semmit. Minden menjen stdout-ra es onnan syslogba. Btw sok szerencset az uj munkadhoz ;)
Koszi.
Hasznalunk logspoutot, de ezt szeretnem kulon logban latni, mert maskepp akarom feldolgozni, mint amit most a logspout dologz fel, mindenkeppen el szeretnem szeparalni a STDOUT-os logtol.
Arrol szo sincs, hogy diszkre szeretnek logolni. Kozeptavon az lesz a megoldas, hogy egy pipe-ba logol bele a cucc, hogy named pipe vagy mas, az majd elvalik (meg nem tudom, mit tud a ProFTPD e teren), jelenleg az a gondom, hogy egyaltalan nem logol meg fajlba se.
A nyilvanvalo ellenerzesen tullepve, van lehetoseg arra, hogy kikenyszeritsem belole a fajlba logolast? Egyaltaln, a Docker kornyezet akadalyozza meg a logfajl irasat, vagy pedig valami nyomora van ennek a szerencsetlen demonnak, es emiatt nem hajlando logot irni? Meg nem teljesen ertem ezt az LXC-s koncepciot, lehet, hogy csak nekem nem vilagos valami. Kerlek, legy ebben a segitsegemre, es ne csak a best practice-t mondd el, hanem a mogottes okokat is.
--
Blog | @hron84
Üzemeltető macik
Külső syslog szerverre esetleg?
Logspouttal tudsz tobb iranyba is routolni a routesapin keresztul, a startupnal megadott targeten kivul is, mondjuk igy:
curl http://localhost:8000/routes -X POST -d'{ "source": { "name": "proftpd", "types": ["stdout","stderr"] }, "target": { "type": "syslog", "addr": dns vagy ip:514" }}'
Igy mondjuk a papertrailen kivul tudod magadnak is kuldeni a logot egy syslog szerverre, leszurod arra ami neked kell, az meg kuldi egy named pipeba amit aztan fel tudsz dolgozni on the fly es akkor nem irtal ki semmit diskre.
Vagy egy masik konternerbe iranyitod az osszes logot a fentebbi modon es ott dolgozod fel ahogy akarod. Vagy van kafka driver logspouthoz es onnan dolgozod fel egy masik kontenerrel, a kafka ugyis nagyon hipszter.
Ez nyilvanvaloan nem oldja meg a szeparaciot, mindennek az stdoutra/stderr-re kell mennie es minden megy minden iranyba, a logspout majd tamogatni fogja kesobb - afaik - a syslogot is a routolasban es akkor lehet majd jatszani a facilitykkel gondolom.
btw, ha a proftpd jol van felkonfigolva tud containeren belul is fileba loggolni, de inkabb sztem ne.
a logspoutnak van vagy 200 forkja, hatha ott is talalsz vmit a problemadra :)
Nezd en ertem, es megertem, hogy a logspout az ajanlott megoldas erre, es hogy a fajlba logoltatas docker kornyezetben nem ajanlott, nem erre valo, meg a jo eg tudja, hogy mi meg. De probalom a dolgokat lepesenkent megoldani. Az, hogy hova iranyitsam, hova dolgozzam fel a logot, az egy masodlagos problema, azt mar meg tudom oldani, arra mar csak egy scriptet kell megirnom, es mar minden elo van keszitve a log fogadasahoz. Jelenleg a jo konfig ellenere nem jon ki belole a transfer log, es ezt probalom lepesrol lepesre megfejteni, hogy miert. Jelenleg a Docker szamomra ismeretlen tenyezo, elvben ertem, hogy mit csinal a hatterben, de nem tudom kizarni, hogy a logolast nem az akadalyozza meg. Egy dev kornyezetben kinlodok az egesszel, szoval az se erdekel, ha ket sor log utan szethullik az egesz a francba.
Kell valami specialis konfig, jog, barmi ahhoz, hogy fajlba logoljon?
--
Blog | @hron84
Üzemeltető macik
Igazabol a konfigot kene latni ehhez, a kontener nem fog megakadalyozni abban, h kiird a logot.
Ez nem a Global szekcioban van, hanem a globalis nevterben, mindenfele szekciokon kivul.
Ennel hosszabb a konfig, persze, de eleg sok darabbol all ossze, problemas lenne osszeollozgatni. Ha mondod, mi kell, bepasztazom.
A lenyeg: se a TransferLog, se a SystemLog szekcionak nincs hatasa Dockeren belul, a SystemLog-ot letrehozza (minden esetben) de nem irja, a TransferLog letre se jon. Dockeren kivul inditva mindket logfajl rendesen irodik ugyanezzel a konfiggal.
--
Blog | @hron84
Üzemeltető macik
Két dolog jutott eszembe, hátha segít.
a. supervisod-vel indítva sem logol fájlba?
b. A log könyvtár írható? (umount /var/log/proftpd.log)
A log konyvtar jog szerint irhato, supervisord-t nem probaltam meg...
--
Blog | @hron84
Üzemeltető macik
Próbáld úgy, hogy a supervisord-t indítod és az indítja a proftpd-t.
Gondolom Dockerfile-t írsz és abból csinálsz image-t.
Felesleges meg egy reteget alarakni. Utkozne a docker filozofiaval - 1 process per kontener.
Itt a konfigban lesz a hiba :)
Technikailag akkor a Postfixbol se lehetne kontenert csinalni, mert az inditas utan vagja szet magat vagy 6 processzre. Ugyanez a Sambaval, az Apache-csal, a PHP-FPM-mel. A QMailt mar meg sem emlitem...
Hagyjuk ezt a filozofalast pls. Azon felul, hogy nincs igazan ertelme (mindenki abbol csinal Docker kontenert, amibol akar, es ugy ahogy akarja), csak ellentetet szul.
--
Blog | @hron84
Üzemeltető macik
1 process per container != child processes
De, ugy csinalod, ahogy akarod, igazan orulok, h segithettem.
Technikailag a supervisord is child processekkel dolgozik... Vekony jeg ez, hidd el. Nem kotozkodok, csak tenyleg nem latom ertelmet ezt eroltetni.
--
Blog | @hron84
Üzemeltető macik
-n, --nodaemon
Disable background daemon mode and send all output to stderr)
Ez a proftpd nodeamon kapcsolo nem a hiba oka? Nem vagyok dockerhez erto de miert is letfontossagu az?
1) pont ugyanigy futtattam egy sima EC2 node-on is (-n/--nodaemon kapcsoloval) es logolt, tehat nem, nem ez a hiba oka. Pont ezert fogalmaztam meg a nyitot ugy, ahogy megfogalmaztam.
2) azert kell ez, mert a docker nem kepes normalisan elkezelni a demonizalodo processzeket, azok ugyans _technikailag_ befejezodnek a szamara amikor elforkolnak es a parent processz visszater. Nem koveti le a forkokat. Asszem vannak ra kulonfele hackek, hogy ezt meg lehessen kerulni, de alapvetoen a legtobb taszk kezelo (systemd, upstart, Docker, etc) az eloterben futo processzekre van elsosorban felkeszitve.
--
Blog | @hron84
Üzemeltető macik
A docker config fajlba nem lehetne hasonlot irni mint ngninx talaltam:
# forward request and error logs to docker log collector
RUN ln -sf /dev/stdout /var/log/nginx/access.log
RUN ln -sf /dev/stderr /var/log/nginx/error.log
Docker verzio , konfig fajlok etc hasonloak gondolom. Mivel nem az ftp kliens a ludas azt mondod akkor a dockerrel van valami.
Azert en megneznem, hogy a /var/lib/docker alatt mi a helyzet. Oda szokta dobni a dockeren belul stdout-ra irt uzeneteket. Keresnem a docker inspect-tel a LogPath-ot.
A TransferLog nem jelenik meg a STDOUT-on, a tobbire nem reagalok, mert mar egy csomot irtam a logolasrol korabban. Kerlek, olvass vissza. Nem az STDOUT-os logolassal van a baj, azt ismerjuk, szeretjuk, fel is dolgozzuk.
A kerdes az, hogy miert nem logol fajlba. Minden mas kerdes irrelevans a temaban.
--
Blog | @hron84
Üzemeltető macik
Ertem en hogy ideges vagy, de meg is nezted Te mikor irtad az stdout-rol a dolgokat es en mikor irtam az en hozzaszolasomat?
Egy javaslatom lenne meg, hogy a /var/log volume-t nyomd ki a host-on valahova, mondjuk legyen a /var/log/dockerlogs/proftpd. A hostra mindenkeppen ki kellene tudnia irni az allomanyt. Mondjuk pont proftpd-t nem hasznalunk, de szinte az osszes docker instancunk igy logol.
Ha a hostra sem megy ki, akkor az proftpd nyug, es elkezdenek nezeleodni az fd-k kornyeken. Megprobalja e megnyitni egyaltalan azt a franya fd-t?
Vagy ne is reagalj a tovabbiakra. :D
Meglett a megoldas, bar elegge korulmenyes modon.
Eloszor is, az xferlog nem jar alanyi jogon. Attol, mert ott van a konfigban, meg nem lesz ott a diszken. A ProFTPD akkor hozza letre, amikor az elso feltoltes zajlik. Bennem valamiert mindig az Apache mukodese el ilyenkor, az indulaskor megprobal minden logot letrehozni, biztos ami biztos alapon, es ordibal (el sem indul) ha nem megy.
Masodszor: valahogy nem volt meg, hogy a docker nem fajlszinten, hanem fajlrendszer szinten dolgozik, azaz inkabb keveredett bennem a dolog. Ugye ez azt okozza, hogy ket run kozott nem marad ugyanaz semmi, hiaba nem szerepel az image-ben a xferlog.
A lenyeg: attettem a logot egy kivulrol becsatolt adatkotetre, igy most folyamatosan nyomon tudom kovetni az alakulasat akar a host oldalarol is.
Sajnos a named pipe nem valt be, nem tudtam stabilan kihozni belole a logot, neha hiaba logoltattam bele a ProFTPD-t a tuloldalon nem jott ki belole semmi.
--
Blog | @hron84
Üzemeltető macik
Ha egy regi instance-ot start-al inditasz el, abban bizony megmarad minden. Az uj run termeszetesen uj containert indit az image-bol. Az aktualis rw filesystem layer ugye megmarad mindenkeppen a regi kontenerben. Igy celszeru inkabb a regit elinditani, mint ujat krealni. Szoval ha tul sokat run-olsz start helyett, eloallhat az az eset, hogy megtelited a sajat fajlrendszeredet. Nalunk egy ugyfel nem ertette miert lett tele a filerendszer, mikozben csak per kilobajtnyi volt egy fs layer az inditott kontenereknel. Mondjuk abbol ket het alatt inditott vagy szazezret. A "docker ps -a" veget sem akart erni soha. :D
Tehat a docker nem filerendszer szinten dolgozik, hanem FS layeren. Ami viszont egy konyvtar a /var/lib/docker alatt az aufs layers konyvtarban. Igy viszont azt is mondhatjuk, hogy file szinten dolgozik. :D
A telitodes nem gond, mivel a dockert futtato kornyezet folyamatosan nullarol ujra van krealva deploymentnel (az adatdiszk egy kulon EBS, amit a krealas utan ujracsatlakoztatunk). A dockert ebben az esetben elsosorban a szeparacio, semmint a deployment miatt hasznaljuk (affele rich man's chroot)
--
Blog | @hron84
Üzemeltető macik