3 ms·

How does one perform deployments with go+sqlite? With a client-server database such as postgres your app and database are on separate servers, and you can perfo

by leg100 4y ago

How does one perform deployments with go+sqlite? With a client-server database such as postgres your app and database are on separate servers, and you can perform a blue-green, canary, etc, deployment of the app, spinning up new servers running the new version alongside the servers running the old version, before shutting down the servers running the old version. But with sqlite you'd have to perform a hot-upgrade, surely? i.e. shut down the old version and quickly fire up the new version, with a small window of downtime in between. Note: I see Litestream/LiteFS allows distributed deployment (both in beta).

markusw 4y ago
Essentially yes, with a single SQLite instance, you have a small window of downtime on every deploy. But depending on your setup, that window could be very small, and unnoticeable if you have something in front that just delays incoming requests (like fly.io does with a load balancer in front of that single instance). And yes, LiteFS just selects a new leader and does a rolling deploy (or whatever else you want).
- ngrilly 4y ago
  Another, more hacky option, would be to teach the binary executable how to download a new version, and start it to replace itself, while staying in the same container. Nginx does this for example. Of course, that’s some additional complexity, but then it is possible to have zero downtime upgrades (by basically upgrading the executable in the container but not the container itself). It is also possible, and simpler to upgrade the container, if it’s possible for different containers to share the same volume, but I don’t think this is possible on Fly.io.
  - markusw 4y ago
    I believe systemd can do something similar, essentially replacing the binary and queueing network calls while doing so.
    - ngrilly 4y ago
      Yes, systemd does that. But as you wrote, it will queue network calls. The nice thing with the method I suggest above is that both Go processes, the old one and the new one, can be both serving requests in parallel, as they can share the same SQLite file, which makes it really zero-downtime.

by leg100 4y ago

markusw 4y ago

Essentially yes, with a single SQLite instance, you have a small window of downtime on every deploy. But depending on your setup, that window could be very small, and unnoticeable if you have something in front that just delays incoming requests (like fly.io does with a load balancer in front of that single instance). And yes, LiteFS just selects a new leader and does a rolling deploy (or whatever else you want).

ngrilly 4y ago
Another, more hacky option, would be to teach the binary executable how to download a new version, and start it to replace itself, while staying in the same container. Nginx does this for example. Of course, that’s some additional complexity, but then it is possible to have zero downtime upgrades (by basically upgrading the executable in the container but not the container itself). It is also possible, and simpler to upgrade the container, if it’s possible for different containers to share the same volume, but I don’t think this is possible on Fly.io.
- markusw 4y ago
  I believe systemd can do something similar, essentially replacing the binary and queueing network calls while doing so.
  - ngrilly 4y ago
    Yes, systemd does that. But as you wrote, it will queue network calls. The nice thing with the method I suggest above is that both Go processes, the old one and the new one, can be both serving requests in parallel, as they can share the same SQLite file, which makes it really zero-downtime.