Subject: Lightening my cloud automation via tiny-cloud

From: "Daniel F. Dickinson" <[email-masked]>
Date: Sun, 3 Jul 2022 00:58:59 -0400

Hi all,

TL;DR I'm starting an 'experiment' with 'less is more' automation via
tiny-cloud and **no** Packer or Terraform, and no cloud-init, python
(and therefore Ansible), et al on the client side, and would appreciate
any development advice in so doing.

Since Natanael has been been working on the answer file automation and
tiny-cloud is alive:

> I'm working on the testsuite to add tests to make sure setup-alpine
> works with an "answer file".

> I intend to make some kind of tiny-cloud nocloud provider, which will
> be able to take some sort of cloud-init compatible config for
> unattended installs.
And as it happens, as a related option, I have a never finished metadata
server I was intending to use to serve 'cloud-init' metadata and it's
'NoCloudNet' data source (I stopped work because of cloud-init
limitations when using 'NoCloudNet'), it occurs to me that having a
generic metadata server that can be added as provider option to
tiny-cloud (looking at the code, the tiny-cloud part should just be a
matter of adding a couple tweaks to add a provider) could be relatively
easy.

I'm thinking that at least as a proof of concept, using a CGI or FastCGI
script would be the quickest route. I'm wondering if there would be
language preference when it comes to such a script, assuming this became
an interesting enough project to include (I'm thinking Lua seems the
lightest option, as it's been a few years since I've coded C in any
meaningful way and for this kind of application one is more likely to
make security-impacting mistake with it). I might also poke at ACF and
see if there are any relevant methodology in that service.

What I was doing was a trivial Python CGI script, but I don't think that
is the best route, and was more of a 'quick hack' choice.

Also, in my last email I mentioned:

> A final note: I've got some cloud-init image creation using Packer
> that I soon intend to push to public repository, along with Terraform
> usage of the same; is there interest in those here?

there doesn't seem to be interest in this, and the HashiCorp stack seems
rather heavy if one is going the tiny-cloud route, so I'm planning on
switching gears. I don't know if would still be useful to publish the
code somewhere for those who might want to make another choice,
especially since I don't plan on maintaining it, so I thought I'd ask
what you folks thought.

My plan, now, since I've been in the process of reorganizing my
'on-prem' equipment and my cloud instances is to simplify, simplify,
simplify (I was starting to get a little too 'enterprise-y/bloated with
Vault, looking at Nomad, using Packer and Terraform, and am trying to
avoid over-complicating).

I do, however, want to keep a fairly high degree of automation, for the
purposes of consistency, repeatability, and reproducibility. That, and
once the automation setup is in place, it is a lot faster to do
automated spin-ups than non-automated ones.

I'm wondering what folks on here currently use for this kind of thing,
and what you would like to see available.

Oh, and I guess I will have to figure out how to create and use
development versions of Alpine to get this working. I'd love to hear any
quick tips, getting started info, and "avoid these mistakes I made when
doing this" hints you might have.

Regards,

Daniel

-- 
https://wildtechgarden.ca Technical and professional website
https://princesandmadmen.ca Personal and political blog

---

From: Nico Schottelius <[email-masked]>
Date: Sun, 03 Jul 2022 10:30:15 +0200

Hey Daniel,

"Daniel F. Dickinson" <[email-masked]> writes:

> any development advice in so doing. [...]

as a cloud provider I can only say I really support such
developments. Building a VM is often not much more than x-bootstrap into
a directory that is residing on a loopback mounted disk. As a matter of
fact, we build many of our VM images like this [0].

However our scripts are hardcoded for a specific OS and for use with
opennebula, so they are not universal.

What I'd recommend is actually using python for such a project, as it is
"nearby shell" and easy enough, but this is just my personal opinion.

Regarding the metadata "server": there are 2 ways currently of using it:
a) via an disk / iso image b) via networking. (b) is usually error prone
as many tools rely on having IPv4, which does not exist for instance in
our core network.

Again, writing that daemon is probably not a big thing, but the choice
of network vs. disk might make be smart to consider before.

That said, in case you are a Matrix user, we discuss similar topics in
the #hacking-and-learning:ungleich.ch room from time to time.

If you need at some point in the future a cloud provider crazy enough to
support your project in regards of supporting the whole flow, give me a
ping.

Best regards,

Nico

[0] https://code.ungleich.ch/ungleich-public/ungleich-tools/src/branch/master/opennebula-images

--
Sustainable and modern Infrastructures by ungleich.ch

---

From: "Daniel F. Dickinson" <[email-masked]>
Date: Tue, 5 Jul 2022 19:04:02 -0400

Hi Nico,

On 2022-07-03 4:30 a.m., Nico Schottelius wrote:

[snip]

> of network vs. disk might make be smart to consider before.

FYI, I've heard that 'nocloud' support for 'tiny-cloud' is progress and
should be ready 'soon-ish', so option (a) should be realized in the not
too distant future. I've also had second thoughts about working on (b)
for the reasons you mention, in addition to it being more complicated
(IMO), and likely involving more work than I think is worth the end result.

My plan at this point is to support the 'nocloud' effort. (There is a
'tiny-cloud' MR in progress on gitlab.alpinelinux.org to review and test).

Regards,

Daniel

[snip]