товарищи а в контейнерах сетевые утилиты юзают? ваершарк, дхцп сервер, всякое такое

я однажды запустил tcpdump в контейнере, и у меня видюха сдохла. так, что аккуратнее с этим

ёбана в рот, как будто не у вас спрашиваю?

ну а чего нет то?

я однажды запустил tcpdump в контейнере, и у меня видюха сдохла. так, что аккуратнее с этим

выглядит как совпадение ?‍♂️

ну а чего нет то?

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

выглядит как совпадение ?‍♂️

(trollface)

а чо искать то? свой собрать 10сек.. одна строка

ZABBIX

Сломался функционал проверки статуса сервера в нем

Раньше на заббикс и надеялся

Но не нужен)

Через него можно конференци коллы делать, а через тебя - нет. Так что я бы задумался о 'нужности'

Через него можно конференци коллы делать, а через тебя - нет. Так что я бы задумался о 'нужности'

Через скайп же)

https://twitter.com/seecurity/status/995906576170053633

Добрый день. Подскажите каналы по big data + machine learning .

Через скайп же)

Вобще то там ограничение на количество человек

https://raw.githubusercontent.com/cloudflare/ebpf_exporter/master/examples/bio.write.latency.png

https://raw.githubusercontent.com/cloudflare/ebpf_exporter/master/examples/bio.write.latency.png

сколько ухищрений что бы сказать одно число.

одно?

Дивапсы, настал ваш час

Хецнер заблокировали или нет?

нед

То есть можно там развернуть впс и не ссать?

я бы ссал если бы развернул что-то на хецнере и без блокировок

но хецнер немного только попал под блокировки и новых не завозили пока

мой редис все вянет и вянет...

парни, подскажите, как можно убить зависшую джобу в дженкинсе через CLI?

прибей идешник в фс

не реагирует вообще ни на что

точнее не так

останови дженкинс

и прибей файло

потом запусти

я тут давеча наебался

я зашел, оказалось она 2 месяца висит уже

и нигде не отображается

о

убил

Jenkins.instance.getItemByFullName("JobName").getBuildByNumber(JobNumber).finish(hudson.model.Result.ABORTED, new java.io.IOException("Aborting build"));

отак

вставил свои джобнейм и джобномер

Всем привет! У меня вопрос такой, никак не могу найти что-то, что меня бы направило в правильное русло. Есть git репозиторий, с которым будут работать по Git Flow. В нем есть ветки develop, master и будут создаваться release/$version ветки для каждого релиза и hotfix/$version для исправления багов, найденных в master ветке. Я пытаюсь найтроить VSTS для CI/CD (Не важно, в чем именно, вопрос не по имплементации). В данный момент я вижу flow следующим образом: Когда происходит push в develop, создается docker image ($image):($version)-dev($revision) и деплоится в kubernetes в dev namespace Когда происходит push в release, создается docker image ($image):($version)-rc($revision) и деплоится в kubernetes в qa namespace Когда происходит push в master, создается docker image ($image):($version) и деплоится в kubernetes в prod namespace Вопрос: Стоит ли делать так? Я читал, что image из qa должен в случае успешных тестов быть развернут в продакшн, а не собран снова. Как в этом случае быть? Я вижу 2 варианта: 1) Собирать image для qa из master ветки. Но в этом случае непонятно, что делать, если QA не принимает билд и нужно еще внести некоторые правки, потому что если код попал в мастер, он уже должен быть без известных изъянов. 2) Собирать image для qa из release ветки и этот же image отправлять в prod, если QA принимает билд. Но в этом случае нарушается правило "В master ветке всегда имеем код, который сейчас в продакшне". Я понимаю, что все это очень субъективно и может быть много разных вариантов решения. Я буду рад любым предложениям и конструктивной критике. Спасибо за уделенное время.

Напоминаем что уже завтра, 17 мая, c 10:30 до 19:00, состоится второй Big Monitoring Meetup! BIG MONITORING MEETUP #2 — уникальная возможность встретиться с экспертами и профессионалами в области мониторинга. Вас ждут живое общение, обсуждение лучших практик и нетрадиционных подходов, обзор новинок и тенденций в области мониторинга и смежных технологий, выступления специалистов и экскурсия по дата-центру! Основные направления конференции: Мониторинг оборудования и приложений Мониторинг сервисов Новинки производителей Мониторинг для интернета-вещей Мониторинг и ML/AI — новые возможности Визуализация инфраструктуры и бизнес-процессов Информационная безопасность Спикеры мероприятия (докладчики и темы уточняются): Виктор Исаев, команда SAYMON, Мониторинг ЖКХ с помощью SAYMON Александр Зобнин, Grafana (тема уточняется) Григорий Юдин, DCConsult, Применение современных технологий мониторинга ЦОД Павел Козлов, Деловой Партнер, Мессенджеры в системе мониторинга Алексей Широких, NOC Project, Сетевой мониторинг NOC Project Константин Рядов, Openway Service, Isolated Enterprise Operational Monitoring Ольга Филиппова, Тинькофф банк, Мониторинг бизнес-сервисов аналитическими методами Сергей Кунько, Veeam, Veeam One – мониторинг, отчетность и планирование ресурсов Денис Муравьев, GoodWAN, Интернет событий – будущее LPWAN на базе российских технологий Татьяна Свирко, Selectel, Мониторинг инфраструктуры современного дата-центра Для прохода в дата-центр необходим паспорт. Начало регистрации в 10:20. Первый доклад в 11 часов. Регистрация https://eventuer.timepad.ru/event/702213/

