[OUTDATED] Extended Docker configuration page

Guys, Tom had an idea of adding a new section on Menu, called Apps or something like that. Originally, we planned to add an icon of the dockerized app  into this section with a link to it's web ui.

We can do more than that; some commands could be added too, if we use some kind of banner.

This is barely a scratch, but can offer an idea of what I'm saying. This could be a kind of simplified interface to add, start/stop, edit or remove apps.

So, what do you think?

Thats awesome!

Guys, Tom had an idea of adding a new section on Menu, called Apps or something like that. ...snip...

So, what do you think?

I love the idea of having a control panel from within the WebUI (much like you wrote) and the icons are attractive.  I can see the need of having 30 or so apps, and frankly I prefer them to be in a table that can be sorted by name or popularity, or installed or not, much like your current plugin. 

I'd prefer a table layout: Little icons on the left side;  for installed apps controls to start and stop, and log, and volume mapping.  For those not installed a short description, info url, and an install link.

D

Guys, Tom had an idea of adding a new section on Menu, called Apps or something like that. Originally, we planned to add an icon of the dockerized app  into this section with a link to it's web ui.

 

We can do more than that; some commands could be added too, if we use some kind of banner.

 

This is barely a scratch, but can offer an idea of what I'm saying. This could be a kind of simplified interface to add, start/stop, edit or remove apps.

 

So, what do you think?

I like it!

Guys, Tom had an idea of adding a new section on Menu, called Apps or something like that. ...snip...

So, what do you think?

 

I love the idea of having a control panel from within the WebUI (much like you wrote) and the icons are attractive.  I can see the need of having 30 or so apps, and frankly I prefer them to be in a table that can be sorted by name or popularity, or installed or not, much like your current plugin. 

 

I'd prefer a table layout: Little icons on the left side;  for installed apps controls to start and stop, and log, and volume mapping.  For those not installed a short description, info url, and an install link.

D

It won't be a replacement, just a more "app" centric menu;  the users click on the logo, the config page will open. The extension page will still exist.

Hello gfjardim,

Thx for your pyload docker, with your docker, i don't have anymore rights problems with my downloaded files.

I NAT  the ports you exposed like this:

192.168.0.14:7227->7227/tcp

192.168.0.14:8000->8000/tcp

192.168.0.14:8022->9666/tcp

For me 8000 for the GUI, 7227 remote and 9666 for SSH

But i can't connect to SSH.

Can you confirm please?

I need to connect by SSH to the docker for install unrar without this pyload can't uncompress automatically.

Thx for the help.

Obrigado

Guys, Tom had an idea of adding a new section on Menu, called Apps or something like that. Originally, we planned to add an icon of the dockerized app  into this section with a link to it's web ui.

 

We can do more than that; some commands could be added too, if we use some kind of banner.

 

 

This is barely a scratch, but can offer an idea of what I'm saying. This could be a kind of simplified interface to add, start/stop, edit or remove apps.

 

So, what do you think?

Sounds sensible to me.

I have two thoughts:

Lets make sure we build in the ability to run the same app multiple times if a user so requires. This is a cornerstone of docker that would be easy to not cater for when moving to an "app in a box" model.

IMHO a serious failing of docker is transparency of what specific version of things you are getting when you start a vanilla container or an enhanced "update with script" container. We need to think of better ways to present this information and allow users more control as taking XBMC for example a single version makes a world of difference...  between it matching your other systems and on the other hand being to old (a.k.a useless) or too new (a.k.a messing up your database).

Another preview:

Some banners aren't scaled correctly, but you can see what I propose.

Some banners aren't scaled correctly, but you can see what I propose.

I like it!

As someone mentioned, version numbers would be another great addition, but that is a good look.

I'm not sure what will happen when you click an icon; will it launch the program, open the config, give me options to uninstall, or update, etc.

Oh, maybe an overlay showing if an update is available too; like your current system, but with a graphic instead of text.

Looks promising.

Some banners aren't scaled correctly, but you can see what I propose.

 

I like it!

 

As someone mentioned, version numbers would be another great addition, but that is a good look.

 

I'm not sure what will happen when you click an icon; will it launch the program, open the config, give me options to uninstall, or update, etc.

 

Oh, maybe an overlay showing if an update is available too; like your current system, but with a graphic instead of text.

 

Looks promising.

Versions are complicated to obtain. Imagine a CouchPotato or a NZBGet container with EDGE? How to import/export version info?

For now, if you click on the logo, it will open the config page to those that has it. Start/Stop/Edit/Remove are already functional too.

It is unfortunate that application versions are not handled by docker itself. I would suggest the best route for us would be something simple like a "VERSION" config file that is created by startup.sh and contains a direct query of the daemon version info (or some better variant of this).

Another area we need to consider is backups up the config files. This is something that deserves a wider discussion but for now perhaps something as simple are a button to download a tgz of the config folder when the container is stopped.

Also we still need to address how to visually differentiate and handle between more than one copy of a container.

Another area we need to consider is backups up the config files. This is something that deserves a wider discussion but for now perhaps something as simple are a button to download a tgz of the config folder when the container is stopped.

Upcoming -beta8 has big changes in store for how docker is managed.  What we're doing is creating "image" files that are formatted using btrfs and loop mounted onto /var/lib/docker.  This is all done by rc.docker.

The 'my-template' template files are stored in a directory inside this volume called /var/lib/docker/unraid-templates.  The list of autostarted containers is stored in /var/lib/docker/unraid-autostart.  In other words, not on the flash.

Let's say you start out and create a 10G image file named, say /mnt/disk1/Volumes/docker.img.  Now you start docker as usual and download all your images, create containers, etc.

To backup the entire collection it's only necessary to copy that 10G file somewhere, maybe to /mnt/user/Backups.

Similarly you can have a set of image files.  Maybe one where you have everything tweaked just how you want it, and another one that starts out as a copy but maybe you experiment with certain applications.  You can select between these volumes easily through the Docker management page.

More later....

Just to clarify; in this new scheme where does the "appdata" reside e.g. mariadb's, config files etc

HOLY SMOKES.

Dude you have been busy!  This is amazing.  When can I get it? LOL!

HOLY SMOKES.

 

Dude you have been busy!  This is amazing.  When can I get it? LOL!

This will have to wait a bit, because of the inclusion of this plugin into the core functionality. The downside is that not all current templates will be included by default. Community templates will be added by PLG files, I think. I'm waiting Tom on this. The templates will have to be modified to add new functionalities, but until this got defined, I won't play much with it.

Alongside, Tom want icons in this page; I think banners can do a better job. Let's see what got decided.

Just to clarify; in this new scheme where does the "appdata" reside e.g. mariadb's, config files etc

They can be where ever you want them to.  Some options:

a) On another share, eg, /mnt/user/appdata - this is how a lot of templates are set up

b) In the docker volume itself, eg, /var/lib/docker/volumes/appdata - with this the appdata is 'captured' inside the volume

I can see pros/cons for both approaches depending on what you're trying to achieve.

Just to clarify; in this new scheme where does the "appdata" reside e.g. mariadb's, config files etc

They can be where ever you want them to.  Some options:

a) On another share, eg, /mnt/user/appdata - this is how a lot of templates are set up

b) In the docker volume itself, eg, /var/lib/docker/volumes/appdata - with this the appdata is 'captured' inside the volume

I can see pros/cons for both approaches depending on what you're trying to achieve.

Agree. I suggest that we choose a default that best fits with where we are going with docker. The way this addon covers it this now is /setpath/containeralia. We should probably just change this to match where you are going with the main docker files (var/lib...) so any future versioning and backup enhancements natually extend to appdata as well. After all the appdata is actually the most valuable of the three (image+template+appdata).

But this is why I keep bringing up being able to run any number of the same container as it has implications in both the template names and the appdata subfolder. Simply we want the unRAID front end to be as flexible as the actual docker backend.

[glow=red,2,300]UPDATE: [/glow]

Version 2014.08.31:

- Add Apps menu.

What setup of the new Docker install will keep all the config/appdata on the cache drive and ensure that the array disks aren't spun up whenever the Docker containers are starting up/working unless there is a specific reason too (i.e. file copy/move to an array disk/share)

What setup of the new Docker install will keep all the config/appdata on the cache drive and ensure that the array disks aren't spun up whenever the Docker containers are starting up/working unless there is a specific reason too (i.e. file copy/move to an array disk/share)

Let's wait the next beta to see what's being done.

What setup of the new Docker install will keep all the config/appdata on the cache drive and ensure that the array disks aren't spun up whenever the Docker containers are starting up/working unless there is a specific reason too (i.e. file copy/move to an array disk/share)

 

Let's wait the next beta to see what's being done.

You have PM.

How can I get all the nice Icons in the Apps section ?  I have some, but not all.  I see you have a NZBDrone logo... not me, why?

If you need an Icon for PyLoad :  http://pyload.org/_media/logo:pyload-logo-edited3-new-font.png

Interesting.  I have an NZBDrone icon, but not a SABnzbd icon

Regardless, this is good work.  Thanks again for all you do for us.

+1 for the good work!