311–320 of 347 posts
Does this setup support blue-green deploys?
No. It seems quite complicated at such a small scale to do that.
Earlier quoted context omitted.
> In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm? On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well. Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. Th…
This is wrong. Docker is a VM on Windows at least.
Earlier quoted context omitted.
Thanks for the kind words. I should update the part about the queues. I started using this pattern for SKIP LOCKED and it works well for multiple workers (search engine crawlers). https://www.2ndquadrant.com/en/blog/what-is-select-skip-lock... And implemented in Django: https://docs.djangoproject.com/en/3.1/ref/models/querysets/#...
Have you looked at django-fsm for managing your state transitions? Overkill for small projects - invaluable for larger ones where state changes can be literally anywhere.
Is that sql docker exposed to the Internet or is there another network other than ‘web’ ?
The only exposed containers are (usually) Traefik (80, 443). There is a docker network where traefik talks to all containers handling HTTP traffic.
Other containers run in their own separate docker networks.
Earlier quoted context omitted.
I'm not trying to pick on you personally here but this comment, like many I see on HN, seems overly adversarial and could have made the same arguments in a less combatative way. There's a lot of emphasis on your own perspective: "*I* don't get", "*I've* been doing that", "Not once have *I* missed Docker", "making *me* less productive", "*my* personal experience*" And an assumption that it applies to others: "Just use…
Denigrating any subjective experience because it's "too direct" is bordering on passive aggressive. Every suggested edit you've made to the comment completely alters the meaning of the text: you're basically saying that if you're not looking to learn and completely disregard the veracity of your own experience in every statement you do, you're better off not saying anything at all. It strikes me as exceedingly dishon…
That's really not what I'm trying to say at all. If I had to condense it down to one sentence it would be: "if there's a difference in opinion between two reasonable people, it's probably because you've had different experiences; you'll have a more productive discussion by finding out what they are than simply stating your opinions".
> It strikes me as exceedingly dishonest to pretend that you're genuinely interested in someone's opinion if you already know you strongly disagree with it, and it's by no means a requirement to lack an opinion to have a respectful debate. Telling someone that you believe they're wrong is not an insult.
If you're not interested in somebody's opinion, what value could there possibly be in having a discussion with them?
Earlier quoted context omitted.
Putting them in the same container means I have to manage the processes myself with something like supervisord. A docker-compose file makes this trivial because it is just a matter of a few lines of YAML that link the services together. It also means I can ship updates to my application and restart it without touching the rock-solid Postgres image.
What do you mean by "manage the processes"? Why would you need to touch postgres when updating your application?
If you put both processes in the same container, then you cannot simply upload a new image and restart the container. This is where it gets very complicated, error prone, and not in line with what I understand to be current best practices with docker.
Earlier quoted context omitted.
No. It seems quite complicated at such a small scale to do that.
Maybe I am using the wrong terminology, but I am interested in whether this provides for zero-downtime deploys with health/readiness checks and rollbacks. This enables safe and non-disruptive deploys. It is a common feature of many software platforms.
In my case I just take the 5-10 second downtime in between container restarts.
Earlier quoted context omitted.
I'm not trying to pick on you personally here but this comment, like many I see on HN, seems overly adversarial and could have made the same arguments in a less combatative way. There's a lot of emphasis on your own perspective: "*I* don't get", "*I've* been doing that", "Not once have *I* missed Docker", "making *me* less productive", "*my* personal experience*" And an assumption that it applies to others: "Just use…
I understand your concern and agree that I am being extremely direct. It's not out of spite. On the one hand, it comes from my frustration with what I as an engineer perceive to be wrong advice. It feels to me like OP is using Docker because he read a blog post about it somewhere, never seriously thought about alternatives, then stuck with it and now recommends it to others, repeating a cycle where software gets wors…
And being direct isn't a bad thing either, my point here wasn't "don't be direct or concise, you'll offend people" but "assuming everyone here is reasonable, disagreements are likely due to differences in experience and you'll have a more productive discussion by figuring out the differences than simply stating opinions".
How do you do websockets?