3 ms·

Not having to install and manage a tomcat server is pretty nice. There is "embedded" tomcat so you can just run `java -jar my-app.jar` but then you still have t

Not having to install and manage a tomcat server is pretty nice. There is "embedded" tomcat so you can just run `java -jar my-app.jar` but then you still have to worry about installing and managing the JVM plus whatever file-system resources like logging locations etc. > [JRE version] would change very rarely. It's optimizing for setting up new machines and having everything about how to run an application contained within that application itself rather than relying on sysadmins to `yum install` things or whatever. Plus with docker you always run the same version in prod that you do in dev (and on your local machine) unless you intentionally do something else. > I don't know how fast docker/jib would be but I am imagining this would be a somewhat heavier setup? Not really - a layered docker image may have tomcat as a base layer and then the app jars etc layered atop. Deployment is just downloading a new layer which wouldn't really be any overhead atop of just the jars.

pjmlp 8y ago
Not if the JVM goes with the application, specially now that Java also has a linker.
lmm 8y ago
> 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.
- ryanianian 8y ago
  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.
  - lmm 8y ago
    > 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?
chvid 8y ago
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?
- kimdotcom 8y ago
  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.
  - chvid 8y ago
    So it is so slow you have two spin up a second node :-D
- ryanianian 8y ago
  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.

pjmlp 8y ago

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

lmm 8y ago

> 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.

ryanianian 8y ago
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.
- lmm 8y ago
  > 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?

chvid 8y ago

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?

kimdotcom 8y ago
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.
- chvid 8y ago
  So it is so slow you have two spin up a second node :-D
ryanianian 8y ago
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.