Would you consider that to be a big enough risk to not deploy production apps in their environment? I.e. having your app on 1 droplet and a dedicated db on another. I'm new to ops and trying to learn all that I can :)
I do this in prod, you just need to take extra steps to protect. i.e. make a firewall rule on the database to only allow access to the database port on your private network card, from your specific web IPs (and make sure the traffic is encrypted).
In your Procfile you can have any type of process you want. The "web" process type is just special because it expects you to open an listening tcp socket on the port it provides in their environmental variable to your app. Aside from that you could say have a worker process, emailer process, etc and scale them independently.
> flares where people wish people involved in systemd would be run over by a bus or just accusations of incompetence.
Wow, these are really contrasting examples.
This HN thread is really focusing on the first category but I who haven't been following any of this actually had the impression that the 2nd category (incompetence) was right on the money regarding the recent bugs I've seen in my Debian installation.
I've used Debian since 2000 or so (slink was the first release I installed). I don't know if this problem is Debian or upstream. But ever since systemd became the default, my machine displays "Segmentation fault" at every boot, boots slower than before, and my previously working bluetooth pairings broke. Even when Debian was inserting extra memset()s into OpenSSL, I've never seen it this bad. It really doesn't feel like the system it used to be and I'm about to give up on it.
Can you context this up for us? Are you running the unstable testing branch and complaining about bugs? (If so, have you filed these bugs with anyone?) Or has your Debian system somehow gotten more buggy since they announced that systemd would be the default init system of the version of Debian that ISN'T OUT YET?
> Are you running the unstable testing branch and complaining about bugs?
Yeah I'm running testing. I have been running either testing or unstable on personal machines on a rolling basis since slink (released 1999) and I have experienced breakage of various sorts over the years, but nothing as fucked up as when the switch to systemd happened.
> (If so, have you filed these bugs with anyone?)
Sorry I don't have a lot of time for this. Usually when I have seen really bad issues running sid I just wait for them to get resolved after the next dist-upgrade or two. And that usually works well enough. Not this time though.
This is actually a common way that a lot of people run debian, or at least used to be last I checked. Often if you don't do this you get an old kernel version that doesn't work with the latest hardware. (I've built machines, put Debian stable on them, and the SATA controller is completely unrecognized, whereas unstable works.) I have been running Debian this way for a long time without any major complaints. For something as critical as boot, typically my expectations established by years of use is they don't fuck it up this badly, don't merge in piece of shit software and make everything else depend on it. That expectation was broken egregiously for the first time ever for me, during a period of ~15 years of use. I am not exaggerating when I say I have been a Debian fan for a long time and I really question where the quality is going.
But OK, you and others are entitled to think I'm being capricious and haven't thought it out.