osbuild-runner: run osbuild in an ec2 vm #3939
Conversation
croissanne
force-pushed
the
osbuild-in-vm
branch
7 times, most recently
from
c6dc11f
to
002fc04
Compare
croissanne
requested review from
supakeen,
ondrejbudai,
achilleas-k and
mvo5
croissanne
force-pushed
the
osbuild-in-vm
branch
3 times, most recently
from
b40338a
to
312a5fd
Compare
templates/packer/ansible/roles/common/files/worker-initialization-scripts/worker_builder.sh
Outdated
Show resolved
Hide resolved
|
I just realised, since this machine will still need to be subscribed, we also need the ability to add a role to read a single secret. |
croissanne
force-pushed
the
osbuild-in-vm
branch
5 times, most recently
from
0faf1f3
to
72c5a35
Compare
croissanne
force-pushed
the
osbuild-in-vm
branch
2 times, most recently
from
4947409
to
8308487
Compare
croissanne
force-pushed
the
osbuild-in-vm
branch
2 times, most recently
from
b3008b6
to
93b9447
Compare
templates/packer/ansible/roles/common/files/worker-initialization-scripts/worker_executor.sh
Outdated
Show resolved
Hide resolved
croissanne
force-pushed
the
osbuild-in-vm
branch
from
93b9447
to
0341630
Compare
There was a problem hiding this comment.
Thank you, this looks very nice. I really like the attention of detail in the security setup! I add a whole bunch of ideas/suggestions and also have some questions. All is just nitpicks or personal preferences, feel free to ignore them if you have different preferences or opinions :) Hope this is useful.
| cmd.Stdout = stdout | ||
| cmd.Stderr = stderr | ||
|
|
||
| err = cmd.Start() |
There was a problem hiding this comment.
A bit of a meta-question - given that osbild-jobsite-manager is part of this repo and written in go, why is it not used directly from go code, why the extra indirection via a os/exec and the json? is it for robustness, i.e. a crashing osbuild-jobsite-manager would not affect the service? or is there a different/deeper reason?
There was a problem hiding this comment.
@supakeen implemented the manager as a separate process, and I don't think there's a way to invoke it currently directly from go.
As to the reason, maybe to avoid sharing secrets between the processes? Or if the builder could somehow make the manager do something weird, it would be contained within that process?
There was a problem hiding this comment.
It's a layer of separation here; the worker might/will spawn multiple managers for multiple builders and/or run them inside containers or separate network namespaces.
Robustness and allowing users to run the manager/worker separately from the rest of the stack also plays a role.
Wrap the current osbuildexecutor.Executor in an interface so it's easier to add different executors, which for instance can run osbuild in a VM.
croissanne
force-pushed
the
osbuild-in-vm
branch
2 times, most recently
from
1752fb3
to
e472ecf
Compare
This instance can only contact the host, and requires this host to be running on AWS itself with the appropriate IAM role.
croissanne
force-pushed
the
osbuild-in-vm
branch
from
e472ecf
to
ac6bc37
Compare
This way the `worker-initialization.service` knows to spin up the builder instead of the worker.
This executor spins up an instance which can only contact the host, and uses the osbuild-jobsite manager & builder to invoke osbuild.
croissanne
force-pushed
the
osbuild-in-vm
branch
from
ac6bc37
to
594167a
Compare
croissanne
force-pushed
the
osbuild-in-vm
branch
from
594167a
to
bc1e7d7
Compare
No description provided.