
WTF is a container? - kawera
https://techcrunch.com/2016/10/16/wtf-is-a-container/
======
Azeralthefallen
I remember going to AWS Reinvent last year and having some beers with a bunch
of people who did devops. We started talking about tools, and they were
utterly flabbergasted, that we had not embraced docker. They went on an on
about how simple docker made HA, and handling fail overs/maintenance. More or
less made it seem like it was the greatest thing since sliced bread.

Me and a few coworkers decided to try and dockerize some of our serivces, and
move our staging ES cluster to docker.

For the most part building our own containers was easy enough, for the various
services. The biggest issue we had was with Elasticsearch, since we have 4
types of nodes. So we ended up building 4 specialized containers for each node
type.

Then came the issues:

* Making containers work together, for example we use a logging agent, we decided to make that its own container. Then actually getting a way to share a log directory with the agent, was very painful and unclear. (Honestly the single most frustrating thing i recall was asking for advice in irc and more or less being told i am doing it wrong)

* Containers would randomly crash under load exiting with error 137 out of memory. Apparently a few of our services would randomly leak memory, but only when running inside a docker container vs ubuntu 14.04. (I never figured this out)

* Containers would randomly become unreachable, forcing me to kill them and restart them.

* Random hanging issues, suddenly docker exec is hanging. Being told to revert to an older version, or install a newer version is tiring and makes my environment very inconsistent.

* Trying to debug why our app in the container isn't working is not fun at all.

However the single part that killed me was, i was chatting with one of the
people who i met at Reinvent, and i mentioned my issues. He acted like it was
completely normal for these kinds of issues.

After a solid 2 weeks of random issues and the constant barrage of pagerduty
alerts, i just rolled everything back to static EC2 instances for staging, and
have ran into 0 issues. I want to try containers again because i want them to
work, but i have just had too many issues.

~~~
ksec
flabbergasted? Wow this is a new word for me, I have never heard of it. When i
first read it in my mind I thought it was a Spanish Football player that used
to play for Arsenal, Then Barcelona, and now Chelsea. LoL

Is this word even used anywhere else beyond US? Never heard it used in the UK.

~~~
Jefro118
I'm from the UK and I hear "flabbergasted" reasonably often, more often from
upper-middle class folks. Maybe a regional thing?

~~~
philk10
more of an age thing? I use it but I doubt my daughter ever does

------
dancek
I agree that containers (both for shipping and servers) are a great idea. And
because I'm tired of always configuring servers, I decided to give it a try
some time ago.

