-
-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtualmin app server plugin #626
Comments
My 2 cents... I vote in favor. Also, Java, and Python with its own virtual environment For docker, one could automate Portainer, the container manager app everyone uses. My use cases.... 1. Python: odoo CE and offlineimap. 2. NodeJS: homebridge, SuiteCRM 8. 3. Java: websphere, JBoss, Alfresco CE on Tomcat. |
Worth looking at pm2 for NodeJS. |
I would love to be able to run https://hub.docker.com/r/glitchtip/glitchtip |
I see this is started! https://github.com/virtualmin/virtualmin-app |
I think Joe just missed it. I would like to stress out, that if we're going to support different application servers in one so called Virtualmin Applications Servers module, we should ensure that it's simple to use, and covers expected functionality for each service! That said, how are we going to combine, for example Docker and pm2? Unless you want this module solely provide display for service status and configured proxy paths? What is your vision about it, Jamie? |
So I'm thinking that we can start by supporting arbitrary commands that run as app servers, and then add support for things like Docker that provide an app in an entire container. But I'm still investigating docker ... |
If you're looking at docker, please don't forget that docker is not included in RHEL, but it's drop-in podman is instead. |
Would be brilliant to also be aware of python apps/services running on the system, inside their own "python virtual environments" (directories). This web interface does it. Could it be easily added in? |
Yeah, podman is generally considered recommended across the Linux distro landscape, because Docker hasn't been super friendly to Open Source. And, technically, podman is superior on several fronts (no daemon BS, not tied to any commercial cloud services, uses a bunch of more modern Linux security features). But, and this is a big but, nobody knows the name "podman", and everybody wants "Docker support". So, I guess we need to detect if the user has the docker tools installed (from third party sources, probably) and allow use of those instead. Because podman doesn't use a daemon, it isn't entirely compatible with Docker on the same system; so, even though they have almost identical command line options and use the same Dockerfile syntax, if you list containers with podman you won't see the ones Docker is managing and vice versa, AFAIK, and you can't stop/start/pull/push/etc. across the two. I prefer podman, and I hope most users who don't know the difference will just accept it. I don't think Java has any notable interest among Virtualmin users. I would put it way down the list of things to support. Don't waste time on something that has very little overlap with our userbase. If a large paying customer wants it, fine, but otherwise, ignore Java. Docker/Podman, nodejs, and Python in a virtualenv, is probably the most common in that order (after php-fpm, but we already have pretty great PHP-FPM support), but I think it should just be easy for a user to follow the docs for a project installation and then use the Virtualmin UI to setup ports and such. I would caution against trying to take over how apps are deployed; every app has their own docs and own processes, we should just be trying to make it easy to do what the project says to do, which often includes setting up proxying to a local port or named socket (encouraging named sockets would also be good, for security reasons) and the ability to start services on boot (we have virtualmin-init, but it's kind of a secret and our users have a hard time making the connection between that and running app servers, for some reason). The goal is not to reinvent the wheel, just to provide a clear path for Virtualmin users to use the existing wheels. NodeJS has popular and standard ways to deploy apps, Docker has common ways to deploy apps, Python is a mess with many competing and terrible ways to do it, but it's a mess we can try to stay out of. Also, it may be that our best solution is better/clearer docs about these specific tasks rather than code. But, right now, it's not as easy to setup a proxy rule and setup an app server to start on boot, even though those features already exist! Nobody uses them because they're kind of obscure and seem unrelated to running app servers (you and I know that that's all you need to do to run an app server, but most user somehow don't know it). In general, the problem we need to solve is just providing a golden path that is obvious for the users who keep asking, "How do I run X app in Virtualmin?" When the answers is always "However the docs for X app tell you to do it, Virtualmin is a normal Apache/nginx system." All that said, being able to treat Docker/podman as a package manager for user-installable web apps would be a very exciting feature for a lot of users, and in that case we'd need to be a little bit more intrusive and involved than just "follow the docs". And, Docker/podman is probably the highest priority feature to consider for this, as it covers apps in literally any language and a lot of modern apps recommend installing with Docker instead of setting up the execution environment yourself. Our Discourse forum is a Docker deploy, for instance. |
Thanks, I'll take a look at adding support for installing Docker apps in this app server plugin. |
@swelljoe you mentioned a while back that it would be cool to have support in Virtualmin for running application servers (like say node.js or docker containers). I'm thinking I could create a plugin for this which tracks apps and sets up start/stop scripts and proxying for them pretty easily.
Did you have any other thoughts about this feature, or example use cases?
The text was updated successfully, but these errors were encountered: