Fórum Root.cz
Hlavní témata => Server => Téma založeno: HanzHanz 01. 11. 2024, 23:51:34
-
Netušíte prosím někdo, jak uvnitř běžícího kontejneru (debian/ubuntu) umožnit autostart ssh? Ssh spustím pomocí service ssh start, ale samozřejmě po restartu je to zase vypnutý a příkaz systemctrl enable "cokoli" v kontejneru není dostupný.
Celá aplikace se skládá ze 3 kontejnerů (sql, cache a hlavní aplikace) a k sestavení používám používám docker-compose.yml.
Ať googlím jak chci, (entrypoint, command... ty mi to pro "radost" pouštějí při startu stále dokola a kontejner se pořád restartuje :-)) nedokážu docílit něco jako "systemctrl enable sshd" aby to zůstalo perzistentní.
Děkuji!
-
Problém/vyhoda kontejnerů je že tam by default bezi Jen jeden proces. Takže co potřebuješ je aby ten jeden proces pustil další procesy
Asi nejjednodušší řešení je si do kontejnerů nainstalovat supervisord napsat si entrypoint kterej pustí ten supervisord a přes supervisord už si můžeš pustit kolik dalších věcí potřebuješ (třeba i to ssh) je to jednoduché elegantní...
Trochu nevýhoda je že ten supervisord sám žere asi 30mb RAM což je prd ale když chceš mít úsporné kontejnerů tak se bez něj jde obejít prostě ten ssh sever pustíš v entrypointu ale pustíš ho na pozadí abys pak mohl nahodit další službu. Není tak elegantní protože ten supervisord za tebe dělá i další práci (automaticky restart padnute servisi...) což si jinak budeš muset v tom entrypointu nak pořešit sám (a nebo se na to vykašlat ono ssh zas tak často nepadne)
-
Problém/vyhoda kontejnerů je že tam by default bezi Jen jeden proces. Takže co potřebuješ je aby ten jeden proces pustil další procesy
Asi nejjednodušší řešení je si do kontejnerů nainstalovat supervisord napsat si entrypoint kterej pustí ten supervisord a přes supervisord už si můžeš pustit kolik dalších věcí potřebuješ (třeba i to ssh) je to jednoduché elegantní...
Trochu nevýhoda je že ten supervisord sám žere asi 30mb RAM což je prd ale když chceš mít úsporné kontejnerů tak se bez něj jde obejít prostě ten ssh sever pustíš v entrypointu ale pustíš ho na pozadí abys pak mohl nahodit další službu. Není tak elegantní protože ten supervisord za tebe dělá i další práci (automaticky restart padnute servisi...) což si jinak budeš muset v tom entrypointu nak pořešit sám (a nebo se na to vykašlat ono ssh zas tak často nepadne)
Moc děkuji za radu! Mohl bych tě poprosit o příklad souboru docker-compose.yml? Kam vložit ten supervisord a jak spoustit třeba ten "service ssh start"?
-
Spis je na snadne otazka co vlastne resis. Mam trochu pocit, ze se snazis naroubovat neco z tradicniho OS pristupu na kontejnery. Pak z toho vznikaji ty multiprocesovy kockopsi. Co pres to SSH potrebujes resit?
-
Nainstaloval jsem supervisor do kontejneru, upravil conf. soubor a v kontejneru to běží... Nicméně jsem zase na začátku a prostě nemůžu nikde najít, jak v souboru docker-compose.yml zadat entrypoint, který spustí ten supervisor (něco jako supervisord -c supervisord.conf).
To ssh tam potřebuju kvůli backupu dat rsyncem mimo kontejner.
-
No dve veci
1) pokud chces menit editovat entrypoint je mnohem lepsi sahnout primo do Dockerfile zmenit to tam a zbuildit si upraveny image..
2) jak uz tu padlo velmi casto je to znamka spatneho navrhu pokud tu resis backup tak od toho tu slouzi spis
Volumes.. namountujes si do kontejneru slozku a backupovat muzes z hosta alternativne pokud to nechces resit na hostu tak muzes ten volume namountovat do druheho kontejneru kde pobezi prave JENOM ssh. a budes to zalohovat "z boku"
je to mnohem cistejsi reseni. Ale tak nebo tak pristup pres Volume je mnohem cistejsi protoze tim davas na prvni dobrou najevo ktere slozky maji byt persistentni.. oddelis tak bezstavovy kontejner (a ano kontjener CHCES mit bezstavovy) od stavovych dat..
-
No dve veci
1) pokud chces menit editovat entrypoint je mnohem lepsi sahnout primo do Dockerfile zmenit to tam a zbuildit si upraveny image..
2) jak uz tu padlo velmi casto je to znamka spatneho navrhu pokud tu resis backup tak od toho tu slouzi spis
Volumes.. namountujes si do kontejneru slozku a backupovat muzes z hosta alternativne pokud to nechces resit na hostu tak muzes ten volume namountovat do druheho kontejneru kde pobezi prave JENOM ssh. a budes to zalohovat "z boku"
je to mnohem cistejsi reseni. Ale tak nebo tak pristup pres Volume je mnohem cistejsi protoze tim davas na prvni dobrou najevo ktere slozky maji byt persistentni.. oddelis tak bezstavovy kontejner (a ano kontjener CHCES mit bezstavovy) od stavovych dat..
Díky, ale jak píšeš to prostě nelze realizovat. Protože ta aplikace (Seafile) používá nějaký filesystem jako Git a já prostě potřebuju odzálohovat normální adresářovou strukturu. Takže v kontejneru se musí použít fuse mount filesystem-ala-git /nějaký cílový adresár a pak jsou vidět normálně adresáře a soubory.
Umím spustit zadat v docker-compose.yml příkaz - třeba command: sh -c "echo "baeldung" && echo "docker" ", ale problém je v tom, že když to celej ten stack (3 kontejnerů vytvoří), tak to spouští pořád dokola ten kontejner co obsahuje command . Já potřebuju aby se ten příkaz spustil jen jednou po startu kontejneru a ten běžel stejně dál, jako beží když ten command výše v docker-compose.yml vůbec nemám...
-
Urcite to realizovat jde :) i primo u nich na foru jsou na to navody ukazky pokud ty data jsou na disku tak to proste z definice jit musi.
Trochu se desim ze si rozbehavas reseni ala seafile kde bych potencialne chtel mit data o ktere NECHCI prijit a plaves v zakladech.
Ten kontejner se ti otaci protoze kontejner NENI VMka.. tim ze tam das command tak on pusti kontejner a pusti command ten command je "init" podobne jako kdyz poustis distro tak prvni proces je "init" (proces s id 1) a vsechny ostatni procesy jsou jeho potomci. Ve chvili kdy skonci / umre INIT tak konci vsechno.
Tzn pokud sis jako command dal "echo whatever" tak ten echo je "init" a ve chvili kdy skonci tak skonci cely kontejner protoze tam proste nema co bezet. musis si napsat vlastni shell skrtip / nainstalovat tam supervisord (pres Dockerfile)
tohle v docker-compose delat nechces (ne ze by to neslo ale bude to zlo budes se skrabat pres 3 ramena a nemam moc jak ti poradit).
-
Urcite to realizovat jde :) i primo u nich na foru jsou na to navody ukazky pokud ty data jsou na disku tak to proste z definice jit musi.
Trochu se desim ze si rozbehavas reseni ala seafile kde bych potencialne chtel mit data o ktere NECHCI prijit a plaves v zakladech.
Ten kontejner se ti otaci protoze kontejner NENI VMka.. tim ze tam das command tak on pusti kontejner a pusti command ten command je "init" podobne jako kdyz poustis distro tak prvni proces je "init" (proces s id 1) a vsechny ostatni procesy jsou jeho potomci. Ve chvili kdy skonci / umre INIT tak konci vsechno.
Tzn pokud sis jako command dal "echo whatever" tak ten echo je "init" a ve chvili kdy skonci tak skonci cely kontejner protoze tam proste nema co bezet. musis si napsat vlastni shell skrtip / nainstalovat tam supervisord (pres Dockerfile)
tohle v docker-compose delat nechces (ne ze by to neslo ale bude to zlo budes se skrabat pres 3 ramena a nemam moc jak ti poradit).
Tak jasně, že to jde z hosta, třeba pomocí rclone, což je ještě větší opruz než toto a musí se to dělat po jednotlivých uživatelích. Jinak o naše data fakt starosti mít nemusíš, víme jak zálohovat, nikdy jsme o data nepřišli ani po ransomware ani selhání hw/disků.
Fascinuje mě, jak na jednoduchý dotaz "jak nastartovat ssh" po spuštění cont. vznikne mnoho textu, ale ani jeden řádek, který bych vložil do docker-compose.yml (ať už rovnou command nebo script z připojeného volume), který by vyřešil požadované.
Ano, tohle neumím a proto se na to ptám. Samozřejmě můžu celou aplikaci Seafile nainstalovat do VM, ale to jaksi není práce na 2min, jako při použití kontejneru (což je i preferovaný způsob instalace developera tohoto sw).
Tím supervisorem to určitě taky jde, nicméně i ten supervisor je třeba nějak spustit (nejspíš stejně jako by se spouštělo to shh či nějaký jiný script).
Takže ještě jednou prosím někoho kdo to ví, jestli poradí. Myslím, že takováhle prkotina musí jít levou zadní. A myslím, že asi nebudu jediný, komu se to může hodit, aby ssh bylo nastartované i po restartu kontejneru.
-
Ono totiz to co chces jednoduse NEJDE takze JEDNODUCHOU odpoved tu proste nedostanes.. nekolikrat jsem ti tu rekl ze aby jsi toho dosahl musis editovat Dockerfile a upravit si entrypoint. Ted bych ocekaval ze se podivas na to jak se edituje Dockerfile co je to vlastne ten entrypoint jak se s nim pracuje.. a budes mit pripadne dalsi otazky. Jestli cekas ze to za tebe cele napisu tak promin mam sve prace dost.
Druha vec je ze to co delas proste neni spravne a driv nebo pozdeji se ti to vymsti. Priznavas ze jsi v tom zacatecnik a chtel bys poradit ale kdyz ti rikame takto to neni dobre tak nam vysvetlujes ze presne takle je to spravne.. ok pak ses v tom ale sam.
-
Ono totiz to co chces jednoduse NEJDE takze JEDNODUCHOU odpoved tu proste nedostanes.. nekolikrat jsem ti tu rekl ze aby jsi toho dosahl musis editovat Dockerfile a upravit si entrypoint. Ted bych ocekaval ze se podivas na to jak se edituje Dockerfile co je to vlastne ten entrypoint jak se s nim pracuje.. a budes mit pripadne dalsi otazky. Jestli cekas ze to za tebe cele napisu tak promin mam sve prace dost.
Druha vec je ze to co delas proste neni spravne a driv nebo pozdeji se ti to vymsti. Priznavas ze jsi v tom zacatecnik a chtel bys poradit ale kdyz ti rikame takto to neni dobre tak nam vysvetlujes ze presne takle je to spravne.. ok pak ses v tom ale sam.
No a já ti zase říkám, že to jde... Entrypoint jde specifikovat i v docker-compose.yml. Jen já to neumím či někde dělám nějakou syntax chybu. A ty to evidentně neumíš taky, ale jinak jsi profík :-)
A mám fakt strašně nahnáno, jak se mi to vymstí, že budu mít připravenej ssh přístup po startu cont. :-))))
Tak se věnuj své důležité práci a neobtěžuj se vypisováním hovadin :-) On mi poradí třeba nějakej skutečnej profík nebo holt dogooglím.
-
Ať už při vytváření image nebo při startu kontejneru můžete určit, co se má spustit. A to něco může být klidně skript, který vám nastartuje více procesů.
Ale takový postup je špatně. V kontejneru má běžet jenom jedna služba. Pomocí SSH se nemáte připojovat do kontejneru se službou, ale na hosta, odkud se připojíte do kontejneru.
On mi poradí třeba nějakej skutečnej profík nebo holt dogooglím.
Profíci vám tu radí. ALe pokud si myslíte, že to víte líp, než oni, nechápu, proč se tu ptáte. To, že se vám nelíbí rada, která je správná, není problém té rady.
-
Problem toho pristupu ale vubec neni v bezpecnosti a v tom ze tam pobezi SSH to je prave to co nechapes..
Problem je to ze kdyz sahnes do entrypointu tak uz celkem dost sahas nastaveni kontejneru jako takoveho autor ho ma odladeny otestovany a dela tam spoustu veci kterym ON rozumi a ktere tam musi z nakeho duvodu byt.
Ve chvili kdy ten entrypoint prepises tak menis inicializacy celeho toho udelatoru co tam startuje muze to fungovat / nemusi. To samo o sobe jeste problem neni na to prijdes opravi se to a nak to pobezi ale pak autor vyda novou verzi image kde neco zmeni prida tam nake nastaveni ty to pouzijes a ono to v tom lepsim pripade nenabehne. V tom horsim pripade to nabehne ale vlivem toho ze jsi tomu sahnul do initu se bude dit naka velmi nepekna vec na kterou prijdes treba az za pul roku a udela tvuj den nestastnym..
Pripadne prijde naky kolega ktery ma o chlup vetsi znalosti nez ty a bude cekat ze je to vyresene tak jak je to spravne jak se to delat ma tim ze mu narusis tenhle predpoklad mu taky zpusobis nepekne chvilky.
Nerikam ze to nejde ale prave proto ze se v tom tolik neorientujes bych se tuplem drzel doporuceni. To co chces sice jde parkrat jsem to pouzil ale vzdy jako krajni moznost (a vetsinou se mi to dlouhodobe vymstilo prave na maintanance cost).
-
Ať už při vytváření image nebo při startu kontejneru můžete určit, co se má spustit. A to něco může být klidně skript, který vám nastartuje více procesů.
Ale takový postup je špatně. V kontejneru má běžet jenom jedna služba. Pomocí SSH se nemáte připojovat do kontejneru se službou, ale na hosta, odkud se připojíte do kontejneru.
On mi poradí třeba nějakej skutečnej profík nebo holt dogooglím.
Profíci vám tu radí. ALe pokud si myslíte, že to víte líp, než oni, nechápu, proč se tu ptáte. To, že se vám nelíbí rada, která je správná, není problém té rady.
Pane Jirsáku, vás třeba jako profíka beru. A chápu, že to není asi best practice to co chci:-) Ale...
Když nejdřív "někdo" poradí Supervisor, ale neřekne jak ho vlastně spustit, tak se dostáváme opět na začátek, že. A to fakt profi není nehledě na to, že to stejně není best practice evidentně tak jako tak v případě kontejnerů.
Ale dobrá, už to mám vyřešené, spuštění ssh přidané do entrypoint scriptu. Ssh po restartu kont. jde.
Nicméně by mě stejně zajímalo, jak by se to vyřešilo lépe a správně, když podmínky jsou takovéto:
1) Seafile sw má spec. filesystém, je třeba uvnitř kontejneru stejně spusti fuse mount, aby byla vidět normální adresářová/souborová struktura
2) Zkoušel jsem i fuse mount do adresáře hosta. Mount proběhne v pořádku, ale na hostu soubory v daném adresáři vidět nejsou
3) Z důvodu 2 jsem přistoupil na pravidelné odzálohování (či spíše vykopírování) fuse mount složky pomocí rsync/ssh. Zálohy samotné jsou řešeny několika Proxmox Backup Servery.
4) Fakt si neumím představit, že Seafile se po..... ať už hw nebo sw nebo ransomware a někdo chce obnovit jenom určité soubory. To je fakt peklo bez klasické adr. struktury. Ale zase ten jejich FS je super na synchronizaci a je to třeba násobně rychlejší než Nextcloud.
Jestli existuje jednodušší/lepší řešení/spolehlivější(v čem?), klidně to předělám...
-
Ok takze jak bych to videl ja data mate predpokladam na Volume to proste musite jinak si koledujete o prusvih.
Seafile si na tom volume dela vlastni file system pres mount fuse tzn z venku to vidite jen jako Blob a vy by jste je chtel zalohovat po souborech ok dava smysl.
Tzn udelam novy kontejner do ktereho nainstaluju ten fuse co pouziva seafile. Do tohoto kontejneru namountuji ten samy volume (idealne Read only tim mam zaruceno ze data nepodelam).
Pustim normalne kontejneru seafilu nemusim se mu hrabat v init skriptech.
Vedlejsi kontejner ma namountovana data a bezi tam SSH pro rsync proc ne.
Komplikace bude udrzovat ten fuse modul ve stejne verzi jako ma seafile proto je tu varianta ze bych pustil znovu cely ten image seafilu (ten uz to ma nainstalovane) ale misto seafilu bych v nem pustil jen a pouze to SSHcko to uz umite...
Vyhoda: kdyz budete upgradovat seafile tak proste jen zmenite verzi image, tim ze jste mu nesahal na entrypoint tak docela urcite nabehne. V "backup" kontejneru taky vzdy jen zmenite verzi na tu samou => budete mit garanci ze FUSE je v te same verzi data uvidite bez problemu.
Sahat do entrypointu budete ale nebude to tolik vadit tim ze v tom backup kontejneru pobezite "SVOJE" sluzby tak si za ne zodpovidate sam vite co se tam deje a mate to pod kontrolou nebudete se hadat s vedlejsimi procesy / nebudete se byt se seafilem
Takto nak bych to videl ja kdybych to chtel udelat jednoduse.. za sebe bych si radeji udelal mensi image pro ten backup a ten fuse tam nainstaloval rucne bude s tim vic jebani ale je to cistejsi a image bude vyrazne stihlejsi. (na druhou stranu ten image uz tam stejne mate kuli seafile samotnemu a docker ma deduplikaci celkem dobre zmaklou). Navic je to takto i bezpecnejsi protoze na data budete sahat jen pro cteni a muzete si kontejnery oddelit i na urovni uzivatelu..
-
To SR:
Hele, chápu, že jsi mi chtěl poradit, ale nějak to prostě nevyšlo, nebo nechápu ty výhody...
Moje instalace Seafile má samozřejmě persistentní Volume na data i databázi, jakýkoli upgrade celýho stacku funguje okamžitě.
A teď k tomu zálohování...
V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
-
To, že se to takto nedělá, má dobrý důvod. Kontejnery nejsou nic jiného, než abstrakce nad určitými vlastnostmi linuxového jádra. Z hlediska systému je kontejner proces (určitým způsobem nakonfigurovaný) a všechny jemu podřízené procesy. Když se ukončí hlavní proces (ať už sám nebo signálem zvenčí), ukončí i všechny podřízené procesy a tím se ukončí i kontejner. Když tam nastartujete bokem nějaký jiný proces, a hlavní proces se ukončí, zůstane vám běžet proces v neexistujícím kontejneru.
Používá se i to, že v kontejneru běží nějaké podpůrné procesy pro ten hlavní kontejner (řeší třeba logování, přístup apod.) – pak ale musí hlavním procesem v kontejneru být něco, co se o všechny ty podřízené procesy postará, ukončí je při ukončení hlavního procesu a předává informace mezi hostitelem a hostem. Tj. když se ukončí hlavní služby v kontejneru, ukončí se i ten správcovský proces a tím celý kontejner. Když přijde z venku signál k ukončení do toho správce, pošle to dál té hlavní službě.
Neznám ten vás konkrétní způsob použití. Ale pokud můžete nad daty (tj. ve vašem případě složkou, kde jsou data Seafile) pustit víc instancí aplikace, tak se zálohování řeší tak, že při zálohování spustíte druhý kontejner, který se připojí ke stejným datlům a zazálohuje je. Ten zálohovací kontejner běží jen po dobu zálohování. Má to i tu výhodu, že hlavní kontejner služby nemusí mít vůbec přístup k zálohám, takže kdyby vám někdo napadl tu hlavní službu, nemá možnost hned zlikvidovat i zálohy.
Vzhledem k tomu, že Seafile předpokládám udržuje i historii souborů, připadalo by mi logičtější zálohovat celý jeho adresář a v případě potřeby obnovy nad ním spustit druhou instanci Seafile, ve které najdete potřebnou verzi souboru a tu obnovíte. Akorát je potřeba dát pozor na to, zda ta záloha musí být konzistentní (k jednomu časovému okamžiku) nebo ne.
No a do třetice, Seafile chápu jako nějaké úložiště souborů – velmi by mne překvapilo, kdyby nějaké možnosti zálohování nemělo přímo vestavěné nebo zdokumentované. To je cesta, kterou bych osobně začal – použít prostředky přímo té aplikace.
Pokud by nic z předchozího nešlo, předpokládám, že fuse mount komunikuje s Seafile přes nějaký síťový protokol Seafile, takže ho klidně můžete spustit v jiném kontejneru a z toho jiného kontejneru provést zálohu. Tj. bylo by to podobné, jako první případ, ale nepřipojoval byste se přímo k datům Seafile, ale pomocí fuse mount byste se připojil k té běžící instanci Seafile „přes síť“. Byl oby nutné vyřešit, aby ten zálohovací kontejner viděl síťově na ten hlavní kontejner se Seafile, ale to je řešitelné.
Osobně bych se ale nejprve podíval na možnosti zálohování, která má předpokládám Sealfile vestavěné.
-
V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
Lepsi je to v tom ze jste takto sahl do zavadece seafile v tuhle chvili vam to treba funguje ale po zmene nemusi. Muze se v tom zavadeci neco zmenit muze se zmenit adresa /opt/seafile/seafile-server-latest/seaf-fuse.sh muze se stat cokoli vy nad tim nemate kontrolu mozna si rikate ze s kazdou novou verzi seafile budete kontrolovat obsah entrypointu ale to delat urcite nebudete.. bud na to zapomenete nebo vas nekdo vystrida.. autor vam dal otestovany funkcni kus kodu a vy jste sahl na jedno z jeho citlivich mist. v tu chvili jste ztratil veskere zaruky... ztratil jste jednu z vyhod proc se kontjenery pouzivaji.
Mozna to bude fungovat mozna ne mozna se to pokazi tak ze na to prijdete v tom lepsim pripade hned a opravite to snadno v horsim az po case a bude to bolet
-
To: Filip Jirsák
Pane Jirsáku, myslím že Seafile zálohování řešené nemá, nebo jsem to nenašel. Každopádně ani to jejich zálohování (pokud by existuje) vůbec není potřeba, celý kontejner/stack včetně VM nám zálohuje Proxmox Backup Server.
Seafile kontejner samotný nemá žádný přístup k zálohám. Pokud kontejner samotný umře, vůbec nic se neděje. Zprovozní se znova ze zálohy PBS. Pokud se někdy přeruší nedokončí rsync /zdroj seafile-fuse /cíl-někam, taky se nic nestane, proběhne znovu po obnovení funkčnosti Seafile kontejneru.
Nicméně, představte si situaci, že uživatel, kterého data se synchronizují na Seafile ztratí ntb, nepamatuje si přístup (jméno/heslo) nedej bože ztratí i tel., kde má 2FA. A v tom samém okamžiku lehne Seafile server. Obnovení dat ze zálohy bude rychlé, přístup bez hesla a 2FA není hned, ano admin samozřejmě může vyresetovat, vypnout 2FA. Nicméně pokud nutně potřebuje hned nějaký konkrétní soubor, hned to prostě nejde...
Pokud ale mám ještě další formu formu zálohy jasně čitelného filesystému pomocí kombinace rsync/fuse/proxmox backup server, je to otázka minuty.
Chápu, že best practice je jiný kontejner, který by řešil to vykopírování pomocí rsync/ssh, ale fakt v tom v tomto konkrétním případě nespatřuji vůbec žádnou výhodu, pouze kontejner navíc.
Ale každopádně děkuji za zajímavé postřehy.
-
Rozhodne samostatny kontejner ciste pro backup. Pokud nekde potrebujes supervisor tak je potreba hledat a rozebirat proc, protoze vetsinou (nerikam, ze vzdy) to znamena spatny navrh.
-
Rozhodne samostatny kontejner ciste pro backup. Pokud nekde potrebujes supervisor tak je potreba hledat a rozebirat proc, protoze vetsinou (nerikam, ze vzdy) to znamena spatny navrh.
Já supervisor nepotřebuji, pouze ssh. Supervisor byla rada od SH...
-
No, i tento pozadavek mi prijde ponekud zvlastni a zda se mi to byt rovnak na vohejbak, ale neznam ten seafile
-
V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
Lepsi je to v tom ze jste takto sahl do zavadece seafile v tuhle chvili vam to treba funguje ale po zmene nemusi. Muze se v tom zavadeci neco zmenit muze se zmenit adresa /opt/seafile/seafile-server-latest/seaf-fuse.sh muze se stat cokoli vy nad tim nemate kontrolu mozna si rikate ze s kazdou novou verzi seafile budete kontrolovat obsah entrypointu ale to delat urcite nebudete.. bud na to zapomenete nebo vas nekdo vystrida.. autor vam dal otestovany funkcni kus kodu a vy jste sahl na jedno z jeho citlivich mist. v tu chvili jste ztratil veskere zaruky... ztratil jste jednu z vyhod proc se kontjenery pouzivaji.
Mozna to bude fungovat mozna ne mozna se to pokazi tak ze na to prijdete v tom lepsim pripade hned a opravite to snadno v horsim az po case a bude to bolet
No nic, je vidět, že si stále nerozumíme...
Po upgradu stacku v entrypoint scriptu nic nebude, nebo tedy pouze to co obsahovala instalační image developera. Takže se nemá co podělat.
A mě stačí opět dopsat pouze znovu ty 2 řádky (ssh + fuse).
A pokud bych měl separátní kontejner pro to rsync/ssh vykopírování a změnila se image (a nějaké cesty v nové Seafile image), stajně bych to musel měnit/updatovat v tomto separátním kont. Stále tedy nevidím žádnou výhodu pro další separátní kontejner.
-
No, i tento pozadavek mi prijde ponekud zvlastni a zda se mi to byt rovnak na vohejbak, ale neznam ten seafile
Chápu a vím že to není úplně ideální, ale je to daný tím, že Seafile má filesystem jako Git či co. Kdyby to mělo normální filesystem tak se to odzálohuje z Volume na hostovi a pohoda...
-
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.
mam treba svuj mejlserver a nevidim duvod to mit v dockeru.
-
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.
mam treba svuj mejlserver a nevidim duvod to mit v dockeru.
Je to doporučená instalace developera Seafile...
-
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.
mam treba svuj mejlserver a nevidim duvod to mit v dockeru.
Je to doporučená instalace developera Seafile...
no kdyz chces, ale ja nepotrebuju veci kontejnerovat, takze i kdyz je neco primarne v dockeru, tak ja to nemam rad a vytahnu si to ven. zatim jsem nenasel duvod pro sebe docker pouzivat. chapu, ze je to fajn pro firmu s mnoha projekty a tunou hardware.
-
Pane Jirsáku, myslím že Seafile zálohování řešené nemá, nebo jsem to nenašel. Každopádně ani to jejich zálohování (pokud by existuje) vůbec není potřeba, celý kontejner/stack včetně VM nám zálohuje Proxmox Backup Server.
Ve vlastnostech uvádějí dva způsoby pro Backup and data Recovery (https://www.seafile.com/en/features/#:~:text=Backup%20and%20Data%20Recovery)
Zálohovat prostředky samotné aplikace obvykle bývá lepší – většinou tak získáte zálohy, se kterými se lépe pracuje. V krajním případě můžete zálohováním mimo aplikaci získat nepoužitelnou zálohu (představte si, že třeba aplikace přesouvá data ze souboru A do souboru B, a zálohovací program zazálohuje nejprve soubor B, když v něm data ještě nejsou, a pak soubor A, když v něm data už nejsou).
Seafile kontejner samotný nemá žádný přístup k zálohám.
To sice nemá, ale pořád při zálohování pouštíte kód uvnitř kontejneru Seafile. Takže útočník vám může posílat do záloh třeba zašifrovaná data, a teprve až budete mít všechny zálohy zašifrované, zašifruje vám i primární zdroj dat.
Pokud kontejner samotný umře, vůbec nic se neděje.
Pokud umře celý kontejner, opravdu se nic neděje. Pokud umře kontejner, ale zůstanou po něm nějaké běžící procesy, které byly spuštěné bokem, není to dobrá situace.
Nicméně, představte si situaci, že uživatel, kterého data se synchronizují na Seafile ztratí ntb, nepamatuje si přístup (jméno/heslo) nedej bože ztratí i tel., kde má 2FA. A v tom samém okamžiku lehne Seafile server. Obnovení dat ze zálohy bude rychlé, přístup bez hesla a 2FA není hned, ano admin samozřejmě může vyresetovat, vypnout 2FA. Nicméně pokud nutně potřebuje hned nějaký konkrétní soubor, hned to prostě nejde...
Pokud lehne Seafile server, je nejrychlejší vzít kompletní zálohu jeho dat (tj. včetně databáze a těch metadat a la git), zkopírovat to na nový server a nad tím spustit novou instanci Seafile. Ve vašem případě řešíte přístup jednoho uživatele k jednomu souboru. Ale pokud lehne Seafile server, pravděpodobně budete potřebovat obnovit všechny soubory, včetně historie, uživatelské účty, přiřazení oprávnění atd.
Chápu, že best practice je jiný kontejner, který by řešil to vykopírování pomocí rsync/ssh, ale fakt v tom v tomto konkrétním případě nespatřuji vůbec žádnou výhodu, pouze kontejner navíc.
To platíte kontejnery za kus? Nebo v čem je problém mít tam další kontejner? Kontejnerová technologie byla vymyšlená právě proto, aby jednotlivé služby byly oddělené. Ta otázka nezní: „Jaká je výhoda mít to v samostatném kontejneru?“ Mít to v samostatném kontejneru je standard. Otázka je opačná: „Je nějaký dobrý důvod, proč víc věcí sloučit do jednoho kontejneru, když to je proti principům kontejnerů?“ Nebo pokud mermomocí potřebujete odpověď na vaši otázku – dělat věci standardně je obrovská výhoda, zejména když používáte technologie, o kterých toho moc nevíte. Dělat věci nestandardně znamená akorát si přidělávat problémy, o kterých ani nevíte.
-
Pane Jirsáku, myslím že Seafile zálohování řešené nemá, nebo jsem to nenašel. Každopádně ani to jejich zálohování (pokud by existuje) vůbec není potřeba, celý kontejner/stack včetně VM nám zálohuje Proxmox Backup Server.
Ve vlastnostech uvádějí dva způsoby pro Backup and data Recovery (https://www.seafile.com/en/features/#:~:text=Backup%20and%20Data%20Recovery)
Zálohovat prostředky samotné aplikace obvykle bývá lepší – většinou tak získáte zálohy, se kterými se lépe pracuje. V krajním případě můžete zálohováním mimo aplikaci získat nepoužitelnou zálohu (představte si, že třeba aplikace přesouvá data ze souboru A do souboru B, a zálohovací program zazálohuje nejprve soubor B, když v něm data ještě nejsou, a pak soubor A, když v něm data už nejsou).
PBS je velmi spolehlivé a osvědčené řešení pro tento případ, nehodláme měnit. Zálohuje samotný systém Seafile i data.
Seafile kontejner samotný nemá žádný přístup k zálohám.
To sice nemá, ale pořád při zálohování pouštíte kód uvnitř kontejneru Seafile. Takže útočník vám může posílat do záloh třeba zašifrovaná data, a teprve až budete mít všechny zálohy zašifrované, zašifruje vám i primární zdroj dat.
Separátní kontejner kontejner by na tom v tomto případě byl úplně stejně. Nicméně napadení ransomware bychom poznali okamžitě. Záloha PBS z předchozího by byla dostupná.
Pokud kontejner samotný umře, vůbec nic se neděje.
Pokud umře celý kontejner, opravdu se nic neděje. Pokud umře kontejner, ale zůstanou po něm nějaké běžící procesy, které byly spuštěné bokem, není to dobrá situace.
Ano, zřejmě zůstane nějaký zombie proces až do restartu/obnovení fce. Vadí to ještě něčemu jinému?
Nicméně, představte si situaci, že uživatel, kterého data se synchronizují na Seafile ztratí ntb, nepamatuje si přístup (jméno/heslo) nedej bože ztratí i tel., kde má 2FA. A v tom samém okamžiku lehne Seafile server. Obnovení dat ze zálohy bude rychlé, přístup bez hesla a 2FA není hned, ano admin samozřejmě může vyresetovat, vypnout 2FA. Nicméně pokud nutně potřebuje hned nějaký konkrétní soubor, hned to prostě nejde...
Pokud lehne Seafile server, je nejrychlejší vzít kompletní zálohu jeho dat (tj. včetně databáze a těch metadat a la git), zkopírovat to na nový server a nad tím spustit novou instanci Seafile. Ve vašem případě řešíte přístup jednoho uživatele k jednomu souboru. Ale pokud lehne Seafile server, pravděpodobně budete potřebovat obnovit všechny soubory, včetně historie, uživatelské účty, přiřazení oprávnění atd.
Opět, řešeno pomocí PBS, pokud server lehne komplet.
Chápu, že best practice je jiný kontejner, který by řešil to vykopírování pomocí rsync/ssh, ale fakt v tom v tomto konkrétním případě nespatřuji vůbec žádnou výhodu, pouze kontejner navíc.
To platíte kontejnery za kus? Nebo v čem je problém mít tam další kontejner? Kontejnerová technologie byla vymyšlená právě proto, aby jednotlivé služby byly oddělené. Ta otázka nezní: „Jaká je výhoda mít to v samostatném kontejneru?“ Mít to v samostatném kontejneru je standard. Otázka je opačná: „Je nějaký dobrý důvod, proč víc věcí sloučit do jednoho kontejneru, když to je proti principům kontejnerů?“ Nebo pokud mermomocí potřebujete odpověď na vaši otázku – dělat věci standardně je obrovská výhoda, zejména když používáte technologie, o kterých toho moc nevíte. Dělat věci nestandardně znamená akorát si přidělávat problémy, o kterých ani nevíte.
Chápu. Problém dalšího kontejneru není. Ale i ten další kontejner rozhodně nebude dle všeho výše uvedené best practice a je to další CT/VM ke správě oproti 2 řádkům nestandardu.
Ale nechápejte to prosím tak, že tento postup rozporuji, jen mi přijde v tomto konkrétním případě nic nezlepšující, naopak práci přidělávající...
-
To: Filip J.
Nebo se zeptám ještě jinak. Jaký by byl rozdíl, kdyby to nebyl CT ale VM s ssh serverem, a ta VM by chcípla stejně jako ten CT? Mě to přijde dost podobný, ne-li stejný, tedy ty následky...
CT je méně náročný na prostředky, kernel bere z hosta a je ideální na jednorázové věci, super rychle startuje atd. My CT spíše používáme na testovací věci, pokud developer daného sw přímo nedoporučí pro produkci.
-
Nebo se zeptám ještě jinak. Jaký by byl rozdíl, kdyby to nebyl CT ale VM s ssh serverem, a ta VM by chcípla stejně jako ten CT? Mě to přijde dost podobný, ne-li stejný, tedy ty následky...
CT je méně náročný na prostředky, kernel bere z hosta a je ideální na jednorázové věci, super rychle startuje atd. My CT spíše používáme na testovací věci, pokud developer daného sw přímo nedoporučí pro produkci.
Ve virtuálním stroji vám běží celý operační systém, který je stavěný na to, že v něm běží spousta nesouvisejících služeb. Proto máte v distribucích typicky systemd nebo nějakého jiného správce služeb, který se stará u jejich běh.
Kontejnery jsou dělané pro běh jedné služby. Nic vám nebrání v kontejneru provozovat skoro celý operační systém se spoustou služeb, ale není to něco, k čemu by byly kontejnery určené. A je pak na vás, abyste věděl, co děláte, a správně to nakonfiguroval a provozoval.
Když „chcípne“ VM, znamená to, že přestal běžet celý ten OS. Když „chcípne“ kontejner, znamená to, že se ukončil proces, který tvořil ten kontejner, a OS ukončí jeho potomky. Pokud z toho kontejneru byly nastartované nezávislé procesy, které nejsou potomkem toho hlavního procesu, ty vám zůstanou v systému běžet, protože už nemají žádnou vazbu k tomu hlavnímu procesu.
Kontejnery nejsou nic jiného, než procesy izolované pomocí cgroups už na úrovni jádra operačního systému. Jádro nezná žádnou entitu „kontejner“ – kontejner je jenom naše označení pro procesy nakonfigurované určitým způsobem.
-
Mimochodem, zásadní chyba je už to, že v tom obrazu vůbec sshd je. (Což je samozřejmě chyba autora toho obrazu, ne vaše). Ale je to další důvod, proč na to nespoléhat – protože v další verzi obrazu to sshd být nemusí a vám pak přestane vaše zálohovací řešení fungovat.
-
Mimochodem, zásadní chyba je už to, že v tom obrazu vůbec sshd je. (Což je samozřejmě chyba autora toho obrazu, ne vaše). Ale je to další důvod, proč na to nespoléhat – protože v další verzi obrazu to sshd být nemusí a vám pak přestane vaše zálohovací řešení fungovat.
Jo, jo, to samozřejmě beru včetně vašeho min. příspěvku a chápu.
Tak myslím, že asi nejlepší bude to přemigrovat z CT na VM a bude klid.
Díky a pěknej víkend...