I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh,
not a container though, because I also needed https, which meant I needed
either a mechanism to build and update letsencrypt certs in the weird format
that weechat expects, or to run an nginx instance in the front (and also
somehow get the certs, but that's easier with nginx). So two containers.

And even though there was a ready-made nginx+letsencrypt https reverse proxy
container (actually several), I had a huge amount of headaches to get it
actually working. Even with the system set up, I occasionally have the
container crash with exit status 137 (IIRC), which I've assumed might be
because weechat leaks/consumes memory and eventually the host server kernel
kills the process. Maybe.

So in my limited experience, comparing Docker containers to shipping
containers is a gross simplification. Shipping containers are simple
constructions requiring well-defined simple maintenance, while Docker
containers seem to be complex thingamabobs that have multiple points of
failure.

~~~
nvarsj
Docker is a poorly engineered and over-hyped technology.

The concept is great - and in fact, many companies have built great tooling
around Linux cgroups. It lets you efficiently binpack applications on a single
server - which is why 'containers' were created in the first place.

The side benefit of letting you define your OS libraries, and other things, is
a nice bonus, and way overblown in my opinion.

Docker and its tooling is just plain bad. It's so bloody unstable, unless you
pick some esoteric combination of versions and storage backends (old docker +
old aufs + old ubuntu seems to do the trick) - and even then, you'll run into
problems. Documentation won't help you here - it's trial and error.

The docker group seems focused on feature, feature, feature, while the basic
stability and performance remains poor. It's quite amazing how they get it so
wrong. Browse through the github issues for performance and hanging issues.
The surrounding tooling is poor as well - registry v2 doesn't even support
deletes (because they need to maintain compatibility with the 100000 different
storage backends for it). There is no LTS release, bug fixes only happen in
latest version, so you're in a constant state of brokenness. And so on.

~~~
ChoHag
The concept is great but it's also not original. It's called "processes".
Docker is little more than a mass of complication laid atop fork+exec.

That's why nobody can get it right - because we already did.

~~~
jjnoakes
How is "your own network, your own view of the file system, your own view of
the process table, your own view of the user IDs, ..." the same as
"processes"?

~~~
elsonrodriguez
On modern Linux distros every process is running in a cgroup and namespace by
default. So these days the main difference between a "container" and a regular
process is that regular processes are all jumbled together in the same root
namespace, and containers are in separate namespaces.

~~~
jjnoakes
Which Linux distributions do this? I'd like to read how "most" instances of
fork and exec end up with unique networks and file system namespaces.

~~~
elsonrodriguez
I didn't say unique, I said "jumbled together".

Now as far as which distros put processes in a namespace and cgroup by
default, I know at least CentOS 7 and Ubuntu 15 do this. And those two distros
on their own would qualify for "most".

To check if your distro does it, one way of checking is just doing a `cat
/proc/1/cgroup`. This will show you what cgroups process 1 is in. By default
you will be in the "root" cgroup.

To check your namespaces, `ls -l /proc/1/ns/`. You'll see the process is in
some randomly generated namespace ID per item.

I'm sure you could recompile your kernel to disable this behavior, but the
default reality of modern Linux is that everything is already running in a
"container".

Now the question is whether or not people want to take advantage of that
reality, and separate out processes in isolation, or keep running everything
on a system in such a way that any single process can impact the whole system.

------
Hondor
I never quite understood containers and this article makes them seem kind of
similar to what OSs already do.

How is a container different from just installing all the dependencies along
with an application? Coming from a Windows background, this is pretty common
to avoid DLL hell. Nobody distributes a Windows application that requires the
user to go and install some 3rd party library before it'll work.

Isolation from each other seemed like one advantage, but that's not even
security strength isolation so you can't count on it to protect the host OS
from malware in a container.

A claim I often see, and that's repeated here, is that containers can run
anywhere. But can they really run in any more places than an ordinary
application with dependencies included, or even statically compiled into it?
You still need Linux and the same CPU architecture, right?

~~~
vidarh
> How is a container different from just installing all the dependencies along
> with an application?

Once the image is built, you can get another installation that is guaranteed
to be identical. You can do that with VM images too, but you can not
reasonably do that if you try to install multiple applications side by side in
a single VM without further isolation - there are too many ways they can
interact.

> Isolation from each other seemed like one advantage, but that's not even
> security strength isolation so you can't count on it to protect the host OS
> from malware in a container.

That's only true to the extent that they don't have a long enough track
record. Many container technologies do have a decent track record when it
comes to security.

But even so there are plenty of reasons for isolation in cases where the
security requirements are not the primary reason for further isolation. E.g.
making it impossible for an app to accidentally reading/writing files it
shouldn't is in itself helpful.

> A claim I often see, and that's repeated here, is that containers can run
> anywhere. But can they really run in any more places than an ordinary
> application with dependencies included, or even statically compiled into it?
> You still need Linux and the same CPU architecture, right?

Try to get an application - statically compiled or not - to run across
different Linux distributions, and you will see why this matters.

Needing Linux and the same CPU architecture isn't much of a limiting factor on
servers. Being able to not having to account for distribution peculiarities or
version differences is a big deal.

~~~
paulddraper
> Try to get an application - statically compiled or not - to run across
> different Linux distributions, and you will see why this matters.

Done. A statically compiled application has no other dependencies.

~~~
vidarh
Does it never do DNS lookups? Open files? Do you not want to tie into process
management? Logging? Do you really have no dependencies on a functioning
locale? Network settings? Are you sure it won't try to exec anything?

An application with no other dependencies is exceedingly rare. Small tools,
sure. Sometimes. But even then I see people making silly assumptions all the
time, which makes using a container as a suitable straightjacket very useful.

E.g. I run all kinds of tools "with no other dependencies" all the time, that
turns out to have all kinds of dependencies when you actually try to put it in
the smallest container possible.

~~~
paulddraper
> Does it never do DNS lookups?

Yes, it does.

> Open files?

Yes, it does.

> Do you not want to tie into process management?

I don't know what this means.

> Logging?

Yes.

> Do you really have no dependencies on a functioning locale?

What makes a locale "function"?

\---

Remember that the my standard C lib or whatever can be statically linked as
well. At that point, I'm left with syscalls.

Docker containers depend on syscalls too; it's not like they ship with their
own kernel. (If they did, they'd be VMs.)

------
disposablezero
Weak virtualization often lacking security, resource
metering/prioritizing/quotas. Hurray, zombie Docker instances needs a whole VM
reboot yet again, still not fixed in several years. But look how fast I can
deploy millions of containers without SELinux, monitoring, HIDS, SDN, billing,
live migration, backup/restore/DR/data lifecycling and all the other things we
just pretend to ignore when throwing away sensible production VMs on Type 1
hypervisors devopsec.

~~~
hvidgaard
The smart use of containers is using it to specify the deployment. You should
use proper virtualization as the environment to deploy into. Because you use
containers doesn't mean you throw all that away.

------
BjoernKW
Containers are often touted is this novel concept that's bound to
revolutionise software development and software delivery in particular.

The general idea isn't all that new however. Java Applications have been
delivered as containers since 1995 (although the concept isn't explicitly
named that way with Java applications).

Each JAR / WAR is a self-contained application that can run anywhere where
there's a JVM (which is pretty much everywhere).

From a feature perspective the only real innovation of Docker-style containers
probably is that those aren't limited to the JVM but are (largely) language-
and runtime-agnostic.

~~~
geodel
> Each JAR / WAR is a self-contained application that can run anywhere where
> there's a JVM (which is pretty much everywhere).

Jar could be self contained or it could depend on 100s of other jars so it is
not as straightforward as one assume.

War required a Java application containers to be deployed which is outside a
War not inside. Also J2EE deployments can get pretty complicated with its
infamous XML usage for configuring anything.

JVM is not everywhere by default or work without config by default for non
trivial application. It is complex software which can lead to myriad
classpath/ version issues related to jar files if not installed very
carefully.

~~~
dismantlethesun
Containers are like that as well. You can have a container for your
application, that doesn't really do anything unless you can connect to your
database which runs in another container.

------
sytelus
These hand-wavy explanations that constantly avoids explaining how things work
at low level are not adequate.

Here's short explanation for developers even with moderate understanding of
how OSes work:

[http://stackoverflow.com/questions/16047306/how-is-docker-
di...](http://stackoverflow.com/questions/16047306/how-is-docker-different-
from-a-normal-virtual-machine/34757096#34757096)

------
jdoliner
This is a pretty good analogy for containers but there's an unfortunate
conflation of terms. There's actually a distinction with computing containers
between the thing that you ship code around as and the thing that you run code
in. The latter is the real container while the prior is called a "container
image" or often simply an "image." This gets confusing quick if you apply this
analogy since you assume that the thing you ship the code as would naturally
be called the container.

------
gtrubetskoy
It's amazing how slow the development community en masse has been in
"discovering" containers. I remember I worked for web hosting company that
offered containers as a web hosting solution back in 1999, I then ran my own
little host offering FreeBSD jails and then Linux containers (based on the
excellent Linux-VServer project) in 2003, and I do remember how when I tried
to explain to (pretty technical) people how this is way more efficient than
stuff like Xen they'd go "but it's a hypervisor..." (as if that meant
"magic"). I eventually gave up on it and sold my little hosting operation
because it was too much work and not enough money, it looks like it was about
10 years ahead of it's time.

~~~
sdsk8
I think the same, i've been deploying containers or things that look like
today's containers for the past 12 years, i even did a tool that manages
containers with lxc that really look like docker, but 3 years before.

~~~
cesnja
There were many solutions very similar to Docker, but you have to agree that
they made some essential things the right way - UnionFS (e.g. OverlayFS),
standardized way of building containers (Dockerfiles) and the right timing.

------
fenomas
I'm only a beginner, but the analogy that makes sense to me is that containers
do for app deployment what npm does for Javascript development. That is, the
magical part isn't that Docker simulates an operating system and so on - the
magic is that it allows a chunk of logic to precisely declare its dependencies
- including on other pieces of logic which declare their own dependencies -
and then Docker knows how to (in theory anyway) run the logic in such a way
that its dependencies are all satisfied.

And of course the meta-magic is then that there's a public registry of (in
theory) solved problems, which one can build on top of by declaring
dependencies against them.

I have a pet theory that this "declared dependencies + dependency wrangler +
public registry" is a general formula which will keep cropping up as we find
new places to apply it.

~~~
kpil
Not really - Linux package management systems do exactly that.

The magic - if there is any - is to combine it all together; separation,
discovery, relatively easy packaging and dependencies.

~~~
fenomas
Sure, at a different level. Package managers at the app level, docker at the
deployment level, npm at the development level, or something vaguely along
those lines.

I wasn't suggesting this was unique to Docker - precisely the opposite, that
it's a generally useful pattern, being applied here to deployment.

------
parito
for the love of god - forget docker, use lxc containers - its simple, secure,
goes with its own init, cron, and you dont need to do somersaults to achieve
simple tasks. Included with linux kernel. Your own isolated linux system. We
use lxc in production for over three years, and we have over 3000 of them. No
issues whatsoever.

~~~
choxi
You're right that LXC containers have a similar API compared to Docker, but I
think developers often underestimate the benefit of the community around a
certain technology.

Docker has significantly better documentation, extensions, package management
tools, and third-party integrations. Overall, Docker has an incredibly more
robust community than LXC or closer competitors like Kubernetes, and those
features are just as important as the API for developers.

~~~
parito
The point of the LXC is, you get a full blown standalone linux, rather than a
single process - this simplifies everything a lot, meaning you don't have to
have that much documentation about it in the first place.

~~~
majewsky
Can you clarify what "full-blown standalone Linux" means? It sounds like
running a separate kernel, but since we're talking containers rather than VMs,
this can't be it.

~~~
Kubuxu
It is shared kernel, separate userspace.

It uses: X-namespaces (network, pid, user, ...) and cgroups to separate those
userspaces from each other.

I have community server running debian in which there are 10+ LXC containers
running in which people are given normal root access, one container per user.

~~~
majewsky
So it's the same as with Docker.

------
lottin
I guess I'll never get it. Don't most OSs already run processes isolated from
each other, have advanced process scheduling mechanisms and manage access to
hardware resources? Also with static linking nothing stops you from creating
huge binaries that "will run anywhere".

~~~
austinjp
From my perspective, where I'm planning a hosting service with multiple
customers, containers promise to allow me to slice machines into dedicated
chunks. VMs could do this too, but they'd consume far more disk-space, which
would mean my hosting costs would be comparatively higher.

Containers promise to allow me to limit the resources each of my customers can
consume without killing the entire box. For example, I can limit RAM, CPU and
disk-space per customer. If one customer goes rogue, the shared box remains
performant for my other customers. Also there's the data protection: in theory
customers would not be able to access each others' data, even if they tried
to.

There are other considerations as others here have pointed out. This is just
my primary concern at the moment.

~~~
greedo
All of your requirements can be satisfied with properly configured VMs.

~~~
austinjp
Including total disk space consumed on the host? I can't see how. Containers
are by definition far lighter.

~~~
greedo
It depends on what you build into your containers. Your customers will need
storage at some point, unless they're just using the containers as processing
engines. You'd also be surprised at how lean you can built a VM with Linux (or
one of the BSDs) as the OS.