@dvoikik пересобирать. qa должны тестировать не имидж, а код. и от пересборки не должно ничего меняться. в любом другом случае возникает проблема разрыва кода и энва

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

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

Это как?

Pre hook, не?

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

+100500. Артефакт собирается не по ветке, а по тегу (коммиту). Ну и для контроля соответствия двух артефактов можно использовать хэши. Типа - собрали из релиз-ветки, протестировали, взяли хэш. Потом влили в мастер, собрали, взяли хэш. Хэши должны быть одинаковые, если это не так - то где-то сам себя обманываешь.

Это как?

мы это решаем с помощью геррита

http://www.opennet.ru/opennews/art.shtml?num=48601

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

чем?

ну так...

http://www.opennet.ru/opennews/art.shtml?num=48601

уже обнвоа 2 дня как пришла

уже обнвоа 2 дня как пришла

спасибо, ваше мнение очень важно для нас :)

мы это решаем с помощью геррита

Что именно? И как gerrit может быть интегрирован в CI/CD pipeline?

@dvoikik пересобирать. qa должны тестировать не имидж, а код. и от пересборки не должно ничего меняться. в любом другом случае возникает проблема разрыва кода и энва

я вот против, любая сборка тянет зависимости, некоторые из них никакого отношения к коду не имеют и могу после пересброки сломаться. ТС прав и вопрос поднимался не раз, артефакт из QA\DEV должен идти дальше в случае прохождения тестов\аппрувов без пересборки

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

Что именно? И как gerrit может быть интегрирован в CI/CD pipeline?

решаем проблему тестирования изменений до их фактического мерджа. >И как gerrit может быть интегрирован в CI/CD не понял вопроса.

Всем привет! У меня вопрос такой, никак не могу найти что-то, что меня бы направило в правильное русло. Есть git репозиторий, с которым будут работать по Git Flow. В нем есть ветки develop, master и будут создаваться release/$version ветки для каждого релиза и hotfix/$version для исправления багов, найденных в master ветке. Я пытаюсь найтроить VSTS для CI/CD (Не важно, в чем именно, вопрос не по имплементации). В данный момент я вижу flow следующим образом: Когда происходит push в develop, создается docker image ($image):($version)-dev($revision) и деплоится в kubernetes в dev namespace Когда происходит push в release, создается docker image ($image):($version)-rc($revision) и деплоится в kubernetes в qa namespace Когда происходит push в master, создается docker image ($image):($version) и деплоится в kubernetes в prod namespace Вопрос: Стоит ли делать так? Я читал, что image из qa должен в случае успешных тестов быть развернут в продакшн, а не собран снова. Как в этом случае быть? Я вижу 2 варианта: 1) Собирать image для qa из master ветки. Но в этом случае непонятно, что делать, если QA не принимает билд и нужно еще внести некоторые правки, потому что если код попал в мастер, он уже должен быть без известных изъянов. 2) Собирать image для qa из release ветки и этот же image отправлять в prod, если QA принимает билд. Но в этом случае нарушается правило "В master ветке всегда имеем код, который сейчас в продакшне". Я понимаю, что все это очень субъективно и может быть много разных вариантов решения. Я буду рад любым предложениям и конструктивной критике. Спасибо за уделенное время.

в этой схеме, образы создаются для dev/qa/master по-разному? или только называются с префиксом?

решаем проблему тестирования изменений до их фактического мерджа. >И как gerrit может быть интегрирован в CI/CD не понял вопроса.

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

в этой схеме, образы создаются для dev/qa/master по-разному? или только называются с префиксом?

Только называются

Ну, из мастера образ еще и помечается тэгом latest, в остальном все идентично

Только называются

Вернее, помечаются (tag), названия у образов, строго говоря, одинаковые

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

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

