puppet CI

что ты замеряла

что являлось индикатором

что ты замеряла

время на таски

что являлось индикатором

решение задач, связанных с этим тагом

0 в этом месяце и 0 в прошлом

тоесть после внедрения CI ты стала делать таски быстрее ?

тоесть после внедрения CI ты стала делать таски быстрее ?

мы стали реже ломать инфраструктуру

причём в прошлом проекте тоже

как замеряли ?

на ансибле

может тогда дело не в паппете а в опыте ?

как баес учитываешь ?

как замеряли ?

через зафайливание тестов

лол

они случаются каждую неделю

в паппете

в его репах

Пример дня. мне нужно было поднять свежий 6й эластик и кибану, и потестить хёртбит их

я 3 контейнера апнул за 15 минут и соединил. и посмотрел как это выглядит из вне.

удалил и тачки чистые.

вопрос. сколько бы мне понадобилось на это с lxc \ виртуалками ?

паппет это код

Паппет - это состояние прода :)

я 3 контейнера апнул за 15 минут и соединил. и посмотрел как это выглядит из вне.

я тоже так сделаю

на своём лаптопе

ты думаешь, у меня там докера нет? :)

я 3 контейнера апнул за 15 минут и соединил. и посмотрел как это выглядит из вне.

А сколько времени это займет у кубера после команды kubectl apply -f ?

ты думаешь, у меня там докера нет? :)

а почему в проде не сделаешь ?

А сколько времени это займет у кубера после команды kubectl apply -f ?

если сравнивать номад, время отработки плана и скажем время работы локального композа, то разница в единицах секунд, при том что мы измеряем поднятие аппа из 3-4 контейнеров на 4 нода, примерно 15 секундами.

а почему в проде не сделаешь ?

по тому, что я хочу знать, что я запускаю в проде и как

ты предлагаешь, Птчёл, верить разработчику. Даже если это какое-нибудь приложение на Django, разработчик которого не удосужился положить внутрь контейнера Nginx, и любую базу, кроме sqlite

в микросервисном подходе сложности с CI (при том, что сам по себе докер идеален для CI - можно прогонять тесты не с начала, а по сути патчить, по крайней мере на каждом коммите, оставляя прогон с нуля для найтли билдов), и ты берёшь и объявляешь CI не нужным для инфраструктуры

ну конечно, это серебрянная пуля, а не тупой, модный хайп, правда?

Если ты не расковыряешь контейнер, ты не сможешь нормально его тестировать. Т.к. атомарномарность для бизнес-критикал сервисов это часто утопия. Нельзя взять большой блоб, объявить его атомом, и как-нибудь базово тестировать его,

как чёрный ящик

в индустрии есть противоположное движение, в сторону бигдаты и мониторинга всего того, что вообще возможно, любых метрик

а это ты делать с атомом, который не мантайнишь, не сможешь

поэтому что-нибудь поставить посмотреть в докере можно и удобно, но в прод? А зачем?

как-то странно там запускать сервисы, которые ты не понимаешь, как работают, и которым время от времени нужен трабблшутинг

если у тебя там stateless, это ещё ладно, а если stateful? Давай, расскажи про нагруженные базы данных внутри докера :)

ты предлагаешь, Птчёл, верить разработчику. Даже если это какое-нибудь приложение на Django, разработчик которого не удосужился положить внутрь контейнера Nginx, и любую базу, кроме sqlite

Это просто опять слова в воздух ?

как чёрный ящик

Как раз в этом и суть

в индустрии есть противоположное движение, в сторону бигдаты и мониторинга всего того, что вообще возможно, любых метрик

Это ортогональные вещи

а это ты делать с атомом, который не мантайнишь, не сможешь

Дурь

как-то странно там запускать сервисы, которые ты не понимаешь, как работают, и которым время от времени нужен трабблшутинг

Это вообще никак не оьносится к докеру пох в докере оно или нет

если у тебя там stateless, это ещё ладно, а если stateful? Давай, расскажи про нагруженные базы данных внутри докера :)

Изи, монга, Кассандра, пг.

Посмотри на опыт заландо

Если ты не способна , не нужно утверждать что это плохо

Это вообще никак не оьносится к докеру пох в докере оно или нет

так ты же рассказываешь, что можно взять докер апп и запушить в продакшен - ага, без снятия метрик, без CI, итд

Если же ты собираешься расковыривать докер апп, то этого плюса нет и никогда не было, а ты просто сам себе противоречишь

так ты же рассказываешь, что можно взять докер апп и запушить в продакшен - ага, без снятия метрик, без CI, итд

Так живёт большинство;)

И пушат в прод и работают дальше:) и допиливают ci и тд

так ты же рассказываешь, что можно взять докер апп и запушить в продакшен - ага, без снятия метрик, без CI, итд

Где я сказал такое ?

Если же ты собираешься расковыривать докер апп, то этого плюса нет и никогда не было, а ты просто сам себе противоречишь

