Речь о серверных приложениях. Т.к. сейчас все делают через JS-фреймворки React/Vue/Angular, а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты. Чуть глубже. Сейчас многие предпочитают виртуализацию, т.е. все через Docker/Kubernetes и при каждом новом деплое — обычно создается новая вирт. среда (а старая удаляется, дабы не думать о совместимости).
Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. Или же проделывали то же самое через sftp/ftps.
Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки). Даже более — можно было создать плагинную систему и копировать плагины просто в директорию, добавляя таким образом новый функционал, не вмешиваясь в старый, не производя компиляцию даже.
Теперь подобного можно достичь с помощью т.н. микросервисов, что не подходит для мелких случаев — для каждого плагина делать отдельный микросервис — это бред.
Ну и вопрос такой. Как лучше совместить плагинную систему и современные тренды, когда принято все собирать из исходников с нуля, обычно собирают целый проект а не по частям? Или же лучше не делать плагинов а просто пересобирать все с нуля как все?
Здравствуйте, Shmj, Вы писали:
S>Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты.
Нет никакого такого стандартного способа.
S>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые.
Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки).
Это как? Ты раньше на проде патчил только одну сборку из проекта? Ну ты герой.
S> Даже более — можно было создать плагинную систему
Зачем плагинная система на сервере? Чтобы тормозов побольше?
S>Теперь подобного можно достичь с помощью т.н. микросервисов, что не подходит для мелких случаев — для каждого плагина делать отдельный микросервис — это бред.
Микросервисы это не плагины, и цель у них совершенно иная.
S>Ну и вопрос такой. Как лучше совместить плагинную систему и современные тренды, когда принято все собирать из исходников с нуля, обычно собирают целый проект а не по частям? Или же лучше не делать плагинов а просто пересобирать все с нуля как все?
Делать без плагинов, по крайней мере пока ты не сможешь ответить на вопрос какие бенефиты тебе дают твои плагины.
Здравствуйте, Shmj, Вы писали:
S>Так вот. Ранее не было нужды пересобирать все, если изменения касались одного модуля (библиотеки). Даже более — можно было создать плагинную систему и копировать плагины просто в директорию, добавляя таким образом новый функционал, не вмешиваясь в старый, не производя компиляцию даже.
Можно но не нужно. Куда проще сделать скрипт, который все удалил и накатил новое.
И пересобрать все — какая проблема? Не вручную же ты символы пишешь, компьютер автоматом все пересоберет и не устанет. Ну, если сборка проекта целиком занимает двое суток, могу понять, но в дотнете как-то обычно сборка совсем не такая длинная...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Shmj, Вы писали:
S>>Итак, стандартный способ деплоя — через непрерывную интеграцию CI/CD с помощью специального ПО или же просто через скрипты.
НС>Нет никакого такого стандартного способа.
S>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые.
НС>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Здравствуйте, Shmj, Вы писали:
S>Ну и вопрос такой.
Использую следующую схему.
1. приложение монолитное(т.е. без плагинов).
2. паблиш запускает скрипт который зипует сборку app_1.0.1.42.zip без лишних артефактов.
3. либо через простейшую реализацию submit либо ручками копирую в спец папку на сервак.
4. дальше опять либо ручками, либо через filewatcher запускается процесс обновления.
в скрипт можно встроить бэкап приложения, базы. вообщем резвимся как хотим.
в IIS есть еще фишка под названием app_offline.htm(из webdeploy).
если такой файл кинуть в корень приложения, то оно останавливается(вместо него содержимое странички пользователям)
и можно спокойно обновить приложение.
по поводу вебдеплоя долго настраивали с товарищем, но в ответственный момент происходил сбой, причину которого я так и не отловил.
лечилось с трудом, шаманство и повторная настройка. подозреваю из-за отсутствия валидного сертификата на сервере. может еще что-то.
поэтому отказался.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. НС>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Мне надо было наколеночный проект закачать на машину в aws, что подцепить к RMQ для обработки задача.
Как webdeploy тут мог помочь, он же вроде только для веба (ISS,asp.net)? Я просто тот, кто копировал
файлы (папочку с ) на прод. Сейчас (net5) проще -- single_exe (а-ля го) + докер. Хотя и без докера
один exe совсем симпатично. А webdeploy для не веб приложения как?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Мне надо было наколеночный проект закачать на машину в aws НС>У AWS свой инструментарий.
У нас своя инф-ра, в частности RMQ, так что aws тут не поможет.
S>>один exe совсем симпатично. А webdeploy для не веб приложения как? НС>А где я обещал webdeploy не для веб-приложения?
Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
Наколеночные приложения не только веб. Это может быть обработчик, который живет на отдельной машине.
Здравствуйте, Sharov, Вы писали:
S>>>Мне надо было наколеночный проект закачать на машину в aws НС>>У AWS свой инструментарий. S>У нас своя инф-ра, в частности RMQ, так что aws тут не поможет.
Не очень понял при чем тут своя инфраструктура. Если речь про деплоймент самого кролика или прочей инфраструктуры, то он деплоится контейнерами или образами VM, таки через штатные средства AWS. Если же речь про деплоймент своего кода, как в стартовом сообщении, то при чем тут вообще кролик?
S>>>один exe совсем симпатично. А webdeploy для не веб приложения как? НС>>А где я обещал webdeploy не для веб-приложения? S>
S>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Наколеночные приложения не только веб.
Ты стартовое сообщение читал?
а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
Не нужно выдирать мои слова из контекста и приписывать то, что я не утверждал.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>У нас своя инф-ра, в частности RMQ, так что aws тут не поможет. НС>Не очень понял при чем тут своя инфраструктура. Если речь про деплоймент самого кролика или прочей инфраструктуры, то он деплоится контейнерами или образами VM, таки через штатные средства AWS. Если же речь про деплоймент своего кода, как в стартовом сообщении, то при чем тут вообще кролик?
Нету докера и вм, есть машина на которой надо запустить exe файл (или сервис).
S>>Наколеночные приложения не только веб. НС>Ты стартовое сообщение читал? НС>
НС>а вопрос касается .Net — то о WebAPI, ибо все остальное уже не актуально.
НС>Не нужно выдирать мои слова из контекста и приписывать то, что я не утверждал.
Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp
я не знаю.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Раньше было несколько иначе — постоянно держали сервер, заходили на него по RDP, вручную удаляли файлы сайта на IIS, копировали новые. НС>>Так делали только ... цензурное слово не подбирается. Даже для совсем наколеночных проектов проще было деплоить через WebDeploy.
S>Мне надо было наколеночный проект закачать на машину в aws
Если вы прям ненавидите амазоновскую проприетарщину, есть прекраснейший Terraform, который умеет всё то же, что и CloudFormation (но только _немного иначе_). Умеет ещё кучу других провайдеров, и совсем "общие" вещи вроде подключиться через SSH куда-то и что-то там выполнить. Можно одним слоем развернуть инстанс EC2, а вторым навалить на него какой вам софт нужен.
Не надо прикрываться этой "наколеночностью" — сейчас много хороших инструментов с отличной документацией, которые позволяют сразу сделать хорошо.
Здравствуйте, Sharov, Вы писали:
S>Нету докера и вм
В AWS? Так не бывает.
S>Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp S>я не знаю.
Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity.
Но в 2021 году не использовать контейнеры, а вместо этого ручками копировать через RDP файлики — очень странное решение.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Если речь о развертывании веб решений, то ладно. А как не веб решения без докера развертывать не через rdp S>>я не знаю. НС>Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity. НС>Но в 2021 году не использовать контейнеры, а вместо этого ручками копировать через RDP файлики — очень странное решение.
Здравствуйте, Sharov, Вы писали:
S>>>Легаси, .net 4.* какой-нибудь. НС>>И? Контейнеры с ним есть. S>А если нету win10, рабочая win7 и win2008 продуктовая?
Поставить.
S> А как до докера люди делали?
А еще раньше люди огонь при помощи кремня добывали.
Здравствуйте, Sharov, Вы писали:
S>Ну это уход от вопроса. Т.е. таки rdp и копировать ручками.
Ну вам же ответили ранее https://rsdn.org/forum/dotnet/8087679.1
Есть куча решений, зависящих от конкретной инфраструктуры. У каждого оркестратора, к примеру, они свои или набор сторонних заточенных под него. Есть относительно универсальные решения типа Ansible или DSC. Есть средства управления развертывания, например Octopus. Есть решения на базе средств, напрямую не предназначенных для развертывания — svn, git, teamcity.
Как минимум Octopus, Ansible и DSC для связки .Net 4 и Server 2008R2+ работать должны.
К перечисленным решениям можно добавить еще:
— Microsoft System Center (который Operation Manager и иже с ним)
— TFS (release management там с версии 2015 вроде) / Azure DevOps / Azure Pipelines
В принципе, народ работал и на базе GPO в Active Directory, но это, скорее из серии "когда уж совсем никак, то пусть будет хоть это".
RDP + ручная установка вполне прокатывают как разовое средство, но как только речь заходит о более-менее регулярных деплоях (или деплоях на более чем один Instance, а я так думаю, в большинстве случаев деплой одного релиза идет минимум 3 раза: на тестовом окружении, на Stage и на Prod и это еще без учета того, что на скорее всего у вас кластер машин на Prod), имхо, от них нужно уходить и как можно быстрее, иначе риск операторской ошибки становится слишком большим!
Здравствуйте, Sharov, Вы писали:
S>>> А как до докера люди делали? НС>>А еще раньше люди огонь при помощи кремня добывали. S>Ну это уход от вопроса. Т.е. таки rdp и копировать ручками.
Я тебе там целую пачку вариантов помимо контейнеров привел, но ты их все проигнорировал. Ну ОК, продолжайте с RDP развлекаться.
