Здравствуйте, Михаил Романов, Вы писали:
МР>RDP + ручная установка вполне прокатывают как разовое средство, но как только речь заходит о более-менее регулярных деплоях (или деплоях на более чем один Instance, а я так думаю, в большинстве случаев деплой одного релиза идет минимум 3 раза: на тестовом окружении, на Stage и на Prod и это еще без учета того, что на скорее всего у вас кластер машин на Prod), имхо, от них нужно уходить и как можно быстрее, иначе риск операторской ошибки становится слишком большим!
Благодарю, я это все понял и, отчасти, знал. Просто было категорическое заявление, что RDP+ручное копирование
используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе.
Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде).
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>Легаси, .net 4.* какой-нибудь. НС>>И? Контейнеры с ним есть.
S>А если нету win10, рабочая win7 и win2008 продуктовая? А как до докера люди делали?
Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows, пишется скрипт, который заливает новый билд и дёргает что там у IIS надо дёрнуть, чтобы он понял что произошло. Даже такая наколенка в сто раз лучше, чем руками через RDP. Более хороший вариант — примерно то же самое, только не на коленке, а хоть через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
Сейчас стараются максимально разграничить "неизменную часть" (типа низкоуровневая инфраструктура вроде сервера, на котором есть чистая минимальная ОС и демон докера) и изменяемую часть (контейнеры, которые в том самом докере крутятся). Вот эту изменяемую часть не обновляют — её на каждый деплоймент убивают и создают новую с нуля.
Даже если не Packer, точно так же делаем EC2 с голой виндой, натравливаем на него Ansible/Puppet, получаем свежий сервер со свежим билдом, старый грохаем.
Здравствуйте, Sharov, Вы писали:
S>Просто было категорическое заявление, что RDP+ручное копирование S>используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе. S>Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде).
А я вот плюсану категоричность, потому что нет каких-то объективных причин выделять "редко деплою" и "деплою всего на 1 машину" в отдельную категорию. Обычно если умеешь, то пофигу редко там или не редко — заскриптованный деплоймент становится таким необсуждаемым минимумом, как руки мыть после туалета. Если не умеешь, да, причины не делать нормально всегда найдутся.
Здравствуйте, rosencrantz, Вы писали:
R>Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows,
И что же там самое близкое? Не cmd ли? Вы лично как делали во времена IIS?
R>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
Ansible появился совсем недавно а Puppet работает только через cygwin.
Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
Раньше проще всего было через RDP или FTP — разница не большая. Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, rosencrantz, Вы писали:
R>>Для случая "вот у нас есть один сервер, в него надо деплоить" — берётся что там самое близкое к SSH в Windows,
S>И что же там самое близкое? Не cmd ли?
Ага, через телнет.
S>Вы лично как делали во времена IIS?
Ну например TeamCity + MS Build + WebDeploy в 2012 году. А что?
R>>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности.
S>Ansible появился совсем недавно а Puppet работает только через cygwin.
Ansible появился 9 лет назад, и слово "подходы" у меня там именно для того, чтобы говорить не об инструментах, а об идеях.
S>Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
Из мира .NET я довольно быстро сбежал как раз из-за чудовищной экосистемы заточенной на "кликанье мышкой через RDP". Но в нескольких .NET проектах всё-таки довелось сделать CI/CD, поэтому у меня есть (возможно немного устаревшее) представление о том, что там может или не может работать. В этот тред я пришёл потому что CI/CD занимаюсь уже лет 10, последние 5 лет это где-то половина моей работы, я думаю не будет преувеличением сказать, что у меня есть опыт, и я вобщем не вижу почему бы моя точка зрения не была интересна/полезна для коллег. Ты пришёл мне сделать какое-то замечание?
S>А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
С моей точки зрения ситуация принципиально не поменялась — как 10 лет назад кто-то верил в ценность автоматизации, кто-то предпочитал руками, так и сейчас. Разве что раньше это часто было "запросить у админов виртуалку, потратить полдня на установку тимсити, и т.д.", а сейчас за 10 минут билд пайплан делается в облаках.
S>Раньше проще всего было через RDP или FTP — разница не большая. Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Между RDP и FTP разница таки большая. Аплоад по FTP автоматизируется тривиально, а автоматизировать RDP — это реально лучше сразу к врачу.
Здравствуйте, Shmj, Вы писали:
R>>через какой-нибудь Ansible или Puppet — меньше шансов налажать, какая-то диагностика, обработка ошибок. Но это типа подходы 10-летней давности. S>Ansible появился совсем недавно
9 лет назад это недавно?
S>а Puppet работает только через cygwin.
Есть еще дакая древность как Шеф. Было бы желание.
S>Сразу видно, что никогда в жизни вы этого не делали — только теоретизируете про чистые идеалы
Сразу видно что это ты никогда этим не занимался, вот и колхозишь бог пойми что на коленочке.
S>А сейчас совсем другая ситуация — любой дурик сделает деплой через CI/CD.
CI/CD это принцип, а не конкретный софт. О чем ты сейчас?
А конкретный софт это тот же Октопус или ТимСити, которые тоже уже больше 10 лет доступны. А до этого был, в конце концов, svn и серверные хуки.
S>Раньше проще всего было через RDP или FTP — разница не большая.
Просто нет.
S>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>9 лет назад это недавно?
Да. Я начинал в 2004.
S>>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро.
НС>Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить.
Раньше было на одну. Там уже папка открыта — просто заходишь, удаляешь, вставляешь.
Здравствуйте, Shmj, Вы писали:
НС>>9 лет назад это недавно? S>Да. Я начинал в 2004.
А я в 94. И 9 лет это давно по меркам подобных тулов.
S>>>Просто нажимаете одну кнопку, подключаетесь — и копируете файлы. Это быстро. НС>>Не одну. И куча способов накосячить, особенно если тебе не на одну машину деплоить. S>Раньше было на одну.
Никогда не было.
S>Там уже папка открыта — просто заходишь, удаляешь, вставляешь.
Это все одним нажатием кнопки, причем сразу на все инстансы, да?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Раньше было на одну. НС>Никогда не было.
Для средних сайтов хватало одного мощного сервака для IIS.
S>>Там уже папка открыта — просто заходишь, удаляешь, вставляешь. НС>Это все одним нажатием кнопки, причем сразу на все инстансы, да?
Здравствуйте, Shmj, Вы писали:
S>>>Раньше было на одну. НС>>Никогда не было. S>Для средних сайтов хватало одного мощного сервака для IIS.
High availability? Не, не слышал.
S>>>Там уже папка открыта — просто заходишь, удаляешь, вставляешь. НС>>Это все одним нажатием кнопки, причем сразу на все инстансы, да?
S>1 инстанс.
Все равно рукопашное копирование одним нажатием в RDP у тебя никак не получится. Надо собрать локально, открыть сессию RDP, подключится к диску, найти нужный каталог, создать файлик app_offline, запустить копирование, ответить на промт о перезаписи. И так для каждого инстанса. Ошибиться — миллион возможностей. И весь этот рукопашный перфоманс — просто чтобы не напрягать моск, один раз разобравшись с какой нибудь механикой деплоймента.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>High availability? Не, не слышал.
Раньше этим мало кто страдал. Если база была на отдельном серваке и делались регулярные бекапы раз в день — уже неплохо.
S>>1 инстанс.
НС>Все равно рукопашное копирование одним нажатием в RDP у тебя никак не получится. Надо собрать локально, открыть сессию RDP, подключится к диску, найти нужный каталог, создать файлик app_offline, запустить копирование, ответить на промт о перезаписи. И так для каждого инстанса. Ошибиться — миллион возможностей. И весь этот рукопашный перфоманс — просто чтобы не напрягать моск, один раз разобравшись с какой нибудь механикой деплоймента.
Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
Здравствуйте, Shmj, Вы писали:
НС>>High availability? Не, не слышал. S>Раньше этим мало кто страдал.
Или просто ты был не в курсе.
S>Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Во-первых, инстанс всегда один. Папка на RPD оставалась открытой, никто ее не закрывал. Версии новые выпускались не так часто, чтобы этим страдать.
НС>Ну чо, продолжай в том же духе.
S>>Просто было категорическое заявление, что RDP+ручное копирование S>>используют совсем нехорошие люди. В моем случае была развертка на одну машину и совершенно на нерегулярной основе. S>>Вот как раз для подобного RDP+ копирование самое то, поэтому меня и удивила категоричность (а-ля всегда и везде). R>А я вот плюсану категоричность, потому что нет каких-то объективных причин выделять "редко деплою" и "деплою всего на 1 машину" в отдельную категорию. Обычно если умеешь, то пофигу редко там или не редко — заскриптованный деплоймент становится таким необсуждаемым минимумом, как руки мыть после туалета. Если не умеешь, да, причины не делать нормально всегда найдутся.
Я полностью согласен с тем, что задача любого программиста автоматизировать вся и все. Но вот как быть с таким
важнейшим компонентом как время? Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза
от силы скажем не менее часа, а то и более 2-х. При этом по RDP скопировать, проверить и запустить дело от силы
5 минут. Автоматизация нужна для выигрыша времени в основном. Тут никакого выигрыша нет, разве что опыт, да
и выложить скрипт на гитхаб всяким hr показывать. Не более.
Здравствуйте, Sharov, Вы писали:
S>Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза
У тебя сервис 5-6 раз деплоится, а потом ты его выкидываешь на свалку?
S>Автоматизация нужна для выигрыша времени в основном.
Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
Здравствуйте, Sharov, Вы писали:
S>Я полностью согласен с тем, что задача любого программиста автоматизировать вся и все. Но вот как быть с таким S>важнейшим компонентом как время? Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза S>от силы скажем не менее часа, а то и более 2-х. При этом по RDP скопировать, проверить и запустить дело от силы S>5 минут. Автоматизация нужна для выигрыша времени в основном. Тут никакого выигрыша нет, разве что опыт, да S>и выложить скрипт на гитхаб всяким hr показывать. Не более.
Вот именно из-за такой точки зрения эти подходы для многих остаются "абстрактными идеалами". Если зафиксировать все параметры и сравнивать только время, вы правы — с большой вероятностью автоматизация будет выглядеть невыгодно. Но сравнивать нужно не только время, но ещё:
* предсказуемость — "оно делает именно вот это"
* воспроизводимость — "оно делает так всегда"
* задокументированность — "вот есть скрипт и его можно прочитать, чтобы понять что происходит"
* возможность захотеть большего — деплоить более 1 энвайронмента, деплоить чаще чем вы привыкли, и т.д.
У ручного подхода есть проблемы с предсказуемостью и воспроизводимостью — мыслящий человек после N повторений начинает оптимизировать процесс, начинает придумывать, что вот вот этот шаг не обязателен, в этот раз вот это обновлять не буду, т.к. точно знаю, что в билде оно не менялось. И в какой-то момент 5-минутный ручной деплоймент превращается в 20-минутное ковыряние "чё за фигня, почему так?"
Задокументированность — другая головная боль. Понятно, что если вы вводите процесс ("процесс ручного деплоймента"), его надо хотя бы минимально описать. Если это будет написано человеческим языком, можно очень легко забыть что-то упомянуть, или забыть что-то поправить, когда по факту процесс немного изменился. Легко получить документ, который не соответствует реальности.
Возможность захотеть большего — деплоймент скрипт можно развивать (и это будет "нормально"). Ручной деплоймент развивать некуда — с каждым усложнением он будет становиться всё менее предсказуемым и воспроизводимым.
Попробуйте на деплойменты смотреть так же как на юнит/инт тесты: "в принципе можно тестировать руками — и это позволит сэкономить время на написании тестов"
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну ушло бы у меня на написание и отладку скрипта, которым я воспользуюсь 5-6 раза НС>У тебя сервис 5-6 раз деплоится, а потом ты его выкидываешь на свалку?
Это исправление ошибок и новая версия. Все остальное время он просто работает.
S>>Автоматизация нужна для выигрыша времени в основном. НС>Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
Сложно сломать сервис, который по сути один exe файл со справочной бд в виде файла sqlite.
Надо понимать, что программы\сервисы разные бывают, а не только high scalability веб сервисы.
Здравствуйте, Sharov, Вы писали:
S>>>Автоматизация нужна для выигрыша времени в основном. НС>>Автоматизация в таких вещах нужна прежде всего для надежности и повторяемости, чтобы не сломать что нибудь случайно. А если лежаших полдня сервис или случайно удаленные данные клиентов твоих не беспокоят — ну ок, продолжай экономить время.
S>Сложно сломать сервис, который по сути один exe файл со справочной бд в виде файла sqlite. S>Надо понимать, что программы\сервисы разные бывают, а не только high scalability веб сервисы.
Согласен "про разные бывают", но осуждаю эту уверенность про то, что "X никогда не случится" сервис всегда будет таким, я всегда буду единственным программистом в этом проекте, на другую инфраструктуру мы переезжать не будем, и т.д. И потом бац, бизнес такой: "а давайте в облака чтоли переедем", "т.е. как 3 месяца займёт? щас наймём тебе в помощь второго программиста"
