Re:Ask HN: Which tool(s) do you use to install/upgrade your ...
by humbledrone on Thursday June 04, 2009 @02:53PM
(#641948)
I am just finishing up something akin to what you described in your last line (for my employer). It's just a simple daemon written in Python that is told what to do via XML/HTTP. Implementing such a daemon was made much easier by using the python-apt module.
Re:Ask HN: Which tool(s) do you use to install/upgrade your ...
by ankhmoop on Thursday June 04, 2009 @04:00PM
(#642091)
Any chance of open sourcing it? It would be pretty cool to couple that with a central, authenticated server management web interface.
Re:Ask HN: Which tool(s) do you use to install/upgrade your ...
by jermy on Friday June 05, 2009 @08:27AM
(#643085)
We use an absolute minimum in terms of packaging (#) - after all, we don't need to don't need to go out of our way to make it easy to re-build. Packages are mostly C/C++ and python apps, so fortunately none of the extra issues with Java packaging.
Oh, and dependencies are great.
(#) Link has gone now, but available at http://web.archive.org/web/20060925094756/http://www.kclee.d...
Re:Ask HN: Which tool(s) do you use to install/upgrade your ...
by sunkencity on Friday June 05, 2009 @07:01AM
(#643015)
I use capistrano and in some cases i use debian packages. As the debian tools don't work on OS X. I've made a debian package tool called apt_fu that can run on any unix system. It's at github:
http://github.com/sunkencity/apt_fu/tree/master
it's really a quick hack, but it get's the job done.
I've found the dpkg method to be very effective. You can sign the packages, mirror the repositories, and set up servers to automatically upgrade some/all of the packages via cron jobs.
Packages can be automatically generated by your continual integration system, which also has the nice effect of creating a fully-trusted and centralized deployment path, making it difficult to sneak in uncommitted changes and non-managed files, etc.
The packages themselves support complex dependencies, start/stop scripts, etc, and dpkg/apt-get themselves have been ported to non-Linux platforms.
Personally, I'd still like a more comprehensive centrally managed solution based around the packaging model (ie, each server runs a management agent that can install/remove/update packages, etc).