Otthoni nextcloud raspberry pi és docker segítségével

Van egy owncloud példányom egy bérelt LXC konténerben. Arra használom hogy a személyes és munka fájlok három példányban legyenek fenntartva (két laptop + szerver), vinyó hiba vagy ellopás esetére. Nem elégít ki mindenfajta extrém backup igényt (inkcremental, daily, encryption, stb..), de parasztos backupnak jó. Plusz arra, hogy random embereknek át tudjak adni fájlokat úgy hogy ne kelljen google-öznöm (privacy rocks).
Már jóideje használom, még OpenVZ-ként adták amikor elkezdtem. Sajnos nem bizonyult futureproof megoldásnak, legalábbis hagytam elenyészni. Egy turnkey -es kiadás volt, amire felhegesztettem a lets encryptet és hagytam futni. Már akkor is el volt forkolva a nextcloud és azóta csak még jobban elhúzni látszik ismertség és fejlődés terén. (és az androidos app nem fizetős). Mivel borzasztó munka lett volna a 7-es owncloudról áttérni egy mai nextcloudra, inkább körülnéztem hogy az otthon cicergő raspberryk esetleg nem tudnának-e segíteni ebben.
Arról nem beszélve, hogy a providerem és én sem tudunk rájönni hogy mi az anyámért shutdownol random időközönként ez a cucc az openvz -ről lcx-re migrálás óta, így inkább lemondom a szolgáltatást, mert kényelmetlen volt hetente bekapcsolgatni. Plusz a hugom is használja két dolgozós laptoppal, így szeretném ha megbízható szolgáltatást kapna ő is.
(igen, végignyálaztam az összes logot és a shutdown eventeket, senki nem tört be, nekem úgy tűnik hogy kívülről jön a kikapcsolós parancs).

Vissza a raspberrykhez:
Három van:
- rpi1: playback only, hálószoba, másra már nem futja szegénynek
- rpi3: playback only, nappali, libreelec: újra kéne telepíteni mert a libreelec nehezen bővíthető, és a storagenek szóba jöhető NAS esetleg jobb ötlet
- rpi3 másik: openmediavault, ami tkp egy standard uptodate armhf debian, csak rá van telepítve az omv. Erre egyébként is rá van kötve egy 3TB-os vinyó, amin a linux isok torrenteződnek és játszódnak le, többszáz gb helyem van még, jó lesz ez!

Eszembe jutott, hogy docker már van raspberry -re, nézzünk körül hogy van-e használható docker image a célra. (sokak által letöltött, dokumentált, forráskódot biztosító csapat - nem pistike dockerfile nélküli binárisa).

Pár órát elütöttem közepesen amatőr konténerekkel, amikor rábukkantam a tutira.

