Baremetal remote/headless re-install with new ignition file

[James Drake]

Is it possible to reboot a running coreOs installation to a new ignition file?

As some background, I am using a small script to create and modify a custom ignition file (with the config transplitter) in our CI loop to be able to initialize a set of distributed bear metal deployments.
At times it is required that the ignition file that is used is updated - services, and files changed. I would like to push that new file to the deployments and have them at next reboot to use the new file (which I have a remote management capability to do).

It was possible to achieve this using the cloud-config, but I prefer to use the ignition format.

Thanks for any advice,
James

[Derek Gonyeo]

Hi James,

Unfortunately this isn't possible. If you can PXE boot in your setup then Ignition will run on every boot (since every boot is the "first" boot) and you'll get the effect you want. Matchbox (link here: https://github.com/coreos/matchbox) is some tooling we've made to make that easier. If that isn't feasible for you I'm afraid that you'll need to reinstall the machines.

As an aside, I'd love to have a "reprovision" button that does that, but it's not technically feasible in Container Linux the way things are today.

Derek

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Drake]

Derek,

Thanks for the response, however disappointing.
Sadly I don't have control of the baremetal client infrastructure so it is not possible the PXE boot the devices.

So now I think I will need to our CD:
1. Parse the created ignition (or config yaml)
2. Push each change (file or system..etc) directly to the remote system (including all the .service files)

Regards,
James

[Seán C. McCord]

Depending on what you mean by not having "control of the baremetal client infrastructure," that may not be important.  matchbox does not require, for instance, control of your DHCP server.  Instead, it can use proxyDHCP to supply PXE booting without coordination with the network's DHCP server or router.  In short, it can run on any machine (virtual or real) which has layer 2 access to the network on which the Container Linux machines will be connected.

Matchbox really is the _intended_ solution to your (abstracted) problem.

--

You received this message because you are subscribed to the Google Groups "CoreOS User" group.

To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Seán C McCord

CyCore Systems, Inc

+1 888 240 0308

PGP/GPG: http://cycoresys.com/scm.asc

[James Drake]

Thanks Sean,

When I say “control of the client infrastructure” I mean I have no possibility to understand, know, change or impact it dynamically, as it may not be managed by our team (it could be an external premise), so could already have PXE services running (and therefor the dhcp options already given).
I’ll have a look at Matchbox for how it could be used - maybe a dedicated network, but it would not be a simple task.

Best regards,
James

[Seán C. McCord]

The only one of those which should be a problem is an existing boot service.  Even then, I would at least see if you could get a VLAN to separate your stuff out from it.  

 - Not understanding can be fixed. :)

 - Not knowing can be either fixed or ignored

 - Not being able to change is fine:  proxyDHCP does not need to coordinate with an existing DHCP server, nor does it require modifications thereof

 - Not being able to impact is fine:  you will only be offering PXE boot to particular MAC addresses

However, if you are intending to put singleton CoreOS boxes out in client networks across a wide geographic area with the primary impetus for the use of Container Linux being the declarative configuration and automatic updating features,  you should really consider your plans carefully.  Container Linux is meant to be run as a cluster.  All of its tooling is constructed with the understanding that an individual machine is merely a piece of a larger whole.

Please pardon the pedantry if I am not reading your intentions correctly; I have seen far too many people coming to Container Linux for the wrong reasons and trying to wrangle a square peg through a round hole, rather than considering another hole or another peg.  Container Linux can be an extraordinarily apt tool for many applications, but it is not intended to be like other Linux server distributions.  It is important to take time to understand its strengths and play to them.

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[christopher clark]

Thank you Sean,

I was attempting to do exactly what you mentioned! I'm glad you could answer so succinctly.

Container Linux looked like a perfect solution for how small and lightweight it is, to manage several machines, and the containers these devices should be running. What additional layers other than k8 could be used to accomplish this? Keeping in mind small and lightweight is a desire. Is docker the next step on top of Container Linux?

Since coreos( I'm making an assumption coreos and container Linux is  the same thing) is so small and lightweight it could have additional product value for being great field device management. Think POS, IOT, Mobile, etc. I'm not here to try and sell this ideology, and you even mentioned many people have came here with the same assumptions/ attempts. All I'm asking is if their is a path for those who would be concerned with field/client device management?

Thank you either way, sorry to hijack the original posters question.

[Seán C. McCord]

By "exactly what you mentioned," I'm guessing you mean that you are wanting to leverage Container Linux's declarativity, deployed size, and automatic updating to build out a number of singleton installations across many (potentially differing) clients.

You certainly _can_ use Container Linux for this purpose, but much of the tooling isn't going to help you for it.  It is presumed that there is some additional scheduling/deployment layer above the node which handles allocating loads to the node.  Since that is not the case for you, you will have to use something else for this tooling.

One option is fleet[1], though it is now deprecated.  You _could_ create a centralized etcd cluster to which all of your nodes connect to obtain their (dynamic) load descriptions.  This is an elegant solution if the security of etcd (TLS + auth) is sufficient for your purposes, and if your nodes are going to be connected to the internet.

Another option is a configuration manager, such as Ansible[2].  You could manage your load based on systemd units which are copied over and/or updated by the configuration manager.

Another option is a synchronization script, which is basically a hand-rolled configuration manager.  It does basically the same thing but with a simpler, more custom script.

Each of these uses the same basic conceit:  all load is defined entirely by systemd unit files.  These unit files should define services which pull down container images and then execute them in your container runtime (I would use rkt for your local runtime, since it plays better with systemd, but docker is a perfectly valid choice).  Thus the entirety of your post-install customizations are contained in the unit files.  Container Linux automatic updates will be completely transparent to this process, since the unit files will be stored in either /etc/systemd or /run/, depending on the method you choose.  Both of those directories are safe from modification by the update processes.

[1] - https://github.com/coreos/fleet

[2] - https://www.ansible.com/