3 ms·
> we did get a little more complicated and create a SystemD script to launch it at startup If only there was a tool to: - bundle, distribute and deploy applic
by ex_amazon_sde 5y ago
> we did get a little more complicated and create a SystemD script to launch it at startup
If only there was a tool to:
- bundle, distribute and deploy applications
- ...and configuration files
- ...and systemd unit files
- ...even directories containing a Python virtualenv
- keep track of what is installed and in what version
- roll forward or roll back
I would call it Advanced Packaging Tool.
- joecot 5y agoThis is the normal progression. A new technology comes along, and folks are so happy to use it everywhere that they teach new people to use it, without any understanding of why it's useful or what it was made to fix. And they have little to no understanding of the ecosystem that preceded it. I watched it happen with virtualization. Everyone was so hyped about virtualization that everything was run in VMs. Later there was a counterrevolution of folks going "hey, we discovered that running things on bare metal servers is a thing you can do, and it's way faster and cheaper", a push that has mostly died out now that virtualization has hit near bare metal performance anyway and cloud hosting is the norm. But that counterrevolution happened because everyone embraced VMs and cloud services without dwelling on its actual use case, or in what cases it was an improvement over bare metal hosting. I watched similar happen with both the NoSQL and Serverless revolutions, and now we're watching it with containers. So yes, this would be better setup as a deb package, or deployed as part of a cloudinit startup script or similar. But if you came in when everyone was just shoving docker down each other's throats, you don't know what stages there were before that, and which one is the most appropriate one for your use.