6 ms·

Glad to see more articles like this. I find tons of writings about stateless containers, but hardly any about best practices for stateful containers. Just yeste

by rburhum 10y ago

Glad to see more articles like this. I find tons of writings about stateless containers, but hardly any about best practices for stateful containers. Just yesterday I was going over the Django tutorial in the official Docker docs. Everything there made sense except that it completely ignores how to handle "media" folders (i.e. the Django folder that, among other things, contains user uploads). Yes, the database is in a volume so I am glad that survives creating/destroying the postgres container, but I kind of need the other files, too.

atmosx 10y ago
Well in today's world you'll handle the media folder by hosting files in the cloud (e.g. an S3 bucket). Most of the times if you use volumes, it's because of poor design[1] than anything else. [1] modern web-app design guidelines: http://12factor.net/ http://12factor.net/
- ngrilly 10y ago
  Well, I keep reading this, but what if you design an app that relies on local storage, for example one that uses an embedded database like SQLite, LevelDB or BoltDB? 12 factors don't address this.
  - aleem 10y ago
    You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs. Building stateless containers is good practice. There will always be exceptions but it's good to know the tradeoffs before making those exceptions.
    - tokenizerrr 10y ago
      Right, and third party software is a thing. There are also plenty of reasons to prefer the simplicity of SQLite even if that means you have the task of managing your own backups.
      - vidarh 10y ago
        There are plenty of reasons to prefer that simplicity if you intend to write software meant to run on a single computer. The moment you want to deploy a service, unless the data is "mostly static" (e.g. something you might update offline and ship copies of), the simplicity that makes things like Sqlite great often ends up creating complexity.
        tokenizerrr 10y ago
        Not everything needs to be highly available. Using docker does not mean that you are using it in a highly available environment. Plenty of things I run in docker containers can be down for a few hours every night to run backups.
    - ngrilly 10y ago
      Yes, I'm aware stateful services need redundancy, scaling and backups. That's exactly my point. 12 Factors only address stateless processes, which is the easy part. But most applications are stateful. It doesn't matter if data are stored in an embedded database (like SQLite, LevelDB, BoltDB) or in a client-server database (like PostgreSQL, MySQL, MongoDB, RabbitMQ, Redis). 12 Factors doesn't address this issue at all.
      - icebraining 10y ago
        The point of 12 Factors is to isolate the application from the data store, making it easy to manage and upgrade the former. That's important because they recognize applications are stateful. But yes, 12 Factors doesn't purport to guide people on how to manage the stateful part.
- rburhum 10y ago
  I am not debating whether you should or should not store files on S3. I can see use cases for both using S3 (or some alternate storage). My point is that - even in the case for django configured with S3 in this docker tutorial, there is absolutely no mention of this. The "dockerized Django" example in the documentation destroys your uploaded files every time you restart the container. Most of the "Dockerizing <whatever you want>" that I have read so far miss the maintaining state part. To me, that is overlooking an important point.