------
sztwiorok
Docker is the best thing since sliced bread! VM is much more resource and time
consuming.

# We switched our dev/stage env to containers 2 year ago.

# We have made our own standalone app in Docker style. Once again - Easy as
pie.

if you are a developer you should add Docker + Docker Compose to you working
tools.

~~~
cZuLi
We moved over to Docker at the development process some time ago and it really
speed up our work.

------
novaleaf
> The way virtual machines work, however, is by packaging the operating system
> and code together. The operating systems on the virtual machines believes
> that it has a server to its own, but in reality, it’s sharing the server
> with a bunch of other virtual machines — all of which run their own
> operating systems and don’t know of each other. Underneath it all is the
> host operating system that makes all of these guests believe they are the
> most important thing in the world. You can see why this is a problem. The
> guest virtual machines basically run on emulated servers, and that creates a
> lot of overhead and slows things down (but in return, you could run lots of
> different operating systems on the same server, too).

Wait a second. Isn't this the whole point of hardware virtualization support?
So that hypervisors don't have all those VM overhead slowing things down?

------
AJRF
On VM's: "Underneath it all is the host operating system that makes all of
these guests believe they are the most important thing in the world. You can
see why this is a problem."

Two paragraphs later (On containers):

"The only operating system on the server is that one host operating system and
the containers talk directly to it."

