[OUTDATED] Extended Docker configuration page


Recommended Posts

  • Replies 635
  • Created
  • Last Reply

Top Posters In This Topic

The /var/lib/docker/community-templates directory will we the default path to community based templates.

These should go in /boot/config/plugins/dockerMan/ - and instead of the actual templates being in there, perhaps there is a file that defines the URL's of where the "community templates" are located, e.g., github repos.

Link to comment

The /var/lib/docker/community-templates directory will we the default path to community based templates.

These should go in /boot/config/plugins/dockerMan/ - and instead of the actual templates being in there, perhaps there is a file that defines the URL's of where the "community templates" are located, e.g., github repos.

 

Hum, this approach is doable, but will centralize the the availability of templates.

 

Maybe a JSON formated file?

 

[{"user":"gfjardim","name":"CrashPlan","url":"http://path.to/Crashplan.xml"},{"user":"needo","name":"CouchPotato","url":"http://path.to/CouchPotato.xml"}]

 

Something like this???

 

There's a major drawback in this approach. I get tons of info from those templates. The user templates don't have all these info (icon, banner, docker hub, webui etc...) and even if they do, they could have a bug that never got fixed. Even now or then I add some info tho those templates.

 

Do if we go this path, these xml files need to be downloaded to the server, and made available promptly. Maybe download templates on the first access to the webui, and then update them alongside with containers.

 

How this sounds to you?

Link to comment

 

Please, update to the last version please. I modified so many things that's impossible to keep track them.

 

well like i said .. when i click check it says it is up to date ...

no new versions show up...

can i stop docker ... remove the plugin

and install extension again ?

or will i loose my templates like this?

running beta 7 fyi

 

Link to comment

 

Please, update to the last version please. I modified so many things that's impossible to keep track them.

 

well like i said .. when i click check it says it is up to date ...

no new versions show up...

can i stop docker ... remove the plugin

and install extension again ?

or will i loose my templates like this?

running beta 7 fyi

 

Hum, I've stopped updating for beta7. Since you're using a beta version, you should update to beta8.

 

The instructions are here: http://lime-technology.com/forum/index.php?topic=34955.0

Link to comment

Hum, this approach is doable, but will centralize the the availability of templates.

I think it does the opposite: does not centralize availability of templates.

 

Maybe a JSON formated file?

 

[{"user":"gfjardim","name":"CrashPlan","url":"http://path.to/Crashplan.xml"},{"user":"needo","name":"CouchPotato","url":"http://path.to/CouchPotato.xml"}]

 

Something like this???

 

More like this:

 

[{"user":"gfjardim","url":"http://path.to/repo.that.contains.template.xml.files"},
{"user":"needo","url":"http://path.to/repo.that.contains.template.xml.files"}]

 

The 'template manager' would retrieve list of all gfjardim's templates, and all needo's templates.  Say user wants to install a Plex image.  Maybe gfjardim's templates all use phusion baseimage.  Maybe needo uses a different baseimage.  That might be one criteria for which Plex template a user might choose.  Maybe there are other differences. 

 

UI would include a way to add somone else's "template repo", eg, "limetech".

 

I don't think it's necessary to store the template lists somewhere - UI just retrieves it each time.  Here's one reason I want to do this and I'll state it plainly: some of the popular applications people use "facilitate" what some might consider "pirating", depending perhaps on which country you live in.  These popular apps need to be hosted somewhere other than a limetech repo and certainly not "built-in" to unRAID OS distro.  Make sense?

 

An aside: why did you choose xml for the template files?  Everything in Docker uses JSON - just curious.

Link to comment

