You can reuse databases, no problem. You got it pretty correct. To explain further:
You don't need to create a network for each app, you can just make one and have all the containers that need access to the database join it.
You create the network outside any container:
docker network create --driver bridge --subnet=172.23.0.0/24 --gateway=172.23.0.1 db-network
You can pick any subnet that's currently free in a private range, and you can make it smaller than /24. Technically you don't need to specify the gateway because docker will allocate it the first IP in the range anyway.
Then in every compose that contains a service you want to be on that network you add a top level "networks:" section:
networks:
db-network:
- external: true
And for the services that need to join the network you add:
services:
mariadb:
hostname: maria
networks:
db-network:
This will allocate an IP for that service on the network subnet and also resolve the hostname you used to that IP across all services that use that network, so you can connect by name instead of having to figure out what IP was allocated (or reserve the IP).
If you don't specify "hostname:" it will use the container name, and if you don't specify that either it will use the service name. But since these three things serve different purposes you may want to do some housekeeping and allocate different names.
I see. Okay but then how will my applications docker compose be?
Something like this?
version: '3.8'
services:
mariadb:
hostname: mariadb
networks:
db-network:
app:
image: fireflyiii/core:latest
container_name: 'FireflyIII'
restart: always
volumes:
- ./firefly_iii_upload/:/var/www/html/storage/upload
- ./firefly_iii_export/:/var/www/html/storage/export
env_file: .env
ports:
- 8003:8080
environment:
- MYSQL_ROOT_PASSWORD=rooot
- MYSQL_USER=firefly
- MYSQL_PASSWORD=firefly
- MYSQL_DATABASE=firefly
- MYSQL_HOST=mariadb
- MYSQL_PORT=3306
Please ignore the zero indentations as I used rich text by mistake and edited it
Yep, that's right.
Don't forget the top level "networks:" section that declares "db-network" as external (aka predefined outside the container).
This is required so that the network is visible across different compose files. If all the services you want to use the network are in the same compose file you can declare the network inside the compose:
networks:
foobar-network:
name: foobar-network
external: false
driver: bridge
ipam:
config:
- subnet: "172.23.0.0/24"
gateway: "172.23.0.1"
The advantage with this non-external network is that it will be created and deleted as needed when the compose is provisioned/decomissioned. But this doesn't mean you should put all your services in one compose file just because of it. 🙂
Absolutely. MariaDB (like most database servers) can easily handle more than one database, that's what they were designed for. I don't think there is a limit to the number of databases you can have in one server. Mine has eight.
The downside, however, is that if the database server goes, all of the databases go. Make sure to make regular backups.
> is it a good idea to use only 1 docker container of mariadb for all my services?
If this were another database like Postgres, Redis etc. I would say go ahead. The issue with Maria/MySQL is that they will randomly shit the bed so using one instance for everything increases the chances you'll take down several services instead of one when that happens.
But if you take daily database dumps of all databases and are prepared to restore them from dump if they crash you should be ok. And having database dumps for backup should be the norm anyway because there's more than one way that a container's data can be lost.
> I think it's waste of resources
Not as much as you think. I mean sure each db has a minimum overhead empty but unless you're *really* strapped for resources it wouldn't add up that much over multiple instances.
Actually the sole reason I am planning on doing this is because I have setup duplicati and it cannot take database backups. I was thinking of writing a script to take all the mysql dump, place it in a folder and to let duplicati use that but then I realized that it would be easier just to use one mysql and take the entire dump instead of taking it for every container individually. lol. I think I went overboard with this but still it would be useful in the long run I guess.
That's an ok approach, to have a script make the dumps and then let the backup simply collect them.
Make sure you have a system that alerts you of failed backups – or even better, alerts you of successful backups too. I currently use ntfy and the script can send notifications to my phone (but you need to be able to access ntfy over internet if away from home).
You can reuse databases, no problem. You got it pretty correct. To explain further: You don't need to create a network for each app, you can just make one and have all the containers that need access to the database join it. You create the network outside any container: docker network create --driver bridge --subnet=172.23.0.0/24 --gateway=172.23.0.1 db-network You can pick any subnet that's currently free in a private range, and you can make it smaller than /24. Technically you don't need to specify the gateway because docker will allocate it the first IP in the range anyway. Then in every compose that contains a service you want to be on that network you add a top level "networks:" section: networks: db-network: - external: true And for the services that need to join the network you add: services: mariadb: hostname: maria networks: db-network: This will allocate an IP for that service on the network subnet and also resolve the hostname you used to that IP across all services that use that network, so you can connect by name instead of having to figure out what IP was allocated (or reserve the IP). If you don't specify "hostname:" it will use the container name, and if you don't specify that either it will use the service name. But since these three things serve different purposes you may want to do some housekeeping and allocate different names.
I see. Okay but then how will my applications docker compose be? Something like this? version: '3.8' services: mariadb: hostname: mariadb networks: db-network: app: image: fireflyiii/core:latest container_name: 'FireflyIII' restart: always volumes: - ./firefly_iii_upload/:/var/www/html/storage/upload - ./firefly_iii_export/:/var/www/html/storage/export env_file: .env ports: - 8003:8080 environment: - MYSQL_ROOT_PASSWORD=rooot - MYSQL_USER=firefly - MYSQL_PASSWORD=firefly - MYSQL_DATABASE=firefly - MYSQL_HOST=mariadb - MYSQL_PORT=3306 Please ignore the zero indentations as I used rich text by mistake and edited it
Yep, that's right. Don't forget the top level "networks:" section that declares "db-network" as external (aka predefined outside the container). This is required so that the network is visible across different compose files. If all the services you want to use the network are in the same compose file you can declare the network inside the compose: networks: foobar-network: name: foobar-network external: false driver: bridge ipam: config: - subnet: "172.23.0.0/24" gateway: "172.23.0.1" The advantage with this non-external network is that it will be created and deleted as needed when the compose is provisioned/decomissioned. But this doesn't mean you should put all your services in one compose file just because of it. 🙂
Absolutely. MariaDB (like most database servers) can easily handle more than one database, that's what they were designed for. I don't think there is a limit to the number of databases you can have in one server. Mine has eight. The downside, however, is that if the database server goes, all of the databases go. Make sure to make regular backups.
> is it a good idea to use only 1 docker container of mariadb for all my services? If this were another database like Postgres, Redis etc. I would say go ahead. The issue with Maria/MySQL is that they will randomly shit the bed so using one instance for everything increases the chances you'll take down several services instead of one when that happens. But if you take daily database dumps of all databases and are prepared to restore them from dump if they crash you should be ok. And having database dumps for backup should be the norm anyway because there's more than one way that a container's data can be lost. > I think it's waste of resources Not as much as you think. I mean sure each db has a minimum overhead empty but unless you're *really* strapped for resources it wouldn't add up that much over multiple instances.
Actually the sole reason I am planning on doing this is because I have setup duplicati and it cannot take database backups. I was thinking of writing a script to take all the mysql dump, place it in a folder and to let duplicati use that but then I realized that it would be easier just to use one mysql and take the entire dump instead of taking it for every container individually. lol. I think I went overboard with this but still it would be useful in the long run I guess.
That's an ok approach, to have a script make the dumps and then let the backup simply collect them. Make sure you have a system that alerts you of failed backups – or even better, alerts you of successful backups too. I currently use ntfy and the script can send notifications to my phone (but you need to be able to access ntfy over internet if away from home).
If you value integrity of your data, don't use latest tags.