Docker pe Raspberry Pi

Revenind la docker...
Am zis "hai sa vad si eu care-i treaba cu pi-hole". Am ajuns la setarile astea.
Explicati-mi si mie ce-s map-urile din imagine. 2019-09-28 08.36.27.jpg

Eu am inteles ceva de genul ca directorul din stanga este in container si continutul poate fi accesat de pe host in directorul din dreapta. Dar cum se intampla asta efectiv? Fisierele unde sunt fizic stocate? In container sau pe host? Ce se intampla daca directorul de pe host nu e accesibil? Pot folosi un director din retea? Un stick USB?
 
  • Haha
Reactions: Neo
Invers. Containerul e o imagine read-only. Calea din interiorul containerului trebuie să o mapezi altundeva pe host, într-un folder ales de tine, pentru ca aplicația să poată scrie chestii persistente undeva.
 
OK, deci ce se intampla daca acel director nu exista sau e gol cand porneste ce-i in container? Sau nu e stabilit, gen "Las' ca vezi tu..."?
 
puterfixer said:
Ză instracșăns.

1. Pregătirea Raspberry Pi:

Descarci Raspbian (Lite) și-l scrii pe un microSD folosind Balena Etcher.

Pe cardul microSD o să găsești 2 partiții, una boot și alta linux. Pe cea de boot pui în folderul rădăcină un fișier gol cu numele ssh (fără extensie) pentru ca să se activeze serviciul SSH direct, fără să trebuiască să pui monitor și tastatură. De asemenea, mai modifici fișierul config.txt adăugând la sfârșit:

Code: 
dtparam=spi=off
dtparam=audio=off
start_x=0
enable_uart=0
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
gpu_mem=16

Cu asta dezactivezi SPI, audio, UART, bluetooth și wifi dacă intenționezi să-l folosești doar pe fir. De asemenea, eliberezi din memorie din moment ce-l vei folosi headless și atunci GPU-ul nu are nevoie să rezerve memorie pentru grafică.
Click to expand...
Am adăugat respectivele la config.txt la rPi mk1 și acum am 64% RAM load de la 56% RAM load, vreo idee de ce? :biggrin:
 
Marius '95 said:
OK, deci ce se intampla daca acel director nu exista sau e gol cand porneste ce-i in container? Sau nu e stabilit, gen "Las' ca vezi tu..."?
Click to expand...

Imaginea din container are nevoie să scrie chestii pe disc. Nu o poate face ÎN container, fiindcă e imagine read-only. De-aia se bazează pe faptul că tu îi mapezi niște directoare read/write în afara containerului. Unde? Unde vrea mușchiul tău. Fără asta, n-am idee ce se întâmplă cu aplicația din container. Zice că nu poate porni fiindcă nu poate inițializa ceva fișier pe calea necompletată/nemapată? Pornește, da' își pierde setările de la o rulare la alta? Pornește, da' nu funcționează corect?

Pi-hole are nevoie de 2 directoare de-astea. Le-am făcut, goale. La prima pornire, și-a pus în ambele niște fișiere. Acolo, de exemplu, salvează listele de filtre selectate și descărcate, ca să nu le descarce la fiecare pornire a aplicației. Fișierele rămân persistente, le pot face backup, le pot modifica (când containerul e oprit). Dacă șterg conținutul lor, containerul își pierde setările.
 
Containerul face o copie a imaginii, tu poți modifica orice în container (ex: intri în consolă și apt-get sau yum whatever, merge perfect chiar dacă n-ai vreo mapare de volum) doar că nu vor fi persistate dacă omori containerul și faci altul. Dacă doar îi dai start/stop sunt persistate. Nu e o idee bună să faci asta (pentru că nu ai garanția persistării așa cum ai la un volum mapat de tine), dar se poate.
 
In container. De exemplu scoti imaginea de raspbian, o rulezi intr-un container cu /bin/bash si in consola faci apt update & apt upgrade. Opresti containerul, in momentul asta tot ce ai facut in interiorul lui e salvat doar acolo, local nu ai nimic. Containerul e mort si il poti sterge sau poti face din el o imagine noua in care vei avea update-urile facute. Daca vrei sa salvezi date, cum faci cu configuratiile din pihole, mapezi un folder si le tii acolo, in felul asta cand rulezi orice imagine de pihole vei mapa folderul acela.

