Blueprint best practices

[Eric]

Hi Folks,

I'm starting with blueprint and would like to hear from more experienced users what  practices/patterns are often used. For example, what kind of system files do you usually include or exclude in our blueprints? 

Maybe we can make this thread work as a cookbook, what do you think?

Cheers,

Eric

[Mister Guru]

I support this idea - I'd like to make some exclude blueprints for the default installs of certain platforms. For examples, if I install ubuntu 12.10, the second I get to the first ssh prompt, I want everything installed up to that point to be excluded.

I'm fresh to blueprint I might add, but the way I'm thinking about doing that, is to take a snap shot, and then install my stack, then take another snapshot, and work on the diff.

It seems a bit much, so some community excludes would be great :)

Thanks

[Richard Crowley]

> I support this idea - I'd like to make some exclude blueprints for the
> default installs of certain platforms. For examples, if I install ubuntu
> 12.10, the second I get to the first ssh prompt, I want everything installed
> up to that point to be excluded.
>
> I'm fresh to blueprint I might add, but the way I'm thinking about doing
> that, is to take a snap shot, and then install my stack, then take another
> snapshot, and work on the diff.
>
> It seems a bit much, so some community excludes would be great :)
>
> Thanks

I have considered before a frontend that would produce ignore files
from blueprints. Seems like that would fit your workflow really well.

[Eric]

Hi Guys,

Despite the fact I'm still a "newbie" with blueprint, after a lot of trial and errors, I believe I've learned the "right way" to deploy packages with blueprint. So here goes my 2 cents for our cookbook. Since I use Ubuntu my contribution assume apt as the package manager, but the principle is the same for non debian based distros.

Include external repositories using files resources

To Include external repositories you should add the appropriated reference in /etc/apt/sources.list.d/<repository>.list file and then drop the public key into /etc/apt/trusted.gpg.d/<repository>.gpg file. The trick here is that file that goes into the trusted.gpg.d directory is a keyring file, but usually what you have is a public key declaration. In this case you can produce the keyring file with gpg with a command like this: 

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg.d/some_repository.gpg --import /tmp/some_repository.key

After this you can include /etc/apt/sources.list.d/* and /etc/apt/trusted.gpg.d/* in your blueprints and install your packages normally via :packages resource.

Avoid deploying packages as sources

Sometimes we need 3rd part software that are only available as deb or tar.gz packages. At first I was manually installing them and later including them in my blueprints using the :source resource. This produced some huge git repository that leads to some git out-of-memory errors and also made it harder to be pushed to my blueprint server. Instead of doing so, prefer to create your own repository (eg. setup your own PPA repository in Launchpad), and repack everything publishing them in your repository so blueprint can manage it as a :package instead of :source.

Cheers,

Eric

[Mister Guru]

Hi Eric - Thanks for your reply, but blueprint isn't going to be my
deploy weapon of choice. It's a tool that I am considering to write
into a work flow for documenting, and also implementing some sort of
change management to the ever increasing number of software stacks
that are in use today.

I plan on using puppet to deploy and configure my end points, and I'd
like to use blueprint as a quick way to document the different
software stacks that we have, and help to provide a more agile testing
environment.

Picture this:
I get an email with a IP address, a username and a password, and I'm
told, hey we just bought this new website/company and now we need ten
more. Can we have them by Friday, preferably in our flashy new cloud
system please?

Or my favourite
You know that project that we outsourced? Well, those web guys
vanished, and no one knows how their server works - Can you fix it, by
lunch?

Now we all know that I can forget about getting any documentation any
time soon - so I need to reverse engineer this baby, and apply it's
configuration to machines that I do know well - So I'd like to use
blueprint to pull that configuration so that I can deploy it the same
way on a nicely managed system - I'm guessing that this isn't really
the main aim of blueprint, but it sure as hell has been helping me in
this way, so I'm trying to take the time to see how i can get it to
fit my needs.......

... Discuss :)

[Eric]

Hi there MrGuru,

I'm not directly involved with the development of Blueprint, therefore I can't speak about they're vision and goals of Blueprint. Anyhow I believe that great tools doesn't fit a single purpose, bit it sounds to me that BP is a great choice for you case. Not only it does provide a reverse engineering of running systems but it can output it's outcome in several formats, puppet included.

It seems to me that BP, as it is now, may not fully attend your needs in some cases, due to some premise it has that may reduce it's applicability for "all and every" case you may come up (for example, your system must be either debian based or an rpm based, some directory structures are assumed and so on). On the other hand I don't know of any other tool that does what BP and even if it's does not fully attend you, it will certainly bring a time-saving to your to start.

That being said, some best practices may still apply even in cases where you are using BP just as a documentation tool, so please, feel free to share your findings with us.

Best regards,

Eric

On Monday, September 24, 2012 12:41:46 PM UTC-3, Mister Guru wrote: