Określanie zbioru zadań, w którym zaplanowana usługa Azure WebJob jest przypisana do

Question

Czy jest możliwe określenie kolekcji zadań, które powinien używać program Visual Studio podczas wdrażania usługi Azure Web Job z harmonogramem? Domyślnie próbuje utworzyć nową kolekcję wolnej warstwy, ale ponieważ już ją posiadam (i limit jest jeden dla każdego konta), nie wdraża się.

Chcę skonfigurować płatną kolekcję prac i wszystkie moje wdrożenia należy do tej kolekcji.

Wdrażam WebJob z programu Visual Studio w wersji Publish as Azure WebJob.... Komunikat o błędzie w Visual Studio to:

Wystąpił błąd podczas tworzenia harmonogramu WebJob: Subskrypcja "XXX" nie może zawierać więcej niż 1 "darmowych kolekcji zadań. (/subscriptions/XXX/resourceGroups/CS-WestEurope-scheduler/providers/Microsoft.Scheduler/jobCollections/YYY)

chcę, aby moje istniejącego bezpłatnego zbierania pracy (jak to ma inne zadania utworzone ręcznie w nim HTTP). Byłoby znacznie lepiej, gdybym mógł określić, gdzie powinien iść harmonogram WebJob.

Dzięki!

Answer 1

Udało mi się obejść to na teraz. Wykonałem następujące kroki:

1. Usuń mój istniejący zbiór zadań wolnych poziomów w witrynie Azure Portal.
2. Wdróż jeden lub więcej moich nowych WebJobs z Visual Studio (w tym informacje o harmonogramie).
3. Powróć do witryny Azure Portal i zmień kartę Skalowanie zbioru zadań z Wolny, ponieważ został utworzony przez Visual Studio do wersji Standard/Premium.
4. W witrynie Azure Portal utwórz nową (bezpłatną) kolekcję zadań i ponownie dodaj do niej istniejące ręcznie utworzone zadania HTTP.

Gdy to nastąpi, wdrożeń z Visual Studio przejdź do automatycznie utworzonego Job Collection (automatycznie nazwie WebJobs-WestEurope po geolokalizacji mojej aplikacji), a drugi zbiór zostaje sam do użycia jak chcesz .

Zasadniczo Visual Studio musi dostać się do FIRST, aby utworzyć jego kolekcję, a następnie można dodawać kolekcje według własnego uznania. Wydaje się, że ograniczeniem jest to, że nie można kontrolować, którą kolekcję wybierze, więc trzeba pamiętać, że konkretna kolekcja jest w magiczny sposób związana z wdrożeniami Visual Studio. Jestem wszystkim za konwencję nad konfiguracją, ale nie konwencję NIE POZWALAJĄC konfiguracji.