Replies: 2 comments 7 replies
-
|
Hello @seqdan , content of As it is mentioned in README, we suggest using the following guide to build own images: https://github.com/actions/virtual-environments/blob/main/help/CreateImageAndAzureResources.md Also, it could be tricky to build images on Hosted agents because
Ideally, you should use self-hosted agent deployed in the same Azure subscription where you build VMs. In this case, packer agent and VM will be connected directly and there won't be security problems |
Beta Was this translation helpful? Give feedback.
-
|
@seqdan I believe you can use service-principal authorization in that case |
Beta Was this translation helpful? Give feedback.
-
|
@seqdan , currently, this script doesn't support auth in non-interactive way. But we would be glad to review pull-request to add support for it if you would like to contribute. Probably, we can introduce additional optional inputs to auth via service principal and if they are not specified, fallback to interactive way. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @maxim-lobanov and @miketimofeev , I have created a PR: #2622 |
Beta Was this translation helpful? Give feedback.
-
|
Would anyone be able to give me feedback on the service principals? |
Beta Was this translation helpful? Give feedback.
-
|
@seqdan , may be we don't need to create new service principal if it is already provided as an input. We can just use input Service Principal to build image. |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys! Long story short. According to colleagues these tests were passing previously - maybe a couple of months ago. Is there anything on the hosted agent which can block outbound fetch requests? Cheers, |
Beta Was this translation helpful? Give feedback.
-
|
@itachenko we're not aware of any changes. Could you please create an issue with the repro steps? |
Beta Was this translation helpful? Give feedback.
-
As far as I understand it, this repository seems to enable us to run our own Azure DevOps Agents in the cloud and/or on premise, and although we run them, they would have the same configuration as those agents that Microsoft offers as "hosted agents". Awesome!
I have experimented a bit creating my own windows2019 images. Some things went smoothly; others were a bit hard. I am not an expert; some things might have been difficult because of limited knowledge. But I just discovered the "Discussions" tab here and thought it might make sense to take notes of my progress (or not progress) and share them here for feedback. I'd be happy to update the documentation (via PR) here from what I figure out.
I find it quite tempting to be able to create a new VM image automatically via pipeline whenever there is a new release in this repository. This could be used in a virtual machine scale set in Azure. Once fully automated, one would automatically have always the latest agents up & running. It goes without saying that there should be security measures in place, like a manual review and approval step. And I obviously want to install a handful of extra tools, to save time during the pipeline runs.
It took me a while until I understood that, in order to create an image via my local machine, I only need to follow a few steps here: CreateImageAndAzureResources.md . Clone the repo, cd into it, and run the script:
The build itself took a bit more than 7 hours.
Now, the next step would be, to run this unattended in a pipeline. Wouldn't it be awesome to run it on a hosted Azure DevOps agent?
This is the challenge I am currently trying to solve. I am not sure if the hosted agents with their maximum runtime of 6 hours are fast enough and capable enough to run through the entire image generation process. It might be advisable to just launch a VM in Azure instead, but I want to try it out first.
There is an Azure Pipeline file windows2019.yml which seems to exist for exactly this purpose: I have created a pipeline in my own Azure DevOps Organization and linked it to this file.
The first stumblestone was the agent pool, which is hard coded in image-generation.yml . It would be great to have this defined as a variable, so that people with other pool names can directly hook their Azure Pipeline up to the repository. I have cloned it and ... hard coded :D a different value in my fork.
The second hurdle were the expected variables and permissions for the pipeline. The pipeline expects a certain set of variables set in a variable group named
Image Generation Variables.These variables seemed to be required:
Permissions were a bit tricky. It is clearly written in the documentation:
Unfortunately, by the time I was working on this, I had forgotten about that part of the documentation, and encountered an error message I could not interpret:
This issue here finally helped me figuring out why the disk could not be created: while it had full permissions on the resource group, it did not have any on the subscription. Therefore, the temporary resource group could not be created. Giving the SP full permissions on the subscription gave me a angry look of a colleague, but made it work.
Another thing I was unsure about were the vnet and subnet variables. I found it confusing that they are required to be filled. I have tried various approaches, like creating a vnet manually, leaving the value empty, and taking the variables out of the packer command (that one definitely works). I wonder if these really have to be mandatory, or if one could make them optional.
The pipeline has failed after 6 hours 11 minutes. I was surprised that the logs contained less content (1000 lines) after the job had failed than during the run (about 50k lines the last time I had looked). The raw log's first line:
The error message in Azure DevOps:
This is most likely due to the 6 hours timeout.
Beta Was this translation helpful? Give feedback.
All reactions