4 ms·

> 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 <-> App

> 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.
- opendais 12y ago
  > 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. opendais-www1 -> fails -> shoot in head, replace. vidarh-www1 -> fails -> shoot all of the containers in the head, replace. At this point, its the same atomic unit I originally started with. Now, I have multiple executions to perform that I have to build out. This is the very definition of wasteful added complexity. The high level process is effectively identical but you have to do more things to make it work. > - 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. My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process. > - Each container is limited in what it can access, ensuring that interdependencies between the containers are documented and explicit. How is my container not limited exactly? Because nginx and php-fpm can access the same files? o.O I don't think this is really an argument of any kind beyond the theoretical. > Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms. You've never seen this go wrong before in production I take it when Person X updates a component that breaks Person Y's application I take it? I have and it is not pretty. This is added complexity to manage. > 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 reason I said "To me, for my use," in the original parent comment is this is for my usage. I don't claim to speak for everyone who might use Docker. I'm sure there are people with different requirements. My requirements involve not building the sort of products you mention in the second group. > 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. If you are storing state in an application container, it isn't a role-based container. I'm going to assume this is because I said something that was unclear. Please explain to me how you concluded I stored state in this container: Load Balancer w/ Builtin HTTP Health Checks <-> Application Containers [nginx+php-fpm] > 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. It doesn't save me time and adds complexity. Maybe everyone who is arguing with me is just a better developer than me. Maybe they are just people who have never worked in an environment where every added layer of complexity leads to a higher frequency of breakage because Random Team Member X forgot something.
mwcampbell 12y ago
I think that in the specific case of nginx plus php-fpm, separating things all the way out to one process per container is overkill, and it would be better to put the two in a single container, managed with something like runit or supervisord. Conceptually, the combination of nginx and php-fpm can be treated as a single service, and your operations team (or youu when wearing your ops hat) would probably prefer to think of it as such. There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor.
- opendais 12y ago
  It is why I used it as an example. Nginx+php-fpm = web app role, easy to conceptualize as a single service, and in many workplaces might be the entire depth of a given service [except for the database]. > There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor. I was simplifying it for purposes of example. The reality is I'd have a log-shipper as well shipping logs. I don't need it to dump to the container's stdout/stderr because its all in [insert log management application here]. They shutdown as cleanly enough as-is without worrying about it too much as well.
- vidarh 12y ago
  I disagree. It's a perfect example where one of the components is likely to scale differently than the other, and where the components are reusable separately but less reusable together. As someone constantly wearing my "ops hat", I much prefer to see them treated separately for that reason.
  - deleted 12y ago
    [deleted]

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.

opendais 12y ago
> 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. opendais-www1 -> fails -> shoot in head, replace. vidarh-www1 -> fails -> shoot all of the containers in the head, replace. At this point, its the same atomic unit I originally started with. Now, I have multiple executions to perform that I have to build out. This is the very definition of wasteful added complexity. The high level process is effectively identical but you have to do more things to make it work. > - 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. My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process. > - Each container is limited in what it can access, ensuring that interdependencies between the containers are documented and explicit. How is my container not limited exactly? Because nginx and php-fpm can access the same files? o.O I don't think this is really an argument of any kind beyond the theoretical. > Versioning of e.g. system packages can evolve separately for each component, without needing separate (heavier) full vms. You've never seen this go wrong before in production I take it when Person X updates a component that breaks Person Y's application I take it? I have and it is not pretty. This is added complexity to manage. > 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 reason I said "To me, for my use," in the original parent comment is this is for my usage. I don't claim to speak for everyone who might use Docker. I'm sure there are people with different requirements. My requirements involve not building the sort of products you mention in the second group. > 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. If you are storing state in an application container, it isn't a role-based container. I'm going to assume this is because I said something that was unclear. Please explain to me how you concluded I stored state in this container: Load Balancer w/ Builtin HTTP Health Checks <-> Application Containers [nginx+php-fpm] > 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. It doesn't save me time and adds complexity. Maybe everyone who is arguing with me is just a better developer than me. Maybe they are just people who have never worked in an environment where every added layer of complexity leads to a higher frequency of breakage because Random Team Member X forgot something.

mwcampbell 12y ago

I think that in the specific case of nginx plus php-fpm, separating things all the way out to one process per container is overkill, and it would be better to put the two in a single container, managed with something like runit or supervisord. Conceptually, the combination of nginx and php-fpm can be treated as a single service, and your operations team (or youu when wearing your ops hat) would probably prefer to think of it as such. There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor.

opendais 12y ago
It is why I used it as an example. Nginx+php-fpm = web app role, easy to conceptualize as a single service, and in many workplaces might be the entire depth of a given service [except for the database]. > There are two tricky parts though: getting both underlying processes to log to the container's stdout/stderr, and getting them both to shut down cleanly in response to a SIGTERM to the supervisor. I was simplifying it for purposes of example. The reality is I'd have a log-shipper as well shipping logs. I don't need it to dump to the container's stdout/stderr because its all in [insert log management application here]. They shutdown as cleanly enough as-is without worrying about it too much as well.
vidarh 12y ago
I disagree. It's a perfect example where one of the components is likely to scale differently than the other, and where the components are reusable separately but less reusable together. As someone constantly wearing my "ops hat", I much prefer to see them treated separately for that reason.
- deleted 12y ago
  [deleted]