This is what we use to call "application containers" that run a minimal environment tailored to support a single application (say Nginx or your bug tracker that connects to an external database). There is another (somewhat less common) type of container that runs almost an entire operating system and behaves like a VM, but instead of having virtualized hardware running a full OS, it shares the kernel with the host machine. This way you can have, say, a Fedora server environment on an Ubuntu machine without the overhead of a VM. On one of my previous jobs, I ran the latest Ubuntu LTS inside a container on a recent non-LTS Ubuntu workstation.
Sometimes the host OS exposes a "fake" kernel to the container, allowing it to behave as a different OS. This is how Solaris machines used to host Linux containers (not sure they still do it).
Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Well yes you are right. There are a load of different things and understandings of containers. Personally, from quite an abstract level I tend to understand containers as a mere "structural interface" between operations and development that needs to be just as flexible as the environment itself is heterogenous. Back in Java EE days we used to have "all Java EE 1.6", devs were using a Glassfish application server locally and the same was running on the server. In such an environment, the Java EE application packages (such as .war or .ear files) do pretty well as containers. This doesn't work anymore, however, as soon as you got to deal with node.js or Python in your development and deployment tool chain. If you need this, your interface between development and operations needs to be capable of managing this. Recent container technologies seem pretty good at exactly that. ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is what we use to call "application containers" that run a minimal environment tailored to support a single application (say Nginx or your bug tracker that connects to an external database). There is another (somewhat less common) type of container that runs almost an entire operating system and behaves like a VM, but instead of having virtualized hardware running a full OS, it shares the kernel with the host machine. This way you can have, say, a Fedora server environment on an Ubuntu machine without the overhead of a VM. On one of my previous jobs, I ran the latest Ubuntu LTS inside a container on a recent non-LTS Ubuntu workstation.
Sometimes the host OS exposes a "fake" kernel to the container, allowing it to behave as a different OS. This is how Solaris machines used to host Linux containers (not sure they still do it).
Well yes you are right. There are a load of different things and understandings of containers. Personally, from quite an abstract level I tend to understand containers as a mere "structural interface" between operations and development that needs to be just as flexible as the environment itself is heterogenous. Back in Java EE days we used to have "all Java EE 1.6", devs were using a Glassfish application server locally and the same was running on the server. In such an environment, the Java EE application packages (such as .war or .ear files) do pretty well as containers. This doesn't work anymore, however, as soon as you got to deal with node.js or Python in your development and deployment tool chain. If you need this, your interface between development and operations needs to be capable of managing this. Recent container technologies seem pretty good at exactly that. ;)