- Most people run everything as root in a container.
Most people is probably a bad way to start that list. It’s not best practice to run apps as root, without regard to if the app is running inside or outside of a container.
Containers are akin to FreeBSD jails or Solaris zones, etc.
If I’m running PostgreSQL, I run it as the postgres user in Docker containers and outside of them. If I’m running RabbitMQ, I run it as the rabbitmq user in Docker containers and outside of them. Nothing changes because of docker. People who run apps as root in Docker are likely to be the same people who run apps as root outside of Docker.
- Templates for docker containers are called “images”
Given how long you’ve been programming, think of the Golden Images of 20 years ago where you’d burn an app to a CD or create a R/O floppy for an app. It’s the same thing. Dockerfiles are like shell scripts that tell docker how to make your golden image for your app. That image is then immutable. If you want to release a new version, you create and run a new image.
- People who want to run RoR in a container start with an image that is NAMED after ruby and the version they have
Usually the image/container is the app itself. Your ruby app called foo is run on an image called foo that may extend a OS level image that has RoR installed.
- No one runs stuff like rvm in a container
I’m not a ruby person, so I can’t say for sure. I don’t know what rvm is or why one would run it.
- The problem of credentials hasn’t really been solved
Which problem of credentials? Storing credentials is generally a bad idea. Systems like Hashicorp’s Vault are a really keen way to go when you’re dealing with Dockerized applications since you can ask for credential leases and the authentication information is only stored in your app’s runtime, not committed to a filesystem or image.
- A container is somehow lighter than a VM, but in ways that no one really talks about ever
Apps running in containers are isolated by the system kernel to their own process space. They are not running inside a virtual server running inside a physical server. Take these terrible ascii representations as examples:
Application
----------------
Operating System
----------------
Virtual Machine
----------------
Operating System
----------------
Physical Machine
vs
[ Application ]
----------------
Operating System
----------------
Physical Machine
Where [ Application ] is the containerized application that appears to be running in its own operating system but instead is just the OS Kernel representing that to the application. The kernel provides isolation for the process space and the filesystem in a similar way to a VM, but without the overhead of a VM. You can run your app in an isolated way on hardware without having to run your app in an OS on a VM that’s running in an OS on a real machine.
FWIW I read your post as if you were either angry or frustrated with the technology stack, which is why I replied.
There are lots and lots of good resources that explain these concepts. It might be good to start with the basis of the technology that Docker uses in Linux, which is based upon LXC. I’d then look for blog posts or intro articles on Docker and don’t worry about what “everyone else” is doing. The best practices regarding security, etc don’t change because of Docker.
