So first off I do think Docker is an awesome evolution for Unraid but the last few days has me thinking.  And we know how dangerous that is.

 

As things are progressing right now, aren't we still going to run into the problem that Docker Apps are only as healthy and up-to-date as their creator makes them?  Aren't we still at risk of abandonment like we were with plugins? Dependent on the good graces of a single dev, and stuck when they disappear?

 

Sure we've eliminated the package dependency concerns but I worry we'll still find ourselves in the wild west of rising and falling ghost towns.

 

"But jumperalex someone else can take it over / fork the effort" you say.

 

Well that is/was possible with plug-ins too.  And sometimes it happened.  Other times it didn't.  When it did it was after a long delay while everyone waited to see if the dev came back so as to avoid wasting their time.

 

I bring this up because, again, I do think docker has great promise.  But I think a lot more thought has to be put in (by LT and the community) about how best to structure the Docker ecosystem for unRAID.  Because it needs to be an ecosystem with standards and practices, and self-sustaining/healing.

The effort to takeover/fork a stagnat dock is orders of magnitude less than a similar action with a plugin.

 

Also the skill required to support a dock is much less than a plugin and has very little unRAId specific knowledge.

 

Proof in point lets compare nzbget dock to plugin here in this post to add inpact

 

FROM debian:jessie
MAINTAINER needo <[email protected]>
ENV DEBIAN_FRONTEND noninteractive

# Fix a Debianism of the nobody's uid being 65534
RUN usermod -u 99 nobody
RUN usermod -g 100 nobody

RUN sed -i 's/main$/main non-free/' /etc/apt/sources.list
RUN apt-get update -q
RUN apt-get install -qy unrar nzbget

#Path to a directory that only contains the nzbget.conf
VOLUME /config
VOLUME /downloads

EXPOSE 6789

# For some unknown reason nzbget does not work with ENTRYPOINT
ADD start.sh /start.sh

# Let's not run nzbget as root
USER nobody
CMD ["/bin/bash", "/start.sh"]

 

<?xml version='1.0' standalone='yes'?>

<!DOCTYPE PLUGIN [
<!ENTITY plugin "NZBget">
<!ENTITY author "overbyrn">
<!ENTITY plgver "1.3">
<!ENTITY pkgnam "nzbget.x64">
<!ENTITY pkg "/boot/packages">
<!ENTITY plg "/boot/config/plugins/nzbget">
<!ENTITY img "/boot/config/plugins/images">
<!ENTITY gui "/usr/local/emhttp/plugins">
<!ENTITY url1 "https://raw.github.com/overbyrn/UnRAID/master">
<!ENTITY url2 "https://dl.dropbox.com/u/572553/UnRAID">
<!ENTITY dev "false"><!-- set to "true" during plugin development -->
]>

<PLUGIN>
<!--
Copyright 2013, Rich Manton (overbyrn)

This Plugin installs and provides nzbget support for unRAID.

Plugin file locations:
/boot/plugins/nzbget_x64_overbyrn.plg # this file
/tmp/plugin-prepare # network readiness script
/tmp/plugin-chkcfg # plugin upgrade check script


900 LINES REMOVED here

<FILE Name="/tmp/plugin-development" Run="/bin/bash">
<INLINE>
if [ "&dev;" == "true" ]; then
  if [ -f /boot/config/plugins/nzbget.php ]; then
    rm -f &gui;/nzbget/nzbget.php
    ln -s /boot/config/plugins/nzbget.php &gui;/nzbget/nzbget.php
  else
    mv &gui;/nzbget/nzbget.php /boot/config/plugins/nzbget.php
    ln -s /boot/config/plugins/nzbget.php &gui;/nzbget/nzbget.php
  fi
  if [ -f /boot/config/plugins/rc.nzbget ]; then
    rm -f /etc/rc.d/rc.nzbget
    ln -s /boot/config/plugins/rc.nzbget /etc/rc.d/rc.nzbget
  else
    mv /etc/rc.d/rc.nzbget /boot/config/plugins/rc.nzbget
    ln -s /boot/config/plugins/rc.nzbget /etc/rc.d/rc.nzbget
  fi
fi

rm /tmp/plugin-development
</INLINE>
</FILE>

</PLUGIN>
[code]

 

I had to remove over 900 line sof code to post the addon here whereas the docker is a complete copy.

 

IMHO this alone makes it very unlikely a popular dock will die.

 

Personally I would not worry

Sounds fair.  Thanks for indulging me.  And from the other discussions it sounds like losing base image support (phusion) is the bigger hassle, though still not a likely occurrence.  And of course hopefully there will soon be more officially supported OS images out there in the near future as docker gains popularity.

... whereas the docker is a complete copy.

 

Are you sure?

 

There's an "ADD start.sh ..." in there.  Don't we need to know the contents of start.sh in order to re-create the image?

 

Also, the docker file is dependent on debian:jessie ... isn't that a potential maintenance problem?

 

Sorry, I'm just trying to learn about creating docker images, and wanting to understand.

The dockers have got more complicated than originally expected but still VASTLY simpler than the equivalent unraid specific plugin.

 

Assuming the source is licensed correctly I am still sure taking over a project is simple.