mmm that will require a lot of work :(

 

and i was waiting if limetech would stick with this half assed solution by mounting this docker image

he first lets us go through the trouble of converting our reiserfs cache disks to btrfs without a converting tool ... so moving off cache drive ... reformat ... putting on cache drive again

and now he changes idea again and we need to docker build all our containers again ...

cause i have custom containers which are not in your templates...

 

if he can tell me how to copy my containers into this new image that would make things MUCH easier ....  >:(

Link to comment

mmm that will require a lot of work :(

 

and i was waiting if limetech would stick with this half assed solution byt mounting this docker image

he first lets us go through the trouble of converting our reiserfs cache disks to btrfs without a converting tool ... so moving off cache drive ... reformat ... putting on cache drive again

and now he changes idea again and we need to docker build all our containers again ...

cause i have custom containers which are not in your templates...

 

if he can tell me how to copy my containers into this new image that would make things MUCH easier ....  >:(

 

What are you on about?  Come on, it's beta - things change.  You don't want to adapt, then wait for -rc1.  The docker image is absolutely not half-assed either, it provides a lot of benefits.  There are ways to migrate your btrfs-formatted file system to an image file, but if you are complaining about having to move files off a single disk in order to re-format, you will not like procedure to move btrfs file system that preserves subvolumes.

Link to comment

well limetech

 

unraid is for media files...

i have 45000 + tv episodes

which brings my plex database up to about 1500000 small files which are a pita to transfer ....

takes about 1 day to just move these .....

now i know with just having to rebuild my containers i don't need to move my data

but still it is a lot of work ... download the docker zip.... make changes to the docker file.... then do a docker build and then make the container ....

 

i know in your testing environment there is not such an abundance on files so i seems all easy to you

but for us in the real world it is a lot of work especially when you change ideas a lot

 

and the main reason why i updated is because beta 6 btfs version was SLOOOOOW

now beta 7 is much quicker ....

i hope beta 8 is also an improvement ... but i will have to work hard to get there

so i was waiting for beta 9 where i saw already a hint for in one of the posts Tom made to see what changed in that one

 

Link to comment

well limetech

 

unraid is for media files...

i have 45000 + tv episodes

which brings my plex database up to about 1500000 small files which are a pita to transfer ....

takes about 1 day to just move these .....

now i know with just having to rebuild my containers i don't need to move my data

but still it is a lot of work ... download the docker zip.... make changes to the docker file.... then do a docker build and then make the container ....

So you are not complaining about moving your 1500000 small files (because they are not in the ./docker tree right??), just complaining that you have to re-download your docker images - is that right?

 

Here's the general idea, should work but I haven't tried it:

 

1. Shrink your btrfs file system on your disk to something smaller.  Your btrfs-formatted disk is probably pretty big, and the amount of space Docker is actually using is much smaller, right?  Let's say Docker is using 8GB.  Then you use 'btrfs resize' to shrink file system down to say 10GB.

 

2. Now use 'dd' to copy 10GB starting at beginning of partition where btrfs is stored, to a file on another disk.  This file is now your 'docker image' file to use with -beta8.

 

Seems to me that should work.  But I'd probably make a copy of the source disk first.

 

There are maybe other ways, but in the end it's just simpler to start your docker images re-downloading and then go off to the bar and come home when it's done.

 

None of this nonsense will be necessary using image files.

Link to comment

Hum, this approach is doable, but will centralize the the availability of templates.

I think it does the opposite: does not centralize availability of templates.

 

Maybe a JSON formated file?

 

[{"user":"gfjardim","name":"CrashPlan","url":"http://path.to/Crashplan.xml"},{"user":"needo","name":"CouchPotato","url":"http://path.to/CouchPotato.xml"}]

 

Something like this???

 

More like this:

 

[{"user":"gfjardim","url":"http://path.to/repo.that.contains.template.xml.files"},
{"user":"needo","url":"http://path.to/repo.that.contains.template.xml.files"}]

 

The 'template manager' would retrieve list of all gfjardim's templates, and all needo's templates.  Say user wants to install a Plex image.  Maybe gfjardim's templates all use phusion baseimage.  Maybe needo uses a different baseimage.  That might be one criteria for which Plex template a user might choose.  Maybe there are other differences. 

 

UI would include a way to add somone else's "template repo", eg, "limetech".

 

I don't think it's necessary to store the template lists somewhere - UI just retrieves it each time.  Here's one reason I want to do this and I'll state it plainly: some of the popular applications people use "facilitate" what some might consider "pirating", depending perhaps on which country you live in.  These popular apps need to be hosted somewhere other than a limetech repo and certainly not "built-in" to unRAID OS distro.  Make sense?

 

An aside: why did you choose xml for the template files?  Everything in Docker uses JSON - just curious.

 

XML is more human readable, I think. People need to know what is happening under the hood. I always struggled interpreting JSON. I almost adopted YAML for that matter. ;D

 

Illustrating: the webui needs to present a icon. Where it find that information? Today it's in the xml template. The template is the glue that stick together the params needed to run a container and information that allow us to present a more feature rich interface. Because of that, or we have the templates stored on the server, or we have to think about storing these info in another form. We can download them and update them, but it won't suffice the need of the webui to download them on-the-fly.

 

I don't think templates should be a legal problem; Synology ship their NAS'es with all these features in the Download Center. A knife is legal until you kill your wife and let your FS orphan  ::) ... These are legal tools. Templates don't carry any code that download or serve anything.

 

 

Link to comment

I finally upgraded to beta8, and am having a bit of difficulty getting my dockers running again.  Here's what I've done so far...

 

I was using gfjardim's docker manager plugin from -beta6, so I deleted its .plg file from /boot/config/plugins.

 

Next, after Starting array, visit Extensions/Docker...Decide where (which disk/share) you want your docker image to exist and what you want to name it, and enter it here.  I entered:

 

/mnt/disk10/docker  (You don't have to name it docker.img.  Could be docker1.img or my-docker.img or test-docker.img, etc.  You don't have to give it an img extension.  Could give it any extension or no extension.  =>  so I decided to keep the same name I had on my cache "docker")

 

I set the size to "10" for the field GB.

 

Now click 'Start' to start docker.  Since this is first time starting it will create the image file and mount it at /var/lib/docker.

 

Once you have your new docker volume image set up, you can copy all your existing my-* templates by typing this command:

 

cp /boot/config/plugins/Docker/* /var/lib/docker/unraid-templates

 

After that you can delete /boot/config/plugins/Docker from your flash, or leave it there if you want - it's no longer used.  (I have not deleted anything yet)

 

Sorry you will need to re-download all the docker images again.

 

I got stuck with the above, re-downloading / installing the dockers again.  I have not done the steps below yet; I'm waiting until everything is working before removing anything.

 

The following is optional, depending on how you set up docker pre -beta8.  It's ok to skip this and deal with it later.

 

Next to get rid of 'docker' directory on cache disk (or btrfs array disk if you did that), it's kind of a pain.  Here's how to do it:

 

(assuming /mnt/cache/docker is your docker volume from beta7)

btrfs subvolume delete /mnt/cache/docker/btrfs/subvolumes/*
rm -r /mnt/cache/docker

 

When I tried clicking the green plus button, I was able to select one of my templates, which seemed like a good thing.  I chose SABnzbd to start.

 

I verified everything looked good, then clicked on Add.  I got the screenshot below.

 

I then tried installing the plugin from the beta 8 location (https://raw.githubusercontent.com/gfjardim/dockers/beta8/dockerMan/dockerMan.plg) and that seemed to install okay.

 

I tried again to add SABnzbd, but got the same message.

 

I've stopped and posted this before I messed anything up (worse?)

new_docker_fail.jpg.46f49bf06f2003b08c50bcc8e2723cf1.jpg

Link to comment

XML is more human readable, I think. People need to know what is happening under the hood. I always struggled interpreting JSON. I almost adopted YAML for that matter. ;D

 

Illustrating: the webui needs to present a icon. Where it find that information? Today it's in the xml template. The template is the glue that stick together the params needed to run a container and information that allow us to present a more feature rich interface. Because of that, or we have the templates stored on the server, or we have to think about storing these info in another form. We can download them and update them, but it won't suffice the need of the webui to download them on-the-fly.

I tend to agree and have no problem using xml files - just was curious what your reasoning was...

 

Templates don't carry any code that download or serve anything.

That what the people behind The Pirate Bay thought about torrent files.  ;)

 

Anyway, besides that, the idea of having template repos is a powerful one I think.  It lets developers create 'families' of images independently of unraid os releases.

Link to comment

 

Anyway, besides that, the idea of having template repos is a powerful one I think.  It lets developers create 'families' of images independently of unraid os releases.

 

I agree. The remote file should be in JSON, I think. The local file, I don't know. A plain text file with URLs should suffice. What do you think?

Link to comment

I agree. The remote file should be in JSON, I think. The local file, I don't know. A plain text file with URLs should suffice. What do you think?

 

Say you had a text file /boot/config/plugins/dockerMan/template-repos (for example) that had these two lines:

 

https://github.com/gfjardim/docker-templates/tree/master/templates/gfjardim
https://github.com/gfjardim/docker-templates/tree/master/templates/needo

 

Then you would use github API to retrieve set of xml files in there (github api uses json).

 

The part in the url after "github.com/" is the owner of the repo, ie, "gfjardim's templates".

 

In your case, you are kind and hosting other people's templates (needo, eroz, smdion).  Maybe this is what you meant before: "centralized"?  I would probably request those guys to host their templates on their own github repos.  In this case maybe the two lines look like this:

 

https://github.com/gfjardim/docker-templates/tree/master/templates
https://github.com/needo/docker-templates/tree/master/templates

 

If it turns out that hitting github to download all these templates each time someone wants to create a container proves to be too slow, well they can be cached, maybe like this:

 

/boot/config/plugins/dockerMan/templates/gfjardim

/boot/config/plugins/dockerMan/templates/needo

etc

 

 

 

 

 

Link to comment

The /var/lib/docker/community-templates directory will we the default path to community based templates.

 

Something else I noticed: you are creating a /var/lib/docker/images directory to store the banners and icons.  The problem is choice in directory name.  Should not be "images" - should be "unraid-images", or put images under unraid-templates.

 

The reason is this: when docker first starts up,  it generates that initial directory structure and set of files in /var/lib/docker.  In essence, that directory is "private" to docker.  Suppose they come out with a new docker release that wants to create an "images" directory - well it might fail (or our plugin might fail) because we already create and use an 'images' directory.

 

That is why I put 'unraid-' prefix on 'unraid-autostart' and 'unraid-templates' - it's extremely unlikely those names would conflict with anything docker might want to create.

 

So I dunno - I'm open to suggestions and opinions.  If it looks like we might be adding more 'unraid-specific' stuff to /var/lib/docker then maybe we should create this:

 

/var/lib/docker/unraid

/var/lib/docker/unraid/autostart - the autostart file

/var/lib/docker/unraid/templates/ - contains my-*.xml

/var/lib/docker/unraid/images/icons

/var/lib/docker/unraid/images/banners

 

If you agree with this let me know and I'll get changes rolled into -beta9 (this will affect rc.docker).  But on the otherhand, this will require people to move their templates (again)..  Pretty sure users won't want us to change anything because it makes work for them, but once unRaid OS goes to -rc1 it's really going to be "cast in concrete" so if it makes for a better design, now is the time to do it.

 

One more thing:  There is small bug in the .plg file.  Near the bottom of the file in the 'remove' method there is this line:

 

  ln -sf /usr/local/emhttp/plugins/&name;/&name;.plg /var/log/plugins

 

please change to:

 

  ln -sf /usr/local/emhttp/plugins/&name;/&name;.plg /var/log/plugins/&name;

Link to comment

Copying the templates aren't that painful but for someone used to a windows gui it can get confusin.

 

Is there anyway a migration script can be included ?  It could look up the current storage places for the templates/iomages etc then copy them to where they need to go and bingo, all done.

 

But without doubt there are a lot of issues with something like that that I have thought of.

Link to comment

The /var/lib/docker/community-templates directory will we the default path to community based templates.

 

So I dunno - I'm open to suggestions and opinions.  If it looks like we might be adding more 'unraid-specific' stuff to /var/lib/docker then maybe we should create this:

 

/var/lib/docker/unraid

/var/lib/docker/unraid/autostart - the autostart file

/var/lib/docker/unraid/templates/ - contains my-*.xml

/var/lib/docker/unraid/images/icons

/var/lib/docker/unraid/images/banners

 

If you agree with this let me know and I'll get changes rolled into -beta9 (this will affect rc.docker).  But on the otherhand, this will require people to move their templates (again)..  Pretty sure users won't want us to change anything because it makes work for them, but once unRaid OS goes to -rc1 it's really going to be "cast in concrete" so if it makes for a better design, now is the time to do it.

 

 

I agree with that. I just start adding things and don't pay attention to those kind of stuff.

 

May I suggest:

/var/lib/docker/unraid
/var/lib/docker/unraid/autostart        - the autostart file
/var/lib/docker/unraid/templates/       - persistent storage of templates;
/var/lib/docker/unraid/user-templates/  - contains my-*.xml
/var/lib/docker/unraid/images/icons     - persistent storage of icons;
/var/lib/docker/unraid/images/banners   - persistent storage of banners;

 

There's also one thing we'll need to make GitHub API download doable: an OAUTH-TOKEN with tons of hits available; currently, GitHub only allows 60 unauthenticated API hits per hour, which isn't enough.

 

PS. there's another approach: use the git command line to download this stuff.

 

Link to comment

I'm glad you guys are considering the future, and how best to set up the docker stuff, because like you said, once it goes final, it'll be much harder to change these decisions.  We, as beta testers, can live with these changes, as that's part of the deal when you use beta software.  Better to have it 'right' in the end, than worry about us having to move things again.

 

With all that discussion, I suspect my error might have gotten overlooked.  Can anyone please help me get the plugin running?  http://lime-technology.com/forum/index.php?topic=33965.msg326000#msg326000

Link to comment

I finally upgraded to beta8, and am having a bit of difficulty getting my dockers running again.  Here's what I've done so far...

 

I was using gfjardim's docker manager plugin from -beta6, so I deleted its .plg file from /boot/config/plugins.

 

Next, after Starting array, visit Extensions/Docker...Decide where (which disk/share) you want your docker image to exist and what you want to name it, and enter it here.  I entered:

 

/mnt/disk10/docker  (You don't have to name it docker.img.  Could be docker1.img or my-docker.img or test-docker.img, etc.  You don't have to give it an img extension.  Could give it any extension or no extension.  =>  so I decided to keep the same name I had on my cache "docker")

 

I set the size to "10" for the field GB.

 

Now click 'Start' to start docker.  Since this is first time starting it will create the image file and mount it at /var/lib/docker.

 

Once you have your new docker volume image set up, you can copy all your existing my-* templates by typing this command:

 

cp /boot/config/plugins/Docker/* /var/lib/docker/unraid-templates

 

After that you can delete /boot/config/plugins/Docker from your flash, or leave it there if you want - it's no longer used.  (I have not deleted anything yet)

 

Sorry you will need to re-download all the docker images again.

 

I got stuck with the above, re-downloading / installing the dockers again.  I have not done the steps below yet; I'm waiting until everything is working before removing anything.

 

The following is optional, depending on how you set up docker pre -beta8.  It's ok to skip this and deal with it later.

 

Next to get rid of 'docker' directory on cache disk (or btrfs array disk if you did that), it's kind of a pain.  Here's how to do it:

 

(assuming /mnt/cache/docker is your docker volume from beta7)

btrfs subvolume delete /mnt/cache/docker/btrfs/subvolumes/*
rm -r /mnt/cache/docker

 

When I tried clicking the green plus button, I was able to select one of my templates, which seemed like a good thing.  I chose SABnzbd to start.

 

I verified everything looked good, then clicked on Add.  I got the screenshot below.

 

I then tried installing the plugin from the beta 8 location (https://raw.githubusercontent.com/gfjardim/dockers/beta8/dockerMan/dockerMan.plg) and that seemed to install okay.

 

I tried again to add SABnzbd, but got the same message.

 

I've stopped and posted this before I messed anything up (worse?)

 

How did you have docker configured before beta8? Were you using an external btrfs disk, or had you converted your cache disk to btrfs?

 

Personally, I had an external btfrs disk, and I've just commented it out in the go script and have created the 10GB disk on my cache drive. The benefit here is that it has no means of accessing any of my old docker stuff (though my config folders are still in /mnt/user/appdata.

 

I had created a 200GB disk originally because I didn't see the note on 10GB. I've subsequently stopped docker, removed the docker.img file, re-created and re-downloaded all the containers successfully (though without the my-templates as I forgot to copy them out of the docker.img first).

 

So, if I were you I'd make sure there are no old container details lying around, and try again. You can also try without the my-template - just use the default from the GUI (you really only need to know what paths you had defined).

 

If you want to go back to virgin beta8 setup you can stop docker and delete, then re-create the docker.img file as well in case something got screwed up - however as mentioned, this will wipe your my-templates.

Link to comment

Copying the templates aren't that painful but for someone used to a windows gui it can get confusin.

 

Is there anyway a migration script can be included ?  It could look up the current storage places for the templates/iomages etc then copy them to where they need to go and bingo, all done.

 

But without doubt there are a lot of issues with something like that that I have thought of.

 

I would say that anyone who gets confused by this process shouldn't be running betas. :)

 

Also, depending on whether you were running beta6 or beta7 the locations could be quite different. Better for each user, who set docker up, to manage their own migration (at least in my opinion).

Link to comment

mmm that will require a lot of work :(

 

and i was waiting if limetech would stick with this half assed solution by mounting this docker image

he first lets us go through the trouble of converting our reiserfs cache disks to btrfs without a converting tool ... so moving off cache drive ... reformat ... putting on cache drive again

and now he changes idea again and we need to docker build all our containers again ...

cause i have custom containers which are not in your templates...

 

if he can tell me how to copy my containers into this new image that would make things MUCH easier ....  >:(

 

This isn't really a fair complaint. We know it's beta software, and with the introduction of the btrfs requirement Tom and team have been trying to figure out the best way to implement this without requiring the general masses going through the hoops you have (which you volunteered for by running beta software).

 

As for copying the containers, it doesn't really matter. They are very quick to re-download. I just made sure I had a screen shot of my docker config page that showed all my volume mappings for reference. I initially used the my-templates when moving to beta8, but wiped my huge docker.img (which I built without thinking) and got myself into a spot where my-templates were gone. I just used my screenshot to re-assign the volume mappings and was back up again in no time.

 

However, the one major difference between my setup and yours was I mounted an external disk for btrfs to play with Docker as I didn't want to screw around with my cache drive - partially because I have a large plex library as well.

Link to comment

How did you have docker configured before beta8? Were you using an external btrfs disk, or had you converted your cache disk to btrfs?

 

I converted my cache drive to BTRFS, then installed docker there.  I just called it "docker" per the instructions at the time (not docker.img)

 

Personally, I had an external btfrs disk, and I've just commented it out in the go script and have created the 10GB disk on my cache drive. The benefit here is that it has no means of accessing any of my old docker stuff (though my config folders are still in /mnt/user/appdata.

 

I had created a 200GB disk originally because I didn't see the note on 10GB. I've subsequently stopped docker, removed the docker.img file, re-created and re-downloaded all the containers successfully (though without the my-templates as I forgot to copy them out of the docker.img first).

 

So, if I were you I'd make sure there are no old container details lying around, and try again. You can also try without the my-template - just use the default from the GUI (you really only need to know what paths you had defined).

 

If you want to go back to virgin beta8 setup you can stop docker and delete, then re-create the docker.img file as well in case something got screwed up - however as mentioned, this will wipe your my-templates.

 

I've now renamed that docker folder on my cache to OLDdocker, so it's not going to be found by anything.

 

I'm stopping the docker plugin, and will restart it to try again.

Link to comment

Hmmm... I removed the docker image on disk10, and started from scratch.  When I go to the docker page from extensions, I don't see anything to indicate the plugin is installed (no way to "update").

 

I then tried to install the docker plugin from the extension page, by pointing to the beta8 version of the plugin, and got a message that wasn't clear if it was successful or not, and the page didn't change, so I suspect it wasn't.

 

I've not tried to install any dockers yet, since this is exactly the same as it was last night, and I suspect there is a problem with where I am so far, so I'd rather focus on fixing that before trying to install dockers.

 

Ideas on how to resolve?

install.jpg.e5d36cc835c498f2f90a690baf0fedd7.jpg

new_docker_fail.jpg.ec07bc255b4dc2860afa2c69ebe557f4.jpg

Link to comment

Hmmm... I removed the docker image on disk10, and started from scratch.  When I go to the docker page from extensions, I don't see anything to indicate the plugin is installed (no way to "update").

 

I then tried to install the docker plugin from the extension page, by pointing to the beta8 version of the plugin, and got a message that wasn't clear if it was successful or not, and the page didn't change, so I suspect it wasn't.

 

I've not tried to install any dockers yet, since this is exactly the same as it was last night, and I suspect there is a problem with where I am so far, so I'd rather focus on fixing that before trying to install dockers.

 

Ideas on how to resolve?

 

I remember the update process is pretty vague, however I think I got a 4th line that said "running as anonymous" or something equivalent. The only way I knew it was updated properly was when I go to the extensions page I see the Docker Apps entries, and now if I go to extensions/plugins I see Docker Manager and can update it (with just beta8 you only see UnRAID Server OS under plugins).

 

I am not sure why the update would fail, but maybe gfjardim or Tom could help troubleshoot. Also, I've never looked, but I would guess there are some log entries tied to this that may help.

 

One other thought... when moving to beta8 Tom had us remove the old dockerman.plg file, but other mentioned there were 1-2 other files some had, and some didn't. Have you verified everything docker related under the plugins folder is gone? You may have parts of both GUIs?

 

The Docker Manager aside, are you able to create the new docker image file and start docker without issue? It may be worth trying to add a docker app to see what happens.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.