тоже с телефоном стал такой трюк делать, немного помогает не отвлекаться, особенно когда задача какая-то непонятная\страшная\новая. хотя и понятно, что причина в другом и это не решение проблемы)
Вы следуете по чьему-то опыту, ваших родителей быть может?) Звучит как попытка решить все возможные проблемы заранее на все случаи жизни из-за какой-то тревожности :) Озаботиться решением всех проблем и подготовительных вопросов нужно, но не до такой же степени :)
Не думаю, что вас и тысячи ваших ровесников по такому принципу "заводили" в своё время.
Спасибо за материал. Многими штуками пользовался и пользуюсь. Считаю, что чем проще сделано - тем лучше. Отлаживать эти пайпы то ещё удовольствие, особенно когда они тиражируются на кучу проектов.
Когда я сам делал типовой пайп для приложений, старался сделать стандартную и понятную всем коллегам историю с минимум сложностей. Но даже в этом случае, спустя пару лет, когда заходишь посмотреть и думаешь: блин, а как оно там было и зачем... Без документации ещё не всегда вспомнишь почему так или иначе в каком-то месте реализовано. Впрочем, как и везде)
А есть какие-то оверхеды подключенных библиотек для такого профилирования? Есть ли какие-то проблемы с просадкой производительности, мб НТ до и после делали?
Спасибо за статью! Когда-то пробовал перетаскивать drupal и битрикс в куб, это всё неприятно конечно %)
Подскажите, пожалуйста, а конечное решение в части прямого доступа к сайту и доступа через защиту от ддос реализовано через переключение днс? Типа по дефолту ходим напрямую через свой ингрес контроллер, а если пошёл ддос, то переключаем днс?
Иногда DevOps - это самый обычный подтиратель задниц (аля эникей) только для программистов.
Всё так и есть :) На многих проектах приходилось этим заниматься, никакой синергии от dev и ops там нет и не было, "у нас пайп не прошёл, это к девопсам" или "я не знаю как там мавен собирает, у меня локально всё ок"
Интересно, спасибо. У себя использовал secret injection webhook of Bank-Vaults , показалось удобнее: ставится ванильный аргосд, настраивается единожды интеграция с волтом в кластере куба и дальше для любых манифестов в аннотациях пишутся нужные пути, и так же как и в статье, можно вытягивать секреты через secret: <path:path/to/secret/in/vault#secret_key>
Удобно тем, что работает без всяких плагинов в самом арго. Как для helm чартов можно использовать для деплоя инфра приложений, так и для всяких микросервисов.
Спасибо, статья интересная. Идея "Мы стремимся избавить продуктовые команды от DevOps-специалистов" звучит отлично, а как с этим на практике?
В своём опыте работал в разных командах и везде разный уровень людей в разработке. Кто-то постоянно в запаре и не может/не хочет вникать вообще во что-то из девопс задач: деплой в прод ночью, откат, добавить переменную окружения к микросервису и ещё кучу всего, что обычно просят нас делать :) Люди либо не хотят, либо не умеют вникать, потому что привыкли, что есть девопс к которому можно прийти и попросить сделать, потому что это всегда девопсы и делают.
Полагаю, что для достижения желаемого ( из моего первого абзаца) должен быть очень высокий уровень процессов и культуры в команде/проекте. Что вообще редкость. Я, например, нигде не видел настоящего CI, чтобы каждый день все правки шли в мастер и была постоянная интеграция. Что говорить про остальное)
Здравствуйте, спасибо за статью! Подскажите, пожалуйста, стоит ли игра свеч для небольшой команды (до 10-15 чел), где есть отдельные команды, представляющие по сути всё то что должно быть в платформе, по отдельности?
Хочется понять, насколько это вообще нужно в таких случаях. Вроде унификация и одна точка входа - это хорошо. Но когда оно уже всё есть где-то отдельно и рулится другими командам (гит и ci/cd, таск трекер, облако с мордой и т.п.), а ты как инженер всего лишь помогаешь разработке чтобы собиралось и деплоилось, кажется весьма избыточным и неприменимым решением маленького командного уровня.
Возможно, это даже риторический вопрос, т.к. в первой части статьи было написано, что idp сейчас внедряют крупные компании. Но может быть у вас уже есть опыт внедрения таких решений в маленьких масштабах)
Спасибо за статью. Подскажите, пожалуйста, а как можно было бы реализовать б\г, когда есть микросервисная архитектура и приложения общаются между собой без ингреса через сервисы?
Допустим, есть под А, и в этот под обращается под Б, В, Г и т.п. Если я задеплою новую версию пода А, как другие поды должны узнавать, что есть новая версия и к ней нужно обращаться, чтобы протестировать новую версию?
Это не говоря про то, что нужно будет деплоить новые версии всех зависимых приложений вместе сразу - и А, и Б, и В и т.д. :)
В голову приходит использование только через service mesh, но и то не конкретная реализация. Там тоже надо подумать.
Если вдруг у вас есть какие-то мысли по этому поводу, буду благодарен.
Идея хорошая и в целом мне нравится. Но вот отлаживать это всё дело, если что-то пошло не так, или добавлять новое - не особо удобно, прыгая по всем репам и абстракциям, пытаясь вспомнить как оно было и что куда добавить. Особенно если один раз настроили и забыл :)
Да и сам gitlab ci для отладки в целом так себе. Типа "echo debug", run pipeline, "блин, не то, заново". И так 20 раз.
У меня были три 8-ки, которые "подтачивали" корни соседних и сдвигали зубной ряд, поэтому удалил. Они были ретинированные и было явное показание к удалению. Осталась лишь одна 8-ка последняя, но она никак не мешает, поэтому пока не спешу с ней. Хотя по-хорошему надо бы выпилить уже)
В рекомендациях стоматологов, которых встречал, всегда было предложение об удалении восьмёрок, если они не несут полезной функции.
спасибо большое за статью, хорошая работа проделана. а такой продукт как signoz не рассматривали? вроде на coroot похож, из коробки также и метрики и карты строит с трассами. но ui посимпатичнее.
тоже с телефоном стал такой трюк делать, немного помогает не отвлекаться, особенно когда задача какая-то непонятная\страшная\новая. хотя и понятно, что причина в другом и это не решение проблемы)
Вы следуете по чьему-то опыту, ваших родителей быть может?) Звучит как попытка решить все возможные проблемы заранее на все случаи жизни из-за какой-то тревожности :) Озаботиться решением всех проблем и подготовительных вопросов нужно, но не до такой же степени :)
Не думаю, что вас и тысячи ваших ровесников по такому принципу "заводили" в своё время.
Спасибо за материал. Многими штуками пользовался и пользуюсь. Считаю, что чем проще сделано - тем лучше. Отлаживать эти пайпы то ещё удовольствие, особенно когда они тиражируются на кучу проектов.
Когда я сам делал типовой пайп для приложений, старался сделать стандартную и понятную всем коллегам историю с минимум сложностей. Но даже в этом случае, спустя пару лет, когда заходишь посмотреть и думаешь: блин, а как оно там было и зачем... Без документации ещё не всегда вспомнишь почему так или иначе в каком-то месте реализовано. Впрочем, как и везде)
tcp-стек в Linux писал русский товарищ из наукограда Дубна, насколько знаю. чем не русская ОС условно говоря)
Тоже в печали с такой проблемой. Не нашли решения?
А есть какие-то оверхеды подключенных библиотек для такого профилирования? Есть ли какие-то проблемы с просадкой производительности, мб НТ до и после делали?
Спасибо за статью! Когда-то пробовал перетаскивать drupal и битрикс в куб, это всё неприятно конечно %)
Подскажите, пожалуйста, а конечное решение в части прямого доступа к сайту и доступа через защиту от ддос реализовано через переключение днс? Типа по дефолту ходим напрямую через свой ингрес контроллер, а если пошёл ддос, то переключаем днс?
Всё так и есть :) На многих проектах приходилось этим заниматься, никакой синергии от dev и ops там нет и не было, "у нас пайп не прошёл, это к девопсам" или "я не знаю как там мавен собирает, у меня локально всё ок"
Интересно, спасибо. У себя использовал secret injection webhook of Bank-Vaults , показалось удобнее: ставится ванильный аргосд, настраивается единожды интеграция с волтом в кластере куба и дальше для любых манифестов в аннотациях пишутся нужные пути, и так же как и в статье, можно вытягивать секреты через
secret: <path:path/to/secret/in/vault#secret_key>Удобно тем, что работает без всяких плагинов в самом арго. Как для helm чартов можно использовать для деплоя инфра приложений, так и для всяких микросервисов.
а что за новая схема? расскажите, пожалуйста, кратко
Спасибо, статья интересная. Идея "Мы стремимся избавить продуктовые команды от DevOps-специалистов" звучит отлично, а как с этим на практике?
В своём опыте работал в разных командах и везде разный уровень людей в разработке. Кто-то постоянно в запаре и не может/не хочет вникать вообще во что-то из девопс задач: деплой в прод ночью, откат, добавить переменную окружения к микросервису и ещё кучу всего, что обычно просят нас делать :) Люди либо не хотят, либо не умеют вникать, потому что привыкли, что есть девопс к которому можно прийти и попросить сделать, потому что это всегда девопсы и делают.
Полагаю, что для достижения желаемого ( из моего первого абзаца) должен быть очень высокий уровень процессов и культуры в команде/проекте. Что вообще редкость. Я, например, нигде не видел настоящего CI, чтобы каждый день все правки шли в мастер и была постоянная интеграция. Что говорить про остальное)
Спасибо за быстрый и развернутый ответ.
Здравствуйте, спасибо за статью! Подскажите, пожалуйста, стоит ли игра свеч для небольшой команды (до 10-15 чел), где есть отдельные команды, представляющие по сути всё то что должно быть в платформе, по отдельности?
Хочется понять, насколько это вообще нужно в таких случаях. Вроде унификация и одна точка входа - это хорошо. Но когда оно уже всё есть где-то отдельно и рулится другими командам (гит и ci/cd, таск трекер, облако с мордой и т.п.), а ты как инженер всего лишь помогаешь разработке чтобы собиралось и деплоилось, кажется весьма избыточным и неприменимым решением маленького командного уровня.
Возможно, это даже риторический вопрос, т.к. в первой части статьи было написано, что idp сейчас внедряют крупные компании. Но может быть у вас уже есть опыт внедрения таких решений в маленьких масштабах)
Добрый день, интересная идея о пробросе кода в под для тестов. А подскажите, пожалуйста, как примерно реализовано? Интересует в случае джавы)
Спасибо за статью. Подскажите, пожалуйста, а как можно было бы реализовать б\г, когда есть микросервисная архитектура и приложения общаются между собой без ингреса через сервисы?
Допустим, есть под А, и в этот под обращается под Б, В, Г и т.п. Если я задеплою новую версию пода А, как другие поды должны узнавать, что есть новая версия и к ней нужно обращаться, чтобы протестировать новую версию?
Это не говоря про то, что нужно будет деплоить новые версии всех зависимых приложений вместе сразу - и А, и Б, и В и т.д. :)
В голову приходит использование только через service mesh, но и то не конкретная реализация. Там тоже надо подумать.
Если вдруг у вас есть какие-то мысли по этому поводу, буду благодарен.
А для различия фича-окружений используется версионирование в приложениях или по хешу коммита разделение происходит?
Идея хорошая и в целом мне нравится. Но вот отлаживать это всё дело, если что-то пошло не так, или добавлять новое - не особо удобно, прыгая по всем репам и абстракциям, пытаясь вспомнить как оно было и что куда добавить. Особенно если один раз настроили и забыл :)
Да и сам gitlab ci для отладки в целом так себе. Типа "echo debug", run pipeline, "блин, не то, заново". И так 20 раз.
У меня были три 8-ки, которые "подтачивали" корни соседних и сдвигали зубной ряд, поэтому удалил. Они были ретинированные и было явное показание к удалению. Осталась лишь одна 8-ка последняя, но она никак не мешает, поэтому пока не спешу с ней. Хотя по-хорошему надо бы выпилить уже)
В рекомендациях стоматологов, которых встречал, всегда было предложение об удалении восьмёрок, если они не несут полезной функции.
спасибо большое за статью, хорошая работа проделана. а такой продукт как signoz не рассматривали? вроде на coroot похож, из коробки также и метрики и карты строит с трассами. но ui посимпатичнее.
А зачем здесь верфь, если можно обойтись одним helm для деплоя? По идее схема будет проще же. Я из любопытства ради интересуюсь)