Docker eller inte? Burk för NAS, Nextcloud, mysql, php, letsencrypt

Permalänk
Medlem

Docker eller inte? Burk för NAS, Nextcloud, mysql, php, letsencrypt

Håller på att sätta upp en server för NAS, nextcloud, webhosting (mysql, php) för flera domäner och har experimenterat lite med docker, docker-compose och portainer.

Fördelen med docker tycks vara att det är relativt modulärt och förhållandevis enkelt att sätta igång och skala upp, nackdel verkar finnas med uppgraderingar. Det skulle nog gå att köra allt utan docker, men med problemet att hela OS lär behöver plockas med eller virtualiseras om det skulle flyttas i framtiden.

Använde den här tutorialen för att få igång nextcloud
https://blog.ssdnodes.com/blog/installing-nextcloud-docker/
(nextcloud+nginx reverse proxy+letsencrypt+mariadb)

Tittar man på diverse tutorials för Nginx anger de ny reverse proxy, men antar att det enda rimliga är att det bara ska finnas en enda container med reverse proxy, så får återanvända denna?

- Om jag nu vill lägga till nginx, lägger jag till det i docker-composefilen jag har för nextcloud eller en separat? Samtidigt kanske det är rimligt att separera nginx och nextcloud från varandra för att hålla det modulärt. Vad är best practice? Hur ska man tänka gällande containertopologi? Man vill ju tex att nextcloud och nginx fungerar oberoende av varandra och kan plockas ner och ersättas av annat vid behov.

Har även kikat på SWAG https://docs.linuxserver.io/general/swag men kan inte se om det skulle underlätta eller inte.

Hur skulle ni lägga upp det?

Visa signatur

Propaganda syftar till att göra det politiska opolitiskt.

Permalänk
Medlem

Du verkar ha missuppfattat vad containrar (docker i detta fallet) är. Hela anledningen till att det vuxit fram är dess flexibilitet och just möjlighet till enkla uppdateringar.
Du kan kasta bort en container och starta en ny, från en ny image, utan att påverka hur den körs genom att separera programdata och användardata där användardatan är beständig och monteras in utifrån medan programdatan är ny för varje ny container.
Konfiguration och liknande ligger alltså utanför containern och allt du behöver göra för att uppdatera dina tjänster som du kört igång med Compose är:
'docker-compose down' (stoppar och tar bort containern)
'docker-compose pull' (hämtar ny avbilder)
'docker-compose up' (startar nya containrar)

En compose-fil skapar inte bara rn container utan en container per tjänst. Att separera compose-filen gör inget annat än att det blir enklare att hålla rätt på sina tjänster.
I normalfallet behöver man inte gå in på sånt innan man börjar skala upp ordentligt, men då ska man redan vara i K8 hur som helst.
Om man vill isolera tjänster ihop kan man köra virtuella maskiner eller pods, men då behöver man gå vidare till andra verktyg.

En reverse-proxy kan du köra i en separat maskin om du så vill. Du hade kunnat ha den i din router t.ex. och få samma funktion som att ha den i samma compose-fil. (Ja, man kan få vissa förenklingar med t.ex. Traefik om man ger den tillgång till Docker-demonen, men inget jag rekomenderar..) Trafiken går genom routern på port 80/443, skickas vidare till reverse-proxyn som validerar förfrågan och skickar vidare till tjänsten på det lokala nätverket. (nextcloud.ilyaz.com -> 192.168.1.20:443 typ)
För nu är du inne på nätverksstruktur och nätuppbyggnad och det är ett helt kapitel i sig om man ska gå igenom det.

Permalänk
Medlem

Som med allt annat handlar det om hur mycket dokumentation man läser och vilka krav på driftsäkerhet man har. Om det man inte vill radera läggs i volymer och mounts lär det bara vara att uppgradera, men det gäller då att man har koll på vilka filer det gäller. För nextcloud är det rätt enkelt, men för andra applikationer kanske mindre så, och då kan tex watchtoweruppdateringar ge driftsäkerhetsproblem om man som amatör inte tagit sig tid att förebygga det.

Just nu vill jag bara få igång ett proof of concept som jag kan fila på sen, men nybörjarkonstruktionsfel framkommer ofta sent när det också kan vara svårt att göra något mindre radikalt åt saken. Ofta finns tex standarder eller good practice man kan ha som grund.

Nu kör jag nginx proxy manager och försöker peka runt till diverse containers, vilket fungerar hyfsat. Det kan bli den grund jag bygger vidare på och har kvar ett bra tag, men det finns tusen alternativ att värdera, som tex caddy o dyl som också skulle kunna fungera, vilket gör det till en djungel.

Visa signatur

Propaganda syftar till att göra det politiska opolitiskt.