5 ms·

I think the core flaw with the "no SSHD in Docker, ever" reasoning is it makes a number of assumptions. To me, for my use, Docker is really a lightweight role-

I think the core flaw with the "no SSHD in Docker, ever" reasoning is it makes a number of assumptions. To me, for my use, Docker is really a lightweight role-based VM I can put on a provisioned host of some kind [another VM, dedicated server]. In other words, its a really simple way to deploy X identical instances of an entire service/application. If any component in that instance of the application is non functional the container is dead and you route requests to a different container. The problem with the "one process per Docker instance" logic is you need a great deal more service discovery logic as a result. There are a bunch of projects/methods to simplify this but at the end of the day it adds complexity to operations. Instead of a single health check to monitor, you have X containers to monitor. You have X containers to discover, etc. Sure, this lets you get out of running Supervisor and SSH on a Docker container...but I think it adds alot of application complexity that you can avoid 90% of the time. SOA makes sense when you have a large deployment but if you are deploying to a cluster of 5 machines...its overkill. Many [likely the majority] of projects are at the scale of a basic cluster for redundancy.

vidarh 12y ago
I think that's just an issue of tooling and getting used to a different way of working with the services. If you run each of those services as a single docker container and group them on the same server, there does not need to be any more service discovery: You can link all of them. That still gives you the flexibility of modifying the linking without having to modify any of the containers. The main practical difference vs. running them all in one vm is explicitly documenting dependencies - both which service relies on which package sets etc. (assuming you're strict about what you put in the Dockerfiles) and which part of your system needs access to which other component or needs to share access to which directories. You can also easily start them e.g. via systemd unit files or via a tool like fleet, and pull the ip/port of dependencies on startup of the container and pass them as arguments. This also makes deploying them as a unit easy, but still decouples it: If you need to move one component to a different server, or suddenly realize your foobar server needs lots of resources and want to load-balance it across multiple machines, you can easily do so by forwarding a port via stunnel or load-balancing via haproxy or what have you without affecting the actual containers. As for your health checks, you can still have a single all-encompassing health check if you want - whether it's in one "vm" or a set of separate containers does not really change that in any way, though the bigger the setup, the more additional checks you'll probably want to add. You have X containers to monitor, but you had X server processes to monitor previously. If your use case made it ok to depend on just e.g. hitting a page on a website that depends on all X services being up, then your single old monitor still does the job. The overhead can be made really minimal and beneficial even for a single server setup, yet help you if/when you suddenly want to scale part of it. Personally, I run about a dozen docker containers on my home server so far, and I expect that to increase several times over as e.g. every web app I experiment with ends up running in its own container, with the docker setup in a git repo as documentation of exactly which project caused me to pull in which additional packages etc., and keeping the host itself as pristine as possible. Makes me lot less nervous about distribution upgrades etc.
- opendais 12y ago
  > I think that's just an issue of tooling and getting used to a different way of working with the services. Load Balancer w/ Builtin HTTP Health Checks <-> Application Containers [nginx+php-fpm] Load Balancer w/ Builtin HTTP Health Checks <-> Container [nginx] <-> Container [php-fpm] <-> Additional health check you have to build out to check that php-fpm is working correctly <-> Additional Tooling to make your process work For every single service in your architecture you are adding an additional level of redundant complexity because it "helps you scale". I can spin up as many app containers as I want, as often as I want without a second thought or a moment's consideration. I don't care if I have 1000 of them or 1, as long as the load balancer can handle the connections. The scale you are talking about is when you need more than just a couple load balancers...and you aren't going to need that for 90% of projects.
  - vidarh 12y ago
    Why do you think you need additional health checks? Why do you think you need additional tooling? If you have a health check that checks that php-fpm works, it should need no or minimal adaption to handle the new scenario. The only "new" thing is that the processes have a different parent process than usual and is running in different namespaces. If you didn't care about healthchecks for php-fpm before, there's no reason to care about them now. > For every single service in your architecture you are adding an additional level of redundant complexity because it "helps you scale". You see it as adding complexity, I see it as reducing complexity: By wrapping each bit in a Docker container, I gain: - Explicit documentation of the dependencies necessary for each components. I know it covers at least what is needed, because otherwise the component will fail; as opposed to documentation which easily becomes obsolete. - Each container is limited in what it can access, ensuring that interdependencies between the containers are documented and explicit. - Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms. > I can spin up as many app containers as I want, as often as I want without a second thought or a moment's consideration That's great, as long as all components of the app use sufficiently few resources, and are easy enough to run in parallel. E.g. have fun if one of the components of this container is a Postgres install and all the instances needs a consistent view of the database. Or if one of the components needs tons of memory and you end up running out of memory even if there was no need to run more of that component in parallel. For some apps that's not an issue. For others it is, and even starting a second instance of the full stack becomes a huge waste of resources or a huge added complexity vs. starting more of a specific component. > The scale you are talking about is when you need more than just a couple load balancers...and you aren't going to need that for 90% of projects. The scale I'm talking about is anything from a single, small home server, where you may want to spin up more web servers for experimentation but not need more than a single database server, to large clusters. I use Docker for 100% of my small home projects because it makes life easier and saves me time.
