> I still can't really figure out what a container is.
If you mean this in a general sense...
One use case at Unbounce (where I worked in infrastructure) was to encapsulate the runtime dependencies for different services that were on a machine.
Our monolith required Ruby 2.1 and a bunch of gems. Then we were using Scout for centralized monitoring, which required 1.8 with a separate set of gems. We only noticed the problem when our monolith moved from Ruby 1.8 to 2.1.
To fix this problem of dual-Ruby runtimes, we encapsulated the Ruby 1.8 + gems into a Docker image for Scout, then ran the Scout container on the machine. It works perfectly and never conflicts with the monolith's Ruby runtime.
If you mean this in a general sense...
One use case at Unbounce (where I worked in infrastructure) was to encapsulate the runtime dependencies for different services that were on a machine.
Our monolith required Ruby 2.1 and a bunch of gems. Then we were using Scout for centralized monitoring, which required 1.8 with a separate set of gems. We only noticed the problem when our monolith moved from Ruby 1.8 to 2.1.
To fix this problem of dual-Ruby runtimes, we encapsulated the Ruby 1.8 + gems into a Docker image for Scout, then ran the Scout container on the machine. It works perfectly and never conflicts with the monolith's Ruby runtime.