Some update: we will not use ubuntu because there is not official rust docker image with ubuntu

The current prototype you can use to test the new image is

docker run -it --rm -p 7700:7700 -v $(pwd)/meili_data:/meili_data getmeili/meilisearch:prototype-debian-docker-image-0

Please let me know here if anyone has any issue with it 🙏

⚠️ Prototypes are not recommended for production

@curquiza I support this change, but it may happen that users are extending the docker image in their own dockerfile. So this may lead to a breaking change.

e.g.

FROM getmeili/meilisearch:1.0.0

RUN ...do some stuff \
         # this will break the user CI pipeline if alpine is switched to debian
         && apk run some alpine specific command

A workaround would be to build for debian and alpine and tag the images accordingly

# docker tag
getmeili/meilisearch:1.0.0 === getmeili/meilisearch:1.0.0-alpine

# docker tag
getmeili/meilisearch:1.0.0-debian <= new debian image

Hum you are right that's true, it can be breaking for the users...
And I'm not really happy with having two dockerfile + tagging every Meilisearch image twice

Thanks @mmachatschek for making us realize this 🙏

@dureuill what do you think?

We're moving away from alpine because of its use of musl as libc, which is thought to potentially affect performance, and could cause issues specific to this libc implementation.

This change is made to be consistent with what we're testing day to day. With regards to these motivations I don't think it makes sense to make this change if we're going to keep supporting both docker variants.

As a result I think the solutions that make sense currently are either:

1. commit to make musl supported instead of glibc. Don't provide a debian image, or
2. make the breaking change by switching to the debian image and stop providing the musl image, with a note in the changelogs of v1.x about the breakage.

To help us decide it would be good to have some measure of how many people and CIs would be impacted by that change. Is extending the Meilisearch docker image common? What are the typical use-cases?

Is extending the Meilisearch docker image common?

I guess it can concern a lot of people since it's quite common in the Docker world to create an image based on another one. It's all the "power" of Docker. But I don't know how many people are concerned for Meilisearch specifically. I know the cloud team is doing it for example and would have to change their Dockerfile because of this change

However, in Semver, changing a dependency is not considered as breaking, I don't know if the rule is exactly related to our situation
We added a rule about this in our versioning policy

@dureuill

to be clear here, I totally support this change.

We were also running alpine images with a node application that uses prisma (it's written in rust under the hood). Alpine slowed down our application a lot and switching to the debian based images gave us a lot of performance back. there are some GH issues and blog posts that confirm this.

These articles (+ internal performance tests) made me switch to the debian image because the main reason (small image size) was irrelevant as we use debian-slim that has roughly the same image size as the alpine image version.

• https://pythonspeed.com/articles/alpine-docker-python/
• https://snyk.io/blog/choosing-the-best-node-js-docker-image/#:~:text=Is%20node%3Aalpine%20the,Python%20Docker%20images.

Is extending the Meilisearch docker image common? What are the typical use-cases?

when the meilisearch batch feature was opt in, we created a meilisearch dockerfile that just changed the command and added the cli flag to activate it. But there was no alpine specific code involved. This could have been solved via a docker-compose command config too (without needing to add a dockerfile)

Those results look like most people don't use any alpine specifc commands in their dockerfile
https://github.com/search?l=Dockerfile&q=getmeili%2Fmeilisearch&type=Code

These were the only usages that I could find that apply some alpine specific commands (and where the dockerfile uses the latest tag)

• https://github.com/darkjinnee/web-stack/blob/main/docker/services/meilisearch/Dockerfile
• https://github.com/darkjinnee/larapack-9x/blob/main/docker/services/meilisearch/Dockerfile
• https://github.com/edouardb/meilisearch-on-koyeb/blob/main/Dockerfile

2. make the breaking change by switching to the debian image and stop providing the musl image, with a note in the changelogs of v1.x about the breakage.

preferred +1

@mmachatschek thank you so much this is a great answer ❤️

I thought we linked articles on musl performance somewhere but couldn't find them back after a cursory search, so thank you for contributing some of them.

These were the only usages that I could find that apply some alpine specific commands (and where the dockerfile uses the latest tag)

Thank you for the search! Since this appears to be a manageable number of cases, I guess we could even send advance notice to these repositories before making the change.

Thanks a lot @mmachatschek for your help here

I talked with @dureuill and because of the change it involves for the users, we would rather not release it before measuring it: we want to ensure this change has a real impact on performance to deserve a breaking change on one of our tools. Even if the breaking change is not in the search engine directly, the docker image is still a widely used tool.
I've updated the issue description.

Because of the lack of time before v1.1, we will not be able to apply this change for release v1.1, but more for release v1.2 or v1.3

I ping @meilisearch/cloud-team about the change.