skip to Main Content

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?

2

Answers


  1. Well, this is why docker base images can use scratch in order to define a docker file with zero dependencies. Your imagination and knowledge are the only blockers from here

    https://hub.docker.com/_/scratch

    For your use case, I recommend that you use scratch and copy manually relevant commands from the official images of your desired DBs. However, this option is pretty extreme. Please consider use the base images and extend them

    Also, if your requirement is to create a process that loads specific containers (base on custom images) in a specific order, please use docker compose and specifically depends_on (https://docs.docker.com/compose/compose-file/05-services/#depends_on)

    Hope this information helps your use-case

    Login or Signup to reply.
  2. 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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search