Comments 117
Выбор Марко Армента в 2005 году: дистрибутив CentOS (по сути, бесплатная версия Red Hat Enterprise Linux), который удовлетворяет трём основным требованиям:
Как будто самое главное в построении отказоустойчивой системы это выбрать ОС. Если мы хотим по-настоящему отказоустойчивую систему, то нам нужен кластер, для нормального кластера нам нужны стэкируемые коммутаторы, две или больше отдельных физических линии от провайдера, правильно настроенные роутеры, какой-нибудь Ceph или GlusterFS, бэкапы. Выбор дистрибутива тут пожалуй наименьшая из "проблем".
Вы получаете от $50 000 до $75 000
Только если до этого ты платил за облака, если не платил, то ничего и не сэкономишь.
Ведь программирование — как зависимость, организм получает кайф и требует повышения дозы.
Главное не забывать, что от "передоза" можно и выгореть. Это даже если отбросить тот "малозначительный" момент, что эксплуатация это не программирование.
>> нынче все масштабируются без вышеописанного
Какие все? SQL или noSQL ? И что вы подразумеваете под масштабированием. Горизонатальное масштабирование (шардирование) с синхронизацией транзакций в шардах умеют далеко не все, а точнее сказать почти никто и не умеет. Умеет YDB разве что. А многие ли ей пользуются снаружи Яндекса?
Как же бесят такие утверждения. Не использовал, не настраивал, но высказаться надо.
Для чего Ceph соцсеточке?
Это масштабируемое отказоустойчивое софтово-определяемое хоронилище, которой можно использовать для статики, например. А статики будет овердохренищща.
Это зарплаты в Америке или где либо на загнивающем. Там реально джунам столько платят. Даже первая работа в нормальной фирме будет оплачиватся прилично больше.
Есть такое выражение — "голь на выдумки хитра". Как раз обмазывание всего и вся кубами, цефами, особенно хитрыми CI/CD и так далее делает даже минипроекты местами излишне сложными в эксплуатации. Что, к слову, выгодно облачным вендорам.
Как раз вымирает скилл как из говна и палок слепить относительный web хай лоад, не жрущий денег. За много денег это и каждый дурак сможет, а вот когда денег не так, чтобы много, тут уж и возникают вопросики. И да, всякие стэкируемые коммутаторы не были особой необходимостью для web-проектов, это больше прерогатива кровавого энтерпрайза (хотя нынче уже сложно найти нормальный управляемый свитч без поддержки стека).
Как раз вымирает скилл как из говна и палок слепить относительный web хай лоад, не жрущий денег.
Честно говоря, не представляю, как сделать нормальный high availability за мало денег. Добиться высокой доступности можно только путем резервирования всех критических компонентов системы, если не будет резерва, то с ненулевой вероятностью однажды возникнет ситуация, как у RUVDS, когда волей случая прилетело в ту самую единственную критическую точку. А резервирование всегда стоит денег.
Я кстати ничего не писал в своем сообщении про Кубер, а то что описал считаю минимальным действительно рабочим комплектом для HA-системы с более-менее сложным приложением, использующим что-то помимо единственной БД с репликой. Если знаете как сделать проще, то с удовольствием почитаю.
Несколько А записей + nginx на входе * 2 датацентра + сколько надо аппликейшен серверов * 2 датацентра + 2-3 (зависит от) реплики вашей любимой sql бд тоже в паре-тройке датацентров.
Минимальный отказоустойчивый хайлоад готов.
Всякие кубернетисы в нем просто не нужны. Это излишнее усложнение.
Всякие кубернетисы в нем просто не нужны. Это излишнее усложнение.
Так я в своём сообщении и не писал про Кубернетис.
Посыл статьи то был в том, что стоит только освоить Линукс и вы будете экономить большие деньги, самостоятельно хостя все на свете, а потом вообще все свели к выбору дистрибутива.
Несколько А записей + nginx на входе * 2 датацентра + сколько надо аппликейшен серверов * 2 датацентра + 2-3 (зависит от) реплики вашей любимой sql бд тоже в паре-тройке датацентров.
Ну да, если арендовать сервера в датацентрах, или поставить их там, то часть того о чем я написал (например подключение нескольких линий связи, настройка коммутаторов, роутеров, кластер виртулизации) уже будет сделано другими людьми.
Что касается нескольких А-записей то это работает не очень надежно, в чем я убедился на практике. На одной из работ было так и сделано — две серверных в разных городах с идентичными сервисами и две А-записи. Проблемы вызывают провайдерские DNS, и DNS дешевых роутеров, которые порой категорически отказываются возвращать несколько А-записей.
Сервера конечно арендуем. Aws не надо, но и полный треш не надо.
С одной стороны это решение на минималках. Оно не идеальное.
С другой а чего бы ему ломаться? Nginx ломаться не склонен. Перед опасными действиями, какое-нибудь большое обновление сервера или nginx, вырубаем его из днс и катим спокойно. Остаётся только сценарий сломавшегося сервера или всего датацентра. Риск для высокодоступного сервиса на минималках выглядит приемлемым. Чтобы его исключить надо уже довольно сложные и дорогие штуки делать. L2 балансировки там всякие.
@Pasи не говорит, что не нужно делать HA. Речь шла о том, что не надо перегружать архитектуру ненужными компонентами, для которых потом и прийдётся думать о резервировании.
и не говорит, что не нужно делать HA.
А мой коммент о том, что если вы решили экономить и хостить прямо всё сами, полностью на своей инфраструктуре, то вам не хватит одного только Линукса и всего нескольких месяцев на обучение, тогда как посыл статьи – потрать на Линукс несколько месяцев, и сэкономь десятки тысяч долларов, даже при домашнем использовании. И это не метафора, прямо так и написано, даже цифры есть, $50-75к
Ну от операционной системы тоже многое зависит. Есть давние истории, как люди даже забывали, где у них находится сервер, при том, что годами с ним работали. Впервые прочитал такую историю про случайно замурованный компьютер с FreeBSD, потом и сам с таким столкнулся: рассказали, что первый сервер, который я настраивал (на RedHat 7.3) чуть не забыли при переезде, потому что его поставили в отдельном помещении, заставили коробками, и забыли про него :-) Обнаружили потому что не поленились пересчитать компьютеры в локальной сети и сравнить с тем, что реально присутствовало. Ну так вот, ни разу не слышал такую историю про Windows, ну и тем более тогда. Windows XP (система того времени, ну пусть и не для серверов) без установленных обновлений вообще жила в Интернете минуты (межсетевой экран предусмотрен не был).
ни разу не слышал такую историю про Windows, ну и тем более тогда
У одного из моих клиентов, провинциального музея, был сервер на NT, на котором крутилось вообще всё, от файлопомойки до веб и прокси с почтой. И он продолжал жить на столь же древнем железе годы спустя после выхода последнего сервис-пака. В режиме 24х7х365
У нас в научном учреждении есть сервер на 2000 с почтой, древней как сами понимаете что, которая работает в аптайме в пару тысяч дней. Там конечно нагрузки так себе, человек 500 всего, но таки пашет, и даже с древним айдые винчестером. И торчит в мир (:
У меня таких 4. Ибо там софт, который больше нигде не работает. Сколько там аптайм - хз. В мир не торчат и когда туда заходил админ... ну не вспомнить :)
Не так давно для замены оперативки выключал сервер с 2012r2 с аптаймом 2000+ дней. Вполне обычная система винда для сервера. Единственное что я бы не стал винду высовывать наружу в интернет, т.к. сильно более дырявая штука. Но в интранете вполне ничем не хуже.
Лет 20 с лишним тому назад писали про замурованный сервер в университете Северной Каролины, который 4 года не могли найти.Так он под Novell крутился. Думаю что случай был не единичный...
я сам году в 10 примерно такой сервер оставил на ставшей бывшей работе, мы и сами раз в полгода не с первого раза вспоминали, где он там.
фряха + read-only rootfs на флешке, засунутая в внутристенный шкаф. там по-моему единственная шевелещаяся деталь была кулер бп
на моём первом проекте на ms windows server 2000 аптайм составил несколько лет. На нём крутился локальный сервер местной конторы (почта, внутренний портал) с посещаемостью в несколько сотен человек ежедневно, плюс файлопомойка на несколько сотен гигов. Переезд на юникс был очень болезненным как для юзверей, так и для сисадминов
Ну, если социалочка ляжет на часик раз в год, никто не умрёт. А вот неправильно выбранный дистрибутив может обойтись значительно дороже...
Если мы хотим по-настоящему отказоустойчивую систему, то нам нужен кластер
Попробуйте поднять "кластер" на Arch Linux и поподдерживайте это хотя бы с годик.
Выбор дистрибутива важен, т.к. это основа инфраструктуры.
Если к инфраструктурным тестам добавить [ALA/ARM](https://wiki.archlinux.org/title/Arch_Linux_Archive] — никаких проблем.
Вот если в лоб решать — да, может стать больно.
На самом деле, столкнулся с тем, что современные популярные кластерные решения в большинстве своём вообще очень плохо переживают on-line обновление версии, так что хоть Убунта, хоть RHEL, хоть Arch, поднял, настроил и потом лучше особо не трогать, не обновляя ни сам кластер, ни базовую ОС, на которой всё это крутится. Зачастую, какой-либо существенный апгрейд превращается в сборку нового кластера и последующую миграцию данных. Так что если арч не обновлять и не поломается внезапно ничего ))
Странно рассуждение про рост потребности в bash "программистах". По мне так все ровно на оборот и bash вытесняется другими языками, например python, которые успешно заменяют bash при этом являются языками общего назначения.
Ни разу не видел полной замены shell-скриптинга (это не только BASH) питоном или чем-то ещё. Как дополнение — ок, но как замену — нет. Ну и вообще, нормальный сисадмин может и в питон постучать и shell-скрипт разобрать или быстро накидать, и понять, "почему этот чёртов Makefile не работает", а также YAML, HCL, J2 и прочие выпендрёжи, которые неизбежно встречаются в современном зоопарке.
Можно посмотреть на nushell
Вы как давно разбирались с makefile который неизбежно встречается. Лично я последний раз лет 15 назад. Я понимаю, что некоторые и ядра свои собирают, но это не "неизбежно встречаются в современно зоопарке". В современно зоопарке AWS, кубер, разные эластиксы и папеты, а не makefile.
Как скопировать директорию на питоне?
os.exec("cp -R /path/to/directory /new/dispoition") !!!
Как иронично
а зачем питон, если из него вызывать шелл =)
если утилита не имеет иных механизмов взаимодействия в силу исторических причины ее нужно по религиозным соображения переписать в виде библиотеки или пакета? Зачем если в языке предусмотрен механизм подключения и такого рода утилит через exec? Если так принципиально использование "чистого" питона без внешней утилиты есть os и shutil.
Если на шелле это будет
cp -R /path/to/directory /new/dispoitionто зачем нужен питон, где будет
os.exec("cp -R /path/to/directory /new/dispoition") !!!И я думаю, что кроме os.exec вам еще импорт надо указать.
Затем, что /path/to/directory и /new/dispoition берутся из СУБД?
Как будто сложно на шеле сделать получение данных из СУБД. Возможно даже придется меньше писать для этого.
Вопрос не в возможности, что-то сделать. Вопрос лично ваших перспектив. С шелом вам нужно обязательно знать набор утилит конкретного дистрибутива, ваши знания и код плохо переносятся между разными дистрибутивами и даже между разными версиями одного дистрибутива. Код практически нельзя комбинировать и реиспользовать, вы не можете сделать пакет работы с конкретным api и использовать его в разных местах, постепенно расширяя. Плюс ваши знания бесполезны для множества модных нынче технологий, да и в целом знания языка общего назначения позволяет вам реализовывать некоторый функционал уже из мира программирования, начиная от дата анализа и визуализации, заканчивая простыми сайтами и утилитами, различными etl и тому подобным. Т.е. вы можете делать все тоже самое, только еще много чего дополнительного, ну и работа со сложными объектами, в шелл и том же python, это даже сравнивать нельзя. Фактически нет ничего, что можно сделать на шелл и нельзя сделать в python, особенно учитывая возможность os.exec, но есть масса того, что на шел будет сделать если возможно то, через такие жутки костыли, что и пробовать не стоит. Например недавно мне понадобилась страничка записная книжка звоника для астериск, которая берет данные из базы, это вполне себе админская задача, но на шеле, я даже затрудняюсь сказать, это вообще возможно, наверно да, но это будет жуткое зрелище.
С шелом вам нужно обязательно знать набор утилит конкретного дистрибутива
Почему же?
gnu tools есть во всех дистрибутивах. Причем не только линукса.
POSIX стандарт также распространяется на все.
А множество модных нынче технологий, под капотом могут просто выполнять скриптики на шелл, перл или питон.
ваши знания и код плохо переносятся между разными дистрибутивами и даже между разными версиями одного дистрибутива.
В шелл код ОТЛИЧНО переносится между разными дистрибутивами, а вдобавок еще и соблюдается отличная совместимость между версиями.
Код написанный на шелле с соблюдением POSIX стандартов будет работать практически на любом дистрибутиве, который выходил последние лет 30. Какой язык программирования может таким похвастать?
Например недавно мне понадобилась страничка записная книжка звоника для астериск, которая берет данные из базы, это вполне себе админская задача, но на шеле, я даже затрудняюсь сказать, это вообще возможно, наверно да, но это будет жуткое зрелище.
Если вы не спец по шеллу, то понятное дело. А так - не понимаю какие особые проблемы у шелла работать с базой данных. Консольные клиенты есть для всех нормальных баз данных.
ПОНЯТНО, что есть множество задач, для которых другие языки подойдут лучше, но в автоматизации и администрации, шелл занял надежную нишу и никуда не собирается уходить.
Проблема исключительно в том, что люди, которые не знают шелл, заранее относятся к нему с предубеждением.
Главное это не путать как товарищ ниже POSIX шелл и старые батники виндовс (которые не повершелл)
Почему же?gnu tools есть во всех дистрибутивах.
В шелл код ОТЛИЧНО переносится между разными дистрибутивами
Может быть я не правильно использую шелл, он он у меня практически всегда обвязан утилитами, начиная с того же jks или grep. Да, grep есть, наверно везде, но есть масса других утилит и путей, которые в разных дистрибутивах различны.
Если вы не спец по шеллу, то понятное дело. А так - не понимаю какие особые проблемы у шелла работать с базой данных. Консольные клиенты есть для всех нормальных баз данных.
Возможно вы правы. Но если не использовать js внутри странички( а для этого вам знания шел не достаточно ), я затрудняюсь как реализовать такую страничку, разве, что по расписанию лазить в базу и переписывать статический htm, извинит, но признать такое решение нормальным я не могу, это костыль.
. Да, grep есть, наверно везде, но есть масса других утилит и путей, которые в разных дистрибутивах различны.
То есть вы не поняли что означает термин gnu tools?
Ну почитайте их состав и почитайте что такое posix compatible shell, чтобы знать на что можно рассчитывать в ЛЮБОМ дистрибутиве.
А напомню, что POSIX это стандарт по которому сертифицирован UNIX и MacOS, и по которому Linux compatible
С шелом вам нужно обязательно знать набор утилит конкретного дистрибутива
Учитывая, что в сабветке всерьез обсуждается вызов шелла из пайтона, это звучит как *для вызова утилит конкретного дистрибутива из пайтона их знать не надо, а для вызова из терминала — надо*
Код практически нельзя комбинировать и реиспользовать, вы не можете сделать пакет работы с конкретным api и использовать его в разных местах, постепенно расширяя
Не благодарите
. <path/to/include>
. $PATH_TO_INCUDE
. $INCLUDE_DIR/$PATH_TO_INCLUDEНе хватает неймспейсов и пакетного менеджера — да. Но возможность бить код на модули и переиспользовать их никуда не делась.
ну и работа со сложными объектами, в шелл и том же python, это даже сравнивать нельзя
Для объектов в json вызывается jq, для xml xq, и, даже, угадайте для чегоyq
В конце-концов, тот же пайтон дернуть можно, передав ему на вход короткую программу
Например недавно мне понадобилась страничка записная книжка звоника для астериск, которая берет данные из базы, это вполне себе админская задача, но на шеле, я даже затрудняюсь сказать, это вообще возможно, наверно да, но это будет жуткое зрелище.
В первую очередь, это будет дырка с исполнением произвольного кода. Но да, это возможно: тот же nginx умеет (https://stackoverflow.com/questions/22891148/how-to-run-a-shell-script-on-every-request) дергать шелл, который уже может попросить постгре сделать такое (https://stackoverflow.com/questions/1517635/save-pl-pgsql-output-from-postgresql-to-a-csv-file)
Вот скрипт на баше. Который легко работает на ЛЮБОМ дистрибутиве. Да и вообще он работает и на линукс и юникс и макос и даже виндовс, если там поставить git
https://asciinema.org/a/468242
Учитывая, что в сабветке всерьез обсуждается вызов шелла из пайтона, это звучит как *для вызова утилит конкретного дистрибутива из пайтона их знать не надо, а для вызова из терминала — надо*
Использование возможно но не обязательно, просто многим админам так привычнее, они привыкли использовать эти утилиты и взывают их из python кода, так же как другие админы взывают их из шелл кода. Так можно дойти до мысли, что и шелл код "тру" только если не использует утилиты. Но эти задачи решаются и механизмами языка и его модулями, без утилит, за исключением конфигурирования этих самых утилит в случаях когда конфигурирование через конфиг файлы не поддерживается.
Не хватает неймспейсов и пакетного менеджера — да. Но возможность бить код на модули и переиспользовать их никуда не делась.
Я правильно понимаю, вы считаете переменные окружения равноценной заменой система организации проекта, переносимости кода и управления зависимостями?
В конце-концов, тот же пайтон дернуть можно, передав ему на вход короткую программу
Зачем если ее сразу можно писать на python?
В первую очередь, это будет дырка с исполнением произвольного кода. Но да, это возможно: тот же nginx умеет
Я не понимаю от куда такое желание чесать правое ухо левой рукой.
ЗЫ: Такое ощущение, что я задел какую-то священную шелл корову. Если вам нравится шелл, используйте на здоровье, я ничего не имею против данного инструмента, на нем наверно и веб сервисы можно писать. Но лично я считают, что полноценные языки типа pyhon решают все те же задачи не сложнее, но при этом могут решать "нормальным" образом значительно более широкий спектр задач. В таких условиях я не вижу смысла виртуозно бороться с ограничениями инструмента, если есть инструмент который более широкий спектр задач решает без этой боли.
Суть в том, что есть инструмент, который существует уже много десятков лет. И этот инструмент называется gnu tools
И если для большинства других языков вызов библиотек это нормально, то для языков оболочек нормально вызывать внешние утилиты. Это его "библиотеки" и функции, которых было написано множество.
Включая то, что вполне себе крупные продукты поддерживают командную строку.
Например вызвать условный psql.exe из шелл - для меня выглядит нормальным чистым кодом.
А из питона - нет, для питона должен быть пакет.
И следовательно совместимости, платформы, зависимости.. Не всегда на продакшен можно что-то лишнее поставить, а штатные gnu tools там есть всегда
условный psql.exe из шелл - для меня выглядит нормальным чистым кодом.
Ну это ваша религия, я из 1С могу и ping дернуть если надо, и sqlcmd вместо ADO, и тот же 1С в пакетном режиме для соседней базы, и даже скрипт на питоне, чтобы с телегой не через БотАпи а через клиентский АПИ пообщаться.
Если есть psql.exe - зачем зависимости, платформы, совместимости. Особенно если на питоне в данном случае не приложение, а админский скрипт?
Нет, вы не задели никаких священных коров, кроме здравого смысла. При этом у вас странненькая аргументация, что было отмечено выше, а тут вы уже дошли до соломенных чучел в паре пунктов…
Иногда надо просто остановиться.
С какой именно аргументацией в не согласны:
Python позволяет выполнить все те же действия, что и bash.
Python позволяет выполнить эти действия в большинстве случаев не сложнее чем на bash и в некоторых случаях проще( лично я считаю, что в любых случаях сложнее 10 строчного скрипта ).
Python значительно расширяет ваши возможности по решению смежных задач
"Экосистема" python имеет не сравнимые с bash возможности по переносимости кода и его реиспользованию, управления зависимостями и пакетами.
Python улучшает ваши карьерные перспективы.
Python может и не быть, а posix shell — будет
А вы продолжаете пытаться подменить контекст беседы своими мыслями о нем. Вы же понимаете, что продуктивности это не добавляет, ни в каком смысле?
Я правильно понимаю, что по существую выше сказанного, вы возражений не имеете и эти тезисы мы можем считать принятыми?
Как альтернативный аргумент вы заявляете пункт 0, об отсутствии python на хостовой системе и невозможности или не целесообразности его установки.
Я готово с вами согласится, безусловно в этом случае, когда система полностью исключает исполнение python скриптов, bash скрипты действительно будут иметь преимущество.
Отсутствие python обнуляет все его возможные преимущества и делает дальнейшее обсуждение бессмысленным.
А дальше есть универсальный путь — шелл, и более удобный в некоторых местах (а в других — нет) ЯВУ (причем все равно какой даже) на выбор у человека с определенным сочетанием кривизны рук и прямизны извилин.
Например, вам эти факторы не позволяют использовать шелл модульно, а заодно, волшебным образом, делают ненужным детальное знание работы шелл-комманд при вызове через os.exec(). А другим — позволяют первое и делают очевидным глупость второго.
Хорошо, что мы сошлись на том, что перечисленные мною преимущества безусловно есть, расхождения остались по пункту, можем ли мы считать, что отсутствие инструмента и техническая невозможность его использования на некоторой части систем ставит на нем крест.
Можем ли мы из вашего утверждения сделать вывод, о том, что bash можно будет признать не состоятельным, если мы найдем одну систему где скрипт на bash нельзя выполнить?
Пока что мы достигли согласия лишь в том, что если пайтона нет то его использовать не получится в принципе.
Нет, вывод такой вы сделать не можете, поскольку подменяете общее (posix shell) решение — частным случаем (bash). Если хотите идти по этому пути, тогда придется признать несостоятельным пайтон, если найдется какой-нибудь скрипт на пайтоне, который не запустится на какой-нибудь системе. А он найдется.
Так собственно об этом вы и говорите, python не состоятелен, поскольку есть системы где его нет, во всяком случае именно так вы представили ваш аргумент.
Это объективный факт. Если он вам не нравится — это лично ваши трудности.
Следуя этой логике, если есть системы где нет средства для исполнения скриптов на произвольном языке X, то X не состоятелен?
Разумеется в нашем контексте, как средство для написания скриптов.
Вы же сами предложили такой критерий, а теперь удивляетесь, что стрелочка, оказывается, таки поворачивается.
UPD: разумеется, в том же контексте, да.
khajiit
Python может и не быть, а posix shell — будет
Вы же сами предложили такой критерий, а теперь удивляетесь, что стрелочка, оказывается, таки поворачивается.
Данный критерий, это ваше утверждение 5 часовой давности.
Вероятно, я не слишком хорошо в этом, наши представления о корректном видении дискуссии и аргументации слишком различны, чтобы мы могли прейти к какого либо полезному результату. Предлагаю завершить, этот не продуктивный дискурс.
Вы видимо ограничены своим кругозором разработчика и не работали с инструментами админов, поэтому плохо представляете себе насколько широко интегрирован shell в различные ci/cd системы из коробки.
Jenkins, Teamcity - поддерживают выполнение bash практически нативно. Для питона там нужно дополнительно его готовить.
Вызов внешних программ и их обработка (банальный start/stop скрипт с установкой переменных окружения, запуском программы, сохранения ее pid файла - я не представляю, как на питоне это может выглядеть проще или лучше.
Докерфайл, как вы там питон прицепите?
Польщен, что вы обнаружили у меня кругозор разработчика, но нет, я не разработчик.
C jenkins я не имею плотного опыта работы, но teamcity не требует никакой значительной дополнительной готовки для исполнения python скриптов, насколько я помню начиная с 2020, ранее для этого был плагин.
Вызов внешних программ и их обработка (банальный start/stop скрипт с установкой переменных окружения, запуском программы, сохранения ее pid файла - я не представляю, как на питоне это может выглядеть проще или лучше.
Мы все еще говорим именно о скриптах или о непосредственном выполнении команд в CLI?
Докерфайл, как вы там питон прицепите?
Я не понимаю, что вы подразумеваете под термином "прицепите", докер файл его как бы никуда не прицепляют. Это конфиг для сборки образа.
Мы все еще говорим именно о скриптах или о непосредственном выполнении команд в CLI?
В том-то и дело, что shell это не просто скриптовый язык программирования, а одновременно и CLI оболочка, что позволяет его использовать очень широко и позволяет команды CLI автоматизировать без лишних вещей.
И опять. Вам много раз сказали волшебное слово posix. Почитайте уже что это и сколько систем с ним совместимы, чтобы понять почему скрипты на шелле можно выполнять почти везде. Причем для многих ОС внутренние команды шелла могут быть продублированы внешними бинарниками, на случай если шелл что-то сам не поддерживает. Чтобы все было совместимо.
Затем, чтобы (не знаю я линкуса, извините) вместо
FOR /f "tokens=1-7 delims=/-:., " %%a IN ("%DATE: =0% %TIME: =0%") do (
SET NewBk=.\Docs_Sample_%%c.%%b.%%a_%%d.%%e.%%f.%%g.dt
)
Написать
Дата = ТекущаяДата();
ИмяФайла = ".\Docs_Sample_" + Формат(Дата, "dd.MM.yyyy_hh.mm")+".dt";
И потом вызвать команду системы. Точнее в данном случае даже приложение в пакетном режиме. Причем на втором языке я пишу все время и так, а первый вариант - чистое SO-дривен, так как ну нафига мне часто продвинутые возможности батников?
Для линукса это не так очевидно, ибо там будет что-то вроде
declare -A BASES="<bases list>"
for B in $BASES; do <backup utility name> <options> -o "<backup folder>/$B_`date +%F%T`.dt"; done
При этом и BASES тоже можно заполнить скриптом, и сложить это все в отчет, и дернуть sendmail в конце
потому что не нужно путать MS батники и линукс shell
Использовать xonsh?
а потом xoffsh для устранения последствий?
O_o Оно, кстати, нагугливается, и является шелл-скриптом )
В статье зачем-то много раз повторяется мантра про "администрирование севера это вымирающее искуство", как будто автор хочет заставить нас в это поверить с помощью НЛП.
Камон, в мире очень много легаси проектов, которые долго еще будут использовать дедики и виртуалки. Да и сам Амазон иногда говорит, что "для этого облачного севриса вам нужно развернуть EC2 инстанс", и хоть он и развернется из шаблона, но все же это уже живой сервер, в который кто-то должен уметь зайти глянуть почему что-то не работает.
Ну и армия девопсов вроде не уменьшается, неужели все станут клик-опсами?
А я так и не успел понять зачем облака: там всё сложно, хитро, неэффективно. Сейчас вот пришёл чувак и объяснил: всё нормально, так всё и есть. Осталось дождаться следующего, который скажет: так всегда и было.
А я так и не успел понять зачем облака
Если без DevOps практик, то чтобы не заботиться о железе. Или для разовых задач/тестов когда нужно например обучить нейросеть, а покупать навсегда кучу видеоускорителей, что бы воспользоваться ими один раз -- нецелесообразно.
С девопс практиками сфера применения расширяется: можно например автоматически масштабироваться в зависимости от нагрузки, что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными, а пользователи при этом не будут жаловаться, что ваша онлайн игра легла прямо в долгожданный новогодний ивент. Можно обновляться без простоя, можно плавно перестраивать архитектуру разворачивая временные схемы и уничтожая их, когда они стали ненужными и так далее. В общем те же плюсы, из-за которых люди в принципе используют аутсорс или аренду.
Специализация, сертификация, безопасность, замена capex на opex, экспорт многих рисков... Да много чего, и это не бесплатно. Поэтому свою железку и облако сравнивать лишь бухгалтерским способом не вполне корректно.
Все с точностью до наоборот. Без DevOps лезть в облака финансово опасно, там столько подводных камней, которые просто приведут к сжиганию кучи бабла.
Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
можно например автоматически масштабироваться в зависимости от нагрузки
Ага, только это все маркетинговый bullshit, как только дело до этого доходит, то получаем попу, разного размера. Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач - а веб как раз и не является такими задачами.
что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными
Ага, только на практике ты вряд ли нормально настроишь лимиты, поэтому тот же гугл пытается использовать ИИ для управления ресурсами, и клиентам предлагает autopilot для решения этой задачи. Но получаеться не очень, все тоже сжигание бабла, потому как поднимает лимиты на любой чих, а вот понижать уже сам не будет. Вызвал клиент раз в месяц эндпоинт для генерации тяжелого отчета - лимиты поднялись, и все с этого момента платишь за ресурсы по новым лимитам. Если без автопилота с жесткими лимитами, то у тебя просто перегрузиться контейнер, и по F5 клиент пойдет перегружать соседний контейнер - отчет то он хочет получить.
Можно обновляться без простоя, можно плавно перестраивать архитектуру разворачивая временные схемы и уничтожая их, когда они стали ненужными и так далее.
Это все можно получить и без облаков.
И при всех плюсах у облаков достаточно минусов. И нужно прям сильно хорошо понимать зачем и почему нужно облако для запуска нагрузки в нем.
А ещё хочется добавить, что облака, в особенности публичные, это перепродажа того же самого железа, только за куда более существенные деньги. В облаках зашито много маркетинга и надо это понимать. Не стоит забывать, что облачным провайдерам очень выгодно пушить многие популярные нынче практики, раздувающие использование сервисов просто в разы.
Пример с нейросеткой - это прям очень сильно узкая ниша, и которая появилась сильно позже облаков и всей этой облачной истерии.
Пример с нейросеткой выбран просто как самый наглядный и понятный, сама сфера GPGPU гораздо шире и появилась тоже не вчера.
Начиная от того что cpu/memory usage метрики не годятся для не cpu/memory bound задач
Но ведь вы можете пользоваться теми метриками, которые посчитаете нужными. А вэб он разный, сейчас чего только не делают в вэбе, да и далеко не все сервера в интернете это именно вэб.
Это все можно получить и без облаков.
Конечно можно, только если вам для этого нужны дополнительные мощности на время, например чтобы поднять что-то параллельно, то не всегда имеет смысл покупать необходимое для временных задач железо навсегда. Опять же, смотря что считать облаками. Кто-то понимает этот термин более узко, а кто-то более широко, с моей точки зрения, если это VPS, а не колокейшн или арендованый дедик в датацентре, то это уже облака, а кто-то под этим понимает только PaaS.
Само собой, что облака это инструмент, которым нужно пользоваться, если он подходит для вашей задачи. Странно арендовать экскаватор, если вы хотите выкопать яму 2х2х1, но отказываться от использования экскаватора при выкапывании котлована, потому что при желании это можно сделать и лопатой -- не менее странно.
можно например автоматически масштабироваться в зависимости от нагрузки, что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными,
Можно конечно. Только все чаще оказывается что ДЕШЕВЛЕ купить эти сервера, даже с учетом того, что они будут задействованы только на 10%.
Моя компания переезжает из облаков в on-prem. Экономический эффект - миллионы долларов в год.
Посчитали, что сравнимую конфигурацию в железе нам дешевле содержать в 5 раз, чем в облаке! И это не смотря на лихие корпоративные скидки. Экономисты считали: с аммортизацией, поддержкой и т.п.
А тяжелые ноды для кэшей (терабайты RAM и NVMe) - там экономия еще больше.
В облаках тоже не альтруисты собственники - они тоже считают неплохо.
Оптимальная конфигурация при переменной нагрузке: мин. загружать на on-prem, а спайки докупать в облаке.
Только все чаще оказывается что ДЕШЕВЛЕ купить эти сервера, даже с учетом того, что они будут задействованы только на 10%.
Понятно, что это все индивидуально. Кому-то может быть дешевле и выгоднее даже свой ДЦ построить, вместо того чтобы где-то размещаться, но это не значит, что это выгоднее всем и всегда. Я не думаю, что в какой-нибудь Wargaming никто не умеет считать, и поэтому они пользуются AWS а не ушли в on-prem, и что у других клиентов AWS такая же история, и там тоже никто не умеет считать.
что позволит не покупать лишние сервера, которые будут 90% времени стоять незагруженными, а пользователи при этом не будут жаловаться, что ваша онлайн игра легла прямо в долгожданный новогодний ивент.
А почему многие конторы, даже мастодонты вроде Blizzard об этом не знают? И по сей день мы нередко видим, как на крупных релизах лагают и ложатся сервера. Или может у этих компаний не хватает денег арендовать достаточно мощностей?
ну в случае близзард, и прочих игрушек, как мне кажется, важнее не получить по cap-теореме сплит-брейна за счет сниженного availability
А кто сказал, что их не устраивают ажиотаж и очереди после выхода очередного дополнения?
Сложно и хитро да, насчёт неэффективно это вопрос. Облака это сервис, для чего то они подходят лучше но не решают всех проблем на свете. Я например личные сайты, размещаю на aws и это не стоит мне почти ничего (меньше доллара в месяц)
Сайт раздаётся с s3 (файловое хранилище) через cloudfront (cdn), ssl сертификат от certificate manager, сам ротируется, бэкенд на api gateway + lambda + dynamodb.
Но ChatGPT реально удивляет, подсказывая такие варианты синтаксиса Bash, о которых вы даже не знали, например, расширение параметра с вложенными скобками др
Это же базовый функционал.
То, что программисты, которые никогда не изучали баш, и считают его недоязыком, внезапно открывают для себя, что в bash есть довольно много разных интересных встроенных возможностей, не значит что chatGTP говорит больше, чем документация.
Не знаю как у девопсов, но у разработчиков сейчас такие тенденции, что работодатели очень сильно хотят экономить на первых и скидывать их работу на вторых, не отменяя работы последних для KPI. Я не так давно ушел из одного весьма не бедного банка из первой десятки, потому что выгорел с этой херни до состояния "видеть работу не могу, хочу спать больше 4х часов", занимаясь наладкой инфраструктуры, пытаясь выбить ресурсы неделями, экспериментировать с конфигурациями и чуть ли не все свое свободное время после работы и во время работы это вот, т.к я достаточно ответственный человек... ну а топ админы говорили набрав в рот воды, что "ваша команда админит полностью ваш тенант, у нас туда доступов нет, ни к сервисам, ни к раннерам, никуда, еб***** сами (с) ваши инженеры по инфраструктуре". Занимался этим 3 месяца, почти не делая своей профильной работой на проекте вообще, где я силен, а задачи то 'висят'. Получилось так себе, не хочу больше работать с этим всем далее как "создать конфиг сервиса по шаблону/докам" и тем более с кучей кастомных инструментов by devops, у которых, как правило, нет документации, и ты сидишь и редеплоишь сутками * конфиги, читаешь исходники утилит, чтобы понять что они делают и как все это работает вместо девопсов... и тебе на каждом дейлике стремно говорить о том, что ни черта не получается... Не в жизнь больше не буду работать там, где на меня такое повесят эффективные манагеры...
Отличный пример, описанный фразой "кроилово приводит к попадалову" ©
В вашем случае потерян разработчик. Кстати, теперь то понятно почему админы ненавидят принтеры? :)
Без обид - но это ваш личный косяк. Вы позволили совоменеджерам сесть себе на шею, что они обычно с великой охотой проделывают, как только находят подходящую жертву. Надо четко понимать границы своих компетенций и не лезть не в свою область, если вы, конечно, не собираетесь мигрировать в другую специальность, но из вашего поста я понял что не собирались.
Я бы вот в ответ на "еб***** сами" просто скинул эту проблему на менеджмент проекта, и пускай они там с топадминами сами разбирались, это их работа, им за это зарплату (весьма нехреновую) платят, а сам бы занимался своими задачами, в которые я умею и разбираюсь.
Да, во многом вы правы. Началось то все с благодати, я наконец-то смог освободить время под развитие процессов на проекте, предложил менеджеру и ребятам перейти на TBD, что мы сделали, развитие поперло, скорость фич на коротком горизонте, хотел развернуть готовый бек и фронт для работы с фича тоглами (Unleash)... чтобы бекенд еще наш интегрировать с тоглами, лекции для тестировщиков по работе записал, библиотеку для работы с фронтов с ним написал. И понеслась... То критические баги в этом готовом решении, то херня с инфраструктурой, то отсутствие доступов. Постоянная долбежка архитектору, который единственный и имеет доступы ко всему в тенанте (к нему предъяв никаких, он тоже не знал че делать), девопсам и админам, всех доступных уровней с попыткой понять, что я не так делаю, запрос ресурсов для тенанта..., и отговорки про то, что это не наша зона компетенций (и это правда так, потому что команды отдалили от тех. поддержки максимально)... В результате сел сам разбираться, но тяжело шло, а больше всего времени тратил на бесконечные редеплои конфигурации, пытаясь угадать, что не так... И так вот до конца. По итогу решил все проблемы, но ресурсов не было чтобы развернуть, и тут я уже так сгорел, что толком не смог нормально продолжать работать. До сих пор отойти не могу никак с этой дичи, сплю урывками по 4 часа без работы, даже не пытаюсь устраиваться, благо есть возможность, а уже 2.5 месяца прошло почти, подумываю уже мб пора сходить к неврологу за таблетками...
Эх.. сочувствую, жиза, все эти банки, да и вообще всякие крупные корпорации так забюрократизированы, что больше борешься с системой, чем с какими-то профессиональными задачами. Я по этой причине с одного банка так уволился, достало биться башкой о стену, когда каждый чих сопровождается сбором десятка согласований. Девять кое-как выдерешь, на десятом на какого-либо начальника шлагбаума нарвешься, который не дает добро просто потому что..
Звучит знакомо. Цитата инженеров по инфраструктуре даже имеет смысл, если они действительно занимаются инфрой, а не девопсом.
«Не истина та победа, что добыта чужим оружием»
...Bash-скрипты могут сделать абсолютно всё: и сгенерировать сайт...
И в игру поиграть piu-piu, и утилиту для ssh сделать sshto и для модного кубера kube-dialog...
Творите, выдумывайте, пробуйте!)
Сисадмины, которые разве что умели лишь следить за тем, чтобы приложение и база не упали, да порты нужные открывать/закрывать. Они едва ли знали, что и зачем нужно
То ли дело девопсы... и приложение тебе соберут, и выкатят всю эту гигантскую инфру микросервисов и прочей ерунды. И так же, проследят, чтобы поды не упали да порты прокинут нужные
Мб автор не шарит за девопс, особенно в бигтехе. Или за приложения, кроме тех, что с одним интансом приложения и одним интансом бд
Администрирование Linux серверов и решение проблем с производительностью инфраструктуры, скалирование системы на более высокие нагрузки, отказоустойчивостью и и тд безусловно вызывают интерес, только вот к работе программиста, особенно в крупных компаниях, это почти не имеет отношения и подобными вещами занимаются SRE/DevOps инженеры.
Ведь программирование — как зависимость, организм получает кайф и требует повышения дозы.
По опыту работы в крупном Энтерпрайзе РФ и зарубежом, работа программиста сейчас даже на уровне Senior это копипаст кода по шаблону и бесконечная война в комментариях кодревью из-за условной скобки, поставленной не на той сторке (к сожалению, по опыту трех разных компаний за крайние 4 года, 99% комментариев к ревью именно такие). Посмотрев на все это я перешел в девопсы и ниразу не жалею.
Таким образом, ChatGPT может выполнять роль инструктора и учителя в чём-то…
Я джун SRE, использую иишки (не только chatgpt) чтобы исследовать варианты работы с неизвестными мне областями профессии чтобы не тыкать старшего постоянно и не заставлять его меня бейбиситить. Вывод ии можно проверить или переработать под актуальный тип работы, и они показывают иногда штуки и связи о которых мой джунский мозг даже не догадывался.
Отличная статья, согласен с главной мыслю публикации.
Работаю Linux Админом, разрабатываю код на Ruby и Puppet DSL для инфраструктуры.
Считаю что все зависит от бизнес модели вашей компании от неё в большей степени отталкивается логика приложения а дальше Разработчики с Админами придумывают как с этим жить.
Если у вас Облака то надо постоянно искать где ужаться, меньше логов от приложения сохранять, измерять скорость CI, наблюдать все что тратит денежку, следить за законами какие данные можно хранить в Облаке какие нет, сами Приложения тоже должны уметь расширяться, скалироваться, шардироваться и так далее, также нужно следить за инфляцией, повышением тарифов, отслеживанием ресурсов, подсчетом этих ресурсов, изучением и сравнением других облаков.
Если у вас свои сервера то фокус идет на закуп, инвентаризацию, автоматизацию, возможность безопасных, повторяймых конфигураций, придумывание процессов для снижение различий в настройках серверов, создание определенных возможностей которые требует именно ваша инфраструктура, документировании своих решений, в итоге сами себе облачный провайдер
Сильным вариантом будет гибридный ландшафт, пара публичных облаков и свое внутренее облочко))
а тут нас ждут все достоинства и недостатки разом
И как пишет автор
Уметь настроить linux в такой ситуации это действительно одно из выгодных вложение =)
Управление Linux-сервером — самая ценная инвестиция