Действительно ли возможно установить несколько экземпляров того же сервисного приложения Дельфи?
-
Настройка, к которой я привык, заключается в том, что разработчики в основном игнорируют Docker, пока им не понадобится его для развертывания. Такие инструменты, как каталог Node
node_modulesили виртуальные среды Python, могут помочь изолировать подпроекты друг от друга. Любой отдельный разработчик должен иметь возможность запуститьdocker buildдля создания образа, но обычно не требуется до финальных этапов тестирования конкретного изменения. Вам следует развернуть систему непрерывной интеграции , которая возьмет на себя ответственность за тестирование и создание окончательного образа Docker для каждого коммита. -
Вы никогда не «обслуживаете контейнеры». Если контейнер работает неправильно, удалите его и запустите новый. Ваша система CI должна создавать образ для каждого выпуска, и вы должны развернуть реестр для их хранения.
-
Никогда не храните базу данных в том же контейнере, что и приложение. (См. Предыдущий пункт о регулярном удалении контейнеров.) Мой опыт обычно заключался в том, что производственные базы данных являются важными и достаточно специальными, чтобы заслужить свои собственные выделенные хосты, не входящие в Docker, но в действительности нет ничего плохого в запуске базы данных в Docker; просто убедитесь, что вы знаете, как выполнять резервное копирование, восстановление, миграцию и все остальное на нем.
Нет технической причины, по которой вы не можете использовать Docker Compose для производства, но если вам потребуется развернуть приложение на более чем одном физическом сервере, вы можете счесть его ограничивающим. Кубернетес является более сложным, но, кажется, текущий победитель в этом пространстве; Docker Swarm имеет некоторый импульс; Hashicorp Nomad там; или вы можете создать систему ручного развертывания вручную. (Обратите внимание, что, по крайней мере, Kubernetes и Nomad оба очень хорошо понимают концепцию «что-то изменилось, поэтому я собираюсь удалить и воссоздать контейнер», и оба усложняют разработку в реальных условиях в квазипроизводственной установке.) [ 1111]
Также обратите внимание, что там, где я говорю «развернуть», есть общедоступные облачные версии всех этих вещей (Docker Hub, CircleCI, комплексные решения, включая реестр и Kubernetes, построенные на основе AWS или Azure, или GCP), и если вас устраивает компромисс между затратами и усилиями и последствиями использования внешнего сервиса в цепочке сборки / развертывания, то это может помочь вам быстрее начать работу
5 ответов
Вы не прояснили, что Вы попытались изменить в подклассе TService.
Вы добавили обработчик "BeforeInstall"?
Что-то как:
procedure TServiceMain.ServiceLoadInfo(Sender : TObject);// new method, not an override
begin
Name := ParamStr(2);
DisplayName := ParamStr(3);
end;
procedure TServiceMain.ServiceBeforeInstall(Sender: TService);
begin
ServiceLoadInfo(Self);
end;
procedure TServiceMain.ServiceCreate(Sender: TObject);
begin
ServiceLoadInfo(Self);
end;
Если Вы регулярно делаете это, разделите TService на подклассы, чтобы сделать thie в Конструкторе вместо этого.
Необходимо сделать, то же в BeforeUninstall также - указывает на оба события на тот же метод.
C:\>servicename /install MyService "My Service Description"
Можно создать обслуживание с несколькими потоками внутренне, каждое действие как своя собственная версия/копия сервиса. Вы управляете им с Сервисным Контроллером API, IIRC.
Хорошо да возможно установить несколько экземпляров того же сервиса, просто необходимо динамично изменить имя во время установки (не время выполнения) однако, это не делает это желаемым. (существует некоторый пример кода на проекте Кода http://www.codeproject.com/KB/dotnet/MultipleInstNetWinService.aspx),
Я однако был бы склонен заново продумать Ваш подход, сами сервисные процессы действительно предназначены, чтобы быть одиночным элементом при необходимости в нескольких экземплярах выполняемого процесса возможно, сервис должен просто управлять и справиться с несколькими процессами вместо того, чтобы быть процессом.
Перенесите весь свой код в класс, который наследовался TThread.
Когда Ваш сервис запустится, он считает число из файла настроек или из реестра и создаст это много экземпляров Вашего класса.
Каждый экземпляр работает независимо.
Для изменения количества рабочих экземпляров, Вы могли закрыть сервис, отредактировать установку (в файле или реестре) и перезапустить сервис.
Принятый ответ выше был ужасно полезен.
Код I использовал:
procedure TService1.ServiceAfterInstall(Sender: TService);
begin
//http://stackoverflow.com/questions/612587/is-it-possible-to-install-multiple-instances-of-the-same-delphi-service-applicati
//http://www.c-sharpcorner.com/UploadFile/timosten/DynamicServiceInCSharp11262005062503AM/DynamicServiceInCSharp.aspx?ArticleID=4d5020e4-7317-425c-ab29-5bf37a1db421
//http://support.microsoft.com/kb/137890
SaveRegSetting('\SYSTEM\CurrentControlSet\Services\' + Name, 'ImagePath', ParamStr(0) + ' --name=' + Name, HKEY_LOCAL_MACHINE)
end;
procedure TService1.ServiceCreate(Sender: TObject);
begin
Name := Trim(FCommandLineOptions.Values['name']);
DisplayName := Name;
end;
SAVEREGSETTION - моя собственная процедура, а FCOMMANDLINEOPTIONS - это объект, который токенизирует параметры командной строки.