Docker vs DBP

[WizardStan]

I technically don't. I can, and have, created x86 docker containers. I specifically want to do it in an ARM Debian environment to compare against the Pandora's current offering.
Although I guess since it's all guestimates anyway I can just bring up a Debian VM.

 

[slaeshjag]

Just creating a new VM and hot-plugging a USB-stick a couple times to see how well it detects packages on hot-plug is about the amount of testing I've been doing anyway.

 

[EvilDragon]

I don't see why, it is almost exactly PND with a few extra features.

Well, the speed would need to be tested.
PNDs, for example, have the preview image and PXML data attached at the end, so that these can be read out fast with scanning, so desktop files can be created within seconds without having to mount the archive.

Is that something that works with docker files as well?

If not, we REALLY need to test how fast it scans hundreds of files off an SD Card.
Can someone test that with the Pandora?
The docker files don't need to be run on there, but at least scanning and getting all the information should work... or how do docker files handle that?
[doublepost=1454284423,1454284308][/doublepost]

If nobody ends up using DBPs, I won't hesitate to kill it off. It has been hard enough to find motivation to finish up what is left anyway.

Well, what IS left to finish and what's working already?

I would not like to scrap anything before we know that a replacement would work for us.
If scanning 400 docker files would take more than 15 seconds, it's already too slow, in my opinion, and we don't know anything about that yet.

 

[slaeshjag]

Some additional handling of dependencies (if a package depends on another, they should be mounted to the same directory) and a package manager are two two main points. The rest of my massive todo-list is just polish I guess.

 

[Wally]

I could experiment with my 200 packages if you want but kinda would rather not waste time

The one thing I really don't like about docker is how they use the people who contribute to OpenSource and have Enterprise customers pay for their service, the other thing is how they may monitor usage of their packaging system (DBP doesn't do this) which a lot of people here don't like. Their ToS says a lot.

 

[WizardStan]

the other thing is how they may monitor usage of their packaging system

Shouldn't be a problem for us, we'll have our own repository.

 

[bzar]

How would you implement command line application support using docker? IIRC DBP automatically creates launchers in PATH so you can run the applications like they were installed.

 

[WizardStan]

Wouldn't have to implement anything, it's all done.
"docker start <container>"

 

[bzar]

Wouldn't have to implement anything, it's all done.
"docker start <container>"

Okay, this is a ridiculous example, but I can't come up with a good one at this time. I think it'll show the issue though.

docker start ls | docker start grep foobar > $(docker start mktemp)

 

[WizardStan]

docker start ls | docker start grep foobar > $(docker start mktemp)

docker run -rm -a ls | docker run -rm -ia grep foobar > $(docker run -rm -a mktemp)
(assuming you have some well defined ls, grep, and mktemp containers)
-i makes it interactive (accepts stdin), -a makes it attached (passes stdout and stderr out), -rm removes the container when it's done, otherwise "docker run ls" would just do an ls inside the container and output goes to log file, headless, exit, but continue to exist in the local docker database, taking up space.
It's kind of a useless example though, and not at all what docker was intended for. It was designed for complete application packages, self contained. So you could do "docker run --name my_webserver -p 80:80 httpd" and it'll download the httpd container (apache) automatically, start it, and forward the container port 80 to external port 80. In the future you can simply go "docker start my_webserver" and it'll start up to shut it down. 5 seconds and I've got a web server up and running that contains all the binaries and libraries that it needs, no need to apt-get anything, don't need to confirm anything about libraries, doesn't even need to be the same flavour of linux to work, as long as it uses kernel 3.8 or up. Similarly with mysql, and many other services, just do a properly configured "run" command and it handles everything. I'm envisioning things like a firefox docker container, or games in a docker container, that sort of thing. If a game ever locks up it's trivial to "docker stop TheGame" and it'll kill everything in the container. Many other benefits.

 

[Askarus]

I really like what I read.
Maybe some (video) demo would be nice.

Is it hard to set it up for a noob with Pandora and Linux experience?
If I'll get some assistance I wouldn't mind setting it up on the devboard and see how it works.
We should still have the working Gamescom SD-Card here. As long as Docker can be installed directly from the ARM Debian Repo I don't see a reason why we shouldn't try it.

For scanning speed.
Can't we make a script what creates 300 Docker containers with "Hello World 1", Hello World 2" etc. and adds some icons?
Then let's see how long it takes.

 

[bzar]

docker run -rm -a ls | docker run -rm -ia grep foobar > $(docker run -rm -a mktemp)
(assuming you have some well defined ls, grep, and mktemp containers)
-i makes it interactive (accepts stdin), -a makes it attached (passes stdout and stderr out), -rm removes the container when it's done, otherwise "docker run ls" would just do an ls inside the container and output goes to log file, headless, exit, but continue to exist in the local docker database, taking up space.
It's kind of a useless example though, and not at all what docker was intended for. It was designed for complete application packages, self contained. So you could do "docker run --name my_webserver -p 80:80 httpd" and it'll download the httpd container (apache) automatically, start it, and forward the container port 80 to external port 80. In the future you can simply go "docker start my_webserver" and it'll start up to shut it down. 5 seconds and I've got a web server up and running that contains all the binaries and libraries that it needs, no need to apt-get anything, don't need to confirm anything about libraries, doesn't even need to be the same flavour of linux to work, as long as it uses kernel 3.8 or up. Similarly with mysql, and many other services, just do a properly configured "run" command and it handles everything. I'm envisioning things like a firefox docker container, or games in a docker container, that sort of thing. If a game ever locks up it's trivial to "docker stop TheGame" and it'll kill everything in the container. Many other benefits.

