I would uninstall the docker-compose package (not the docker-compose-plugin package)
sudo apt-get purge docker-compose
I would uninstall the docker-compose package (not the docker-compose-plugin package)
sudo apt-get purge docker-compose
Avoid using multi disk volume groups.
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...
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.
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.
How? Pull request in Github?
Sure, if you want. Otherwise, email, pm, or even post in a thread.
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.
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.
I de- and reinstalled the plugin and get the following errors now:
Why did you uninstall the plugin? The plugin is not causing this. Something in your remotemount settings is causing the issue and plugin can't fix that.
Does this mean that the ability to include self-hosted templates will be a part of the feature in the future - in the way that some other NAS distros have this integrated?
What is a self-hosted template?
Nope, still shows nothing
Do you see any containers in the Stats tab? What is the full path of the shared folder you set on the Settings tab? You can find in the Storage -> Shared Folders tab in the Absolute Path column (may need to make it visible). Also, what is the output of:
dpkg -l | grep -E "openme|docker"
find text file attached.
Any updates available? everything I see looka good.
If there was a "heads up" info about it, how it works and why,
No amount of time for a heads up would’ve been enough and I would’ve had to give a dissertation on how docker works to convince people there was no chance they would lose their data (unless they did something outside our instructions).
ow do I get the running container info to display in the Compose -> Containers tab?
Can you post the output of (likely need to attach a text file)
sudo omv-aptclean repos
sudo omv-salt deploy run compose
The question is: is it possible to return to showing the status of containers in the WebUI without doing this migration? After the omv-extras update, this option disappeared from dashboard.
The container widget moved to the compose plugin. So, the only way to get it is stay with the older version of omv-extras (6.1.1).
this mandatory migration to composer was terrible for me,
It isn't mandatory.
who likes to manage containers (install, update and remove) directly through the Portainer interface
Shockingly, you can do that in the compose plugin and it is simpler in my opinion.
Before, I just clicked a button in omv-extras, installed Portainer and everything was fine and simple.
All you have to do is install the compose plugin from the Plugins tab. Future updates will be installed from the Updates tab which you are doing anyway to update OMV and the OS. The setup of the containers will need to be done again but you had to setup your containers in portainer when you started too. You will have a better backup and easier recovery as well. I get it that change is hard for some but look at it instead of just assuming the change is bad.
I rarely touch the terminal to do anything Docker related
You still won't have to.
Everything seemed so much simpler before and the only thing I did was check the status of containers in the OMV WebGUI.
That also still works.
And all this change seems to be still poorly documented and from what I've read so far in this topic,
There are multiple guides and this thread has just about everything you need. I guess you need to read more.
I'm going to have a lot of work to migrate everything... Terrible.
Or just install portainer in the compose plugin and stay with your old system. Even that migration is covered extensively.
probably some creative way to do that but I cant think of a way right now. might as well add longer delay to docker.
Is there a way to insert delays into the boot sequence?
Sure but then any service that is waiting on the mergerfs pool (like docker for example) would fail. I don't consider this a solution though.
sudo systemctl edit srv-mergerfs-POOLNAME.mount
and add:
Maybe a way to assist is a clear path/guide to "migrate" from portainer way to compose plugin.
Other users.
I run 2 rpi based servers and both show exactly the same issue.
I assume there are other Raspberry users who come across the same issue and I am curious what their findings are.
Isnt that the purpose of the forum?
Sure but we had all of the info/questions/investigation notes in the other thread.
I'm glad you have two that show the same issue but that doesn't help me. The mergerfs plugin has zero issues on my sata connected systems. I don't have a bunch of usb drives (none that are hard disks) and a lot of time to reboot a system waiting for failures. I know you want to blame me for changing from fstab to systemd but all fstab entries are converted to systemd.
If you and other users can figure it out, I will gladly make changes to the plugins.