Practic scopul e sa poti crea X containere in acelasi timp avand ca sursa aceeasi imagine pentru load de exemplu, apoi cand incarcarea scade si nu mai ai nevoie de toate containerele alea pastrezi doar unul. Avand mapat folderul ala local o sa ai datele salvate indiferent cate containere ai creat si cate ai ucis, altfel toate datele s-ar pierde in ele.
 
Dada, asta știu, ce întrebam este unde e fișierul, folderul sau ce e ăla unde se ține copia cu modificările pentru un anumit container? E o imagine diferențială sau o clonă completă? Adică dacă am o imagine de 1GB și rulez 10 containere de pe ea, mă voi trezi instant că undeva se vor mai consuma 10 * 1GB spațiu de stocare?
 
Se folosește același engine de layere ca și la crearea de imagini; tu pornești de la o imagine, mai adaugi ceva, faci altă imagine dar nu se copiază toată imaginea inițială în ultima, ci se mai adaugă un layer cu modificările tale. Fiecare layer are un hash care-i dă unicitate, astfel încât e recunoscut și refolosit. Totul e read-only cu copy on write, dacă ai modificat un fișier când ai creat imaginea a doua, acel fișier apare de 2 ori în definiția imaginii (prima dată din imaginea inițială, apoi cu modificările tale). Când se accesează un fișier se caută progresiv prin layere până se ajunge la el.

Containerul (runtime-ul imaginii) mai are un layer de același tip, doar că e read/write. Cu aceeași tehnologie, copy on write - când modifici un fișier din imagine, se creează o copie pe disc specifică pentru containerul tău și acolo apar modificările. Dacă modifici un fișier de 1 giga din imagine, well, trist :smile: (din câte știu nu știe acces la nivel de bloc, să-ți țină doar o parte din fișierul ăla de 1 giga). Fiecare container are propriul layer de tipul ăsta, așa că fiecare se distrează în incintă. Toate fișierele de genul ăsta sunt pe undeva prin /var/lib/docker - aici sunt și volumele, și layerele rw pentru fiecare container. N-aș recomanda modificarea fișierlor din layere direct din sistemul gazdă, dar din volume am mai modificat.

E util să știi cum monitorizezi spațiul ocupat de docker (https://blog.softwaremill.com/how-to-keep-your-docker-installation-clean-98a74eb7e7b3) pentru că are (sau avea, nu am mai urmărit) limitări legate de cât spațiu poate consuma pe sistem; în primele versiuni era fun când ajungeai la limită, că era un pic tricky să mai faci curat.
 
Last edited:
Na bun, 2 RPi 3B+ -uri au fost înlocuite de unul singur care rulează fericit Docker + Portainer + Pi-Hole + UniFi Controller, cu load mai mic decât instalate pe direct (!!!), cu temperatură mai mică, și muuuuult mai ușor de administrat. A trebuit să opresc containerul ăla care verifica automat dacă sunt versiuni mai noi de imagini încât să actualizeze singur toate containerele, fiindcă freca internetul o dată la câteva minute ca un disperat, și nici n-avea vreo modalitate de configurare.

Va urma instalarea unui nginx sau (mai probabil) traefik prin care să redirecționez traficul spre interfețele de administrare pentru mai multe Dockere, dacă li se suprapun porturile de rețea și nu mai merge să le mapez direct pe host.
 
Problemă. RPi 3b+ cu docker și toate alea pe el merge atât de frumos, că am rămas cu 2 RPi 3b+ nefolosite, plus RPi 2b-ul pe care rula OSMC dinainte să trec în principal pe Fire TV stick. Deci eu ce fac cu RPi-urile astea? :D
 
Le reciclezi, ca orice altă chestie obsolete. Și eu am pe undeva două bucăți de RPi 1 care n-au mai fost pornite de muult timp.
 
Mda, miahi are dreptate, sunt obiecte reciclabile.
Eu am un 2B+ care isi face treaba fara repros, dar cam se simte lipsa unui wireless. Totusi nu face nimic util in afara de a invata una-alta, asta e salvarea lui.
 
Dacă-s 3B+ le trimiți la mine să fac cluster din ele :D

Acum serios, sunt chestii faine, eu am unul făcut consolă retro cu retropie, altul este pihole, am un 4 primit cado cu care sper să apuc să mă joc cu Docker și mai sunt 1001 aplicații pentru chestiile astea. De exemplu, eu nu vreau smart TV, dar poți înjgheba un media player din rPi care să tragă chestii de pe NAS pe TV.

Poți face un media player haudiofil.


IDK. Sunt o grămadă de chestii faine pe care le poți face :)
 
You must log in or register to reply here.
Back
Top