Slashdot Mirror

When you run that demo and load up an nginx container, are you confident it's not tainted?

Is there any reason to think that the official NGINX container is any less secure than the official binary that the official container downloads from the official DEB repository?

A slimmed down VM.

https://www.docker.com/resourc...

Atlassian docker images for the missing products others have stepped in and created unofficial images.

MacOS is not used to run Linux on a Mac.

It can be. macOS includes Apple's Hypervisor.framework, atop which tools (such as xhyve) can be used to run Linux inside macOS.

This is how Docker for Mac works; it runs the Linux kernel inside Apple's Hypervisor.framework, allowing you to run Linux containers. If you have XQuartz installed, with a bit of fiddling you can run Linux GUI apps inside Docker containers on the macOS desktop.

Yaz

I wonder if I can run Linux inside Windows using parallels?

MacOS is not used to run Linux on a Mac.

It can be. macOS includes Apple's Hypervisor.framework, atop which tools (such as xhyve) can be used to run Linux inside macOS.

This is how Docker for Mac works; it runs the Linux kernel inside Apple's Hypervisor.framework, allowing you to run Linux containers. If you have XQuartz installed, with a bit of fiddling you can run Linux GUI apps inside Docker containers on the macOS desktop.

Yaz

This is not even a question anymore. Millions of applications around the world today run on platforms they were never written for because of docker and the containerization technology. It has turned the development model on its head, spawned devops and it run by most of the top 500 companies in the world today. Go and have a long look at https://hub.docker.com/ and pick your application. The beauty of this technology is not only does it not care what platform you run an application on, their are literally millions of docker images available for you to choose from so you don't have to build them yourself. You get to stand on the shoulders of giants and get to work immediately. Example Case: This user installs Docker on his home NAS. Now can run ANY application listed on docker hub.

Some of your questions make more sense than others. In the context of deploying, docker looks a lot like a VM deployment - except instead of having to build up a VM using chef, and with all the luggage that usually entails, the docker image tends to only be running the service. Imagine a linux kernel with only one process running. So there aren't a lot of edges to harden. Usually the service image gets launched in something that looks like a DMZ behind a firewall with a loadbalancer in front of it.. In our case it's a little wild west.

But part of the joy/ease of docker is that you build on some particular image. It would be easy to imagine an organization that was more .. organized than ours specifying a few base image flavors that developers would have to build off of - then you could harden those images all you wanted. I don't know that I would be a big fan of that, however. You can see where redhat supplies a lot of images, for example (https://access.redhat.com/search/#/container-images).

