Reverse engineer your server with blueprint

A few days ago I had an interesting discussion with one of my colleagues. The discussion was about how to apply installed packages, services and source installations of a debian based dev-server to a new “plain” server. He pointed out that I may want to use blueprint for this task. To cut a long story short, as I like to automate things I decided to give it a try and I hadn’t been disappointed.

Anyway, before I start describing the reverse engineer process with blueprint itself I just want to make clear that it’s strongly recommended that both servers (source and target server) have the same linux distribution installed and are both up to date! This is very important as blueprint determines the exact version of each installed package on the source server. On the target server blueprint finally uses the platform dependent package manager to install exact the same version as determined on the source server. If you have for example out dated packages on your source server blueprint will not be able to install them on the target server as they are not available anymore over the package manager. Now you are warned 🙂 so let’s go!

Install blueprint

I did the following to install blueprint on my Ubuntu 14.04 dev-server:

root@test-host: apt-get install git
root@test-host: git clone git://github.com/devstructure/blueprint.git
root@test-host: cd blueprint
root@test-host: git submodule update ––init
root@test-host: make && make install

Reverse engineer the system with blueprint

It is possible to reverse engineer the whole system with one simple command:

edi@test-host: blueprint create test-server

By executing the above command blueprint will collect information about all installed packages. In addition it will determine which configuration files in /etc have been added or modified from their packaged version and collect files in /user/local as well (that are part of any software packages installed from source). Finally, it will build a list of conditions under which services should be restarted, including package upgrades and configuration changes.

Inspect the created blueprint

As stated in the tool documentation the output of blueprint create is of type JSON and can be inspected with one of the following commands:

edi@test-host: blueprint show test-server | less
edi@test-host: blueprint show-files test-server | less
edi@test-host: blueprint show-packages test-server | less
edi@test-host: blueprint show-services test-server | less
edi@test-host: blueprint show-sources test-server | less

Perform blueprint fine tuning

While inspecting the blueprint output you may want to exclude certain files, packages, services or sources from the blueprint. As stated in the blueprint documentation you have two different possibilities. You can add certain files, packages and/or services to blueprint ignore or you define rule files. Me personally I started with blueprint ignore and ended up with rules files as I felt I have much more control over the whole reverse engineering process.

Prepare the blueprint

Finally you can prepare the blueprint to be transferred to your target server:

edi@test-host: blueprint show -S test-server

The above command will at least create a shell script “test-server.sh” in your local working directory. Anyway sometimes blueprint needs more than that to be able to reverse engineer your system configuration (e.g. if some source tarballs need to be installed manually). In this case a separate folder “/test-server” that includes everything necessary is created.

Apply to blueprint

Transfer the file(s) created in last step to your target server and execute “test-server.sh”. Done.

Comments are closed.