Docker base image - 3.0
-
Tentative base image is.cloudron/base:3.0.0@sha256:3f55a3dbde353d5bb574ca7d66e0a391999f2adbd7dae13bd795ecb8f53e962e
Final image iscloudron/base:3.0.0@455c70428723e3a823198c57472785437eb6eab082e79b3ff04ea584faf46e92
The apps below work fine:
- Grafana (Go)
- Snipe-IT (PHP 7.4)
- Verdaccio (node)
- Ampache - php 7.4
- GitHub Pages (ruby + locale fixes)
- Metabase (java)
- Moodle - php 7.4
- Peertube - does not support node 14 yet, but next release will. so it's fine.
- Redmine - 4.1 does not support ruby 2.7 yet - https://redmine.org/projects/redmine/wiki/RedmineInstall . so we cannot update it (it's fine)
- GitLab - fails "Could not find openssl-2.2.0 in any of the sources"
Big TODO: port all addons/services.
-
@girish said in Docker base image - 3.0:
I have often struggled working with minimal images because they often lack the tools for debugging
You will use minimalism only in production, if you are debugging you can use the full tool-set image, but on production you will only include what's is necessary.
In a Apache PHP based app, you don't need 2 web-server, you don't need java or nodejs.
@girish said in Docker base image - 3.0:
just 2GB
2 GB is from 10% to 5% of a Basic NVMe Cloud instances on most provider, is really a lot of space especially during update, it will take resources and time on server that know days are especially small 2 or 3 vCore and 4 to 8 GB of RAM.
Most of the time your docker image update is longer because CPU bottleneck not network (we have a proxy for the image on docker hub) we have test that.I don't think is urgent to do or that cloudron need to do it, but i can understand why most of the docker community like small alpine images, and docker is born for that 1 software-1container, but now is thing of the past.
@mehdi said in Docker base image - 3.0:
container layer
btw if you are using "container layer" with small image stack is better, is how docker work better, a cloudron with just nextcloud don't need to have java on it, that's just w8st of space (jdk is from 160 to 180MB).
You can have:
- Ubuntu base image (with or with out tools that help you debug, depending if is prod or test)
- library that the app need to have to work (webserver, php, java) probably all php apps need the same or can have the same, we don't need to be super efficient, just more efficient
- the app it self, wordpress, nextcloud, ecc ecc.
This can be a possible and probably not so much time consuming to maintain (gitlab ci, is haven in this case), obviously is not the only answer to the image maintenance issue, and one is the big complete image that cloudron is using.
Everything have pros and cons.
And maybe this look like me angry but i'm not, and cloudron support every app that build on there baseimage or build on top of Alpine, so if somebody don't like it, is easy to build a custom app =D. -
Isn't it better to use different commands like
systemd-cgls
andsystemd-cgtop
? I think many tools simply don't work well when mixing host and containers including tools like du. Hard to fix this, just need to write better system tools. -
@girish said in Docker base image - 3.0:
Isn't it better to use different commands like
systemd-cgls
andsystemd-cgtop
? I think many tools simply don't work well when mixing host and containers including tools like du. Hard to fix this, just need to write better system tools.Absolutely not. Have you used those?
A combination of top and htop is decent, except for the UIDs which we have control over.
Hence the ask..
Let's make it nice.
-
-
I don't really see the benefit of messing with user ids within the container. The only reason I see is to map access to existing data from a new containerised app (which is not really the case on Cloudron) or if you want to shift privileged user ids to a higher value on the host.
-