3 ms·

> 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

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

vidarh 12y ago
> 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. You have a handful of lines of dependencies to document, for example using systemd unit files. You need to do the basics once, and then reuse. What you end up with are simpler containers (no separate process monitor per container etc.) at the cost of a couple of lines of extra configuration that also happens to document a dependency. I don't see that as a net increase in complexity. > My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process. It documents the dependencies of the whole container as a unit. It does not without a lot of extra effort enforce capturing the interdependencies between multiple components in the same container. This is why I like to keep the containers as small as possible. As long as you're talking about a couple of components with few interdependencies, that's not a big deal. But once you start piling on additional components, the complexity explodes. I once worked on a project where we were considering running round-the-clock network capture for a few days to reverse engineer the interdependencies between various components because nobody were quite sure exactly what they were any more.. That's the kind of scenarios that drives me to want to encapsulate everything as tightly as possible even if I don't need it right now - complexity has an ugly tendency to creep up on us. > 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. As long as nginx and php-fpm are the only things installed, things remain fairly simple (see below, it seems we've had a misunderstanding). Based on that specific example, I agree it's a value judgement and not a big deal either way. > > 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. I've seen that many, many times. This is complexity that largely goes away when you enforce a fine grained split into containers that are built and tested as a full unit. It's exactly because I've managed systems with 100+ VM's where people have had conflicting needs for upgrades that I love being able to encapsulate each component separately, so the developers gets the freedom to make decisions about even core system packages without stepping on each others toes (as long as the developers working on a specific component can agree, anyway...) > 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. I store the state in separate volumes, but the database server process still needs to run somewhere. But it does seem that we've been talking past each other. My impression was that you were advocating keeping the full stack in a container: > Please explain to me how you concluded I stored state in this container I saw your nginx+php-fpm as just one example since you earlier had written "In other words, its a really simple way to deploy X identical instances of an entire service/application." To me it's not "an entire service/application" unless you also include all the auxiliary processes, including database server and anything else the application depends on. I was making a general point about putting an application stack in a single container, not specifically addressing your nginx+php-fpm example. Since I clearly misunderstood, we disagree much less than I thought. I'd still opt for separating php-fpm and nginx into separate containers too, but as I said above, that's a value judgement.

vidarh 12y ago

> 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. You have a handful of lines of dependencies to document, for example using systemd unit files. You need to do the basics once, and then reuse. What you end up with are simpler containers (no separate process monitor per container etc.) at the cost of a couple of lines of extra configuration that also happens to document a dependency. I don't see that as a net increase in complexity. > My explicit documentation also exists in the form of a Dockerfile and my configuration files. Its a self documenting process. It documents the dependencies of the whole container as a unit. It does not without a lot of extra effort enforce capturing the interdependencies between multiple components in the same container. This is why I like to keep the containers as small as possible. As long as you're talking about a couple of components with few interdependencies, that's not a big deal. But once you start piling on additional components, the complexity explodes. I once worked on a project where we were considering running round-the-clock network capture for a few days to reverse engineer the interdependencies between various components because nobody were quite sure exactly what they were any more.. That's the kind of scenarios that drives me to want to encapsulate everything as tightly as possible even if I don't need it right now - complexity has an ugly tendency to creep up on us. > 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. As long as nginx and php-fpm are the only things installed, things remain fairly simple (see below, it seems we've had a misunderstanding). Based on that specific example, I agree it's a value judgement and not a big deal either way. > > 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. I've seen that many, many times. This is complexity that largely goes away when you enforce a fine grained split into containers that are built and tested as a full unit. It's exactly because I've managed systems with 100+ VM's where people have had conflicting needs for upgrades that I love being able to encapsulate each component separately, so the developers gets the freedom to make decisions about even core system packages without stepping on each others toes (as long as the developers working on a specific component can agree, anyway...) > 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. I store the state in separate volumes, but the database server process still needs to run somewhere. But it does seem that we've been talking past each other. My impression was that you were advocating keeping the full stack in a container: > Please explain to me how you concluded I stored state in this container I saw your nginx+php-fpm as just one example since you earlier had written "In other words, its a really simple way to deploy X identical instances of an entire service/application." To me it's not "an entire service/application" unless you also include all the auxiliary processes, including database server and anything else the application depends on. I was making a general point about putting an application stack in a single container, not specifically addressing your nginx+php-fpm example. Since I clearly misunderstood, we disagree much less than I thought. I'd still opt for separating php-fpm and nginx into separate containers too, but as I said above, that's a value judgement.