cpuguy83 12y ago
And how does running it all in the same container make it easier to discover? All services listening on localhost?
- opendais 12y ago
  More or less, yes. Every instance of the app has static locations for every service it talks to so it doesn't need to care what location. Every docker container has a health check for the load balancer and registers itself with the load balancer on startup. I don't run something like Cassandra or MySQL in docker.
  - cpuguy83 12y ago
    Did you know you can have containers share a network namespace, so effectively containers can have the same localhost?
    - opendais 12y ago
      That is one more thing for me to setup and manage. There is no reason to do that when your scale is small enough that you handle it with 2 load balancers.
      - ldlework 12y ago
        Its a flag. There's not much to manage or setup.
        opendais 12y ago
        > Its a flag. There's not much to manage or setup. Yes, but managing multiple containers is more effort than 1.

vidarh 12y ago

I think that's just an issue of tooling and getting used to a different way of working with the services. If you run each of those services as a single docker container and group them on the same server, there does not need to be any more service discovery: You can link all of them. That still gives you the flexibility of modifying the linking without having to modify any of the containers. The main practical difference vs. running them all in one vm is explicitly documenting dependencies - both which service relies on which package sets etc. (assuming you're strict about what you put in the Dockerfiles) and which part of your system needs access to which other component or needs to share access to which directories. You can also easily start them e.g. via systemd unit files or via a tool like fleet, and pull the ip/port of dependencies on startup of the container and pass them as arguments. This also makes deploying them as a unit easy, but still decouples it: If you need to move one component to a different server, or suddenly realize your foobar server needs lots of resources and want to load-balance it across multiple machines, you can easily do so by forwarding a port via stunnel or load-balancing via haproxy or what have you without affecting the actual containers. As for your health checks, you can still have a single all-encompassing health check if you want - whether it's in one "vm" or a set of separate containers does not really change that in any way, though the bigger the setup, the more additional checks you'll probably want to add. You have X containers to monitor, but you had X server processes to monitor previously. If your use case made it ok to depend on just e.g. hitting a page on a website that depends on all X services being up, then your single old monitor still does the job. The overhead can be made really minimal and beneficial even for a single server setup, yet help you if/when you suddenly want to scale part of it. Personally, I run about a dozen docker containers on my home server so far, and I expect that to increase several times over as e.g. every web app I experiment with ends up running in its own container, with the docker setup in a git repo as documentation of exactly which project caused me to pull in which additional packages etc., and keeping the host itself as pristine as possible. Makes me lot less nervous about distribution upgrades etc.

opendais 12y ago
> I think that's just an issue of tooling and getting used to a different way of working with the services. Load Balancer w/ Builtin HTTP Health Checks <-> Application Containers [nginx+php-fpm] Load Balancer w/ Builtin HTTP Health Checks <-> Container [nginx] <-> Container [php-fpm] <-> Additional health check you have to build out to check that php-fpm is working correctly <-> Additional Tooling to make your process work For every single service in your architecture you are adding an additional level of redundant complexity because it "helps you scale". I can spin up as many app containers as I want, as often as I want without a second thought or a moment's consideration. I don't care if I have 1000 of them or 1, as long as the load balancer can handle the connections. The scale you are talking about is when you need more than just a couple load balancers...and you aren't going to need that for 90% of projects.
- vidarh 12y ago
  Why do you think you need additional health checks? Why do you think you need additional tooling? If you have a health check that checks that php-fpm works, it should need no or minimal adaption to handle the new scenario. The only "new" thing is that the processes have a different parent process than usual and is running in different namespaces. If you didn't care about healthchecks for php-fpm before, there's no reason to care about them now. > For every single service in your architecture you are adding an additional level of redundant complexity because it "helps you scale". You see it as adding complexity, I see it as reducing complexity: By wrapping each bit in a Docker container, I gain: - Explicit documentation of the dependencies necessary for each components. I know it covers at least what is needed, because otherwise the component will fail; as opposed to documentation which easily becomes obsolete. - Each container is limited in what it can access, ensuring that interdependencies between the containers are documented and explicit. - Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms. > I can spin up as many app containers as I want, as often as I want without a second thought or a moment's consideration That's great, as long as all components of the app use sufficiently few resources, and are easy enough to run in parallel. E.g. have fun if one of the components of this container is a Postgres install and all the instances needs a consistent view of the database. Or if one of the components needs tons of memory and you end up running out of memory even if there was no need to run more of that component in parallel. For some apps that's not an issue. For others it is, and even starting a second instance of the full stack becomes a huge waste of resources or a huge added complexity vs. starting more of a specific component. > The scale you are talking about is when you need more than just a couple load balancers...and you aren't going to need that for 90% of projects. The scale I'm talking about is anything from a single, small home server, where you may want to spin up more web servers for experimentation but not need more than a single database server, to large clusters. I use Docker for 100% of my small home projects because it makes life easier and saves me time.

cpuguy83 12y ago

And how does running it all in the same container make it easier to discover? All services listening on localhost?

opendais 12y ago
More or less, yes. Every instance of the app has static locations for every service it talks to so it doesn't need to care what location. Every docker container has a health check for the load balancer and registers itself with the load balancer on startup. I don't run something like Cassandra or MySQL in docker.
- cpuguy83 12y ago
  Did you know you can have containers share a network namespace, so effectively containers can have the same localhost?
  - opendais 12y ago
    That is one more thing for me to setup and manage. There is no reason to do that when your scale is small enough that you handle it with 2 load balancers.
    - ldlework 12y ago
      Its a flag. There's not much to manage or setup.
      - opendais 12y ago
        > Its a flag. There's not much to manage or setup. Yes, but managing multiple containers is more effort than 1.