------
chewxy
This is not quite related to Docker/Kubernetes, but a phrase in the article
triggered memories about a very good book that I think everyone should read -
The Box by Marc Levinson. It really is a fascinating book.

~~~
haalcion3
Definitely "not quite", as it is about shipping containers, but an interesting
read.

------
ilaksh
The reason people don't get the advantage of Docker is because there is a
weird (and in my opinion stupid) tabboo against putting all of your deps in
one container. This is about 10-100X easier than trying to compose a bunch of
containers.

Not everyone can do that, but plenty of people could. Except they don't not
because of some actual ops requirement (in many cases) but because they don't
want someone to say they did it wrong.

I am assuming this situation has actually changed now I hope and swarm/compose
or whatever is built in is not too hard to use?

~~~
ohdrat
no it's worse now. There's also all the PKI required compounding the pain and
suffering.

Phusion baseimage-docker seems to help.

Worth nothing Atlassian stepped back and does scaleout approach using regular
cloud instead of container orchestration technology.
[https://www.atlassian.com/company/events/summit/2016/watch-s...](https://www.atlassian.com/company/events/summit/2016/watch-
sessions/build-deploy/scaling-your-first-1000-containers-with-docker)

Also worth noting you can take away all the PKI and registry pain and have
instant scaling with the registry by using cloud store for registry and having
Jenkins gatekeeper be the only writer, all dev and production nodes use the
same store only readonly.

