[GH-ISSUE #368] Minimize container image #188

Closed
opened 2026-02-26 10:30:46 +03:00 by kerem · 10 comments
Owner

Originally created by @rugk on GitHub (Jul 7, 2021).
Original GitHub issue: https://github.com/ONLYOFFICE/Docker-DocumentServer/issues/368

Do you want to request a feature or report a bug?
"feature"

What is the current behavior?
You currently use Ubuntu 20.04 as your base image:
github.com/ONLYOFFICE/Docker-DocumentServer@3b830417a2/Makefile (L45)
github.com/ONLYOFFICE/Docker-DocumentServer@3b830417a2/Dockerfile (L1)

What is the expected behavior?
Ubuntu is really a big image, and I doubt all that is required. It only leads to a big image size (and thus potentially attack surface). IMHO a smaller image would be nice.
IMHO you don't have to use Alpine, but why not a simple and smaller Debian as many containers do?

Also, IMHO, it is a bad practice to include all required services/dependencies in the image. That's not how Docker/containers were supposed to be used.
Better offer a productive docker-compose file similar to what you already include and then start each service on one container.

In the same way, IMHO, such a image should not include anything related to Let's Encrypt. It's not the main job of this tool. You can include a version that works with that or an adapter, e.g. as it is done for nginx, but the tools itself do not belong into the image.

If you don't want to offer this for backwards-compatibility, what about a separate image or IMHO better tag such as documentserver-lite that only includes all the necessary things for the server itself and is intended to be run with a docker-compose file?

Originally created by @rugk on GitHub (Jul 7, 2021). Original GitHub issue: https://github.com/ONLYOFFICE/Docker-DocumentServer/issues/368 **Do you want to request a *feature* or report a *bug*?** "feature" **What is the current behavior?** You currently use Ubuntu 20.04 as your base image: https://github.com/ONLYOFFICE/Docker-DocumentServer/blob/3b830417a2879733a513a543487e387c629af29f/Makefile#L45 https://github.com/ONLYOFFICE/Docker-DocumentServer/blob/3b830417a2879733a513a543487e387c629af29f/Dockerfile#L1 **What is the expected behavior?** Ubuntu is really a big image, and I doubt all that is required. It only leads to a big image size (and thus potentially attack surface). IMHO a smaller image would be nice. IMHO you don't have to use Alpine, but why not a simple and smaller Debian as many containers do? Also, IMHO, it is a bad practice to include all required services/dependencies in the image. That's not how Docker/containers were supposed to be used. Better offer a productive docker-compose file [similar to what you already include](https://github.com/ONLYOFFICE/Docker-DocumentServer/blob/master/docker-compose.yml) and then start each service on one container. In the same way, IMHO, such a image should not include anything related to Let's Encrypt. It's not the main job of this tool. You can include a version that works with that or an adapter, e.g. [as it is done for nginx](https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/), but the tools itself do not belong into the image. If you don't want to offer this for backwards-compatibility, what about a separate image or IMHO better tag such as `documentserver-lite` that only includes all the necessary things for the server itself and is intended to be run with a docker-compose file?
kerem 2026-02-26 10:30:46 +03:00
Author
Owner

@ShockwaveNN commented on GitHub (Jul 8, 2021):

I think you're right

should not include anything related to Let's Encrypt. It's not the main job of this tool.

As a side note - you don't know how much users asked to include Let's Encrypt support in our base image )

Right now we got smaller images, that are made for k8s support - you can look out them in k8s configs - like here
https://github.com/ONLYOFFICE/Kubernetes-Docs/blob/master/deployments/docservice.yaml#L61

But they are still not officially documented how to proper usage

<!-- gh-comment-id:876199049 --> @ShockwaveNN commented on GitHub (Jul 8, 2021): I think you're right > should not include anything related to Let's Encrypt. It's not the main job of this tool. As a side note - you don't know how much users asked to include Let's Encrypt support in our base image ) Right now we got smaller images, that are made for k8s support - you can look out them in k8s configs - like here https://github.com/ONLYOFFICE/Kubernetes-Docs/blob/master/deployments/docservice.yaml#L61 But they are still not officially documented how to proper usage
Author
Owner

@stavros-k commented on GitHub (Jan 26, 2022):

It would be awesome, if you also plan to offer a CE version of the said images :)

