docker utilization for plugins

Zitat von ryecoaaron

Thanks for the info

Where do the files from for an image based on something other than the host? Can the docker access the host file system?

Images are stored in /var/lib/docker. If you try and start a container based on an image you don't have, docker will automatically check the online registry and start downloading the image to store locally. The containers themselves are also stored in /var/lib/docker (can't remember the exact file structure). But what's really nice is that the underlying container file system is based on aufs, layered over the top of the image. So for example, if I have a debian image that takes up 200mb, I then start up a container based on this image and download a 50mb piece of software into the container... the total amount of space taken by the container is only 50mb (plus a small amount of overhead). Docker doesn't duplicate the entire file system. If I create a second container from that debian image, and download a 20mb piece of sofware, the total amount of space for my containers is 50mb + 20mb. And of course, the 200mb for the original image. So running multiple containers can be surprisingly efficient, as long as they are based on the same image.

I suspect this is probably one of the reasons why containers are so quick to start up.

You can make files and folders in the host file system available to a container when you start the container. You basically map a folder on the host system, with a folder in the container, eg docker run -v /etc/myapp_config:/config would map the host directory to a corresponding directory in the container (they don't have to have the exact same path). This allows you to share data from host to container, and between containers. But also, containers can be transient... you tend to create and delete them as needs dictate. Data mapped backed to the host remains in place, after the container has been shutdown or even deleted.

YES YEY YES. Finally Aaron

Zitat von ryecoaaron

Can you explain these two comments more?

Something Tyberious Funk didn't mention that is a HUGE advantage to using docker is that a "dockerfile" is essentially server/application documentation. When you make a server change, you make the change in a dockerfile (or script that is run by the dockerfile).

For example: https://github.com/tuxeh/docke…rr/blob/master/Dockerfile. You can see:

• that debian:wheezy is used as a base
• that the first thing done when building the image is install stuff w/ apt
• then it changes some permissions
• Sets some volumes to be used by the host or other containers.

So, you don't have issues w/ docker that you had with VM's where you changed something in a config file or installed some package in the VM and now you don't remember what it was (you forgot to write it down). The dockerfile is essentially self documenting.

One thing to note though, is that containers are NOT meant to be used like virtual machines. By that I mean in a virtual machine, you install the machine, then ssh in and configure the machine. You should NOT use docker containers like this (though it is possible).

Docker containers should be considered completely throw away. Meaning if you save a config file in a container, then next time you rebuild the container, that config file is gone. So if you want "persistent" data (like your config file), you mount your config directories on the host (or in a data container... but that complicates things for now) and the next time you build your container... the entire app inside it (including operating system) can be completely different, but it still uses your old config file (that you mounted/saved on the host) so it still works the same or is upgraded.

Oh, another thing. All the "unraid specific" docker apps that are being made out there would be fully functionally in OMV... so these apps don't really need to be "recreated". Just use an existing docker :).

One more tip. Learn to use: https://github.com/phusion/baseimage-docker for base images.

There are tons of reasons why, but mainly b/c its easier :P. There are mainly 2 schools of thought when it comes to docker containers:

• each container should only run 1 process
• you can run as many processes as you want in a container.

I would go with #2. It makes things easier and I'm not a giant corporation w/ lots of resources, so being a purist (#1) takes too long.

phusion/baseimage allows you to do #2 easily. It has runit built in (so you don't have to mess w/ supervisord), ssh, cron, etc...

Also, one of the main unraid docker guys is using it: https://registry.hub.docker.com/repos/gfjardim/

Zitat von ryecoaaron

That tells me docker would be good for a media encoding app (handbrake for instance) or file sharing. Probably not so good for web server or media server since you don't want to create the database every time. Am I on the right track?

Nope... :). Docker works great for web servers. You just store your databases on the host (or in a data container) and store your database config for the webapp on the host (or in git... or in environment variables). Usually you use 1 container for mysql, then 1 for your webapp (nginx+php for example). Just google docker mysql... or docker lamp...

If using OMV, I would probably use OMV's mysql plugin with all of my docker apps (or maybe in the future have a mysql docker image specifically for OMV). I don't really want a bunch of mysql servers running, I just want 1... then all my docker images can use it.

A great docker based PAAS app out there is https://github.com/dokku-alt/dokku-alt. It makes docker deployment like heroku.... I run many a web app with it. Its written all in bash, so OMV could steal some code from it if needed :).

A plugin that could create a node, iframe and web link would work for anything from Docker that runs via a web server.

I would image that some kind of Docker interface would be relatively simple to build, in a technical sense. But there are a couple of little tricky idiosyncrasies that would need to be worked out in order to make a a Docker plugin "work" nicely.

For example, some changes you make inside the container won't really work unless you make a corresponding change outside the container. eg, if you change sickbeard's default port from 8080 to 8000, you can make the change in the sickbeard interface (which is running inside the container), but it won't really work unless you change the port mapping for the container.

I've also found user permissions to be a bit annoying to resolve. Most containers are built with the assumption that the application contained will run as root. If you run something like, say, SABnzbd this will result in all your downloaded files being owned by the root user, which can cause some problems. If you change your container to run SABnzbd under a non-root user, then that user will only exist inside the container... unless you create a corresponding user on the host system.

None of these are insurmountable problems. But I think if you want to create a clean user experience, you need to first decide on the "OMV way" of handling containers, and then proceed accordingly.

Here is my nginx-phpfpm dokku dockerfile:

• https://github.com/that0n3guy/…er/baseimage-nginx-phpfpm

Its meant to be used as a base for a dokku app, so it doesn't have an app in it. Basically, you could create a simple dockerfile that references the above docker image. You new dockerfile essentially just adds your app to `/app` and the app will be exposed via port 80.

The above uses scripts for setting up phpfpm and nginx. Basically start by readying the dockerfile. It runs scripts to setup other scripts. This uses https://github.com/phusion/baseimage-docker so read that (particularly the init and runit sections of the docs) before looking at things.

Basically:

• setup.sh scripts are run from dockerfile so they are run when the container is built.
• Scripts named init are added via the setup scripts so they run when the container starts. (useful for setting permissions, tweaking config files, etc..). I rarely start a container without rebuilding it, so essentially an init script is run on "first boot", if you want to think about it that way.
• Scripts named runit are added via the setup scripts so they run something and keep it running (like how supervisord does). So Nginx is run by runit. If nginx crashes, runit will restart it.

Its a "more complicated" example of what docker does... but is a good example of how to use baseimage-docker.

For an interface, I could see OMV doing something very similar to unraid: http://i.imgur.com/TcpT6v2.png

Instead of "host path", be able to select a shared folder and be able to set a folder inside the shared folder.

EDIT: oh... also, we could/should support unraids "templates": https://github.com/gfjardim/docker-containers/tree/templates
(from: http://lime-technology.com/forum/index.php?topic=33965.0 ... see template repo section).

The UI is essentially just building a docker command. See: http://screencast.com/t/KOS7LQDhwY ... Also: http://www.seandion.info/unraid/unraid-dockers/

Simpler example:

• template: https://github.com/gfjardim/do…tes/gfjardim/ownCloud.xml
• hub image: https://registry.hub.docker.com/u/gfjardim/owncloud/

Note: The image doesn't show this very well... but we need the ability to add multiple "paths" ,"ports", environtment variables.

Also, another UI out there (more complicated)... with demo: https://github.com/13W/docker-cp

Zitat von ryecoaaron

Does anything need to be executable?  Just making sure a shared folder will work.

I would think that you would use shared folders as a means of mapping to container volumes.

I don't know if it would be such a good idea to use shared folders for actually storing containers.