Yes, it's a ridiculous example, but provides an example of what I meant by support for command line applications. I take it the current shell environment isn't transferred to inside the container? So that ls wouldn't actually list the contents of the current working directory? I can see some of the benefits but there are also quite a few things that may not work as expected because docker isn't designed for this. It's designed for separating the applications from the host system, but especially for CLI applications we specifically want to deal with the environment of execution.

For GUI apps there's also some tinkering required to get the local X to accept stuff from the container, not to mention something like direct framebuffer access.

 

[Plume]

For GUI apps there's also some tinkering required to get the local X to accept stuff from the container

A simple
xhost +
should be enough. There are ways to make it safer, but technically, this should work.

 

[Askarus]

Can I do right click on a file and select "open with..." and choose a program inside a Docker container?
That only works with PNDs when it's done correctly.
Will DBP support that by default?

 

[WizardStan]

So that ls wouldn't actually list the contents of the current working directory?

It doesn't. It can, you can specify the local directory to be mounted (or any directory) but by default it's completely sandboxed.

It's designed for separating the applications from the host system, but especially for CLI applications we specifically want to deal with the environment of execution.

Exactly. If it doesn't completely fit our designs then it's a bad idea, that's why I asked. Do you think packaged command line tools are going to be something we'll want?

Can I do right click on a file and select "open with..." and choose a program inside a Docker container?

That's a good question. I'm not sure. I know you can mount a directory, and then open something in it, but whether it can be done in one step with a right-click? That's something to consider.

 

[Linux-SWAT]

I think the docker way should be investigated.

 

[FBnil]

@WizardStan: Here are examples how to get it rolling on Debian and Centos/Fedora:

https://scottlinux.com/2014/05/04/how-to-install-and-run-docker-on-debian-wheezy/
http://xmodulo.com/docker-containers-centos-fedora.html

I've tested it for a make install and it worked, but I did not know what to do with it, beyond that test case.

There are several videos on youtube about it.
[doublepost=1454381891,1454381738][/doublepost]@slaeshjag: I like DBP too... sorry for liking both...

 

[bzar]

Exactly. If it doesn't completely fit our designs then it's a bad idea, that's why I asked. Do you think packaged command line tools are going to be something we'll want?

Command line applications or optionally graphical applications with a good command line interface, like VLC, are more in line what I'm thinking, not as much tools or utilities. This could probably be alleviated by tooling similar to DBP making execution scripts for application containers.

DBP is nicely getting us closer to using (not just running) portably packaged applications stored on removable media like they were installed on the system. Docker has its ups (containers, dockerfiles) and downs (excessive inode usage, extra configuration and probably performance hit to work with host environment), but it has zero existing support for automatic discovery on removable media, rich metadata or desktop file generation.

Maybe a container based application system would be feasible, but I think it would need to first address the needs of desktop applications and games explicitly. With suitable configuration and workarounds it may well run, say, 95% of the applications well, but break down for that last 5%. For a pyra example, running an OpenGL application reading game control input from evdev and location data from the GPS while maintaining a steady two-way audio over cellular connection utilizing the DSP for decoding it with none-to-neglible performance/latency hit compared to non-container execution would probably be a good starting benchmark. It's made for server applications and as far as I've seen, using it for anything else has been pretty much POC level hacks.

If you can demonstrate my fears baseless, I'll gladly rescind my reservations. Until then I'd be wary of employing an extra layer of separation and complexity for something it was not designed for.

 

[Askarus]

What would be the downside if we would not use docker but DBP?
If there isn't any and DBP does exactly what we need then I don't see a good reason to use Docker.

 

[bzar]

What would be the downside if we would not use docker but DBP?
If there isn't any and DBP does exactly what we need then I don't see a good reason to use Docker.

Well to enumerate the benefits of docker, it does provide a clean way of managing the running applications and easily creating containers that contain the necessary dependencies. Additionally it's already in production use in many server environments, probably a testament to its stability. It also provides an added layer of security by configurably limiting the access each application has to the host system. It has a ready container distribution system and documentation. We'd also benefit from future development and support for it.

DBP on the other hand is more akin to PNDs regarding package creation, hasn't (AFAIK) been used outside development setups and is entirely for us (=people using it) to maintain. We'll also need to roll our own distribution systems and documentation.

There's a case to be made for docker regarding the packaging part, but I suspect the previously voiced downsides for actually running the applications and hassles with host system access more than make up for the benefits gained in that.