<!-- gh-comment-id:1022086661 --> @stavros-k commented on GitHub (Jan 26, 2022): It would be awesome, if you also plan to offer a CE version of the said images :)
Author
Owner

@ShockwaveNN commented on GitHub (Jan 26, 2022):

@stavros-k

We are still not sure if we made them the official way or only for k8s support (and of course there is no point in CE images in k8s)

But if you really needed - you can try to build them themself

I've never done it but I think it's not very complicated, sources here in public repo

https://github.com/ONLYOFFICE/Docker-Docs

<!-- gh-comment-id:1022093342 --> @ShockwaveNN commented on GitHub (Jan 26, 2022): @stavros-k We are still not sure if we made them the official way or only for k8s support (and of course there is no point in CE images in k8s) But if you really needed - you can try to build them themself I've never done it but I think it's not very complicated, sources here in public repo https://github.com/ONLYOFFICE/Docker-Docs
Author
Owner

@stavros-k commented on GitHub (Jan 26, 2022):

I've already have the DocServ packaged in a helm chart for TrueNAS Scale (which runs a k8s underneath).

As Scale is gonna be used from a lot of Home Users, (businesses also ofc). The CE would be awesome.

For business, I might make an EE edition helm packaged app :)

<!-- gh-comment-id:1022099912 --> @stavros-k commented on GitHub (Jan 26, 2022): I've already have the DocServ packaged in a helm chart for TrueNAS Scale (which runs a k8s underneath). As Scale is gonna be used from a lot of Home Users, (businesses also ofc). The CE would be awesome. For business, I might make an EE edition helm packaged app :)
Author
Owner

@ShockwaveNN commented on GitHub (Jan 26, 2022):

Sorry, I've never had any experience with TrueNAS Scale and never heard about it

But could you clarify one thing?

We got a limitation of 20 concurrent users in CE edition (and not planning to remove it as far as I'm aware)

What's the point of using such a complicated thing as k8s for a server which handles 20 users at most

Would a native docker container be simpler to use?

Isn't complicated k8s is a little overkill for home tasks?

<!-- gh-comment-id:1022112451 --> @ShockwaveNN commented on GitHub (Jan 26, 2022): Sorry, I've never had any experience with `TrueNAS Scale` and never heard about it But could you clarify one thing? We got a limitation of 20 concurrent users in CE edition (and not planning to remove it as far as I'm aware) What's the point of using such a complicated thing as k8s for a server which handles 20 users at most Would a native docker container be simpler to use? Isn't complicated k8s is a little overkill for home tasks?
Author
Owner

@stavros-k commented on GitHub (Jan 26, 2022):

Sorry, I've never had any experience with TrueNAS Scale and never heard about it

TrueNAS Scale (currently in BETA) is a new debian based OS from iX Systems. You might have heard them from Freenas

But could you clarify one thing?

We got a limitation of 20 concurrent users in CE edition (and not planning to remove it as far as I'm aware)

For Home Users that's plenty enough :) (That's why I was thinking to add the EE edition, but this won't happen (by me at least) before scale official release)

What's the point of using such a complicated thing as k8s for a server which handles 20 users at most

As TN Scale is mostly focus on business and plan is to support multi node clustering (also storage clustering), kubernetes was the a great choice (IMHO).

Would a native docker container be simpler to use?

Docker is easy to use yea, but Scale officially only supports k8s. Also everything has to be done in the GUI, which abstracts most of the complexity.

Isn't complicated k8s is a little overkill for home tasks?

As everything is done in the GUI, a custom build form is created for each app, which then translates to helm charts.
I'm contributing on one of the community app catalogs https://github.com/truecharts/apps where we build the said GUI's and helm charts.

P.S. Not to be confused. I have no affiliation with iX Systems. I just use their OS :)