------
dkarapetyan
> The promise behind software containers is essentially the same. Instead of
> shipping around a full operating system and your software (and maybe the
> software that your software depends on), you simply pack your code and its
> dependencies into a container that can then run anywhere — and because they
> are usually pretty small, you can pack lots of containers onto a single
> computer.

Already got it wrong. Current containers are exactly the OS and the kitchen
sink for running 'printf("hello world")'.

~~~
chewchew
It's up to you to make your containers bloated or keep them slim. You can use
the alpine versions of the official Dockerhub images. Python on Alpine is 30
MB (vs 267 MB for the debian one).
[https://hub.docker.com/r/library/python/tags/](https://hub.docker.com/r/library/python/tags/)

You can create containers that are just a few MB with compiled languages like
Go (5 MB). [https://www.iron.io/microcontainers-tiny-portable-
containers...](https://www.iron.io/microcontainers-tiny-portable-containers/)

From the article: "Rather than starting with everything but the kitchen sink,
start with the bare minimum and add dependencies on an as needed basis."

~~~
stephenr
If your app is a compiled go binary (so, it runs anywhere) why do you _need_ a
container?

The whole point of containerisation is to group installed dependencies (as
opposed to _installable_ dependencies like with a regular deb or rpm package)
and configuration into a 'black box'.

If your binary is already a single-file distribution, why lump it in with the
crapfest that is docker?

~~~
lowbloodsugar
If "you" here is one person and "your app" is one app, then yes, why do you
need a container. If "you" is 200 developers, and "your app" is 75 different
applications written in Java, Java plus native libs, .NET, python, the other
python, R, scala, NodeJS, and various C libraries, then docker containers, and
more importantly images, are about as ideal as it gets. We're running Mesos so
we don't _have_ to use docker to get containers, but packaging up the products
as images is a significant advantage.

~~~
stephenr
Both the post I replied to and my post explicitly talk about a go app, nothing
else.

------
bsenftner
Plain and simple: containers violate the KISS principal. While you are
developing reams of domain knowledge working with this turd of a technology,
others are making progress with non-self-created problems that matter in the
real world. This is another case of the tech world developing pointless tech
that can be ignored by those solving concrete real world problems.

------
simula67
Putting a little bit more thought into naming things can help newcomers
understand these concepts more easily. The word container is too generic, why
not call it an 'application jail' or a 'virtual operating system' ?

Another word that is over used in our field is 'context'.

~~~
stass
They were called "jails" long before "containers" became a thing on HN.
Somehow "jails" didn't stick, so I'd assume it was even more confusing for
newcomers.

~~~
chii
Jail had no marketing hook. It's a very negative word. I'd guess that's
Probably the major reason.

~~~
hueving
Well that and it wasn't done by a VC backed firm with strong press
connections.

------
alauda
Guys, you really want to give a look to hyper.sh, if you are frustrated with
running containers in production.

------
VLM
The analogy in the article is inferior.

Here comes the standard HN automobile analogy.

The car makers eternally release little light weight cars that are fattened up
with cruft until they're as heavy and expensive and complicated as the
dinosaurs they were originally meant to replace. At which time car makers
birth a new little stripped down lightweight simple compact car line. That
design pattern is self similar and fractal in that even car engines and
transmissions and car radios undergo a similar pattern of revolution to make
something new, then evolution to slowly and methodically make it the opposite
of the original goal, repeat forever. This design pattern also applies to
computer architecture.

To fight the problem of hardware evolution making life pretty hard on
programmers, source code compatible OS and libraries were invented that could
run the same software on vaguely similar hardware, on mainframes in the late
60s at IBM and on PCs in the 70s CPM era, later extended into the "home
computer" series era in the 80s, then into the msdos era. This became unwieldy
and too complicated for the end users so it was replaced.

The same people implemented the idea of OS packages, again more or less in the
60s on IBM mainframes or the 80s on early unix boxes. The idea is to compile
emacs to be integrated very deeply into the OS and cooperate with every other
piece of software. This is contemporary. However especially in NON-FOSS it
doesn't work and doesn't scale and is very expensive if not impossible to
implement, being the only closed thing on an open system is a nightmare for
everyone and everything involved. The stereotype in the 90s was only one
service installed on one MS windows server, even if that meant it took 20 MS
servers to do the job of one unix server. Anyway, expensive, complicated, hard
for end users.

Again the same people implemented the idea of OS virtualization. Again, IBM
mainframes in the 70s with VM, and early PC hardware experiments with TSRs and
multiprocessing in the 80s to give "two computers at once". This is also
contemporary, enormously more advanced today, of course. It turns out that
running 50 OS kernels on a single piece of hardware is kinda wasteful although
possible and cooperation gets complicated and unwieldy so time to replace
again.

Again the same people implemented process jails / chroot on the BSDs and
eventually after some decades linux finally caught up resulting in docker. So
now your packages don't cooperate or interoperate at all with each other or
the OS, which solves all the problems where the previous technology didn't
work, and creates massive new problems that never existed mostly where the old
technologies worked great. There are of course completely separate new
problems. It turns out that a system designed to eliminate interoperability
between packages interoperability a huge PITA and there are other problems
that make use unwieldy and complicated, hard for end users.

Again the same people implemented (this section to be written after 2016).
Maybe IOT. Maybe collapse of hardware prices faster than business demand means
20 rasp-pi cluster is cheaper and easier to maintain than a single beefy
desktop running 20 virtual images or 20 docker containers. Maybe FPGA on the
desktop means people will just synth up whatever matches this hours workload.
Maybe cloud will finally work and no one will maintain servers anymore, it'll
all be magic, or at least push the magic to someone else who now has the same
old problems. Maybe SaaS means we'll all be customers and most productive
software will run on internet scale clusters not individual machines,
individual machines will be dumb webbrowser terminals. Who knows!

------
realworldview
IBM and Sun know.

------
llcoolv
lol. read two paragraphs => click author's name to verify he's got no actual
tech background. life is boring.

~~~
minimaxir
The author has been writing for TechCrunch for a considerable amount of time.

~~~
llcoolv
I have been singing in the shower for a considerable amount of time. Still no
singing expertise.

In both cases it is immediatly audible/visible in the output.

------
mmatoscom
Hi there, good day fellows

I was expecting this kind of thread long ago, thanks guys for sharing your
concerns, I am learning a lot from them!

IMO we can't compare containers vs VMs like many are doing now - and I was too
when first heard about Docker and containers.

I hold almost all VMware certs (VCP/VSP/VTSP for 3.1/4.x/5.x and VCDX), I sign
the 3 major VMware P2V migrations in BR/LA (287 P2Vs in 2005, 1600/2008 and
2500/2011). I was REALLY into VMware from 2000 to 2010, so I feel confident
using it and recommending to many environments. I even manage some of them
still today.

When we clone or migrate a physical machine to virtual, or whenever deploying
a VM from scratch (or even using templates or copying VMdks etc) into
production, we aim to develop the environment in order to see it lasting
"forever". We want this to be flawless, because even with given most-players
virtualization deploying resources (hyper-V, VMware, xen, kVM, vbox+vagrant,
etc), nobody wants to troubleshoot a production environment, we cheer to see
the VMs always up and running. I remember when P2V in mentioned projects
during the night, and needed to fallback physical servers because the cloned
VM didn't behaved accordingly. Please VMware, clone it ok, otherwise the
troubleshoot for legacy shit will be a pain.

On the other side, containers are made to be replaced. They are impermanent.
You can tune your images as your app/env needs. You can have an image for each
service you have. You can have many images running many containers, and some
of them providing services you have. You are able to customize an image in a
txt file called Dockerfile, and generate an image from this file.

So imagine we got this infrastructure to "Dockerize" , a website with a DB.
Does your webserver runs apache? so you can code a Dockerfile, that will
deploy an apache instance to you. It could deploy FROM an ubuntu:16.10 or
10.04, depends on what is better for your app. OR, we could just pickup
Apache's own image, like in FROM apache. You can save this image as
yourid/apache. And you can do the same regardless of what DB you are using,
just install it (the mysql using apt-get in a FROM ubuntu/debian based
system), or use mysql images directly. You are able to publish the website
cloning your site dev repo direct in Dockerfile itself, or you could have the
website at some dir in your host, using ADD or CP to make it available in the
right container dir (eg /var/www/) You could even use Volumes, to mount some
host dir (or a blob, or a storage account, or a partition in your storage,
something available in the host itself). This is specially interesting for DB
in my opinion. Once you have your Dockerfile ok, you can name it yourid/db.

And if you have a main website, and a blog website, you could use the same
apache Dockerfile changing only the git clone line, and save them as
yourid/apache:website and yourid/apache:blog for example.

And when redeploying the container, you will have the same volume data
available in the same container dir. Even if you redeployed it from
ubuntu:15.10 to ubuntu 16:10.You can use the latest improvements from the
freshest image (or patching some vuln), and redeploy all your containers that
uses this same image at once.

The same goes on, you can test jenkins without knowing what OS jenkins image
is made off. You dont have to worry about it. It will just work. You pull the
image and run the container and voila.

NOW, my Docker instances are like this: I use Docker-machine, and locally I
got the default and local envs. I got also an Azure instance at Docker-machine
(that runs on Azure), and another instance configured in Docker-cloud using
Azure as cloud provider (I use Azure due bizspark credits). So, 4 of them. All
those instances, are VMs themselves. Ubuntu VMs to be sure.

You just replace the container (probably published in a cluster if you care
enough your prod env). Not the same as with VMs at all.

I see Docker as a hypervisor for containers the same way VMware and hyperv are
to VMs.

So I understand my Docker hosts VMs have the same HA, failover, load balance,
resources allocation, and so many resources VMs have. I use Docker on those
VMs to make easy deploys, images, tune images, really guys I was the VMware
guy for so long, I went just crazy in the resources Docker gives to us.

Docker has many weak points indeed (NAT networking, privileged containers must
be run sometimes, security concerns, etc), but again, I don't see Docker to be
erasing VMs from my life and now on I can deploy everything that will run
happy forever in containers. We still need HA, failover, load balance,
resources allocation and so on. Docker needs to be used together with TOOLS
that allows it to run smoothly, and allows us to maintain our environments
easier.

One of those tools are containers clusters. I work mostly with Google
Kubernetes, but there are other as Docker Swarm, Apache Mesos, DCOS... Azure
has its Azure Container Services ACS, IBM has its BlueMix containers, etc.
Using a cluster and a deploy methodology, you are able to deploy your
containers in different namespaces such as DEV / STAGING / PROD. You can use a
BUILD environment to read your Dockerfile, build the image and deploy
containers to the namespace you need. You can configure this build to trigger
with a commit in the git repo for exemple.

So lets say we have a developer, and he needs our yourid/apache:website to be
deployed, with the new website version. If the website is already updated in
your git repo, you just clone it. The Dockerfile would look like this:

    
    
      FROM apache
      MAINTAINER Your Name <your@email.com>
      WORKDIR /var/www/
      RUN git clone https://github.com/yourid/website/website.git .
      EXPOSE 80
      CMD ["/run.sh"]
    

This would be named as website.Dockerfile. If you change the project git repo
to any of your other sites that runs on apache, you can SAVE AS
other.site.Dockerfile, and always deploy this service from this specific repo.

You can customize your Dockerfile of course and add support to specific codes
like installing PHP, Ruby, Python, etc. You could even use Configuration
Managers (CMs) as Ansible, Salt, Chef, Puppet, juju etc to apply those
changes.

Lets say we will start the build now. We are developing this image together.
So I just changed my git url on the Dockerfile. When we commit, the autobuild
triggers this build in our build system (in my case, Docker-cloud or jenkins).
This is what Continuous Integration (CI) and Continuous Deployment (CD) are
about.

So when build is triggered, it gets the Dockerfile from the repo, builds from
its image, deploys the container in the namespace you wanted (our case, DEV).
This service could be published as website.dev.mydomain.com for example. Same
concerning to staging namespace. And to www.mydomain.com when ready to
production, in the PROD kubernetes namespace for example. Kubernetes is a
distributed thing, so you could have minions (nodes) splitted across different
datacenters, or geo locations. This pretty much reminds me of VMware VMs
running inside VMfs storage made available through a set of ESXi servers, all
with access to the same luns/partitions/volumes.

This is just my point of view, so please feel free to comment and ask me
anything.

Please, just dont blame Docker because you aren't aware of mainstream techs
available nowadays. If you are comparing Docker to VMs, or SSHing inside the
containers, and often mad cause your data vanished while redeploying your
Docker Containers, believe me you are doing it wrong.

Being a pioneer is often the same: in the 90s we had to explain why Linux was
good for the enterprise, in the 2000's we had to prove VMware was really going
to cluster your legacy systems, and now we have to explain what's possible to
do with Docker. And, as the tech is new (I know there were previously solaris
zones, google borg, etc), but I see Docker will mature its features relying in
other tools (and even copying features from k8s to Swarm eg). Docker is just
one skill needed to run your stuff.

Cheers!

M Matos [https://keybase.io/mmatos](https://keybase.io/mmatos)

------
zk00006
'WTF' really?

------
ChoHag
Take an operating system. Remove all the advantages of a shared environment
like dynamic libraries, package management, clarity. Stick a chroot before
every fork. Boom! Containers.

------
bbcbasic
I've read before on HN about 'don't use docker in production' can anyone
elaborate on that for a newbie?

~~~
knowaveragejoe
My understanding is that plenty of people do actually use Docker in
production, but they use more than _just_ Docker. A docker container isn't
quite the same as a VM.

