МД
Чтобы не перебирать варианты из гугла на практике
Я видел в форумах задания на накрутку AT
Size: a a a
2020 August 28
P
Я видел в форумах задания на накрутку AT
Там много накручивать придется. Да и сколько неинакручивай - фильтр по опенсорсному все равно выдаст нужное
МД
Там много накручивать придется. Да и сколько неинакручивай - фильтр по опенсорсному все равно выдаст нужное
В итоге придём к повсеместной рекламе 0% пива
P
В итоге придём к повсеместной рекламе 0% пива
Надеюсь к тому моменту я уже буду кормить червей)
A
с позиции разработчика, а не DevOps-инженера, поэтому biased.. но тем не менее.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
A
с позиции разработчика, а не DevOps-инженера, поэтому biased.. но тем не менее.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
да, вывод из всего этого такой, что иногда захожу на сервера и смотрю глазами, как оно в целом, надо ли чего.. всё ли в порядке..
для всего остального предпочитаю те средства автоматизации, над которыми имею какой-то контроль:
- понимание принципов работы,
- отражено в диаграме IT инфраструктуры,
- стоимость поддержки не превышает 30 минут в месяц
для всего остального предпочитаю те средства автоматизации, над которыми имею какой-то контроль:
- понимание принципов работы,
- отражено в диаграме IT инфраструктуры,
- стоимость поддержки не превышает 30 минут в месяц
A
поэтому проголосовал за 1 вариант опроса.
МД
с позиции разработчика, а не DevOps-инженера, поэтому biased.. но тем не менее.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
Для этого есть jx - комиттишь настройки в scm - и он перезапускает ноду
МД
да, вывод из всего этого такой, что иногда захожу на сервера и смотрю глазами, как оно в целом, надо ли чего.. всё ли в порядке..
для всего остального предпочитаю те средства автоматизации, над которыми имею какой-то контроль:
- понимание принципов работы,
- отражено в диаграме IT инфраструктуры,
- стоимость поддержки не превышает 30 минут в месяц
для всего остального предпочитаю те средства автоматизации, над которыми имею какой-то контроль:
- понимание принципов работы,
- отражено в диаграме IT инфраструктуры,
- стоимость поддержки не превышает 30 минут в месяц
Значит, у тебя плохой мониторинг
Д
Всем добрый день!!!
Вот у меня есть проект на dot net, который крутится на redhat8 и апачи, исходники на гитхабе.
Посоветуйте как организовать CI/CD, плз) Я в этом деле новичок.
Еще надо чтобы был откат к предыдущим версиям
Вот у меня есть проект на dot net, который крутится на redhat8 и апачи, исходники на гитхабе.
Посоветуйте как организовать CI/CD, плз) Я в этом деле новичок.
Еще надо чтобы был откат к предыдущим версиям
N
мне интересно узнать сколько людей еще что-то делает руками на линуксе, без использования современных средств автоматизации т.к. от результатов опроса можно будет сделать вывод, насколько корректны и современны вопросы по глубокому знанию линукс\виндов и других систем на собесах (при этом про кубер спрашивают ничего или два-три простых вопроса)
намного больше, чем вы думаете!)
A
намного больше, чем вы думаете!)
да как оказалось да...ну или вопрос составлен не очень корректно т.к. многие ставят руками, чтобы написать плейбук ;D
DS
с позиции разработчика, а не DevOps-инженера, поэтому biased.. но тем не менее.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
не всегда нужен докер, кубернетес и ансибл..
- для закрытых систем достаточно иметь watchdog, который перезапустит приложение, если что-то идёт не так.
- настройки приложения могут быть те, которые не меняются после старта, и те, которые меняются.
- хорошая практика уметь подхватывать налету настройки приложения при изменении и писать историю изменений (либо диффы, либо снапшоты с датой изменения, период хранения истории зависит от требований бизнеса, иногда требуется 10 лет хранить историю).
- если речь о микросервисах, то хорошая практика иметь под рукой карту IT инфры.
- другая хорошая практика - трекать зависимости между компонентами и уметь делать проверку на консистентность настроек как на этапе сборки приложения, так и в рантайме.
- из этого вытекает другая практика - уметь нотифицировать во всякие телеграмы-слаки-почты-смсшлюзы в случае ошибок.
- некоторые делают билд-деплой-тулы, которые могут в идеале развернуть любое окружение (дев-стейджинг-куа-прод). такие штуки оркестраторы пайплайнов также могут быть написаны руками.
- докер и кубер накладывают поверх линукса минимум два слоя абстракций, это дополнительная когнитивная нагрузка.
и конечно, нужно понимать, если эти практики не внедрены и не поддерживаются, а команда >50 человек или 100500 систем, то тогда да.
всё зависит от конкретной ситуации, конечно же.
- для моих нерабочих задач k8s, docker, ansible - дополнительная когнитивная нагрузка, которая мешает бизнесу, отбивающему затраты на хостинг и дающий право попивать кофеёк лишний раз в течение дня.
- для моих рабочих задач docker и ansible - дополнительное время на отладку и траблшутинг при апгрейде версий данного ПО. и не всегда это 20-120 минут (зачастую выпадает >1 дня). но я признаю, что достаточно тупой разработчик, а аппеляция к личному опыту - моветон.
знаю я такое "дополнительная когнитивная нагрузка, которая мешает бизнесу". Пришел работать а там 100+ bare-metal серверов админили разрабы на баше. Ничего не мониторилось, что-то упало, хз куда идти чинить, бэкапов нет. Пароль от всех баз что-то типо 1223qwerty, СУБД торчат на ружу голой попой.
Но я не против, мне же потом платят, чтобы я пришел это и разгреб нормально
Но я не против, мне же потом платят, чтобы я пришел это и разгреб нормально
IP
да как оказалось да...ну или вопрос составлен не очень корректно т.к. многие ставят руками, чтобы написать плейбук ;D
Ага плейбучить на проде с «0» как то стремновато
A
знаю я такое "дополнительная когнитивная нагрузка, которая мешает бизнесу". Пришел работать а там 100+ bare-metal серверов админили разрабы на баше. Ничего не мониторилось, что-то упало, хз куда идти чинить, бэкапов нет. Пароль от всех баз что-то типо 1223qwerty, СУБД торчат на ружу голой попой.
Но я не против, мне же потом платят, чтобы я пришел это и разгреб нормально
Но я не против, мне же потом платят, чтобы я пришел это и разгреб нормально
1. ну так это как раз от следствия отсутствия хороших практик.. все эти детские болезни либо лечатся, либо не лечатся и становятся хроническими
2. я ниже в оригинальном сообщении написал, что всё зависит от ситуации, а 100+ bare-metal серверов - это как раз та ситуация, когда не следует пренебрегать мощными инструментами/абстракциями
2. я ниже в оригинальном сообщении написал, что всё зависит от ситуации, а 100+ bare-metal серверов - это как раз та ситуация, когда не следует пренебрегать мощными инструментами/абстракциями
DS
1. ну так это как раз от следствия отсутствия хороших практик.. все эти детские болезни либо лечатся, либо не лечатся и становятся хроническими
2. я ниже в оригинальном сообщении написал, что всё зависит от ситуации, а 100+ bare-metal серверов - это как раз та ситуация, когда не следует пренебрегать мощными инструментами/абстракциями
2. я ниже в оригинальном сообщении написал, что всё зависит от ситуации, а 100+ bare-metal серверов - это как раз та ситуация, когда не следует пренебрегать мощными инструментами/абстракциями
ну так начинали то они с одного), только практики перетекли на 100+
A
Ага плейбучить на проде с «0» как то стремновато
ну так я и не надо сразу на проде. у тебя есть виртуальные стенды. Опять же какие тесты я просто гоняю на локальной виртуалке
A
ну так начинали то они с одного), только практики перетекли на 100+
хронические болезни, запущенные состояния.. показана хирургическая операция!
DS
хронические болезни, запущенные состояния.. показана хирургическая операция!
а все потому что "дополнительная когнитивная нагрузка, которая мешает бизнесу"
A
а все потому что "дополнительная когнитивная нагрузка, которая мешает бизнесу"
почему?
1. вы прочитайте оригинальное предложение полностью: "дополнительная когнитивная нагрузка, которая мешает бизнесу" идёт вместе с "для моих нерабочих задач". у меня, это как правило, 1-3 сервера. для них диаграмма IT инфраструктуры выглядит одним образом.
2. вы говорите про ситуацию, когда несколько серверов перерастает в 100+ bare-metal серверов. это же совсем другое дело!!!
- совсем другая диаграмма IT инфраструктуры,
- и совсем другая когнитивная нагрузка.
3. изменение диаграммы должно отлавливать изменение сложности системы.
1. вы прочитайте оригинальное предложение полностью: "дополнительная когнитивная нагрузка, которая мешает бизнесу" идёт вместе с "для моих нерабочих задач". у меня, это как правило, 1-3 сервера. для них диаграмма IT инфраструктуры выглядит одним образом.
2. вы говорите про ситуацию, когда несколько серверов перерастает в 100+ bare-metal серверов. это же совсем другое дело!!!
- совсем другая диаграмма IT инфраструктуры,
- и совсем другая когнитивная нагрузка.
3. изменение диаграммы должно отлавливать изменение сложности системы.