Fundal: Se pare că Packer are probleme majore configurarea WinRM pe mașinile virtuale Azure create din Microsoft Windows Server editor. Aceasta este doar una dintre numeroasele probleme și fire pe care le-am găsit despre asta și datează de câțiva ani. Din această cauză, nu mă pot conecta la o instanță cu Packer pentru a furniza și pregăti propriile noastre imagini Windows pentru a fi utilizate în cadrul companiei noastre. Am încercat să modific timeout-urile, am încercat diferite dimensiuni de VM, niciuna dintre ele nu funcționează. Șablonul ARM al lui Packer este doar un gunoi la configurarea WinRM. Și nu sunt dispuși să rezolve problema. Într-o sugestie de a oferi o cale pentru a rula un script pe Azure în același mod ca datele utilizatorului AWS, „soluția” asinine a lui Hashicorp este să „pregătească o imagine personalizată pentru a procesa scriptul de date personalizate, astfel încât să puteți pregăti o imagine personalizată cu packer”. Ei chiar sugerează că nu se poate face prin codul lor, care este de-a dreptul fals.
Fac deja acest lucru în AWS, configurând un script userdata pentru a rula, care configurează WinRM și firewall-ul. Am putut constata că Azure are o caracteristică similară numită date personalizate, și în timp ce pot seta acest lucru folosind braț-azur sursă, dintr-un motiv „drăguț”. Windows nu are o modalitate de a-l rula, doar Linux o are cloud-init. Pot rula ceea ce am nevoie folosind Invoke-AzVMRunCommand (indiferent dacă este vorba de date personalizate sau nu, care REPARĂ PROBLEMA! HUZZAH! Cu excepția faptului că Packer nu oferă (ceea ce pot găsi) o modalitate de a rula comenzi de „pre-conectare” de la builder, aveți această opțiune doar odată ce accesați furnizorul. Codul meu de aprovizionare nu va rula până când nu se stabilește conexiunea la WinRM. Pui, întâlnește ou (sau este invers?)
Așa că nu pot automatiza acest lucru cu Packer în starea sa actuală decât dacă îmi lipsește ceva. Cu toate acestea, nu pot folosi un alt instrument aici pentru construirea imaginii din cauza politicilor și procedurilor interne. Îmi cer scuze dacă acest fundal iese puțin dezgustător, sunt extrem de obosit și frustrat de această problemă.
Intrebarea: Există vreo idee acolo nu implică crearea unei imagini personalizate intermediare printr-un alt proces care îmi va permite să rulez un script la momentul aprovizionării împotriva unui VM Windows Azure? Există constructori Azure alternativi pentru utilizare cu Packer care ar putea ajuta? Sau poate un editor Azure care publică imagini Windows care au deja capacitatea de a rula date personalizate la lansare? Sau poate există un truc al lui Packer pe care nu l-am luat încă în considerare aici? Dacă aș putea rula o comandă Azure CLI de la constructor odată ce VM-ul este creat, aș putea rezolva acest lucru rapid.
Celelalte gânduri ale mele sunt de a bifurca braț-azur builder și adăugați singur capacitatea de care am nevoie sau scrieți propriul meu furnizor în întregime. Prima soluție ar putea fi fezabilă și aș putea contribui cu codul înapoi (dacă Hashicorp nu îl va respinge pentru că „nu e felul lor”), dar cea din urmă pare grea pentru situație. În plus, nu știu Go, așa că ar trebui să-l iau și este... diferit de mulți. În orice caz, aș dori să evit să-mi dezvolt propriul cod pentru o soluție dacă există deja o soluție reală pentru acest scenariu.
Mulțumesc anticipat pentru luarea în considerare a acestei probleme.