- cyphar 10y ago
  You're just punting on the problem. Now storage is someone else's problem, who can't use containers because you decided to dump your state on them. Storage with containers is something that we need to solve properly (and Docker isn't doing a great job right now).
  - Annatar 10y ago
    Storage with containers is something that we need to solve properly ...Or you could just use SmartOS zones, and then all these artificial problems go away, as zones natively reside on the ZFS filesystem inside of the zpool underneath them. Why would one want to waste one's time on technology which is clearly not finished and doesn't offer any advantages over zones? As a logical being, I'm genuinely perplexed by the overall insistence on Docker. What is the cause of it?
    - cyphar 10y ago
      Here we go again. As we've discussed before, there are problems that are inherent to designing distributed systems that are not solved by SmartOS's magic sauce. Please stop pretending that every possible problem that is faced by GNU/Linux technologies has already been solved by SmartOS, it's getting quite tiresome. "Storage with containers" refers to correctly decoupling the state from your application and storing it a way that allows for horizontal scaling. It's not as simple as proclaiming "we have a magical filesystem, therefore all problems are solved and you should use SmartOS kthxbai". There are harder problems here, and no amount of SmartOS shilling will get around that.
      - Annatar 10y ago
        You completely ignored my question: what is the cause of insistence on Docker? Docker storage does not solve the scaling problem either, indeed, no known technology in existence solves it: this is one of the unsolved problems in computer science, still largely terra incognita. The only way to design for horizontal scalability is in the application, where the application keeps track of the global state across all nodes it runs on. Even if one were to use distributed storage engine like Oracle RAC with the automatic storage manager and synchronous multimaster replication, one's application would still have to contain logic about ejecting/re-integrating failed RAC nodes, as well as re-trying the transaction on a different node, and that is in addition to internal loadbalancing it would have to perform, especially if the goal is high availability with exactly zero downtime or zero loss of service at all times. As far as my "pretending", show me one problem which GNU/Linux has solved that SmartOS already hasn't. Just one. In closing, I mentioned SmartOS on purpose: perhaps someone reading this will look it up, and try it out. And perhaps they'll like it (Linux became popular the same way). What I get out of it eventually is a job market with opportunities, but most importantly, I get to sleep through the night without having to deal with idiotic problems in GNU/Linux solved anywhere from 11 to 25 years ago in SmartOS (depending on the problem). I really do not want to waste any more time on Linux, and certainly not on Docker. SmartOS can do Docker, just so you know, although it doesn't need it to provide containerization, at all, but one does have that choice. So if you really want to run Docker at all costs, which advantages does GNU/Linux offer you over SmartOS? Let's talk technology.
