4 ms·

We use puppet for configuration that varies between systems, but otherwise bundle our software as debian packages so just need to run 'apt-get dist-upgrade' per

by jermy 17y ago

We use puppet for configuration that varies between systems, but otherwise bundle our software as debian packages so just need to run 'apt-get dist-upgrade' per machine. Separate private repositories for testing/staging/production sets of the packages.

justinweiss 17y ago
We use puppet for managing packages and configuration on our systems. At some point I'd like to take a look at Chef, too -- having Ruby as the configuration language seems like it'd be nicer than puppet's config file format. It took some work to get set up, but it's so nice being able to keep track of what's on each machine in version controlled source files. For actually deploying our code, we use Capistrano, which we also use to run one-off tasks across machines. This pulls from our code repsitory, and each of our dev/staging/production environments know which version control branch to pull and deploy in that environment.
ankhmoop 17y ago
What do you use to produce dpkgs? In addition to the cumbersome standard tools, I'm only aware of jpkg (http://code.google.com/p/jpkg-library/ http://code.google.com/p/jpkg-library/) for Java. 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).
- humbledrone 17y ago
  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.
  - ankhmoop 17y ago
    Any chance of open sourcing it? It would be pretty cool to couple that with a central, authenticated server management web interface.
- sunkencity 17y ago
  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 http://github.com/sunkencity/apt_fu/tree/master it's really a quick hack, but it get's the job done.
  - deleted 17y ago
    [deleted]
  - ankhmoop 17y ago
    You can install apt-get and dpkg on Mac OS X via MacPorts (but apt_fu looks quite a bit nicer than using the dpkg tools).
- jermy 17y ago
  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.de/clemens/unix/HowToCreateYourOwnDebianPackage.html http://web.archive.org/web/20060925094756/http://www.kclee.d...

by jermy 17y ago

justinweiss 17y ago

We use puppet for managing packages and configuration on our systems. At some point I'd like to take a look at Chef, too -- having Ruby as the configuration language seems like it'd be nicer than puppet's config file format. It took some work to get set up, but it's so nice being able to keep track of what's on each machine in version controlled source files. For actually deploying our code, we use Capistrano, which we also use to run one-off tasks across machines. This pulls from our code repsitory, and each of our dev/staging/production environments know which version control branch to pull and deploy in that environment.

ankhmoop 17y ago

What do you use to produce dpkgs? In addition to the cumbersome standard tools, I'm only aware of jpkg (http://code.google.com/p/jpkg-library/ http://code.google.com/p/jpkg-library/) for Java. 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).

humbledrone 17y ago
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.
- ankhmoop 17y ago
  Any chance of open sourcing it? It would be pretty cool to couple that with a central, authenticated server management web interface.
sunkencity 17y ago
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 http://github.com/sunkencity/apt_fu/tree/master it's really a quick hack, but it get's the job done.
- deleted 17y ago
  [deleted]
- ankhmoop 17y ago
  You can install apt-get and dpkg on Mac OS X via MacPorts (but apt_fu looks quite a bit nicer than using the dpkg tools).
jermy 17y ago
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.de/clemens/unix/HowToCreateYourOwnDebianPackage.html http://web.archive.org/web/20060925094756/http://www.kclee.d...