DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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!
