Jeg har en applikation, der skal implementeres på adskillige servere, de vil ikke være forbundet, men køre deres egne uafhængige tjenester i samme kodebase. Jeg har i øjeblikket en docker-container til min frontend og en anden til min backend. Skal jeg lave en til min database? Jeg tænkte, det kunne gøre det lettere at administrere, men vent ikke med at følge bedste praksis eller skadeliggøre ydeevnen for meget. Databasen (Postgres) vil ikke have alt for mange data, max måske 100.000 rækker i én tabel, de andre tabeller vil have betydeligt mindre. Er der nogen ulemper ved at gøre dette.
Sørg for at bruge volumener til dataopbevaring, så dine data forbliver sikre, selvom containeren bliver ødelagt eller genoprettet.
Standard praksis på de virksomheder, jeg har arbejdet på, har været IKKE at containerisere databasen, undtagen i udviklings- eller demo-miljøer. Hovedårsagen er, at databaser har specielle belastningskrav, og at centrale databaseknudepunkter gør backup og genopretning lettere.
Men med så let brug kan det give mening at samle alt. Jeg ved ikke, hvilken skala du taler om her, implementeringsplatform, forventet belastning/TPS, hvad din SLA er, eller din data tabstolerance. Jeg vil sige, hvis dine data er super vigtige og skal være tilgængelige 99,999% af tiden, giver eksterne klynger mere mening.
Bedste praksis er at containerisere front end, midterlag og back end separat i deres egne containere, men bruge docker compose til at skabe et isoleret netværk.
Alternativt kan de klynges og administreres i k8s.
Hvis du spørger r/selfhosted, vil du opdage, at de fleste apps placerer DB i en separat container. Det er meget nemmere at administrere alt ét sted. Det er også almindeligt at oprette et separat netværk mellem backend- og DB-containere (eller endda bruge sockets via bind mounts).
Det er også ret praktisk at bruge docker-compose til at administrere disse tjenester.
Ydelsespåvirkningen er ubetydelig, især med sockets.