<!-- gh-comment-id:1022126319 --> @stavros-k commented on GitHub (Jan 26, 2022): > Sorry, I've never had any experience with `TrueNAS Scale` and never heard about it `TrueNAS Scale` (currently in BETA) is a new debian based OS from iX Systems. You might have heard them from `Freenas` > But could you clarify one thing? > > We got a limitation of 20 concurrent users in CE edition (and not planning to remove it as far as I'm aware) For Home Users that's plenty enough :) (That's why I was thinking to add the EE edition, but this won't happen (by me at least) before scale official release) > What's the point of using such a complicated thing as k8s for a server which handles 20 users at most As `TN Scale` is mostly focus on business and plan is to support multi node clustering (also storage clustering), kubernetes was the a great choice (IMHO). > Would a native docker container be simpler to use? Docker is easy to use yea, but Scale officially only supports k8s. Also everything has to be done in the GUI, which abstracts most of the complexity. > Isn't complicated k8s is a little overkill for home tasks? As everything is done in the GUI, a custom build form is created for each app, which then translates to helm charts. I'm contributing on one of the **community** app catalogs https://github.com/truecharts/apps where we build the said GUI's and helm charts. P.S. Not to be confused. I have no affiliation with `iX Systems`. I just use their OS :)
Author
Owner

@ShockwaveNN commented on GitHub (Jan 26, 2022):

k8s. Also everything has to be done in the GUI, which abstracts most of the complexity.

Whoa, using only GUI for k8s - I have a little experience with k8s but this is most complicated thing I ever working and using ONLY GUI for this is a bad idea

But I think I got your point, I'll create issue about k8s for CE builds, but no promises if our management decide that this build is really needed )

<!-- gh-comment-id:1022138092 --> @ShockwaveNN commented on GitHub (Jan 26, 2022): > k8s. Also everything has to be done in the GUI, which abstracts most of the complexity. Whoa, using only GUI for k8s - I have a little experience with k8s but this is most complicated thing I ever working and using ONLY GUI for this is a bad idea But I think I got your point, I'll create issue about `k8s for CE` builds, but no promises if our management decide that this build is really needed )
Author
Owner

@stavros-k commented on GitHub (Jan 26, 2022):

k8s. Also everything has to be done in the GUI, which abstracts most of the complexity.

Whoa, using only GUI for k8s - I have a little experience with k8s but this is most complicated thing I ever working and using ONLY GUI for this is a bad idea

For new commers, GUI is awesome as it takes all the complexity from them (and put it on the maintainers :P), for someone with deep knowledge, he can build the whole app in yaml files (as we do) and only add a gui for a name, create the catalog, add it to SCALE and from there just click install and give it a name. Just needs couple extra steps.
I think iX Systems also preparing API's, so it could be done like this also.

But I think I got your point, I'll create issue about k8s for CE builds, but no promises if our management decide that this build is really needed )

Thanks! Understandable!

<!-- gh-comment-id:1022141321 --> @stavros-k commented on GitHub (Jan 26, 2022): > > k8s. Also everything has to be done in the GUI, which abstracts most of the complexity. > > Whoa, using only GUI for k8s - I have a little experience with k8s but this is most complicated thing I ever working and using ONLY GUI for this is a bad idea For new commers, GUI is awesome as it takes all the complexity from them (and put it on the maintainers :P), for someone with deep knowledge, he can build the whole app in yaml files (as we do) and only add a gui for a name, create the catalog, add it to SCALE and from there just click install and give it a name. Just needs couple extra steps. I think iX Systems also preparing API's, so it could be done like this also. > But I think I got your point, I'll create issue about `k8s for CE` builds, but no promises if our management decide that this build is really needed ) Thanks! Understandable!
Author
Owner

@ShockwaveNN commented on GitHub (Jan 26, 2022):

I've created issue 55118 in our private issue tracker to discuss the possibility of adding k8s-purposed images for CE version

<!-- gh-comment-id:1022169866 --> @ShockwaveNN commented on GitHub (Jan 26, 2022): I've created issue 55118 in our private issue tracker to discuss the possibility of adding k8s-purposed images for CE version
Author
Owner

@ShockwaveNN commented on GitHub (Oct 12, 2022):

https://github.com/ONLYOFFICE/Docker-Docs now provide all three version of DocumentServer

It's mainly used for k8s via docservice.image.repository key, but can be used without cluster with little bit of tinkering

<!-- gh-comment-id:1275667789 --> @ShockwaveNN commented on GitHub (Oct 12, 2022): https://github.com/ONLYOFFICE/Docker-Docs now provide all three version of DocumentServer It's mainly used for k8s via [`docservice.image.repository`](https://github.com/ONLYOFFICE/Kubernetes-Docs#4-parameters) key, but can be used without cluster with little bit of tinkering
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Docker-DocumentServer-ONLYOFFICE#188
No description provided.