Hacker News Reader

I am curious about startup / deployment times?

When I a deploy WAR-file it, it is fairly small (just app + dependencies), and startup / shutdown is well-defined and happens fast, allowing me to update an application with just a few seconds downtime. But here - how fast would an update be? How much downtime? Does it reinstall the os, the vm, the app, are the shutdown / startup operation well defined or does the process just get killed?

Wouldn't it take quiet a bit of work just to match what you get out of the box in a traditional setup?

You would bring up a 2nd container with the new code, map the traffic to this container, and once you are sure it is good, trash the old container.

If there is a problem with the new code, just point the traffic back to the working container and kill the new container.

So it is so slow you have two spin up a second node :-D

Yes to what kimdotcom says - blue/green is the only real sane way to do it with minimal/no downtime, and that strategy/recommendation is good even if you're not running in Docker. If you're just doing cowboy deploys and accepting a few seconds of downtime while the new war file explodes and tomcat starts up, then Docker won't add any noticeable overhead of its own.

> Does it reinstall the os, the vm, the app,

No. First, "reinstall" isn't the right word. The "OS" is baked into the container. There is no vm, Docker is not a vm. It doesn't re-install the app, it's starting it up in a new container. All your deploys are likely doing is pulling a new container image or layer (about the same size as your war) and calling `docker run` which could be more or less the same as `java -jar...`.

> are the shutdown / startup operation well defined or does the process just get killed?

There is a well-defined container lifecycle that iirc sends SIGTERM by default. This is similar to what systemd or similar would do.

> you still have to worry about installing and managing the JVM

Up to a very limited point. JVM backward compatibility is very good so you can do global version upgrades with reasonable confidence, and the JVM is such a common requirement (in the context of being a java shop) that including it in the base system image makes sense.

> plus whatever file-system resources like logging locations etc.

It's very much doable to get these down to zero (e.g. using remote logging), and I find it's worthwhile.

Backward-compatibility is one thing but forward-compatibility is something else entirely.

I upgraded a whole java shop to java8 and it was not a fun experience having two JVMs on the same machine and all the different tools thought they knew which one was the correct one but none of them agreed (it wasn't as simple as setting JAVA_HOME).

All of this java tooling/versioning is simple in theory since java is a pretty simple ecosystem (compared to something like C++ or even python to an extent), but there's so many layers of indirection in a modern build & deployment system that it's really painful to debug when some tool somewhere sets its PATH incorrectly or doesn't respect JAVA_HOME or symlinks or....)

If the apps had been docker-ized there wouldn't have needed to be a JVM on the host machine at all, and teams could come in and use java9 or whatever without having to work with SREs/devops to upgrade the machines and worry about whatever other apps may be using those machines or virtual-machine images.

> I upgraded a whole java shop to java8 and it was not a fun experience having two JVMs on the same machine and all the different tools thought they knew which one was the correct one but none of them agreed (it wasn't as simple as setting JAVA_HOME).

I agree that having two JVMs on the same machine without something like docker can be problematic, but in my experience there's no need to ever do that - the backwards compatibility is good enough that you can just replace the old JVM with the new one.

I mean, if you're worrying about this kind of thing shouldn't you also worry about whether apps are built against older versions of docker? How easy is it to have two different versions of docker on the same machine and make sure that docker upgrades don't impact other apps running on those machines?

Not if the JVM goes with the application, specially now that Java also has a linker.