objectivefs 10y ago
For stateful containers that need access to a shared folder you can also use a shared file system such as GlusterFS (http://www.gluster.com http://www.gluster.com), EFS (https://aws.amazon.com https://aws.amazon.com), or ObjectiveFS (https://objectivefs.com https://objectivefs.com). This keeps your state in one location and all your containers can access it through the regular file system interface, i.e. you can start using it before you have rewritten everything to be cloud native.
- rburhum 10y ago
  Thank you. We have been using glusterfs since we found those tutorials sometime back. I wish the default "getting started with docker" tutorial included this :-/

by rburhum 10y ago

atmosx 10y ago

Well in today's world you'll handle the media folder by hosting files in the cloud (e.g. an S3 bucket). Most of the times if you use volumes, it's because of poor design[1] than anything else. [1] modern web-app design guidelines: http://12factor.net/ http://12factor.net/

ngrilly 10y ago
Well, I keep reading this, but what if you design an app that relies on local storage, for example one that uses an embedded database like SQLite, LevelDB or BoltDB? 12 factors don't address this.
- aleem 10y ago
  You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs. Building stateless containers is good practice. There will always be exceptions but it's good to know the tradeoffs before making those exceptions.
  - tokenizerrr 10y ago
    Right, and third party software is a thing. There are also plenty of reasons to prefer the simplicity of SQLite even if that means you have the task of managing your own backups.
    - vidarh 10y ago
      There are plenty of reasons to prefer that simplicity if you intend to write software meant to run on a single computer. The moment you want to deploy a service, unless the data is "mostly static" (e.g. something you might update offline and ship copies of), the simplicity that makes things like Sqlite great often ends up creating complexity.
      - tokenizerrr 10y ago
        Not everything needs to be highly available. Using docker does not mean that you are using it in a highly available environment. Plenty of things I run in docker containers can be down for a few hours every night to run backups.
  - ngrilly 10y ago
    Yes, I'm aware stateful services need redundancy, scaling and backups. That's exactly my point. 12 Factors only address stateless processes, which is the easy part. But most applications are stateful. It doesn't matter if data are stored in an embedded database (like SQLite, LevelDB, BoltDB) or in a client-server database (like PostgreSQL, MySQL, MongoDB, RabbitMQ, Redis). 12 Factors doesn't address this issue at all.
    - icebraining 10y ago
      The point of 12 Factors is to isolate the application from the data store, making it easy to manage and upgrade the former. That's important because they recognize applications are stateful. But yes, 12 Factors doesn't purport to guide people on how to manage the stateful part.
rburhum 10y ago
I am not debating whether you should or should not store files on S3. I can see use cases for both using S3 (or some alternate storage). My point is that - even in the case for django configured with S3 in this docker tutorial, there is absolutely no mention of this. The "dockerized Django" example in the documentation destroys your uploaded files every time you restart the container. Most of the "Dockerizing <whatever you want>" that I have read so far miss the maintaining state part. To me, that is overlooking an important point.
cyphar 10y ago
You're just punting on the problem. Now storage is someone else's problem, who can't use containers because you decided to dump your state on them. Storage with containers is something that we need to solve properly (and Docker isn't doing a great job right now).
- Annatar 10y ago
  Storage with containers is something that we need to solve properly ...Or you could just use SmartOS zones, and then all these artificial problems go away, as zones natively reside on the ZFS filesystem inside of the zpool underneath them. Why would one want to waste one's time on technology which is clearly not finished and doesn't offer any advantages over zones? As a logical being, I'm genuinely perplexed by the overall insistence on Docker. What is the cause of it?
  - cyphar 10y ago
    Here we go again. As we've discussed before, there are problems that are inherent to designing distributed systems that are not solved by SmartOS's magic sauce. Please stop pretending that every possible problem that is faced by GNU/Linux technologies has already been solved by SmartOS, it's getting quite tiresome. "Storage with containers" refers to correctly decoupling the state from your application and storing it a way that allows for horizontal scaling. It's not as simple as proclaiming "we have a magical filesystem, therefore all problems are solved and you should use SmartOS kthxbai". There are harder problems here, and no amount of SmartOS shilling will get around that.
    - Annatar 10y ago
      You completely ignored my question: what is the cause of insistence on Docker? Docker storage does not solve the scaling problem either, indeed, no known technology in existence solves it: this is one of the unsolved problems in computer science, still largely terra incognita. The only way to design for horizontal scalability is in the application, where the application keeps track of the global state across all nodes it runs on. Even if one were to use distributed storage engine like Oracle RAC with the automatic storage manager and synchronous multimaster replication, one's application would still have to contain logic about ejecting/re-integrating failed RAC nodes, as well as re-trying the transaction on a different node, and that is in addition to internal loadbalancing it would have to perform, especially if the goal is high availability with exactly zero downtime or zero loss of service at all times. As far as my "pretending", show me one problem which GNU/Linux has solved that SmartOS already hasn't. Just one. In closing, I mentioned SmartOS on purpose: perhaps someone reading this will look it up, and try it out. And perhaps they'll like it (Linux became popular the same way). What I get out of it eventually is a job market with opportunities, but most importantly, I get to sleep through the night without having to deal with idiotic problems in GNU/Linux solved anywhere from 11 to 25 years ago in SmartOS (depending on the problem). I really do not want to waste any more time on Linux, and certainly not on Docker. SmartOS can do Docker, just so you know, although it doesn't need it to provide containerization, at all, but one does have that choice. So if you really want to run Docker at all costs, which advantages does GNU/Linux offer you over SmartOS? Let's talk technology.

objectivefs 10y ago

For stateful containers that need access to a shared folder you can also use a shared file system such as GlusterFS (http://www.gluster.com http://www.gluster.com), EFS (https://aws.amazon.com https://aws.amazon.com), or ObjectiveFS (https://objectivefs.com https://objectivefs.com). This keeps your state in one location and all your containers can access it through the regular file system interface, i.e. you can start using it before you have rewritten everything to be cloud native.

rburhum 10y ago
Thank you. We have been using glusterfs since we found those tutorials sometime back. I wish the default "getting started with docker" tutorial included this :-/