The above links to a new Wiki page I’ve created that modifies the official openSUSE documentation on the Docker site slightly… The original documentation looks like ti was written by an Ubuntu user…
Recent (last 6 mths) new imagining of Docker has finally fixed numerous problems with plain LXC (as still implemented in YAST). In fact, I’d strongly recommend whoever the decision-makers are to investigate how to deploy Dockerized LXC in YAST replacing what now exists in 13.1. Despite the good stuff YAST did in 13.1 with LXC, the underlying LXC technology was/is too ridden with issues to use for more than just running more instances of openSUSE 13.1.
Now, Dockerized LXC truly turns openSUSE (or any other supported distro) into a proper PaaS, able to support any number of other versions of openSUSE, and other Linux distros on an openSUSE Host.
LXC can now be considered a prime virtualization option for running, testing and developing various OS images and even application-only containers on an openSUSE Host on par with, and without the overhead of paravirtualized technologies like VMware, VBox, KVM and other more used choices.
This page only addresses initial Docker installation and a couple examples, running Ubuntu and openSUSE 12.3 containers.
> In fact, I’d
> strongly recommend whoever the decision-makers are to investigate how to
> deploy Dockerized LXC in YAST replacing what now exists in 13.1. Despite
> the good stuff YAST did in 13.1 with LXC, the underlying LXC technology
> was/is too ridden with issues t
That would be something to put in an openFATE request, or open a bug in
Bugzilla for.
I agree that this is something that should be looked into, though - I
played around with Docker pre-1.0 (it caused a kernel panic for me, but
other than that, it was cool), and this would be a useful thing to have.
People should know that only now Docker is IMO 'ready for Prime Time" and means that using LXC should now be evaluated as a primary option with all the efficiencies it has always had, but now far more “Enterprise” capable as a PaaS.
At the moment,
I’m exploring how far I can “Dockerize” the Elasticsearch demo I presented at SCALE and local UGs (of course running on openSUSE).
Re: bumping Docker “upstairs” for possible integration vie openFATE or the bugzilla,
I think that at the moment there isn’t a major rush since 13.2 is scheduled to be released shortly.
After some additional reading about Docker, it’s a critical issue that Docker no longer implements on top of LXC (as of March 2014) replacing LXC with its own libcontainer technology so it’s not a simple matter of switching around some commands under the YAST GUI (well, it’s not a probability).
So,
I’ll work with Docker for awhile before proposing something… but IMO it’s almost a drop dead simple decision to implement Docker containers instead of LXC containers unless you’re using containers for a very narrow use.
TSU, I appreciate what you’ve done here, but maybe I’m not smart enough to grasp it. All the documentation seems over my head, and I haven’t quite figured out what Docker is for. Is it…
a way to run an unstable app in some kind of sandbox, so you it won’t crash your host if it has problems? For instance, if I want to use an app in KDE, that carries a hefty freight of GNOME dependencies, is docker the best way to do it? If so, how do I “dockerize” an app, just an app (and its dependencies) without a whole virtual OS? And as a practical matter, is it easier to do that, than to reinstall my whole system if an unstable program breaks something?
an alternative to VirtualBox for trying other distros, one that won’t sully the experience with laggy performance? I went through your tutorial and installed ubuntu, but clearly it’s stripped down, so no opportunity to evaluate the Unity desktop. In fact, startx didn’t start anything. So I have proof of concept, but that’s it. And not so much proof as all that, because I couldn’t pull the logs. That is, the command “docker logs ubuntu” reports no such container. If ubuntu isn’t the ID, how do I know what is? And one more thing, now that I’ve downloaded the ubuntu image, how do I get rid of it?
Moderators: This is a question about an application, but it’s specifically in response to the how-to introduced here. If I have violated the intent of this forum, I apologize; please advise if I should re-post elsewhere. TSU, if you can answer, please feel free to do so in a different forum and PM me where to find it; I suspect I’m not alone in needing a little more elementary introduction to docker.
IMO this Q is fine since this is not just “How To” but also FAQ. And until an official Docker SDB is created, this place is prob as good as any to ask the questions you asked.
Docker is the latest way to implement Linux Containers. Linux Containers has been around a long time, but whatever previous implementation, there have been a multitude of problems doing something more than very basic, ie same OS as the HostOS, limited portability, few standards and many ways to configure mountpoints and file systems. Docker is still in its “mature infancy” but already solves many of these problems so even now likely should be the “Linux Containers” implementation of choice and even some like Redshift have announced deprecating LXC and implementing Docker.
So, what is Docker at its most basic? It’s super isolation. It’s far superior in additional features and security yet similar to a chroot. In many ways, it appears to utilize similar security practices as systemd yet enable different things. In fact, I’ve described systemd as “system-space using namespaces and cgroups” while Docker might be thought of as “user-space” using namespaces and cgroups. systemd does stuff managing OS sub-systems while Docker is the ability for the User to do similar stuff as User creations… although there can be some overlap.
Linux Containers also have some basic advantages over more common virtualizations, including
“Instant On.” No boot-up required, when you launch a container, it’s already fully running in a split second.
Bare metal performance. I will be exploring GPU intensive gaming eventually which is hardly possible in virtualization. Since docker is “bare metal” you can docker inside another virtualization, like a Virtualbox Guest without problem or penalty. If you try to create a Guest within another Guest with most virtualization the best you can hope for is dog-slow performance.
Loads exist only when they actually exist (no overhead). Container processes are “just another” proc process like any other in Linux so processes and threads automatically sleep, instantiate, etc like any ordinary process. So now you can “over-provision” to the extreme.
If you’re looking for <practical examples> what Docker can be used for…
Well, it’s still very early so people are exploring right now and there are relatively few examples but here are a few…
You can dockerize an entire OS.
This can be a useful place to start since public pre-built images are widely available. No matter what your HostOS, you can run an entire same or different distro (even versions) without modifying your HostOS. So, in this sense Docker is similar to something like Virtualbox, Only diff is that only Linux kernel is supported (with possible non-Linux Unix kernel down the road). In other words, only Linux today, and never Windows today or in the future.
You can dockerize an app
This has wide implications. You can package up an entire app like an Apache or LAMP solution complete with final configuration and deploy it on any physical machine running any distro (doesn’t have to be the original HostOS distro). As noted above, the instance can be fired up within a split second, adding to a web farm or other cluster and taken down in a split second. This also means that if the app itself is flawed and compromised, any exploit would be limited to what is in the container and can’t touch anything in any other container or the HostOS. (Note this is different than previous LXC which often has shared mount points with the HostOS)
The dockerized app is easily configured to run as a service or manually invoked.
There are only minor configuration changes required to implement either way. No service registration needed. No special commands, just stop and start the container to affect whatever is in the container.
You can maintain different environments easily (eg multiple Python or Ruby versions). No switching, you know exactly what is running in each environment.
An example I’m looking forward to trying is Openstack. I’ve had a miserable time getting the entire thing installed on openSUSE (maybe it might install better on SUSE), the code moves so fast that new code is released before the bugs to deploying on openSUSE can be be worked out. But, now although the official Openstack image is built on Debian, it will enable pretty much a guaranteed successful deployment on openSUSE (OpenStack is big. The official image is over 1G, compressed).
So, the current drawbacks? - Some may be resolved very soon, others are just on the roadmap and all are probably typical of a very major project which was re-imagined and re-launched less than a year ago (as of this writing)
Right now, I don’t see a pre-built Docker image running a Desktop environment. If I can solve my “sshd on opensuse” problem, I’ll probably explore this next. In theory, there should not be a problem.
There are some unresolved issues for running as a specified User. They are working hard on this right now and I noticed some beta level code was just released this past couple weeks. So, for now it’s recommended to use mainly for Server apps where Users don’t actually run locally in the container. Or your personal use.
There is a general unaddressed issue about the enormous amounts of disk storage required if you do more than dabble or run only a few containers. To a certain degree, this is unavoidable, for example to maximize portability you have to include all dependencies. Another situation is that you will want to build custom images with your own configurations and files since the public images are all generic and unconfigured or configured only with defaults. You can be making multiple iterative copies over time, each one a half gig or more. I’ve been arguing for increased attention to creating images of all types on minimal file systems, but so far my voice seems to be alone.
The tools are a bit rough sometimes. In particular, there is not an easily accessible tool to access a container’s console. The official documentation describes ssh into the container but that’s not always possible or practical. There is a really great private “nsenter” project which uses unix sockets instead of network sockets to access which usually works but is not fully automated. There are inconsistent command syntax in places (do you spell out the entire "remove’ or abbreviate? Depends). Networking configuration is Docker’s own unique implementation, but there are hints that configuring virtual networks like other virtualization technologies might be possible but since this is little or not documented, it needs exploring.
Thanks for the reply, tsu2. That really clarifies docker for me; they should hire you to write the front page of their website.
A couple of weeks ago, I installed a graphics app, Wings, and found it fails to run. 3D-modeling is resource-intensive and needs more than a conventional virtual machine can provide. Docker sounds like it could run a known good version of Wings, from a prior version of opensuse or even another distro. How much of the OS would be necessary? How would I go about “dockerizing” Wings, or is the process such that it’s still not ready for an unsophisticated user?
Hi,
IMO a question about specific use like this starts to become less FAQ and more appropriate for IMO the Applications forum (although to some extent might be equally appropriate for the Virtualization forum).
But,
In a nutshell…
I’m going to guess the Wings 3D app likely requires a Desktop environment. Wait a day or two as I figure out the issues required to deploy a DE in Docker.
As for other possible related issues,
Currently only 13.1 is available as a public image. If you require another openSUSE version, it shouldn’t be hard to create a 12.3 version for example (I’d be reluctant to create any images for unsupported openSUSE).
Once a desirable working base image is available, you don’t need to use the Dev tools necessary to create the original image, typically you’d just access the inside of the container where you can do nearly anything you’d do in a normal Docker-less environment, then when you’re satisfied, can snapshot your results by a “docker commit” – else whenever a container is restarted it will always start with its own configuration without personal changes.
So, if Docker use is for a very specific single container, I’d expect only minimal Docker commands should be necessary. Most of the experience would be very ordinary like a normal install and environment.
For that very basic set of commands, am currently compiling and modifying a cheatsheet on my github site. Will do a formal announce as it becomes more ready for prime time.
Docker Cheatsheet
This is a highly verbose list of commonly used commands. This early version is a permanent fork from one of the better cheet sheets from someone else(credit to him on my page), but I’m in the process of highly modifying the text. Still, the base commands are there.
One of many good places to get started if you don’t have any experience with Docker (well, after you’ve installed using my wiki page), this will get considerably better after I’ve modified it further.
Docker Dev Corner
If you’re into or considering building and creating docker images, this will be a collection of little known and useful commands, some for special situations. At some point, every heavy user will need to create their custom versions of generic images. If you have special needs, perhaps the tool you need will be here!
A small FYI
The Docker Cheat Sheet referenced in the above post has been greatly expanded in it’s objective…
It should now also be a good reference to skim quickly for anyone who wonders how the pieces of Docker work, sort of getting the “30,000 foot view” before actually installing and using Docker.
I will be creating a separate FAQ for really basic questions someone might ask in the beginning about Docker.
