I need the following KV-DBs for my repository abstraction: Redis, LevelDB, RocksDB, Badger. (not all at once, of course :D)
As far as I know only Redis and RocksDB has either official or community-maintained(almost up-to-dated) Docker image, so I can easily set it up as a service my app depends on in my docker-compose. However, there are still LevelDB and Badger that don't have even community-maintained images. I understand, that they all may haven't an image, as they are positioned as embeddable, but docker & docker-compose looks like the easiest way to interact with any infrastructure dependency.
How do you usually set up such infrastructure dependencies? Maybe I should consider some approaches of fetching and setting up such dependencies within my code I don't know about? I'm using Golang for now.
The only idea I've came up with is to create a Dockerfile for each of those DBs by myself, since some of those DBs don't have a single image(even community, even outdated) in Docker Hub registry. All of them are in the apt registry, btw. Any other ideas?
Both LevelDB and Badger are libraries. They're not independently runnable, and you can't start a separate container for them; instead, you'd add them as dependencies in your application.
For example, you could follow the Badger quickstart guide and go get the library as part of your Go-based application. From there it would be listed in your go.mod and go.sum files, and you'd have corresponding Go import statements in your Go source code. If you had a routine Go Dockerfile (usually that would start FROM golang, RUN go build to produce a binary, and then have a second FROM stage to COPY the binary into a runtime-only stage) that would include Badger in the binary, without having a separate image or container.
Note that the reverse side of this is that both libraries depend on the database storage being in a local file. (The SQLite embedded relational database works the same way.) Local files can be tricky to work with in containers in several ways (in pure Docker, managing permissions; in a clustered environment like Kubernetes, working with multiple replicas) and you might find a separate database container easier to work with in practice.