Всем привет! У меня вопрос такой, никак не могу найти что-то, что меня бы направило в правильное русло. Есть git репозиторий, с которым будут работать по Git Flow. В нем есть ветки develop, master и будут создаваться release/$version ветки для каждого релиза и hotfix/$version для исправления багов, найденных в master ветке. Я пытаюсь найтроить VSTS для CI/CD (Не важно, в чем именно, вопрос не по имплементации). В данный момент я вижу flow следующим образом: Когда происходит push в develop, создается docker image ($image):($version)-dev($revision) и деплоится в kubernetes в dev namespace Когда происходит push в release, создается docker image ($image):($version)-rc($revision) и деплоится в kubernetes в qa namespace Когда происходит push в master, создается docker image ($image):($version) и деплоится в kubernetes в prod namespace Вопрос: Стоит ли делать так? Я читал, что image из qa должен в случае успешных тестов быть развернут в продакшн, а не собран снова. Как в этом случае быть? Я вижу 2 варианта: 1) Собирать image для qa из master ветки. Но в этом случае непонятно, что делать, если QA не принимает билд и нужно еще внести некоторые правки, потому что если код попал в мастер, он уже должен быть без известных изъянов. 2) Собирать image для qa из release ветки и этот же image отправлять в prod, если QA принимает билд. Но в этом случае нарушается правило "В master ветке всегда имеем код, который сейчас в продакшне". Я понимаю, что все это очень субъективно и может быть много разных вариантов решения. Я буду рад любым предложениям и конструктивной критике. Спасибо за уделенное время.

Артефакт должен быть один. Если у тебя артефакты собираются на ветки. То ты будешь тестировать несколько раз.

ERROR: S client not available

а, понял. идея это натянуть на git-flow... мы от этого отказались. :)

да, git-flow хорошо себя показывает, будучи осфериченным в вакууме

а, понял. идея это натянуть на git-flow... мы от этого отказались. :)

А какие есть альтернативы? Не хотелось бы придумывать процесс самостоятельно, есть какие-то аналоги?

каких-то стандартных решений адаптации гит-флоу к реальности я не встречал. каждый случай индивидуален

каких-то стандартных решений адаптации гит-флоу к реальности я не встречал. каждый случай индивидуален

То есть ты за то, чтобы изменить flow работы с VC, а не подстраивать CI/CD под него?

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

https://www.youtube.com/watch?v=G3nELxmECd8

вот, я об этом, вроде)

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

Согласен. Но не лучше ли это сделать на уровне CI/CD, чем на уровне работы с VC? Все таки, CI/CD - автоматика, а работа с VC - люди, вероятность ошибок больше (мое субъективное мнение).

https://www.youtube.com/watch?v=G3nELxmECd8

О, я вроде его смотрел. Сейчас пересмотр еще раз, на всякий, спасибо.

О, я вроде его смотрел. Сейчас пересмотр еще раз, на всякий, спасибо.

не уверен что я именно его имею ввиду, бегло вроде оно

>работа с VC - люди, вероятность ошибок больше вот именно. потому у нас запрещен прямой пуш. всё через реквесты и автоматику. основное требование - ветка должна быть протестированной в любой момент времени. т.к. она же используется и для тестов. сломанная ветка - остановка процесса разработки

>работа с VC - люди, вероятность ошибок больше вот именно. потому у нас запрещен прямой пуш. всё через реквесты и автоматику. основное требование - ветка должна быть протестированной в любой момент времени. т.к. она же используется и для тестов. сломанная ветка - остановка процесса разработки

Правильно ли я понял, что в этом случае вместо создания ветки release/* создается pull request из develop в master? Или создается ветка release/* и из него PR?

разработка ведётся в мастере. релиз отпочковывается в ветку stable/*. хотфиксы черрипикаются в неё из мастера

ну, это у нас. в таких вещах каждый дчет, как хочет. нет универсальных решений

разработка ведётся в мастере. релиз отпочковывается в ветку stable/*. хотфиксы черрипикаются в неё из мастера

То есть ветки с релизами остаются? Я так понимаю, вам нужно сопровождать все прошлые релизы?

ну, не все. согласно SLA

в реальности это сопровождение - та ещё попоболь, но как-то справляются

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

ну, не все. согласно SLA

Да, разумеется. Представляю. Ну, конкретно в моем случае в проде всегда размещен только последний релиз, так что я не знаю, насколько такая модель подойдет.

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

То есть новую фичу в старый релиз?

угу...

Да уж)

не уверен что я именно его имею ввиду, бегло вроде оно

Да, это он. Поставил метку на этот момент. Здесь я как раз вот это и услышал, потому у меня эти вопросы и возникли. https://youtu.be/G3nELxmECd8?t=26m14s

Да, это он. Поставил метку на этот момент. Здесь я как раз вот это и услышал, потому у меня эти вопросы и возникли. https://youtu.be/G3nELxmECd8?t=26m14s

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

и то что Дмитрий говорит про "ту фигню из nodejs удалили" - тоже попал на это, но к счастью не наступил, но вся контора на ушах и фейлах))

А если собирать образы из master, а если они не пройдут QA, то исправлять это hotfix'ами?

отдельный флоу для установки тегов. на вход - sha коммита. в процессе - сборка имиджа и проверка qa. по факту аппрува - постановка тэга и промоут имиджа

Ок, всем спасибо!

Все привет я только начал знакомится с CI подскажите как настроить его на jenkin or aws .