2

I have a setup with a bunch of blades that pxe boot into coreos using terraform/matchbox setup. I currently control them all manually using ipmitool from my desktop.

Is there a way to let jenkins control this?

an example use case would be if a bunch of different builds are being run and a new one is kicked off jenkins will know to use one of the slaves not running a build so it will power reset the machine and wait for it to come up and then run my docker stuff and the build.

3

Generic answer yes, it is possible with a lot of work...

Is it something wise to do? In my opinion no, you should convert your bare metal nodes to hypervisors with low maintenance and use common tooling to start slaves Virtual Machines on those hypervisors.

  • Thanks for the honest answer... I like that idea. I'm worried about certain things, but I think my best approach is to have a way to manually control the up/down of the blade IF it is needed. from there I will put CoreOs on them using the PXE service on my host as well. then jenkins can deploy docker on them and the state will belong to the docker image. – scott Feb 26 '18 at 0:15
0

Jenkins is but a scheduler. It is oriented to respond to code changes, and do whatever you want.

About IPMI, if you cannot follow @Tensibai's advice, I would suggest to wrap the operations at IPMI with something like ansible (Depending on what you actually need to do there).

Usually ipmi environment is used to TEST baremetal operations, in which case you have no other choice but use things like ipmi_boot or ipmi_power ansible modules, or actually write shell based ipmitool invocations to match incompatible hardware special saltos you need to do. Or even to use other "older generatino" things (chef, puppet, even cfengine etc.)

You still may find some consolation in Foreman/Satellite to control BMs via ipmi using PXE boot, and all the other "oldies" technologies.

All that of course, if you cannot actually wrap your BMs somehow to make them either k8s cluster with flexible slave-pods OR VMs, or something ... more "up-to-date" (Sometimes you can't I know).

I believe if you don't have network/io constraints you should go with Kubernetes (a.k.a. k8s), and not with Docker.

With both you can work with locally created images, but Kuberenets will allow you much more convenient housekeeping of containers, groups of containers, and even better - a "service", "operator" and other cool entities.

Besides you can version control your deployments with Helm charts and many many many other nice toys.

Good luck!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.