Его плюс в том что это дешёвый относительно стандартизованный менеджмент сложного артефакта

Любая виртуалка, лхс, лхд итд проигрывают ему во всем

У тебя нету шедулеров нормальных для всего этого говна тоже

У тебя куча разномастных инитов в твой распределенной системе появляется

Я уверен что ты своими очередными костылями из скриптов 'которые ты лучше знаешь' можешь решить. Но врядли это решение достойное инженера

Если ты перестанешь приписывать мне свои мысли и перестанешь просто вбрасывать фразы, а начнёшь отвечать на аргументы, может что то и поймешь

Его плюс в том что это дешёвый относительно стандартизованный менеджмент сложного артефакта

пайплайны говно. Они удобны, если у тебя stateless, и не нужно обновлять/поддерживать ничего

У тебя нету шедулеров нормальных для всего этого говна тоже

это вообще не важно для монолитной архитектуры. Добавляешь не то, что бы было удобно докеру, а то, что нужно для быстродействия приложения и его удобства разработки

пайплайны это оверхед на разработку и поддержание инфраструктуры. Они и есть та самая инфраструктуре-эс-код, только описанная хуже, и не так понятно, как в том же puppet/ansible

Если ты перестанешь приписывать мне свои мысли и перестанешь просто вбрасывать фразы, а начнёшь отвечать на аргументы, может что то и поймешь

по-моему этим ты занимаешься

Пример дня. мне нужно было поднять свежий 6й эластик и кибану, и потестить хёртбит их

Вот тут

Где я сказал такое ?

Сказал

поставить, посмотреть - это хороший кейс для докера. Но дело в том, что темплейты для всяких популярных штук есть вообще под все паблик и прайвед клауд решения

я, в целом, положительно отношусь к докеру, и не представляю, как без него сделать CI (на LXC/OpenVZ было бы куда менее удобно!), но меня раздражает, когда на волне очередного хайпа, обещающего нам нечто универсальное, всем навязывается стек: Kubernetes/микросервисы/Docker/Go Я думаю, что агрессивность рекламы тут компенсирует неуверенность евангелистов в том, что эта модная штука действительно имеет то значение, которое они озвучивают.

Как раз в этом и суть

плохая суть. Нужно много метрик в эпоху бигдаты. С атома ты не получишь over9000 метрик(по тому, что для добавления метрик постоянно придётся постоянно переписывать микросервисы, и все плюсы их использования исчезнут, куча ресурсов будет уходить на поддержание пайплайнов постоянно меняющихся приложений). Метрики зато удобно получать с большого блоба,

когда DevOps вместе с другими разработчиками

можно просто написать вместе те фичи, которые нужно мониторить

я думаю, что если постоянная разработка приложения, в том числе инфраструктуры, то монолит лучше микросервиса

Это вообще плюс монолита - ты не имеешь глупых, искусственных докерных ограничений, и код пишешь быстро. В том числе инфраструктурный, в том числе логику приложения, итд. Нужны новые метрики? Добавляешь. Не нужны? Убираешь... Вместо постоянной смены роутов в пайплайнах

пайплайны говно. Они удобны, если у тебя stateless, и не нужно обновлять/поддерживать ничего

опять непонятно о чем.

это вообще не важно для монолитной архитектуры. Добавляешь не то, что бы было удобно докеру, а то, что нужно для быстродействия приложения и его удобства разработки

это важно для любой архитектуры

это важно для любой архитектуры

только у докера тут оверхед на разработку

там выше всё дичь даже комментировать не хочу

нет у него оверхеда

нет у него оверхеда

такое ощущение, что ты не видел, не знаю, пайплайны докеров для научных рассчётов (например, в биотехе)

там могут быть десятки разных типов контейнеров,

и множество роутов

в пайплайнах

там это удобно, т.к. снятие сотен метрик, как для вебсервисов не нужно,

у меня основная команда в поддержке это дата саенс

со всеми их "особенностями"

связанными со стейтами, и обновлениями больших датасетов для аппов

со всеми их "особенностями"

Вероятно, не нужно постоянно менять метрики

причм тут метрики вобще

если у тебя научный кейс, просто тупо компьют,

ты только что на пайплайны наезжала

то снимать сотни постоянно меняющихся метрик не нужно

я согласна, что тут микросервисы лучше

по тому, что настроил один микросервис, и постоянно забыл

а если постоянно переписывается ядро приложения, чуть ли не каждый третий спринт,

меняется архитектура, то тут докер, контейнеры и прочие микросервисы нафиг не упали

как вобще петод упаковки и доставки связан с метриками ?

я бы умерла менять все эти метрики в заббиксе (к сожалению, у нас пока нет prometheus)

вся телеметрия она "дискаверабл"

вся телеметрия она "дискаверабл"

нам в приложении нужны метрики

и там же юнит тесты встроены