4 ms·

Maybe I am old school. But I kinda like a WAR-file, run/deployment via a maven plugin and a simple servlet container (like Tomcat). If you run a pure Java stack

by chvid 8y ago

Maybe I am old school. But I kinda like a WAR-file, run/deployment via a maven plugin and a simple servlet container (like Tomcat). If you run a pure Java stack why not keep to this stuff that has been around for ages?

paulddraper 8y ago
Containers give control over the application's JRE version (without making a self-extracting executable).
- chvid 8y ago
  Sure but in practice that would change very rarely. For what I am working on a deployment takes a couple of seconds including controlled shutdown and startup of the application. I don't know how fast docker/jib would be but I am imagining this would be a somewhat heavier setup?
  - mateuszf 8y ago
    It depends. The build / environment base images can be cached, and then deployment could be just pushing and additional layer with the jar. This could be pretty pretty fast if setup correctly.
  - ryanianian 8y ago
    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?
  - DannyB2 8y ago
    How a container works is that the file system has a series of layers. Like stacked sheets of glass with drawings on them. What you see at the top is the file system that results from what is on each sheet of glass. Things on higher sheets of glass can obscure or shadow things from lower layers. Your layer, the top most layer, might have only your JAR. Assembling and deploying your container could be very fast -- but docker takes care of that. You could organize your container so that you have a layer with your Tomcat. Another layer with your JVM. Then you can easily swap in / out layers to define different versions of your container. Whoever deploys your container on a server doesn't know or care what technology you use. Java, Python, etc. They just plug in the container and it runs. (Docker assembles its layers.)
- icedchai 8y ago
  You can achieve this with JAVA_HOME and installing your JDK or JRE in a standard location. This has been possible for 20+ years.
  - DannyB2 8y ago
    The person installing your application may not know anything about Java. They don't want a 35 page installation document. With a container, they just plug in your application and it runs. They don't know and don't care what technology it was developed with. You have complete control of your dependencies, which exact Java runtime you use, any other native libraries or tools you use, etc. They are all part of your container and independent of the host system. You can't see the host system, and the host system doesn't care what is in your container. The container is like a giant simple JAR file for any technology that runs on a Linux system. Once you know how to install and run a container, you can run apps developed in unfamiliar technologies. You don't have to know about their conventions for paths, or classpaths, or other things you don't care about. That is all packaged up inside the container.
    - icedchai 8y ago
      I already know all this, and it's nice, but still unnecessary for many, many use cases.
  - paulddraper 8y ago
    > JAVA_HOME and installing your JDK or JRE in a standard location ...and that's exactly what Docker + Java does. Just in a standard format that works with any kind of program, Java or otherwise.
DannyB2 8y ago
The reason to run your WAR+Tomcat or JAR file in a container is that it is portable across different Linux distributions. The container appears to have a certain environment to your application, regardless of the Linux it is running on. Some containers launch a single process, your process. Some containers launch a "linux distribution" sans kernel, really launching the /sbin/init process, such that you now think you have a complete Linux system, as root, with files and libraries laid out in a way that you expect -- regardless of the conventions of the actual Linux system running your container. A container can be as cheap as launching a process, since that is all a container really does. It launches a process with a lot of parameters and controls that set up the environment, network, isolated process table, your own root user zero, your own root directory, etc. It's just kernel features that isolate your process so that it has a controlled view of what the network looks like, what the filesystem is, etc. The other reason to package as a container instead of a WAR or JAR is that other DevOps or sys admins can install your container without knowing anything about Java. They don't even have to know that you are using Java. I can get a container and install it and run it so that it does some specific function, and I don't care what technology the developers used. Java, Python, PHP, C, God forbid Perl, it doesn't matter. Maybe the container has a mini-Linux distribution inside it. Maybe not. I don't care, I don't know. The container just plugs in and runs. Think of a Container as the benefits of a WAR / JAR but for a larger world outside of Java. A container is also a great way to package a legacy application. Or an application using a technology unfamiliar to those deploying it on servers. Your container has all of your dependencies. A specific Java. Specific dependencies, regardless of what the host system has.
- chvid 8y ago
  I can kinda understand that using docker makes Java programs "run" the same way as other languages. But from my perspective, if you run a pure Java stack, using docker instead of the Java technologies for packaging, deployment seems like a step backwards. You can probably use for defining and spinning up new servers (with JRE, database, servlet container and so on) though but that's a different story.
  - DannyB2 8y ago

