3 ms·

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 certa

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
  For a pure Java stack, you might not find any advantage in Docker. There is still one however -- Kubernetes. Run many instances of a Docker container in Kubernetes as a cluster. Oh, but I can set up various Java technology clusters without Kubernetes. Think of Kubernetes as doing for clusters what an OS does for a single computer. 1960s: Joe: can I use the computer today to run my workload? Bob: yeah, but my workload is running the computer until about 3 PM. Today: Joe: can I use the (let's say Hadoop) cluster to run my workload? Bob: yeah, but my workload is running the cluster until about 3 PM. An OS lets Joe and Bob both use the computer at the same time. Kubernetes lets Joe and Bob both use a generalized cluster at the same time. Joe has his Docker container (say a Java workload set up as a Hadoop node). Bob has his Docker container (say some other kind of Java parallel computing workload, or maybe Python or other). Joe tells Kubernetes to run 50 instances of his workload. Bob tells Kubernetes to run 30 instances of his workload. Joe and Bob's workloads can each see each their own nodes on a private network that cannot see the other's nodes on the network. Maybe the physical hardware cluster only has 45 nodes. Kubernetes might schedule multiple docker containers running on the same physical node. Kubernetes is something you would expect from Google running a giant data center where many different people want to run multiple-node clusters ad-hoc at any given time. Even multiple instances of the same type of workload, such as Jane wanting her own 50 node Hadoop, while Carol runs a 40 node Hadoop cluster, but they don't interfere with each other.

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
For a pure Java stack, you might not find any advantage in Docker. There is still one however -- Kubernetes. Run many instances of a Docker container in Kubernetes as a cluster. Oh, but I can set up various Java technology clusters without Kubernetes. Think of Kubernetes as doing for clusters what an OS does for a single computer. 1960s: Joe: can I use the computer today to run my workload? Bob: yeah, but my workload is running the computer until about 3 PM. Today: Joe: can I use the (let's say Hadoop) cluster to run my workload? Bob: yeah, but my workload is running the cluster until about 3 PM. An OS lets Joe and Bob both use the computer at the same time. Kubernetes lets Joe and Bob both use a generalized cluster at the same time. Joe has his Docker container (say a Java workload set up as a Hadoop node). Bob has his Docker container (say some other kind of Java parallel computing workload, or maybe Python or other). Joe tells Kubernetes to run 50 instances of his workload. Bob tells Kubernetes to run 30 instances of his workload. Joe and Bob's workloads can each see each their own nodes on a private network that cannot see the other's nodes on the network. Maybe the physical hardware cluster only has 45 nodes. Kubernetes might schedule multiple docker containers running on the same physical node. Kubernetes is something you would expect from Google running a giant data center where many different people want to run multiple-node clusters ad-hoc at any given time. Even multiple instances of the same type of workload, such as Jane wanting her own 50 node Hadoop, while Carol runs a 40 node Hadoop cluster, but they don't interfere with each other.