Ask HN: How do you document server installs | Hacker News Reader

Ask HN: How do you document server installs

2 pointstonteldoos1 comment

Good day HN,

I'm sure everyone here has set up many servers (or VPSs, VMs, etc) over the course of their work and/or side-projects/hobbies/personal rigs. I do a little bit of both, and am struggling to find a consistent way to log or document the whole process.

What do you use to document these setups, specifically:

  * Versions of installed packages / method of installation
  * Config file changes
  * Setup commands/scripts run
  * Deployment commands
  * Custom scripts/changes
  * Order of changes
  * Information from vendors/maintainers covering niche cases/installation issues

Especially if it's a non-trivial setup (or the first time you're doing it), how do you keep track of what the final working approach was, the order of installation, etc?

Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it's not a comprehensive solution, and possibly error-prone.

Bonus points if your system has a way to easily redo all the work you've done (puppet, chef?).

Thanks!

> Typically, I use a wiki with lots of links, and copies of any custom scripts I made, but it's not a comprehensive solution, and possibly error-prone.

I've done the same for far too many projects, both existing and green field, and always ran into the same issues:

- manual sync (even if reporting is scripted) of every detail, info always ends up stale and often causes more issues from someone inevitably following it as a reference.

- additional overhead and maintenance, tied closely to the point above.

- stale / unaccessible links (file server accounts, etc...)

- change history and supporting multiple versions / environments in parallel

I've come to the personal conclusion that it's easier and faster to bite the bullet and spend the time on your build and deployment steps, with the points you listed in mind.

With a Jenkins server, you could create a project that simply watches your current build directory and creates a new Build with its own Version Number, and a single archive as a Build Artifact containing your changes, including the current versions of your config files, required packages, setup scripts, and possibly a current snapshot of any relevant documentation.

This gives you visibility of exactly what was contained and possibly run (if your setup/update is scripted) for each deployment / update you perform.

You can build on this over time until it contains all the info you require about a particular snapshot of your stack.

Next, you can build a list of your servers (and environments) and track which Build from Jenkins you've installed to each.

(I believe Jenkins has plugins for that, but could be tracked elsewhere)

Reply on news.ycombinator.com