Ez egy NextcloudPi nevű valami ( https://ownyourbits.com/2017/06/08/nextcloudpi-docker-for-raspberry-pi/ ), ami nem csak arm, hanem sima x86os docker konténereket is ad. Ezekben a konténerekben korrektül fel van setupolva egy nextcloud (ez eddig uncsi), viszont adnak fölé egy rendszerszintű taskokat megkönnyítő webes felületet (ettől plus).
Essünk neki:
- usb vinyó átdug laptopra, gparted -el adok 500GB helyet egy partíciónak a jobb szélén: bőven elég lesz, a mostani helyem tokvonóval 50GB a szolgáltatónál (38gb a saját részem, pár gb a hugomé)
- usb vinyó visszatesz az omvre
- tegyük fel a dockert az rpire: curl -sSL get.docker.com | sh
- állítsuk le a docker engine -t, töröljük a /var/lib/docker mappát, hozzunk létre az usb vinyón egy "docker" nevű mappát, és symlinkeljük át
- indítsuk el újra a docker enginet: innentől kezdve a docker engine az usb vinyót dolgozza, nem az sdkártyát
- jöhet a router: regisztráljunk egy új duckdns.org -os nevet, és setupoljuk be az autorenew -t a routeren (ddwrt)
- némi port forward, hogy kívülről elérjem: 80->80, 443->443.
- a leírás alapján indítsuk be a konténert: docker run -d -p 443:443 -p 80:80 --name nextcloudpi ownyourbits/nextcloudpi $DOMAIN (a leírás szerint nem árt egy külső mappát bemountolni, de nekem ez nem kell, bőséggel van hely a docker workdirben, és egyébként sem kell látszódnia annak a fájlrendszernek, elég ha a docker dolgozgat benne)
- az első indítás 1-2 perc, mire mindent összerak magának
- da bum ts. Az első belépéskor generál egy eldobható jelszót a sima nextcloud adminnak és a plus adminnak is, létrehozom az useremet
- törlöm a laptopokról az owncloud klienst, felteszem a nextcloudot. Ekkor mindkét laptopon azonos tartalom van, így az egyik feltölti a szűz szerverre a cuccost, a másik meg csak végigellenőrzi hogy stimmel-e
- profit
- na jó, de nézzük meg, hogy mit tud ez a plus:
-- csak a számomra fontosat írom le: beépített letsencrypt támogatás. na, ez már izgi lehet. a lets encrypt ugye abból áll, hogy egy script ellenőrzi hogy az általad igényelt domain mögött elérhető resource a te ellenőrzésed alatt áll, ezáltal megbízik abban, hogy Béláé a béla.duckdns.org. Ezt nem nehéz összehozni, de némi munkával jár. hát itt nem. konkrétan megnyomsz egy gombot, és a domain feletti kontroll ellenőrzés automatikusan megtörténik, a cert pedig telepítődik a megfelelő helyre: 30 másodperccel később kizöldült a lakat ikon a böngészőben, effort nélkül, nem rossz!
- ha már nextcloud, és van ingyenes app telefonra, akkor tegyük fel, hogy a kamerával lőtt képek azonnal mentődjenek, meg a contact listemet se kelljen kézzel mentegetni, ez is körülbelül 2p

Tegnap óta fut, eddig stabilnak tűnik, felment a 38gb adat, most éppen lefelé megy a másik gépre, már csak huginak kell átkonfolni a laptopját, és mehet a lemondás. Nem a havi 1600+áfa miatt, hanem amiatt, hogy ingyen kapok egy általam felügyelt, mégis gyerekjáték módszerrel telepített rendszert, ami mindenfajta szempontból jobb, mint eddig.

Aki a sebességekre kíváncsi, etherneten 6-10 mbyte/s körül mozog, nem egy erőmű, de nekem elég. Ha nagyobb sebesség kéne, veszek egy újfajta rpi3at, abban sokkal erősebb az usb host controller, ráadásul elég átdugni az sdkártyát és megy tovább. :)

Összetevők, ami kell:
- duckdns fiók, vagy saját domain, amit valami megoldással auto frissítünk, ha megváltozna az otthoni ip cím
- port forward és dyndns támogatású router firmware (ddwrt, openwrt, gyakorlatilag bármelyik jó, ami egyedi HTTP kérést tud összerakni)
- raspberry pi (lehet hogy már a 2 is jó, én 3-at vagy 3+ -t ajánlok)
- külső usb vinyó
- egy kis idő

Esetleg még jobb lenne
- port forward helyett vpn mögötti elérés: kényelmetlenség, mert a céges openvpn mögött nemigen tudom hogyan openvpnezzek tovább, plusz a random embereknek fájlokat adok át sztori is bukó
- swraid1 mögé berakni két ugyanilyen vinyót, hogy a szerver oldal durable-ebb legyen
- raspi helyett egy erősebb vas - jelenleg nincs rá igény

