9 ms·

Why is storage an issue? With databases, for example, you store data upstream (on the host) and keep the dockerised app/thing mostly stateless, or at least capp

Why is storage an issue? With databases, for example, you store data upstream (on the host) and keep the dockerised app/thing mostly stateless, or at least capped with regards to storage. More details about your environment would be appreciated.

jdoliner 10y ago
Keeping data on the host is exactly the reason that it's an issue. Swarm offers not guarantees that containers will be rescheduled on the same host that it was initially scheduled on and assumes that it can reschedule containers as failures arise... this doesn't work when your database gets rescheduled and emptied along the way.
- zamalek 10y ago
  > your database gets rescheduled and emptied along the way That's bundling an CP application into seemingly AP infrastructure (from what I gleaned from their docs). Completely the wrong tool for the job. If the application was designed for that it would have recovered. In your defense, they have nothing to warn about that in their documentation.
  - jdoliner 10y ago
    This isn't really a CAP theorem problem and it's certainly not right to describe Docker as "AP infrastructure." What would that mean exactly? Would you expect this problem to go away if I used a database that sacrificed consistency for availability such as Riak?
    - zamalek 10y ago
      Swarm (not the whole of Docker) seems like something designed for databases like Riak, yes. A SQL failover cluster might work, but certainly not a single database container on infrastructure designed for highly available apps.
- kerr23 10y ago
  In docker 1.12 you can 'tag' a node and tell a 'service' to only run on the tagged nodes. Not saying that's a good idea, but it is getting closer. You could, for example, have a node that's only for DBs that has volumes on it. You could then use DRBD on the host to clone that data to a secondary node. then in the event that node 1 dies swarm would bring the DB up on node2. With the mesh network stuff they've added the endpoint would remain the same, so all your apps would need to do would be re-connect.
  - jdoliner 10y ago
    > Not saying that's a good idea, but it is getting closer. No, that isn't getting closer it's getting farther away. The whole point of containers is that they make the host machine completely fungible. If I can only schedule my DB containers on a specific machine then I might as well just run my DB on that machine and be done with it.
    - kerr23 10y ago
      hmm, your first complaint was that "Swarm offers no guarantees that containers will be rescheduled on the same host". I'm saying that, if you want, you CAN make it guarantee that a container will be rescheduled to the same host. (or a controlled level of hosts). I don't think it's docker's responsibility to solve database clustering. And, as I said, I'm not advocating running a production DB in docker. But I can see a way that you may be able to.
      - jdoliner 10y ago
        I see how that was confusing. I meant that the fact that Swarm doesn't offer such a guarantee is the reason that storing the data on the host isn't a solution. My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers. There's lots of people trying to fix this problem the right way, Kubernetes has made a lot of progress on having volumes follow the containers around from host to host. Torus is a slightly different approach, Flocker is another one. > I don't think it's docker's responsibility to solve database clustering. I don't know if I'd call it a responsibility. But Docker is obviously trying to expand their platform into more and more aspects of containerization. If they figured out persistence that would really set them apart, something that this product doesn't really do. It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.
jodok 10y ago
why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest
jodok 10y ago
why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest

jdoliner 10y ago

Keeping data on the host is exactly the reason that it's an issue. Swarm offers not guarantees that containers will be rescheduled on the same host that it was initially scheduled on and assumes that it can reschedule containers as failures arise... this doesn't work when your database gets rescheduled and emptied along the way.

zamalek 10y ago
> your database gets rescheduled and emptied along the way That's bundling an CP application into seemingly AP infrastructure (from what I gleaned from their docs). Completely the wrong tool for the job. If the application was designed for that it would have recovered. In your defense, they have nothing to warn about that in their documentation.
- jdoliner 10y ago
  This isn't really a CAP theorem problem and it's certainly not right to describe Docker as "AP infrastructure." What would that mean exactly? Would you expect this problem to go away if I used a database that sacrificed consistency for availability such as Riak?
  - zamalek 10y ago
    Swarm (not the whole of Docker) seems like something designed for databases like Riak, yes. A SQL failover cluster might work, but certainly not a single database container on infrastructure designed for highly available apps.
kerr23 10y ago
In docker 1.12 you can 'tag' a node and tell a 'service' to only run on the tagged nodes. Not saying that's a good idea, but it is getting closer. You could, for example, have a node that's only for DBs that has volumes on it. You could then use DRBD on the host to clone that data to a secondary node. then in the event that node 1 dies swarm would bring the DB up on node2. With the mesh network stuff they've added the endpoint would remain the same, so all your apps would need to do would be re-connect.
- jdoliner 10y ago
  > Not saying that's a good idea, but it is getting closer. No, that isn't getting closer it's getting farther away. The whole point of containers is that they make the host machine completely fungible. If I can only schedule my DB containers on a specific machine then I might as well just run my DB on that machine and be done with it.
  - kerr23 10y ago
    hmm, your first complaint was that "Swarm offers no guarantees that containers will be rescheduled on the same host". I'm saying that, if you want, you CAN make it guarantee that a container will be rescheduled to the same host. (or a controlled level of hosts). I don't think it's docker's responsibility to solve database clustering. And, as I said, I'm not advocating running a production DB in docker. But I can see a way that you may be able to.
    - jdoliner 10y ago
      I see how that was confusing. I meant that the fact that Swarm doesn't offer such a guarantee is the reason that storing the data on the host isn't a solution. My real complaint is that none of these give you a way to do persistence that doesn't destroy some other really nice properties of containers. There's lots of people trying to fix this problem the right way, Kubernetes has made a lot of progress on having volumes follow the containers around from host to host. Torus is a slightly different approach, Flocker is another one. > I don't think it's docker's responsibility to solve database clustering. I don't know if I'd call it a responsibility. But Docker is obviously trying to expand their platform into more and more aspects of containerization. If they figured out persistence that would really set them apart, something that this product doesn't really do. It mostly just keeps them even with Kubernetes at best. And an imitation of it at worst.

jodok 10y ago

why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest

jodok 10y ago

why not run the database directly in the container as well? we're doing that with https://crate.io https://crate.io - just expose your local instance store as volume, crate will take care of the rest