6 ms·

Non-zero downtime deployment is supported for apps without mounted volumes: https://github.com/caprover/caprover/issues/661#issuecomment-619548552 https://githu

by zapt02 4y ago

Non-zero downtime deployment is supported for apps without mounted volumes: https://github.com/caprover/caprover/issues/661#issuecomment-619548552 https://github.com/caprover/caprover/issues/661#issuecomment... Tangentially I was looking at Render.com the other day and they also don't support zero downtime deployments if you have a mounted volume, so it's not very uncommon even on cloud platforms. As for restarts, I didn't have that problem yet, I believe CapRover adds `restart: always` to all the running containers so they should automatically boot. You might want to check out the logs of the containers that don't restart or just always hard restart the server after a Docker update.

conradfr 4y ago
I guess most of my apps have persistent data.
- smt88 4y ago
  Every useful app has persistent data. It sounds like you have a design problem, though. If you're treating application servers like cattle, then none of them should have persistent data (except caching that's disposable). There are fire-drill days that require deployments, so downtime incurred when updating your application code is unacceptable. To solve this, put your persistent data on a separate server and store it in a proper database (Postgres, for example). Postgres never needs emergency updates, so the downtime for those (infrequent) updates can be pushed to non-peak hours.
  - conradfr 4y ago
    I would maybe do all that if it was for more than side-projects that can tolerate 5-10 seconds of downtime when deployed :)
    - smt88 4y ago
      That's fine, I wouldn't tell you otherwise. You just complained about a missing feature that isn't actually missing if you use the service properly and treat servers like cattle.
      - conradfr 4y ago
        Well yes, some containers only read the persistent data so if those could have zero-downtime as there's no risk of data corruption it would be great, but that option is not offered to me.

by zapt02 4y ago

conradfr 4y ago

I guess most of my apps have persistent data.

smt88 4y ago
Every useful app has persistent data. It sounds like you have a design problem, though. If you're treating application servers like cattle, then none of them should have persistent data (except caching that's disposable). There are fire-drill days that require deployments, so downtime incurred when updating your application code is unacceptable. To solve this, put your persistent data on a separate server and store it in a proper database (Postgres, for example). Postgres never needs emergency updates, so the downtime for those (infrequent) updates can be pushed to non-peak hours.
- conradfr 4y ago
  I would maybe do all that if it was for more than side-projects that can tolerate 5-10 seconds of downtime when deployed :)
  - smt88 4y ago
    That's fine, I wouldn't tell you otherwise. You just complained about a missing feature that isn't actually missing if you use the service properly and treat servers like cattle.
    - conradfr 4y ago
      Well yes, some containers only read the persistent data so if those could have zero-downtime as there's no risk of data corruption it would be great, but that option is not offered to me.