by chvid 8y ago

paulddraper 8y ago

Containers give control over the application's JRE version (without making a self-extracting executable).

chvid 8y ago
Sure but in practice that would change very rarely. For what I am working on a deployment takes a couple of seconds including controlled shutdown and startup of the application. I don't know how fast docker/jib would be but I am imagining this would be a somewhat heavier setup?
- mateuszf 8y ago
  It depends. The build / environment base images can be cached, and then deployment could be just pushing and additional layer with the jar. This could be pretty pretty fast if setup correctly.
- ryanianian 8y ago
  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?
- DannyB2 8y ago
  How a container works is that the file system has a series of layers. Like stacked sheets of glass with drawings on them. What you see at the top is the file system that results from what is on each sheet of glass. Things on higher sheets of glass can obscure or shadow things from lower layers. Your layer, the top most layer, might have only your JAR. Assembling and deploying your container could be very fast -- but docker takes care of that. You could organize your container so that you have a layer with your Tomcat. Another layer with your JVM. Then you can easily swap in / out layers to define different versions of your container. Whoever deploys your container on a server doesn't know or care what technology you use. Java, Python, etc. They just plug in the container and it runs. (Docker assembles its layers.)
icedchai 8y ago
You can achieve this with JAVA_HOME and installing your JDK or JRE in a standard location. This has been possible for 20+ years.
- DannyB2 8y ago
  The person installing your application may not know anything about Java. They don't want a 35 page installation document. With a container, they just plug in your application and it runs. They don't know and don't care what technology it was developed with. You have complete control of your dependencies, which exact Java runtime you use, any other native libraries or tools you use, etc. They are all part of your container and independent of the host system. You can't see the host system, and the host system doesn't care what is in your container. The container is like a giant simple JAR file for any technology that runs on a Linux system. Once you know how to install and run a container, you can run apps developed in unfamiliar technologies. You don't have to know about their conventions for paths, or classpaths, or other things you don't care about. That is all packaged up inside the container.
  - icedchai 8y ago
    I already know all this, and it's nice, but still unnecessary for many, many use cases.
- paulddraper 8y ago
  > JAVA_HOME and installing your JDK or JRE in a standard location ...and that's exactly what Docker + Java does. Just in a standard format that works with any kind of program, Java or otherwise.

DannyB2 8y ago

The reason to run your WAR+Tomcat or JAR file in a container is that it is portable across different Linux distributions. The container appears to have a certain environment to your application, regardless of the Linux it is running on. Some containers launch a single process, your process. Some containers launch a "linux distribution" sans kernel, really launching the /sbin/init process, such that you now think you have a complete Linux system, as root, with files and libraries laid out in a way that you expect -- regardless of the conventions of the actual Linux system running your container. A container can be as cheap as launching a process, since that is all a container really does. It launches a process with a lot of parameters and controls that set up the environment, network, isolated process table, your own root user zero, your own root directory, etc. It's just kernel features that isolate your process so that it has a controlled view of what the network looks like, what the filesystem is, etc. The other reason to package as a container instead of a WAR or JAR is that other DevOps or sys admins can install your container without knowing anything about Java. They don't even have to know that you are using Java. I can get a container and install it and run it so that it does some specific function, and I don't care what technology the developers used. Java, Python, PHP, C, God forbid Perl, it doesn't matter. Maybe the container has a mini-Linux distribution inside it. Maybe not. I don't care, I don't know. The container just plugs in and runs. Think of a Container as the benefits of a WAR / JAR but for a larger world outside of Java. A container is also a great way to package a legacy application. Or an application using a technology unfamiliar to those deploying it on servers. Your container has all of your dependencies. A specific Java. Specific dependencies, regardless of what the host system has.

chvid 8y ago
I can kinda understand that using docker makes Java programs "run" the same way as other languages. But from my perspective, if you run a pure Java stack, using docker instead of the Java technologies for packaging, deployment seems like a step backwards. You can probably use for defining and spinning up new servers (with JRE, database, servlet container and so on) though but that's a different story.
- DannyB2 8y ago