For the habitat client, we have traditionally used this install.sh - it works great when you have internet connectivity - sucks when you don’t.
I thought possibly it’s time to create an on-prem bldr to support totally offline clients. Then I started to read what it takes to get an on-prem bldr in place. I noticed that the docs require us to have an initial access to the internet.
I’d like to know if it is possible to already have these files loaded on to the server and if those certain artifacts exists, the on-prem builder can do its thing.
Note: assume all the artifacts we need to get can be sneaker-netted over (ie usb drive/floppies/disk/etc.)
It’s not too well documented in the readme, but the on-prem-archive.sh script includes functionality for downloading the archive of packages as a single tarball and then using a tarball on the local filesystem to populate the depot.
For installing the hab client, I keep a copy of it (any version) on a file server and run this script to install:
Hrmm. I think this solves my problem once I get on-prem bldr up, but it will be empty. So I shouuld use this on-prem-archive.sh script to get the harts and push them into my on-prem.
I’ll have to play around with the on-prem installer.
What might be ideal is if there was a Docker Image of the on-prem bldr that I can stand up…
There’s definitely no good story for installing core/hab with no on-prem depot available (i.e. while bootstrapping the depot).
The on-prem builder is made up of 7 independent services. You can export these each to containers and set them up by hand using the provision.sh script as a starting point. I’ve done a little playing with running the depot under kubernetes and it’s worked well (but with me as the only client, so YMMV)
One of my infrastructure obstacles is that we have all bare metal with no virtualization. I also have few of those machines. Hence my motivation for packing more services other than Hab Bldr on to one host.