Why only Docker containers and not dockerfiles?

Is there a reason the unRAID Docker templating system only supports prebuilt Docker containers, and not using dockerfiles themselves to build the containers locally?

The reason I ask, is that I have built some docker containers that have free but proprietary software (such as Syncrify and Adaptec maxView Storage Manager) and it would not be appropriate to include their proprietary software inside a downloadable Docker container... but it is perfectly OK to distribute a dockerfile that--when being built--downloads the software and installs/configures it into a new docker container on the destination system.

I am by no means a docker expert (as in I know zero about creating one) but my understanding is this:

Only when using a non automated builddoes docker bypass the dockerfile (simply because one does not exist)  using automated builds unraid (and any docker implementation) uses the dockerfile from docker hub to build the container.  Therfore you should not have any issues at all. (99% of the docker apps running in unraid are automated builds).

And to expand a bit further (and stretching my understanding quite a bit) unraid does not support docker compose but tbh I don't know the exact ramifications of that for the reasons already given

But for further questions I'd suggest bringing this thread to the attention of lsio or binhex or aptalca etc

Sent from my LG-D852 using Tapatalk

Unless you mean why does the dockerfile have to be hosted on docker hub and not on github etc in which case I would guess that you could install the container manually via the command line but I really don't know much about that

Sent from my LG-D852 using Tapatalk

Building the containers locally is possible, but its like re-inventing the wheel.

As Squid points out, a large percent of dockers are automated build, thus it makes everything simpler to support as everybody will be referring to same published image in Docker Hub. Only the hip, l33t kids with know how should be running hand built images as then they should be able to debug and fix any issues from the docker file.

Now there is no reason why CA, or unRaid itself couldn't support building docker images from the Dockerfile, but really that's like wasting development effort when a fully supported and automated system is already in place in Docker Hub, plus a large docker.img is needed to support development efforts as docker will create intermediary images of increasing size as it continues to build the larger dockers.

As a developer, I have a Slackware Docker to build and test against and that consumes like 7GB and if I was going to DL the bits and pieces everytime I built it and patched it, I would need a huge docker.img say around 50GB, and waste a lot of time, rather than just DLing the total image once from Docker Hub. (after I issued the build command)

Bubbaq, the only way I can see to have a docker container that meets the license restrictions of those apps is if the base image commited to DockerHub Registry does not have it installed but does have a first run script that does all the required steps of installing the licensed software.

The possible trouble with that varies depending on how complex the install is. If it needs to compile software than there will be extraneous files and software in the dockerjust to support the build process.

I wish there was a better way to be legal and follow the license agreements while being user friendly, but there typically isnt. Except for what you already hinted at by only supplying a Dockerfile and supporting scripts to those interested.

I get why pulling docker containers *is* supported, but simplicity does not negate copyrights.  Suppose I created a dockerfile that when built created a docker container full of Madonna music.  The fact that it gets pre-built automatically on Docker Hub before you pull it doesn't work legally.  The analysis doesn't change if "Madonna music" is replaced with proprietary software.

There is plenty of proprietary software out there that is free to download and use, but NOT free to redistribute (such as Adaptec maxView Storage Manager).  Downloading it in a pre-built container is a problem, whereas building the container from a dockerfile (which pulls the software from a proper distribution source) is OK.

Just to clarify what I said, the licensed software would not get pulled down until the END USER ran the docker container.

Just to clarify what I said, the licensed software would not get pulled down until the END USER ran the docker container.

I have done this but you have to have to install the program to a mountpoint on the local filesystem for it to be persistent.... otherwise you'd have to download it every time you started the container.

This is actually necessary with Syncrify because it auto-updates itself and it keeps is own live database in its install home, so my container startup script enforces that the Syncrify home (/opt/Syncrify) has to be mounted to the host filesystem and installs it there if it doesn't already exist.  If it does exist (i.e. the second time you start the container), then it starts the application.

Just to clarify what I said, the licensed software would not get pulled down until the END USER ran the docker container.

 

I have done this but you have to have to install the program to a mountpoint on the local filesystem for it to be persistent.... otherwise you'd have to download it every time you started the container.

 

This is actually necessary with Syncrify because it auto-updates itself and it keeps is own live database in its install home, so my container startup script enforces that the Syncrify home (/opt/Syncrify) has to be mounted to the host filesystem and installs it there if it doesn't already exist.  If it does exist (i.e. the second time you start the container), then it starts the application.

Changes made to a container doesn't get removed if you stop/start the container. That only happens if you update it. So it's not really needed to install it on a host mapped path.

I suppose, you could write a plugin, which could check for the docker image locally and build it as necessary. This is the only way I see unRaid supporting docker images built locally from Dockerfiles. Hmm, if only my php UI skills are worth talking about.

Changes made to a container doesn't get removed if you stop/start the container. That only happens if you update it. So it's not really needed to install it on a host mapped path.

Except when you have a program that has some data files co-mingled with their code.  Doing such an update loses your data, plus you get data stored in the docker image, that blows up its size.  This is particularly true if Syncrify which stores its databases with its code.  It's a good application, just not docker-friendly.

Changes made to a container doesn't get removed if you stop/start the container. That only happens if you update it. So it's not really needed to install it on a host mapped path.

 

Except when you have a program that has some data files co-mingled with their code.  Doing such an update loses your data, plus you get data stored in the docker image, that blows up its size.  This is particularly true if Syncrify which stores its databases with its code.  It's a good application, just not docker-friendly.

I just said that doing an update losses your data.

I don't disagree on your other points.

Changes made to a container doesn't get removed if you stop/start the container. That only happens if you update it. So it's not really needed to install it on a host mapped path.

 

Except when you have a program that has some data files co-mingled with their code.  Doing such an update loses your data, plus you get data stored in the docker image, that blows up its size.  This is particularly true if Syncrify which stores its databases with its code.  It's a good application, just not docker-friendly.

You can copy all those files and folders to the config folder during container start and then create symlinks in their places. That way everything will be preserved.

You can check out my zoneminder container. A lot of files and folders are copied out of the container through the firstrun.sh that runs at start.

LOL.... I completed the changes to the Syncrify docker to delay downloading the app tarball until the docker was run, and got it all working with the install going to the local filesystem.  Did an install test on a clean unRAID test system and it worked.

Then on a whim, I closed out docker, and tried running the application start from native unRAID and voilla..... it runs native now.

So I went back to the application install script and it turns out the whole reason it was failing to install on unRAID native was it was looking for /etc/init.d/ to put its startup script or systemd to setup its service.  So all the work trying to dockerize it was unnecessary.  DOH!