What's your habitat workflow, how are you testing template data? plus a few more :)

Habitat Help
1

Hello Everyone

@bixu from the slack channel suggested that I post my questions here.

:wave: I'm only getting started within habitat (sorry for being a bit late to the party :slight_smile: I've being getting to know habitat by build a concourse cluster, being a 3 tier arch its been good fun getting it up and running using binds, so I'm nearly at the end of that experiment now (in that I have it working). I've had to learn how to do things in certain way which I wanted to share but also find out how other people where developing apps in habitat. I plan on writing it up, maybe for a blog post or something or just serve as a reminder for me in the future. :slight_smile:

  • Template Data
    The docs have a great break down of what's there but I wondered if there was a was I could walk around what was available and look at their values. for example in studio, can I do something like puts {{sys.ip}} or would I need to pry within the init hook to have a look around? outside studio I can see there's a hab sup bash not sure when I would need that but within that can I see for example {{sys.member_id}}

  • Packaging workflow
    There was a lot of trial and error packaging up concourse, errors in my init or run hooks, syntax errors with my handle bar logic or missing binary arguments etc, whilst within studio it would build, I wasn't able to start the package I built so with each iteration I was having to building a new package,
    hab pkg build . -R
    hab pkg install results/root-concourse-version-buildnumber*.hart ,
    hab svc unload root/concourse-worker
    hab svc load root/concourse-worker/version/buildnumber --bind web:concourse-web.default
    check the terminal running the supervisor and see the error and back in studio and iterate again. So is there a better way?

  • Logs
    How do I see the supervisor logs if I start habitat as a service? when does running sup-log work?

  • Hab starting a hart file
    Did you used to be able to run hab start results/root-concourse-v*-build*.hart ? as I found a few examples where they say to do this but hab start only worked for me after I installed the pkg and then loaded the svc first.

  • Un-binlink
    How do you un-binlink a package? sorry if I'm being a doughnut I could binlink fine but for some reason I couldn't see how to remove that when I wanted to binlink a newer version of the same package.

  • /hab/svc/ wasteland
    /hab/svc/ wasn't removed when I unloaded the service or later uninstall the pkg, which is fine but is that down to me to tidy up? ( I made a mess with my versions lol)

I think that's it for me, I did have hab analytics enabled, so you might get a few interesting results back :slight_smile:

Thanks again for a great product, exciting times

Best Regards

Gary

2

Re: template data, I like to just put an extra template in my config directory while developing:

cfg.json:

{{toJson cfg}}

Re: your dev lifecycle, use hab studio enter and you can reuse the environment between builds. Packages built in a studio are already installed in it so you can skip the install step then, and use the supervisor within the studio to test it

Re: logging, sup-log is a shortcut within studios. Outside that, logs are written to the supervisor processes STDOUT. That generally means they’re just in your terminal output if you’re running the supervisor manually, or in /var/log/syslog if you’re using the sample startup script (your startup system would handle logging)

Re: binlinks, if you just want to update them you can use --force, otherwise you just have to delete them

3

For testing templates, you might want to take a look at the relatively new hab plan render command and some examples at https://github.com/habitat-sh/habitat/blob/master/test/fixtures/render/README.md.

4

@baumanj:

Ha, It's like my brain is that tree and you're those little cookie elves. I was going to provide that exact link. :smiley:

@username-is-already:

Couple of things to point out: that README was written in the context of developing Habitat, you don't need the cargo run -p bits, hab plan render is sufficient.

Second, as this is really just rendering the template, you'll have to supply any "habitat supervisor" variables. E.g.: if you're leveraging {{ svc.members }} you'll need to mock that out in your json file supplied with --mock-data. Have a look here for an example.

My thinking was you could create an override.json and have some InSpec tests that could test and validate your config looks as you'd expect. Which could then be run through your CI pipeline.

I would love any feedback, what did you love? what did you hate? about rendering templates with hab plan render, etc.