ps.:
A dockert több mint 2 éve alkalmazzuk különböző nagyobb céges projekteken, és egészen meglepő volt dolgozni vele raspberryn. Ez nem valami unofficial hack, hanem hivatalos docker. :) Persze nem tudja emulálni az x86os konténerek számára a hardvert, így csak kifejezetten arm -ra buildelt imageket tud felnyalni, viszont ha olyant indítasz, az egész procedúra és eszközök pontosan ugyanúgy működnek, nagyon jó!

Hozzászólások

Hasznos leírás, köszönjük!
Hasonlókkal is munkálkodok egy ideje, csak eddig docker nélkül. RPI-kből és BPI M2+-ból mindenféle média, letöltő, megosztó, lejátszó, Openmediavault, adatmentő gépek barkácsolása és üzemeltetése. Nextcloud is, csak eddig normál módon. De most már ki fogom próbálni a docker-es verziót is.
RPI-kkel melegedés problémád nem volt eddig például folyamatos nagy fájlok átvitele közben? Nemrég egy új RPI 3B+ került beállításra adatmentő gépnek UrBackup-al és Syncthing-el és bizony nem mertem otthagyni állandó üzemre alap sebességeken mert felment adat másolás közben 70 fok fölé és még nincs is igazi 35 fok környéki nyár. Tudom hogy elvileg leveszi magát ha túl meleg, de talán nem egészséges neki se egy 80 fok környéki folyamatos üzem, amikor a Win-es gépekről az adatot rántja le magára. Inkább levettem a CPU-t 1000 MHz-re és a LAN sebességét a kb. 30MB/s-ról 15MB/s-ra. Így teljes hálózati terhelés közben is 60-65 fokos tartósan. Passzív hűtő blokk persze van rajta, a gép a gyári piros-fehér műanyag dobozában csücsül.

Szerintem nyugodtan ne foglalkozz a hőmérséklet témával. Egyrészt nem fog odaégni, másrészt a SoC és a board gyártók nagyon is tudják hogy terhelni szoktuk ezeket a lapokat, így szerintem ~90 fokig egyáltalán nem érdekes a téma. Benne van a normál üzem definíciójában.

szerk.: a kérdésre is válaszolok, nem nagyon figyelem a hőmérsékletet. Éppen egy lassabb wifis kliens tölt le róla, 51 fokos.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Baró!
Még egy téma amivel ideje lenne foglalkozni...
Az a helyzet, hogy leragadtam a virtualizációnál. Pedig a konténer mint téma többször feljött mostanság.

Eddig hogy érzed?
- Mennyire biztonságos a virtuális gépekhez képest?
- Mennyire gyors?
- Könnyebb/Nehezebb üzemeltetni?
- Lehet mondjuk ezzel a módszerrel windowsos programokat futtatni Linuxon?

Az a nagy különbség, hogy nekem nem kell tanulnom ilyesmir, de pl a jómodort megtartom azoknak, akik megérdemlik.
Te pl a jelek szerint nem érdemelsz egy RTFM válasznál többet, egyetlen kérdésedre sem. :D
Főleg, hogy ezekszerint a "jó modor" jelentésével sem vagy tisztàban.

"Mennyire biztonságos a virtuális gépekhez képest?"

Kevésbé, mivel a konténer ugyanaz a kernelt használja mint a host, lényegében egy chroot-olt környezet.

"Mennyire gyors?"

Sokkal gyorsabb mint a virtualizáció, kb mint ha nem is lenne konténerben.

"Könnyebb/Nehezebb üzemeltetni?"

Sztem könnyebb üzemeltetni, mint egy virtualizált környezetet, a frissítések sokkal egyszerűbben mennek.

"Lehet mondjuk ezzel a módszerrel windowsos programokat futtatni Linuxon?"

Nem, mivel a gazda rendszer kernelét használja.

""Mennyire biztonságos a virtuális gépekhez képest?"

Kevésbé, mivel a konténer ugyanaz a kernelt használja mint a host, lényegében egy chroot-olt környezet."

Ezt tovább erősíteném. Annak a mezei (nem root) usernek, akinek joga van Dockerezni, gyakorlatilag root felhasználó lesz a host gépen. Tehát a biztonságnál oda kell arra figyelni, hogy csak az az user dockerezhessen akiben maximálisan megbízunk. Ettől eltekintve "biztonságos", tehát a dockerhez nem hozzáférő local userspace nem tud beleolvasni a konténer tartalmába.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Dettó, igazából még én se dockereztem rendesen.
Mivel windows-t használok munkakörnyezetre így sajnos eleve mindent vbox-ban futtatok, így külön van minden projektre dedikált devserverem.

Én arra jutottam, hogy a kettőt összehasonlítgatni felesleges, mindegyiknek megvan az előnye és hátránya - inkább annak nézz utána, hogy mit tud a docker és hol jönne jól néhány fícsöre ami miatt válthatnál.

A Docker for Windows segítségével (Win10-en csak asszem) "natív" Dockered lesz. Annyiban natív hogy nem kell vboxot telepítened, és a korábbi kókánnyal szemben (boot2docker vagy mi) a háttérben sem kreál virtualboxos gépeket, hanem a Hyper-V -t használja belül, de ezzel neked nem kell foglalkoznod. Szintúgy a Docker for Mac egy (azt hiszem) xhyve -ot használ, de szintén "embedded" módon.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Azért a Docker for Mac messze nem olyan, mint a Linuxos Docker. Kicsit olyan, mint a virtuális gép, dedikált CPU-t és memóriát kell adnod neki.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

valami hasonlot hasznaltam en is (nem ugyanez a marka).
Tonkrement az egyik diszk. Sose tudta ujraszinkronizalni, hiaba tettem bele egy ugyanolyan diszket. Raadasul semmi se utalt ra, hogy mit mire fog szinkronizalni (az ureset az adatokra, vagy forditva).

Szoval a 4tb-os vinyot lementeni, kiprobalni a szinkronizalast, hatha megy (2 nap utan feladtam), szoval nemigen mukodott...

---
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....

Ennek a beleben van kis piktogramkupac, hogy mit tegyel, ha melyik lampa piros. Es rendben szinkronolt az elejen a 1.5T WD a 3T toshibaval (1.5T latszott), aztan meg a ket 3T toshiba, es kezzel noveltem a filerendszert utana.

Nem volt vele gondom - de backuppal keszultem en is. :DDD 100euro 4T, + egy kis ido az rsync-re.

De el tudom kepzelni, hogy mas termek zarojelben hagy hiba eseten...

OFF
de engem ez a lépés mindig elborzaszt:

curl -sSL get.docker.com | sh

Több szempontból is... sőt igazából nehezemre esik bármi olyat találnom benne, ami helyesnek lenne nevezhető.
/OFF
---
Régóta vágyok én, az androidok mezonkincsére már!

Amúgy megtettem, és rögtön fel is tűnt, hogy #!/bin/sh, ehhez képest van benne pár - "bash-izmusnak" ugyan nem nevezhető - de legacy sh-van biztosan inkompatibilis megoldás. Csendben épít arra, hogy /bin/sh valamelyik újabbkeletű shellnek (bash, dash, zsh) a kompatibilitási módja. Elegánsnak azért nem nevezném.
---
Régóta vágyok én, az androidok mezonkincsére már!

Lehet hogy nem elegáns de a Docker valamikor 2013 körül kezdett el megjelenni, így garantáltan nem teszik fel legacy rendszerre. A kernel sem lehet régebbi 3.16-nál afaik (vagy akörül).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Mi már két éve is szállítottunk komplett greenfield pénzügyi rendszert, docker és openshift alapon. Az elfogadotton szerintem bőven túl vagyunk. Azt viszont nem várhatja senki, hogy mindenhova beegye magát. Ellenállás és másfajta ötletek mindig lesznek.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Hasznos, köszi!
Ez is még egy dolog, amibe bele kéne ásnom magam...

---
| Dropbox |