how do you handle no downtime deployments?
how do you backup data?
I rather would use kompose+kustomize to convert it to k8s and than use k3s with ingress-nginx with hostPath and backup local volumes with velero.
I rather would use kompose+kustomize to convert it to k8s and than use k3s with ingress-nginx with hostPath and backup local volumes with velero.
I take the few second downtime hit on each deploy. I know, it's iNsAniTy but it's really not. A 5 second blip a few times a week is no biggie for most SAAS apps or services.
To me that's well worth the trade offs of not having to deal with a load balancer, a container orchestrator tool, dealing with database migrations that need to be compatible for 2 versions of your app as it's being rolling restart and all of the other fun complexities of running a zero down time service.
You can still architect your app in a flexible way (env vars, keeping your web servers stateless, uploading user content to S3 or another object store, etc.) so that moving to something like Kubernetes is less painful if / when the time comes. It's just for me, that time has never come.
> how do you backup data?
A background job / cron job runs every few hours and does a pg_dump to a directory in a block storage device. Could easily change that to be S3 too. Just comes down to preference. Personally I found it easier to drop it into block storage since it's just copying the file to a directory.
Backups? You only need backups or the Db, and that have zero impact in the use of docker or not*
*ie: I know what very complex setups the micro-service crow use for serve their smalls-size disruptive app. I still think cron + pg_dump + rsync is more than enough...
No downtime deployments: I don’t bother for these projects. A minute of downtime in off-peak hours for a restart is fine.
Data backup: just like you would backup any other local data: cron, rsync, pg_dump. And there isn’t much local data anyway as most services are stateless, using S3 or a database for long term storage.
I choose docker compose for production when I want to keep complexity to a minimum: All I need is a cloud vm, an ansible playbook to install docker and configure backups. Typically in these scenarios I run the database as an OS service and only use docker for nginx/redis and application services.
Using it in docker would allow easier local development, and shorter setup time.
For production some of these projects run alongside each other on the same host and share the database service. Sometimes the database is on another host.
A typical host like this would be a 50/month Hetzner dedicated machine with only docker daemon and postgres installed natively. And then multiple projects deployed with docker compose. Sometimes nginx is native as well with vhosts pointing to the docker projects.
Edit: s/ghosts/vhosts/
Ex:
- blue/green stateless nodes
- DNS/load balancer pointer flips
- Do the DB as a managed saas in the cloud and only ^^^ for app servers
- Backups: We've been simply syncing (rsync, pg_dump, ..) w/ basic backup testing as part of our launch flow (stressed as part of blue/green flow), and cloud services automate blob backups. We're moving to DBaaS for doing that better, which involves taking the DB out of our app for our SaaS users
In practice, our service availability has been largely degraded by external infra factors, like Azure's DNS going down, than by not using k8s/swarms for internal infra. Likewise, our own logic bugs causing QoS issues that don't show up in our 9's reports.
It doesn't seem you bothered looking into alternatives.
Take for example docker swarm. It already uses docker compose files (well, there are some differences) , they support blue-green deployments of stacks, and they even support multi-node deployments and horizontal scaling.
you'd rather use six complex things instead of one simple one?
> we do not care about no downtime or stateless nodes and a lb in front
and b:
> backup with the standard tooling or stateless nodes
so basically they just use it mostly to "package" the application and everything else is probably done with different tooling.
By that measuring stick, using Docker Swarm instead of docker compose is even simpler as you only need to use docker alone instead of having to install a separate script.
It's common to have a load balancer, that routes traffic to nodes that are up.
That part is mostly straightforward. It could be the application's responsibility or the load balancer's. The tricky bit is maintenance on the load balancing parts.
Very modern stack but totally overengineered.
Things are way simpler with Docker Swarm. You just run a single ingress controller as a separate stack and route all traffic internally.
If you use Traefik as your ingress controller, all you need to do is set labels in your docker compose files and everything just works.
There is absolutely no reason or excuse to use docker compose in anything resembling production.
I work at a university where I make an app meant for maybe a couple of concurrent researchers. Am I seriously supposed to set up Docker Swarm for this or is it OK with you if I run my little setup using Docker-compose on the tiny server that the university has provisioned for me?
Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences.
I agree generally, but playing devil's advocate for GP, what I think they meant is that swarm can be run on a single node with little downside/complexity and a lot of upside from docker compose.
See for example:
https://jarredkenny.com/single-node-docker-swarm/
https://devopstuto-docker.readthedocs.io/en/latest/docker_sw...
Manage deployments as stacks, which support history and backtrack deployments.
Blue-green deployments.
Frankly, it boggles the mind how people put to production devtools that are barely managed to be secure when deployed locally, when alternatives are both simpler to deploy and more capable.
I'm sure you're great at setting up servers. That is probably the part of my job I dislike the most, but it's something I have to do, so I do it.
https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/