Временное отключение служб по умолчанию в servicefabri c с использованием powershell - PullRequest
1 голос
/ 10 апреля 2020

Конкретный вопрос

Для тех, кому просто нужны прямые вопросы:

  • Есть ли способ временно отключить службы по умолчанию для типа приложения ServiceFabri c, чтобы новое приложение можно установить (используя Powershell) без автоматической установки каких-либо служб по умолчанию?
  • Предлагаемое решение заключается в удалении служб по умолчанию из манифеста и последующем их восстановлении. Я могу написать сценарий PowerShell для соответствующей настройки манифеста приложения, но как мне обновить тип приложения с помощью Powershell - при условии, что я уже изменил манифест?

Любое решение, которое решает контекстная проблема, не требующая ручного конфигурирования, является приемлемой - мое предложенное решение, вероятно, не единственно возможное решение. Мы явно хотим избежать ручного вмешательства.

Разрешая вмешательство, мы уже можем просто закомментировать службы по умолчанию, когда нам это нужно. Мы специально ищем решение, которое не требует вмешательства, поскольку это уменьшает количество ошибок и проблем отладки.


Контекст

Я столкнулся с проблемой использования стандартного манифеста приложения услуги во время локальной разработки.

Мне известен общий совет «не пользуйтесь услугами по умолчанию», и он выполняется. Во время сборки CI службы по умолчанию удаляются и не будут использоваться ни для одного из наших кластеров в Azure. Единственное исключение здесь - локальные машины разработчика, которые используют службы по умолчанию, чтобы поддерживать удобство работы с F5 для разработчика, включая все службы при запуске сеанса отладки.

Мы написали специализированные сценарии, которые предоставляют нового клиента (приложение SF) со своим набором услуг (SF service). Не каждый арендатор должен получать все сервисы, мы хотим подключиться к сервисам, что уже делает скрипт (на основе сопоставления, которым мы управляем в другом месте, что не является частью текущего вопроса, поскольку скрипт обеспечения существует и работает ).

Однако, когда службы по умолчанию включены, каждый арендатор уже получает все службы, и фактическая подготовка к подписке бесполезна. Это проблема, которую мы пытаемся решить.
Этот же сценарий работает в нашем производственном кластере, поскольку там не настроены службы по умолчанию. Вопрос заключается исключительно в локальной среде развития.

По сути, мы имеем дело с двумя сценариями ios во время локальной разработки:

  • При отладке мы хотим, чтобы службы по умолчанию были включены, потому что это позволяет нам запускать все наши сервисы, нажав F5 (и не требуя каких-либо дальнейших действий)
  • При тестировании нашего скрипта инициализации нам не нужны сервисы по умолчанию, потому что он мешает нашему поведению выборочной инициализации

Мне известно, что комментирование служб по умолчанию из манифеста решает проблему, но для этого требуется, чтобы разработчики постоянно переключали содержимое манифеста и переустанавливали тип приложения, чего мы хотели бы избежать.
В идеале, мы хотите иметь сервисы по умолчанию в манифесте (как в настоящее время), но затем сценарий инициализации «отключает» сервисы по умолчанию для своей собственной среды выполнения (и восстанавливает сервисы по умолчанию перед выходом), так как это дает нам желаемое поведение в оба случая.

Какое решение требует наименьшего вмешательство разработчика вручную, чтобы получить желаемое поведение в обоих сценариях ios?

В настоящее время я пытаюсь реализовать его так, чтобы сценарий обеспечения:

  1. Копирует манифест приложения в хранилище резервных копий
  2. Удаляет службы по умолчанию из реального манифеста
  3. Обновляет тип приложения с использованием нового манифеста (т. е. без служб по умолчанию)
  4. Запускает протокол обеспечения c
  5. Восстанавливает реальный манифест, используя резервный манифест из шага 1
  6. Обновляет тип приложения, используя восстановленный манифест (т. Е. С сервисами по умолчанию)

Именно шаги 3 и 6 я не знаю, как реализовать.

1 Ответ

0 голосов
/ 12 апреля 2020

Рассмотрите возможность использования двух проектов sfproj в решении. Один со службами по умолчанию, другой без.

Также обратите внимание на использование сценария start-service.ps1 вместо служб по умолчанию. Таким образом, два проекта могут использовать один и тот же манифест приложения.

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-debugging-your-application#running -a-script-as-part-of-debugging

...