Concrete (semi bogus) example: you want to run redis (maybe on windows - where it's not trivial). There is a redis docker image: https://hub.docker.com/_/redis...
"docker run -p 6379:6379 redis"
That will fire up a docker container running redis and will map the port on the image to the port on the docker host (usually localhost, these days). You can now connect to port 6379 and talk to redis. The container running redis is hard to describe - it's a full (stripped) linux system and it's only running that one process. You can fire up a shell on that container using another docker command and it has a bunch of the things you expect. Some shell (maybe bash or something lighter). Most of the filesystem stuff you expect. It's like a VM - if you built a VM to only run redis.

I don't know if any of this helps - it really is a weird concept - at least I had a really hard time wrapping my head around it. But I do love what I can do with it.

The Docker Registry deployment instructions specifically walk you through restricting access using basic auth. Did someone not read the instructions, or did they try to get fancy and screw something up?

Now where have I heard this before

So is the summary. Only 4 of the 38 are social media analysis firms. Docker, for example, is a software container (sort of virtual machine) company.

wget -O- https://example.org/install.sh | sh

is a very common installation method presented by various tools (or via curl). In most cases you even need to run them as root due to the fact that the creators of those tools do not understand how to have their software work as non-root users.

For example:
https://toolbelt.heroku.com/de...
https://docs.docker.com/linux/...
https://nodejs.org/en/download...

But he should have compared github and docker.

She didn't have to, because that's incorrect. Github is to git as Dockerhub is to docker. Wouldn't it be nice if you haters decided to actually look at how the thing works before you spew such incredibly inaccurate information about it? Sheesh.

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

It's actually kind of an inversion.

Docker base images for Debian, CentOS, and Ubuntu are typically 50-100 megabytes. Shrinking down that "base image" doesn't really make sense; Iron.io instead shrunk down images for things like PHP, Node, and Ruby.

Even then, you have two main issues.

Firstly, if you have something stupid like e.g. PHP not coming with ANYTHING installed (no php-pdo, no php-ldap, etc.), you have to write your own Dockerfile to install PHP. Typically, you can just put "image: php/5.6-fpm" in your docker-compose.yml and mount your application as a volume, and it'll work; if you need additional php modules, you have to make docker-compose build a Dockerfile opening with "FROM php/5.6-fpm", running a bunch of install commands to compile and build stuff.

Second, that causes bloat.

Docker reuses base images. PHP comes from debian/jessie, so you download the 60MB debian/jessie image and then an additional 150MB php image which doesn't include any of the stuff in Debian/jessie, and you get 210MB of space usage. The same goes with Java: it mounts its 100MB image on top debian/jessie. Install php (210MB) and Java (160MB) and you're only using 310MB, instead of 360MB.

So now you have 11 PHP applications installed. Each uses a 30MB base image instead of a 150MB base image, so installing iron/php only requires 90MB of space instead of 210MB. Each of your 11 PHP applications needs a different set of PHP extensions, which each need a set of base libraries.

In the most optimal case, you install all of the PHP extensions and use the resulting image, which gets you back to where you started with that hulking 150MB PHP image. 11 separate applications all use the same image, no duplication.

In the less-optimal case, every one of your PHP applications installs all the compiler toolchain and *-dev packages to build the PHP extensions that image needs, then removes the toolchain and *-dev packages in the same RUN line so they don't get stored in any Docker image along the way. Every different combination of tools (or, really, any application not built with *exactly* the same commands in RUN, right down to the white space) creates a new Docker image containing all of the necessary libraries and other files.

Installed php-ldap and php-mysql in one container? That container contains libldap, libmysql, php-ldap, php-mysql, and all other required files. Installed php-ldap and php-postgresql in another container? That container contains A DIFFERENT COPY of the same libldap and php-ldap files, plus php-postgresql and all the required libraries to back it. Etc. etc.

You get to say, "Ah, my images are all tiny! ... why do they take up so much disk space in total?"

It's actually kind of an inversion.

Docker base images for Debian, CentOS, and Ubuntu are typically 50-100 megabytes. Shrinking down that "base image" doesn't really make sense; Iron.io instead shrunk down images for things like PHP, Node, and Ruby.

Even then, you have two main issues.

Firstly, if you have something stupid like e.g. PHP not coming with ANYTHING installed (no php-pdo, no php-ldap, etc.), you have to write your own Dockerfile to install PHP. Typically, you can just put "image: php/5.6-fpm" in your docker-compose.yml and mount your application as a volume, and it'll work; if you need additional php modules, you have to make docker-compose build a Dockerfile opening with "FROM php/5.6-fpm", running a bunch of install commands to compile and build stuff.

Second, that causes bloat.

Docker reuses base images. PHP comes from debian/jessie, so you download the 60MB debian/jessie image and then an additional 150MB php image which doesn't include any of the stuff in Debian/jessie, and you get 210MB of space usage. The same goes with Java: it mounts its 100MB image on top debian/jessie. Install php (210MB) and Java (160MB) and you're only using 310MB, instead of 360MB.

So now you have 11 PHP applications installed. Each uses a 30MB base image instead of a 150MB base image, so installing iron/php only requires 90MB of space instead of 210MB. Each of your 11 PHP applications needs a different set of PHP extensions, which each need a set of base libraries.

In the most optimal case, you install all of the PHP extensions and use the resulting image, which gets you back to where you started with that hulking 150MB PHP image. 11 separate applications all use the same image, no duplication.

In the less-optimal case, every one of your PHP applications installs all the compiler toolchain and *-dev packages to build the PHP extensions that image needs, then removes the toolchain and *-dev packages in the same RUN line so they don't get stored in any Docker image along the way. Every different combination of tools (or, really, any application not built with *exactly* the same commands in RUN, right down to the white space) creates a new Docker image containing all of the necessary libraries and other files.

Installed php-ldap and php-mysql in one container? That container contains libldap, libmysql, php-ldap, php-mysql, and all other required files. Installed php-ldap and php-postgresql in another container? That container contains A DIFFERENT COPY of the same libldap and php-ldap files, plus php-postgresql and all the required libraries to back it. Etc. etc.

You get to say, "Ah, my images are all tiny! ... why do they take up so much disk space in total?"

It's actually kind of an inversion.

Docker base images for Debian, CentOS, and Ubuntu are typically 50-100 megabytes. Shrinking down that "base image" doesn't really make sense; Iron.io instead shrunk down images for things like PHP, Node, and Ruby.

Even then, you have two main issues.

Firstly, if you have something stupid like e.g. PHP not coming with ANYTHING installed (no php-pdo, no php-ldap, etc.), you have to write your own Dockerfile to install PHP. Typically, you can just put "image: php/5.6-fpm" in your docker-compose.yml and mount your application as a volume, and it'll work; if you need additional php modules, you have to make docker-compose build a Dockerfile opening with "FROM php/5.6-fpm", running a bunch of install commands to compile and build stuff.

Second, that causes bloat.

Docker reuses base images. PHP comes from debian/jessie, so you download the 60MB debian/jessie image and then an additional 150MB php image which doesn't include any of the stuff in Debian/jessie, and you get 210MB of space usage. The same goes with Java: it mounts its 100MB image on top debian/jessie. Install php (210MB) and Java (160MB) and you're only using 310MB, instead of 360MB.

So now you have 11 PHP applications installed. Each uses a 30MB base image instead of a 150MB base image, so installing iron/php only requires 90MB of space instead of 210MB. Each of your 11 PHP applications needs a different set of PHP extensions, which each need a set of base libraries.

In the most optimal case, you install all of the PHP extensions and use the resulting image, which gets you back to where you started with that hulking 150MB PHP image. 11 separate applications all use the same image, no duplication.

In the less-optimal case, every one of your PHP applications installs all the compiler toolchain and *-dev packages to build the PHP extensions that image needs, then removes the toolchain and *-dev packages in the same RUN line so they don't get stored in any Docker image along the way. Every different combination of tools (or, really, any application not built with *exactly* the same commands in RUN, right down to the white space) creates a new Docker image containing all of the necessary libraries and other files.

Installed php-ldap and php-mysql in one container? That container contains libldap, libmysql, php-ldap, php-mysql, and all other required files. Installed php-ldap and php-postgresql in another container? That container contains A DIFFERENT COPY of the same libldap and php-ldap files, plus php-postgresql and all the required libraries to back it. Etc. etc.

You get to say, "Ah, my images are all tiny! ... why do they take up so much disk space in total?"

can you also iocage history? docker is to infrastructure what git is to code.

Are you on drugs?

From the Docker website:"Because the Docker daemon uses Linux-specific kernel features, you can’t run Docker natively in Windows. Instead, you must use docker-machine to create and attach to a Docker VM on your machine. This VM hosts Docker for you on your Windows system."

I recommend git. It's fast, it's easy, it's decentralized so code cowboy can't burn your project. And there are gui's for it for windows as well: https://git-scm.com/download/g...

Since IT has set the policy to a Windows operating system only server, you've had your hands tied as to what technology you can use. Fortunately for you, you can run Docker on Windows: https://docs.docker.com/instal..., which means you'll have access to tens of thousands docker containers for various purposes such as gitlab: https://github.com/sameersbn/d...

For basic test on the code (Syntax errors, pytest/nose/or alike with coverage (of tests), check coding style) it sounds like what you're looking for might be jenkins: https://en.wikipedia.org/wiki/... and you can create a docker container for running jenkins on your server: https://github.com/jenkinsci/d... or https://wiki.jenkins-ci.org/di...

bridging capability is built in, and if used with a managed switch...
https://docs.docker.com/articl...

this is actually a good question - but rather than choose your desktop distro based on this, choose a Docker machine that will behave the same no matter where you go.

for example, this is a docker machine to be used with Ruby on Rails.

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications.

My understanding is that ARM-based microservers are attractive for low-compute workloads. For example, a half-rack with 1600 microservers in it would do a great job of coping with the Slashdot effect (it could spin up a whole bunch of web servers).

You are right that if you are scaling out major number crunching jobs, fast Xeon boxes will work out to be more efficient. But those Xeon boxes would be wasted just serving up web pages.

HP has released figures claiming that 1,600 of its Project Moonshot Calxeda EnergyCore microservers, built around ARM-based SoCs, packed into just half a server rack were able to carry out a light scale-out application workload that took 10 racks of 1U servers -- reducing cabling, switching, and peripheral device complexity. The result, according to HP, was that carrying out the workload used 89 percent less energy and cost 63 percent less.

http://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-microservers/

I think Docker and microservers will turn out to be a great combination. Lightweight Docker containers should run great on the microservers.
IMHO the ARM competitors to Xeon are principally interesting to show that you won't be "painting yourself into a corner" if you adopt the ARM platform: it still has plenty of room to improve.

What you might want is a Windows VM (or more than one) inside your Windows that you use for Internet downloads.

At the moment I just run separate VMs, but it's a bit heavyweight.

Remember Docker isn't secure. Process that want to escape can escape.

Hmm, that seems counter to the Docker security model - the processes are not supposed to be able to get out of their container ... or so it claims. How do Docker processes escape?

Docker is sort of an extremely lightweight virtual machines system.

Docker organizes software into "containers". Each container has a complete set of libraries and files, and each container is isolated from the rest of the system. Thus if you need a specific and touchy set of libraries to run Software X, and you need a different specific and touchy set of libraries to run Software Y, you can simply make two containers and run them side by side.

As I understand it, Docker container images use a "snapshots" system to store changes; so the two containers for Software X and Software Y will together be much smaller than two VM images would be.

Using Docker, if developers make a server-side application, they can then hand a container over to production for deployment, and everyone can be confident that the application will run the same in production as it ran in development. (Of course it would still be possible to break things, for example by having different data in the production database compared to the dev test database.) Or, developers could run containers on their laptops and expect them to run the same as on the servers in the office.

Unlike VMs, the Docker containers don't run their own kernels. So you can't run a Linux server with Docker that in turn runs OpenBSD in a container.

As I understand it, many people use Docker to run a single process per container. The web server in one container, the email server in another, the SSH server in another, etc. One use case: if you have a web site hosted in the cloud, and the Slashdot effect starts slamming on the web site, the cloud hosting service could spin up another 500 instances of the web site (500 fresh instances of the Docker container, each container running a single process, the web server).

I talked to an expert sysadmin, and he told me "This is the future." I'm going to set up a Docker server at home and learn my way around it.

https://www.docker.com/whatisdocker/

My reading of the press release is that Microsoft is going to (a) implement the Docker APIs for Windows, so that Windows server applications can be container-ized; and (b) add the ability to run Linux containers. The latter is not implausible; Windows NT has always had so-called "personalities" and Posix has been available as a personality for decades.

http://en.wikipedia.org/wiki/Hybrid_kernel#NT_kernel

Docker heavily relies on linux kernel features

...which you can make available to Docker on Windows as per the instructions here, and which in any case probably won't be the situation now that they've partnered with Microsoft...

and on a stable base OS

How does Docker "rely [...] on a stable base OS" any more than any other piece of software (several million of which run perfectly well on Windows)?

"Hi everyone, look at me. I'm so terribly bored by things I don't use that I have to come tell you how they're useless to me on Slashdot." Let me guess - you're a second-rate sysadmin at third-rate company, who thinks that his 12-node web server farm is just about the most complex thing in the world?

Maybe the features of Docker aren't for you... but their own FAQ outlines quite a few things that Docker adds on top of the base LXC functionality:

What does Docker add to just plain LXC?
Docker is not a replacement for LXC. "LXC" refers to capabilities of the Linux kernel (specifically namespaces and control groups) which allow sandboxing processes from one another, and controlling their resource allocations. On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:

Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any Docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. LXC implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom LXC configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same Docker container can run - unchanged - on many different machines, with many different configurations.

Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less RAM. We think there's more to containers than just that.

Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, Debian packages, RPMs, source tarballs, or any combination of the above, regardless of the configuration of the machines.

Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to git pull, so new versions of a container can be transferred by only sending diffs.

Component re-use. Any container can be used as a "base image" to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal Python environment, and use it as a base for 10 different applications. Your ideal Postgresql setup can be re-used for all your future projects. And so on.

Sharing. Docker has access to a public registry where thousands of people have uploaded useful containers: anything from Redis, CouchDB, Postgres to IRC bouncers to Rails app servers to Hadoop to base images for various Linux distros. The registry also includes an official "standard library" of useful containers maintained by the Docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.

Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. Ther

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.

I think of it as something like a version controlled Make or Grunt script with the output being a jail. Setting up your cloud stack as a series of Docker containers makes it much easier to create, upgrade, scale and relocate your services such as web servers, databases, caches, app servers etc.

What is Docker?
Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications.

How is this different from Virtual Machines?
Virtual Machines
Each virtualized application includes not only the application - which may be only 10s of MB - and the necessary binaries and libraries, but also an entire guest operating system - which may weigh 10s of GB.
Docker
The Docker Engine container comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.

https://www.docker.com/whatisdocker/