3 ms·
I once built a whole deployment system out of packaging all our services as Debian packages and running them out of our own apt repo. Once we got it working, th
by IgorPartola 6y ago
I once built a whole deployment system out of packaging all our services as Debian packages and running them out of our own apt repo. Once we got it working, this was a really low maintenance system and bringing new servers online was stupid easy.
Since then Debian packages have become easier to create and maintain. And it’s a great skill if you ever need to create e.g. a custom-compiled version of nginx or some such. It’s a really well thought out system and I am surprised it isn’t more widely used. By contrast Docker seems to be more portable but way more of a pain in the ass.
- koolba 6y agoBeing able to uninstall something with more than file is enough reason for deb packaging for end user software. Server software isn’t as relevant as the shift to containerized work loads as made server configurations “build once and toss”.
- IgorPartola 6y agoI find that using it on the server is super nice. If you are using Ubuntu on the server anyways, why bother packaging a Docker service for anything else?
- dimator 6y agoWhat do you recommend for learning that stuff?
- IgorPartola 6y agoI wish I could recommend something but I learned it years ago and I honestly don’t remember where from. I’ll try to put together a modern version of my old LUG talk on the subject to show people how to get started.
- ivan_ah 6y agoYes plz. I'd be very interested to read about this (long time Debian user, but never packaged anything). I know there is an install, postinstall, and remove scripts but don't have a clear idea of when exactly they will get called and what "interface" they must implement. It would be really helpful to have a "package lifecycle" state diagram like this https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram https://vuejs.org/v2/guide/instance.html#Lifecycle-Diagram that shows all the states and events that "fire" based on .deb scripts and metadata.
- paxswill 6y agoLike this? https://www.debian.org/doc/debian-policy/ap-flowcharts.html https://www.debian.org/doc/debian-policy/ap-flowcharts.html I skimmed the New Maintainers Guide for a rough idea of what to do and then used the Debian Policy Manual with the various debhelper manpages for specific references of what each field/script meant. I also dig into the source of some packages to see how they were packaged (for example, when I was creating an archive keyring). The two areas I had the most trouble with were deb triggers and debconf, which only seem to be documented on external sites. New Maintainers’ Guide: https://www.debian.org/doc/manuals/maint-guide/ https://www.debian.org/doc/manuals/maint-guide/
- jstsch 6y agoYeah, same here. It’s really nice to be able to spin up a clean Ubuntu VM on any provider, and just adding your repo, key and being an apt install away from deployment. Makes it super easy for us to deploy dedicated instances for Enterprise customers as well - no exotic dependencies and no problem if they want on prem or wherever else.
- gjulianm 6y agoI'm helping with building that part at my current job and the main problem that I'm finding is that the documentation is not good at all. There's a lot of trial and error, outdated documentation and such that makes it hard to get started. I do agree that once it's setup properly with a CI pipeline, it becomes a breeze to install and maintain updated systems.
- IgorPartola 6y agoYeah I remember the Debian docs being a little obscure. And debhelper is only so helpful.