I was kind of thinking like something that Trash guide wrote up.
omv-extras 6.3 / openmediavault-compose 6.7
-
- OMV 6.x
- ryecoaaron
- Geschlossen
-
-
I get that, but I'll do all mine from the files menu, unless I have some bigass yml file with loads of containers in it. If I can save clicks I'm going for it
? I have not counted them, but I would say that it is the same number of clicks, maybe one more to change the tab
-
What do you require for an example?
You can send them to me. Here is what the current examples look like - https://github.com/OpenMediaVa…tree/master/compose-files. The plugin downloads the list.json file to populate the dropdown.
-
The only yml file I have more than 1 container is nginx, everything else I run is a single yml file for each container. So for me personally I assume I can do all from Services->Compose->Files? Or I'm I still getting wrong?
I have added a couple of comments in the description of both tabs, I hope that now it is more clear. Thank you for your questions, they help me improve the document.
-
You can send them to me. Here is what the current examples look like - https://github.com/OpenMediaVa…tree/master/compose-files. The plugin downloads the list.json file to populate the dropdown.
This is going to sound really stupid but where/how do I do that. I've done a few and wanted to send them to see if I need to change my method.
-
Then no, those will not be part of the compose plugin. The first problem is that they require portainer. I see the example compose files available on the files tab as being pretty much an equivalent. We just need more people to contribute to the examples.
How? Pull request in Github?
It is quite simple to transform those potainer templates to compose plugins. They are just yaml files in the end with some default locations that portainer uses, predifined.
-
How? Pull request in Github?
It is quite simple to transform those potainer templates to compose plugins. They are just yaml files in the end with some default locations that portainer uses, predifined.
That would require maintenance of each yaml afterwards. Every time an author modifies their container it could break a lot of people's settings. Maybe I'm wrong, but I think this exceeds what OMV can contribute. I understand and agree with ryecoaaron 's answer. Each user must take responsibility for their containers.
-
How? Pull request in Github?
Sure, if you want. Otherwise, email, pm, or even post in a thread.
-
That would require maintenance of each yaml afterwards. Every time an author modifies their container it could break a lot of people's settings. Maybe I'm wrong, but I think this exceeds what OMV can contribute. I understand and agree with ryecoaaron 's answer. Each user must take responsibility for their containers.
Yes that the idea of templates. There are quite a few github repositories with curated templates/stacks that it is easy to deploy. It is excactly the same logic with the examples in omv. A json file with a lot of templates of apps and/or stacks. The dirence is that omv json file is more simplistic than the one from portainer, and portainer has larger user base and thus more people maintain those lists.
But IMHO it worth investing some time to have a proper examples list that it will make easier the deployement of containers (less errors=less support) and by extend it will increase the capabilities of omv. as ryecoaaron pointed out 99% might not needed but then again I see a lot of questions/issues around containers in the forum... just my humble opinion here..
-
This is going to sound really stupid but where/how do I do that. I've done a few and wanted to send them to see if I need to change my method.
Sent via conversations.
-
But IMHO it worth investing some time to have a proper examples list that it will make easier the deployement of containers (less errors=less support) and by extend it will increase the capabilities of omv.
While I agree, I don't want to get in the business of supporting these apps/templates/whatever. I don't supplying an example file but if people have a problem an image, they should be getting support from the image maintainer.
-
Yes that the idea of templates. There are quite a few github repositories with curated templates/stacks that it is easy to deploy. It is excactly the same logic with the examples in omv. A json file with a lot of templates of apps and/or stacks. The dirence is that omv json file is more simplistic than the one from portainer, and portainer has larger user base and thus more people maintain those lists.
ok, thanks for the explanation, i guess i misunderstood it correctly. If I'm understanding it right now those templates are maintained by the community, in this case it makes sense to do so.
-
IMO, the first step OMV would have to take to sanely supply defaults for containers is to stop using compose files. At least that should make it a little easier (kinda), although how much easier? I foresee at least 3 new tabs: "Container/Paths", "Container/Users" and "Container/DBs". This quickly becomes a rabbit hole.
Why is everyone using compose files? Are people really deploying complex swarms via OMV? How many containers or nodes do you need to justify a compose file?
I setup something called Mailu from .sh's on rented shells. The containers for Mailu are: roundcube, rspamd, dovecot, postfix, radicale, fetchmail, nginx, certbot and postgres. Granted some are interrelated but, each is it's own container. Each is updated, built independently and joins their respective network all via .sh files. The advantages with .sh files is that I can easily modify, parameterize and not have to depend on a secondary binary (for now, I know it's to be merged).
The advantage I'd have with compose when using mailu is.... uhm... having to define "networks:" once?... using "depends_on:" instead of an orderly start up ...? What advantages are there with compose when using trivial container arrays? Is there any? Compose is designed to be a tool of convenience that simultaneously creates lock-in. However, they made the docker command all encompassing, so what else would I choose? Granted I don't run swarms > 2 nodes and I suspect that my opinion of compose would at the very least me modified if I did, but this is OMV (not a dedicated box for running swarms).
-
IMO, the first step OMV would have to take to sanely supply defaults for containers is to stop using compose files. At least that should make it a little easier (kinda), although how much easier? I foresee at least 3 new tabs: "Container/Paths", "Container/Users" and "Container/DBs". This quickly becomes a rabbit hole.
Why is everyone using compose files? Are people really deploying complex swarms via OMV? How many containers or nodes do you need to justify a compose file?The entire plugin is based around docker-compose. To stop using docker-compose would mean a complete rearchitecture/rewrite. Feel free to write that plugin if you want it.
docker-compose does many, many things that helpful that have nothing to do with swarm. Almost all of my compose files are one container. And just about every good image out there has an example compose file. compose files are basically infrastructure as code and very good for source control.
What advantages are there with compose when using trivial container arrays? Is there any? Compose is designed to be a tool of convenience that simultaneously creates lock-in. However, they made the docker command all encompassing, so what else would I choose?
docker-compose is easy because you write the yml file once and run a simple command many times without having to remember command line arguments or options.
I honestly don't care if it creates lock-in because compose has been around forever, is actively maintained, and isn't going away. If you don't like it, you are still free to use whatever tool you want.
docker-compose does everything that me and most OMV users need.
-
I just want to point out that this change does very little to stop you from continuing to use portainer for as long as you want. Portainer is just a docker container with the docker.sock mounted to it as a volume claim. You can just do a docker run command to spin it up any time you want.
I use this (I tweaked the ports slightly for my setup_:
Codedocker run --pull=always -d -p 8001:8000 -p 9001:9000 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latestThe only difference is needing to ssh into your omv server to stop, rm, and re-run the command when there's a portainer update rather than having a one click button to redeploy.
-
docker run --pull=always -d
You better get that docker run command outta here! This is a compose only world
There's a certain amount of comical irony that right after... "docker-compose does everything that me and most OMV users need." someone posts a docker run command
-
Heh, you could convert that to a docker-compose file too I suppose and ssh into omv and just do
Codedocker-compose upFor me, since I just have that command in a Joplin note it's trivial to paste it into an ssh session to redeploy Portainer when an update is available. Portainer is the only thing I deploy with docker run, however. Everything else is stacks (docker-compose).
Personally, I'm thinking about transitioning to Podman, but that'd require switching out of OMV since the Podman version here is so ancient (3.0.1 vs the modern 4.5.0)
-
You better get that docker run command outta here! This is a compose only world
I never said that. I use docker exec all the time. But this is thread about the compose plugin. I have probably said 10 times in this thread that you can still use portainer and docker and whatever you want. No one has to use the plugins I write/maintain.
There's a certain amount of comical irony that right after... "docker-compose does everything that me and most OMV users need." someone posts a docker run command
People like to derail my threads with important information about other options...
-
Hello there,
Like some users, i suddenly don't find docker and portainer in omv-extra menu. I first think it was a bug, alt-F5, same problem, reboot same result.
My server uptime was 1 or 2 months and there was some updates... So my first reaction was: hey, have a look at OMV forum. And voila, took about 2 minutes to find the solution.
I can't understand how you can come here and not even read open threads and start a new one asking for help and complaining about changes...
I just want to thanks ryecoaaron for his work, i also think it's a good change for docker. I want also to thanks KM0201 for his very helpfull guide for the new plugin.
-
IMO, the first step OMV would have to take to sanely supply defaults for containers is to stop using compose files. At least that should make it a little easier (kinda), although how much easier? I foresee at least 3 new tabs: "Container/Paths", "Container/Users" and "Container/DBs". This quickly becomes a rabbit hole.
Why is everyone using compose files? Are people really deploying complex swarms via OMV? How many containers or nodes do you need to justify a compose file?
I setup something called Mailu from .sh's on rented shells. The containers for Mailu are: roundcube, rspamd, dovecot, postfix, radicale, fetchmail, nginx, certbot and postgres. Granted some are interrelated but, each is it's own container. Each is updated, built independently and joins their respective network all via .sh files. The advantages with .sh files is that I can easily modify, parameterize and not have to depend on a secondary binary (for now, I know it's to be merged).
The advantage I'd have with compose when using mailu is.... uhm... having to define "networks:" once?... using "depends_on:" instead of an orderly start up ...? What advantages are there with compose when using trivial container arrays? Is there any? Compose is designed to be a tool of convenience that simultaneously creates lock-in. However, they made the docker command all encompassing, so what else would I choose? Granted I don't run swarms > 2 nodes and I suspect that my opinion of compose would at the very least me modified if I did, but this is OMV (not a dedicated box for running swarms).In my opinion, we must not lose sight of the fact that OMV is designed for the general public. This means that maximum simplicity, efficiency, reliability and ease of use are always sought, adapting to the demands of users who, in most cases, know little about Linux, CLI, systemd, salt or docker.
Following this reasoning, and within the multiple possibilities of docker implementation, in my opinion, docker-compose is the one that best adapts to these characteristics. And the plugin is designed in that spirit as well.
But OMV goes beyond all this. The great advantage that OMV offers, and which other NAS systems do not have, is its flexibility provided by its Debian base, in addition to the customization features that OMV itself offers through environment parameters, etc. All this provides the possibility of also integrating more advanced users like you, users may have more specific needs and the necessary knowledge can adapt OMV to their convenience. In this way, OMV is capable of serving the purposes of the vast majority of inexperienced users and that small minority of advanced users who are looking for something more, such as using docker in another way.
What more could you want?
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!