0

For a database-per-service architecture, how do you guys manage your static data for each microservice? I want to make it easy for a new developer to jump in and get everything up and running easily on their local machine. I'm thinking of checking the entire database with static data into source control with Docker bind mounts so people can just docker-compose up the database service locally (along with whatever other infrastructure services they might need to run and test their microservice).

I know each microservice might need to handle this in their own way, but I'd like to provide a good default template for people to start with.

Dois
  • 594
  • 1
  • 10
  • 25

1 Answers1

1

Making a standard for how to do this sort of goes against the reason for making microservices, i.e. that you can adapt each microservice to the context it exists in.

That being said, Postgres, Mongo and MySQL all run scripts in /docker-entrypoint-initdb.d when initializing a fresh database instance. The scripts have to fit the database obviously, but it's a fairly standardized way of doing it.

They all have descriptions of how to do it on the image page on docker hub.

You can either get your scripts into the container by making a custom image that contains the scripts or you can map them into the directory using a docker-compose volume mapping.

There are some databases that don't have an easy way to initialize a new database. MSSQL comes to mind. In that case, you might have to handle it programmatically.

Hans Kilian
  • 18,948
  • 1
  • 26
  • 35
  • This does seem like the way to go. I tried committing the docker bind mounted DB files. Bad idea. Thanks. – Dois May 23 '22 at 04:13