This issue has been raised a couple of times before but never satisfactorily resolved.
In my case, I am creating a VSTS build agent image for Windows. Within that build I install Visual Studio 2017 and add a number of workload packages using Chocolatey. When installing one of the workloads the build fails because a restart is required (I think it’s the netweb one).
This is just one example and the are of course a much larger number where Windows enters a pending reboot state. It might be possible in some cases to suppress the reboot for some installer types (for example using ‘surpress’ or even ‘reallysurpress’ for the REBOOT property), but what is not obvious to me is whether, when creating an image, this has any real prospect of working at all, and whether the resultant image with a suppressed reboot would actually work. Reboot seems at odds with the way container builds work.
If suppressing a reboot is possible in my case or others, would the fact that a new container is started to handle the creation of the next layer be equivalent ? and if it was the final layer, would starting a container from that image be sufficient to complete the process ?
I guess it’s feasible to go to a lower level than a package manager to avoid some changes being flagged in this way, but that seems awfully difficult ?
When following microservices principals software requirements for an image are purposely constrained to the minimum required (this provides a better security posture as well as helping to reduce image size too), but we all know that for some installs there is no getting away from the need for a post install reboot. In my case I’m creating a more complex build tool container so necessarily it has more software bundled than in a typical app.
Anyway, can anyone provide any clear steer on what my options are and whether, at least for this case, I should go back to a ‘full-fat’ VM for my build agent ?