3 ms·

The author's reaction to "we've decided to try and simplify deployment of our hideously complex app" is to ignore the supported deployment, bury themselves neck

The author's reaction to "we've decided to try and simplify deployment of our hideously complex app" is to ignore the supported deployment, bury themselves neck deep in the guts of the complex deployment the devs worked to abstract away, and then rage about it. I'm not really seeing "server software deployment could be better" as a fair read of that.

jodrellblank 11y ago
His point is not "I don't know how to deploy a Rails app", it's "there is no standard way for a server program to tell the OS how what services to configure, or to query the OS for what services are available. Instead of fixing this, we wrap a pre-configured-OS-image and run it inside our OS. This is daft". As well as "the instructions are incorrect and incomplete, and that's normal". e.g. Set aside the oddball tool breakage and consider that if you follow the instructions to the letter, this web forum requires: cloning (not installing!) the software’s source code and modifying it in-place. Copy-pasting hundreds of lines of configuration into nginx, as root, and hoping it doesn’t change when you upgrade. Installing non-default Postgres extensions, as root. Running someone else’s arbitrary database commands as a superuser. and You’d think that a web app could just have some metadata saying “I need Postgres and, optionally, Redis”, but this doesn’t exist. And the other side, where the system can enumerate the services it has available for a user, similarly doesn’t exist. So there’s no chance of discovery. If you’re missing a service the app needs but failed to document, or you set it up wrong, you’ll just find out on the first request. and "What we should have by now" section. and And I’m really not picking on Ruby, or Rails, or this particular app. I hate deploying my own web software, because there are so many parts all over the system that only barely know about each other, but if any of them fail then the whole shebang stops working.
- krisdol 11y ago
  Service discovery, orchestration, and on-the-fly config/environment changes are things that are solved by tools like consul and mesos (to scratch the surface). The ops world is so much more than just dockerfiles. There is absolutely a "chance of discovery". Using consul has helped us move to zero-configuration, discoverable microservices. Then for the more hobbyist stuff, there's docker-compose. Not looking into the options and ranting is not the same as there not being any options.
csirac2 11y ago
If you're lucky enough to run in a production environment that has zero configuration policy or minimum security requirements, then yes, granting your webapp superuser privs to the database mightn't be a deal-breaker. For everyone else, it's giant shit sandwich, and a constant reminder that the project couldn't arsed untangling their own weird idiosyncrasies from their distributed app, and that this crap wouldn't fly with a traditional distro package, or wouldn't have mattered with the more traditional tarball/REQUIREMENTS/INSTALL.txt that made way fewer assumptions about the end-user's environment. I love docker, but it's letting people get away with murder.

jodrellblank 11y ago

His point is not "I don't know how to deploy a Rails app", it's "there is no standard way for a server program to tell the OS how what services to configure, or to query the OS for what services are available. Instead of fixing this, we wrap a pre-configured-OS-image and run it inside our OS. This is daft". As well as "the instructions are incorrect and incomplete, and that's normal". e.g. Set aside the oddball tool breakage and consider that if you follow the instructions to the letter, this web forum requires: cloning (not installing!) the software’s source code and modifying it in-place. Copy-pasting hundreds of lines of configuration into nginx, as root, and hoping it doesn’t change when you upgrade. Installing non-default Postgres extensions, as root. Running someone else’s arbitrary database commands as a superuser. and You’d think that a web app could just have some metadata saying “I need Postgres and, optionally, Redis”, but this doesn’t exist. And the other side, where the system can enumerate the services it has available for a user, similarly doesn’t exist. So there’s no chance of discovery. If you’re missing a service the app needs but failed to document, or you set it up wrong, you’ll just find out on the first request. and "What we should have by now" section. and And I’m really not picking on Ruby, or Rails, or this particular app. I hate deploying my own web software, because there are so many parts all over the system that only barely know about each other, but if any of them fail then the whole shebang stops working.

krisdol 11y ago
Service discovery, orchestration, and on-the-fly config/environment changes are things that are solved by tools like consul and mesos (to scratch the surface). The ops world is so much more than just dockerfiles. There is absolutely a "chance of discovery". Using consul has helped us move to zero-configuration, discoverable microservices. Then for the more hobbyist stuff, there's docker-compose. Not looking into the options and ranting is not the same as there not being any options.

csirac2 11y ago

If you're lucky enough to run in a production environment that has zero configuration policy or minimum security requirements, then yes, granting your webapp superuser privs to the database mightn't be a deal-breaker. For everyone else, it's giant shit sandwich, and a constant reminder that the project couldn't arsed untangling their own weird idiosyncrasies from their distributed app, and that this crap wouldn't fly with a traditional distro package, or wouldn't have mattered with the more traditional tarball/REQUIREMENTS/INSTALL.txt that made way fewer assumptions about the end-user's environment. I love docker, but it's letting people get away with murder.