#devopsспросил_devopsответил
Конфигурации Jenkins: job и branch
Разберем пример: мы создаем отдельную job под отдельный branch. Почему не можем создать одну job, которая будет билдить несколько бранчей по mask? Например, в TeamCity есть возможность указывать бранч, делая конфигурацию source control, подкладывая branch под job. Получаем возможность мониторить появление бранчей по mask, можем разграничивать бранчи – некоторые билдятся под одной job, другие – под другой. Но почему в Jenkins одна job – одна branch, а не одна job – несколько branch?
В данном примере ответ скрыт в разных конфигурациях. В Jenkins можно сделать Discover Branch и билдить в одной бранче, например, только job с маской dev. Еще суть в том, что TeamCity – платное ПО, поэтому и настраивается там все гораздо проще. В Jenkins нужно все делать скриптами, например, под определенный скрипт подкладывается конкретный бранч. В Jenkins первоначальное значение имеет branch, а потом уже скрипт.
Будет ли при большом количестве бранчей (когда количество доходит до сотни) перегружен сервер? Навряд ли. При Discover Branch вы выбираете определенную mask – dev, prod и т.д. Например, мы планируем деплой с master – получается, что мы создаем multibranch pipeline deploy и отдельный jenkins-файл, и в данном случае будем деплоить только с master.
В Jenkins есть способ полностью автоматизировать шаги по конфигурированию plugins и jobs – можно менять мета-данные. Подкладываем .xml файл в volume, и он запускается на базе volume.
Конфигурации Jenkins: job и branch
Разберем пример: мы создаем отдельную job под отдельный branch. Почему не можем создать одну job, которая будет билдить несколько бранчей по mask? Например, в TeamCity есть возможность указывать бранч, делая конфигурацию source control, подкладывая branch под job. Получаем возможность мониторить появление бранчей по mask, можем разграничивать бранчи – некоторые билдятся под одной job, другие – под другой. Но почему в Jenkins одна job – одна branch, а не одна job – несколько branch?
В данном примере ответ скрыт в разных конфигурациях. В Jenkins можно сделать Discover Branch и билдить в одной бранче, например, только job с маской dev. Еще суть в том, что TeamCity – платное ПО, поэтому и настраивается там все гораздо проще. В Jenkins нужно все делать скриптами, например, под определенный скрипт подкладывается конкретный бранч. В Jenkins первоначальное значение имеет branch, а потом уже скрипт.
Будет ли при большом количестве бранчей (когда количество доходит до сотни) перегружен сервер? Навряд ли. При Discover Branch вы выбираете определенную mask – dev, prod и т.д. Например, мы планируем деплой с master – получается, что мы создаем multibranch pipeline deploy и отдельный jenkins-файл, и в данном случае будем деплоить только с master.
В Jenkins есть способ полностью автоматизировать шаги по конфигурированию plugins и jobs – можно менять мета-данные. Подкладываем .xml файл в volume, и он запускается на базе volume.
В работе банковских систем используются разные типы приложений, каждое ー со своей отличительной структурой, в том числе, журналов. Чтобы централизованно мониторить журналы, нужно контролировать все связанные системы, которые затрагивает приложение, и быть независимым от самих журналов.
В статье приведен пример централизованной структуры и дается пояснение, как собираются и масштабируются разные типы журналов без потери данных.
В статье приведен пример централизованной структуры и дается пояснение, как собираются и масштабируются разные типы журналов без потери данных.
В DevOps часто используется архитектура микросервисов. Это подход к разработке, когда приложение состоит из набора небольших сервисов. У каждого из них свой процесс, и с другими сервисами он обменивается данными через детально продуманный интерфейс. Как правило, для обмена используется простой механизм: например, программный интерфейс на базе HTTP (API).
Зачем нужна архитектура микросервисов?
Anonymous Quiz
6%
Чтобы сделать стоимость разработки более дешёвой.
86%
Чтобы модули приложения могли работать отдельно друг от друга. У каждого из них своя задача.
7%
Чтобы проще было тестировать ПО.
2%
Чтобы отдать разработку каких-то микросервисов на аутсорс.
ОТВЕТ: Чтобы модули приложения могли работать отдельно друг от друга.
У каждого из них своя задача.
Более того, эти модули могут быть написаны на разных языках. Многие приложения, с которыми мы постоянно сталкиваемся: интернет-банки, YouTube, например — созданы с использованием множества технологий. Это и есть архитектура микросервисов.
У каждого из них своя задача.
Более того, эти модули могут быть написаны на разных языках. Многие приложения, с которыми мы постоянно сталкиваемся: интернет-банки, YouTube, например — созданы с использованием множества технологий. Это и есть архитектура микросервисов.
Чем занимаются команды SRE, и как они могут помочь продукту. Неплохой разбор в статье 👇
#devops_tools
KubeScrape
Продукт для разработчиков, который поможет легко и интуитивно отслеживать структуру, состояние и метрики кластера
KubeScrape
Продукт для разработчиков, который поможет легко и интуитивно отслеживать структуру, состояние и метрики кластера
Хорошее чтиво подвезли :)
Кристофер Александер «Язык шаблонов»
Больше тысячи страницы, читать можно год, но оно того стоит! Must-have для всех, кто связан с разработкой, проектированием, архитектурой в айти. Книгу можно использовать как справочник ー там много про паттерны, принципы и подходы в проектировании и архитектуре, которые можно перенести на любой проект.
Кристофер Александер «Язык шаблонов»
Больше тысячи страницы, читать можно год, но оно того стоит! Must-have для всех, кто связан с разработкой, проектированием, архитектурой в айти. Книгу можно использовать как справочник ー там много про паттерны, принципы и подходы в проектировании и архитектуре, которые можно перенести на любой проект.
Почему раньше DevOps не было и зачем эта концепция появилась?
Anonymous Quiz
5%
Раньше разработка была более трудоемким процессом
37%
Раньше новые релизы не выходили так часто, как сейчас
12%
Увеличилось количество запросов на разработку
46%
Все ответы правильные
Взгляд на концепции Service Level Objectives и Service Level Indicators на примере Instana
В статье идет речь о показателях работы сервиса, связанных с удовлетворенностью пользователей и производительностью программы. Автор пишет о двух показателях ー Service Level Indicator (SLI) и Service Level Objectives (SLO), рассказывает, как их внедрить в проект и на примере инструмента Instana показывает, как контролировать метрики.
В статье идет речь о показателях работы сервиса, связанных с удовлетворенностью пользователей и производительностью программы. Автор пишет о двух показателях ー Service Level Indicator (SLI) и Service Level Objectives (SLO), рассказывает, как их внедрить в проект и на примере инструмента Instana показывает, как контролировать метрики.
Мабуть, немає людини з IT, яка б не чула про Git. Це місце, де зберігається найцінніше будь-якого проєкту розробки ー його величність код. Зручна, легка та відкрита платформа для роботи з репозиторіями дає можливість відстежити будь-яку точку в історії проєкту. Саме про роботу з цими спеціальними відмітками (Git Tags) розповідаємо у нашій статті.
This media is not supported in your browser
VIEW IN TELEGRAM
Llama — еще один terminal file manager?
Легкий и минималистичный, с быстрой навигацией по файловой системе. Легкая интеграция cd & ls. А еще из llama можно запускать vim.
Легкий и минималистичный, с быстрой навигацией по файловой системе. Легкая интеграция cd & ls. А еще из llama можно запускать vim.
Давайте закрепим :) Инфраструктура как код — модель, по которой настройка инфраструктуры аналогична процессу создания ПО.
Это основа облачных вычислений. Но вот почему это неотъемлемая часть DevOps.
Это основа облачных вычислений. Но вот почему это неотъемлемая часть DevOps.
Anonymous Quiz
58%
Инфраструктура как код управляет виртуальными машинами на программном уровне, не настраивая вручную
7%
Появилась новая профессия — «разработчик в облаке». Он как раз отвечает за разработку инфраструктур
34%
Масштабировать инфраструктуру сложно, но её настройка происходит быстрее и легче, чем раньше
1%
Дело идёт к созданию универсального языка программирования. Так можно быстрее создавать приложения
Правильный ответ:
Инфраструктура как код позволяет управлять виртуальными машинами на программном уровне. Не нужно вручную настраивать и обновлять отдельные компоненты оборудования. Это быстро, экономично и здорово уменьшает риски.
#devops_tools grimd
Скоростной dns proxy, который запускается где угодно. Блокирует Интернет-рекламу и вредоносные серверы.
Скоростной dns proxy, который запускается где угодно. Блокирует Интернет-рекламу и вредоносные серверы.
Всім привіт 💛💙
17-18 травня наші друзі з DevOps ком’юніті та команда DevOpsDays Kyiv роблять велику міжнародну благодійну онлайн конференцію DevOpsDays #StandWithUkraine.
Будуть говорити про DevOps in crisis з Patrick Debois, Kelsey Hightower, Martin Woodward, Kris Nova, Lena Hall, Andrew Clay Shafer та українськими спікерами – Олегом Миколайченко, Володимиром Цапом та Антоном Бабенко.
Після доповідей буде Open Space Discussions, де планують обговорити теми, які оберуть самі учасники.
Також цей івент має й масштабну благодійну мету – зібрати €100 000 на допомогу Україні та передати трастовим благодійним фондам – дуже віримо в те, що робимо!
Обов’язково розкажіть про івент своїм DevOps друзям та знайомим з усього світу. Запрошуємо до реєстрації. До зустрічі на DevOpsDays #StandWithUkraine! 👋
17-18 травня наші друзі з DevOps ком’юніті та команда DevOpsDays Kyiv роблять велику міжнародну благодійну онлайн конференцію DevOpsDays #StandWithUkraine.
Будуть говорити про DevOps in crisis з Patrick Debois, Kelsey Hightower, Martin Woodward, Kris Nova, Lena Hall, Andrew Clay Shafer та українськими спікерами – Олегом Миколайченко, Володимиром Цапом та Антоном Бабенко.
Після доповідей буде Open Space Discussions, де планують обговорити теми, які оберуть самі учасники.
Також цей івент має й масштабну благодійну мету – зібрати €100 000 на допомогу Україні та передати трастовим благодійним фондам – дуже віримо в те, що робимо!
Обов’язково розкажіть про івент своїм DevOps друзям та знайомим з усього світу. Запрошуємо до реєстрації. До зустрічі на DevOpsDays #StandWithUkraine! 👋
Друзі, привіт! Ми повертаємось до вас із корисною інформаіцією зі світу DevOps та продовжуємо спілкування на тему Developement and Operations. Пропонуємо сьогодні перевірити, чи не забули ви про фішечки цього напрямку.
Одна з методик DevOps – безперервна інтеграція (CI). Вона допомагає швидше знаходити й виправляти помилки ПЗ, покращувати його якість і скорочувати час на перевірку та випуск оновлень.
Раніше розробники однієї команди могли довго працювати ізольовано і поєднували зміни коду з основною частиною проєкту лише після завершення своєї роботи.
Одна з методик DevOps – безперервна інтеграція (CI). Вона допомагає швидше знаходити й виправляти помилки ПЗ, покращувати його якість і скорочувати час на перевірку та випуск оновлень.
Раніше розробники однієї команди могли довго працювати ізольовано і поєднували зміни коду з основною частиною проєкту лише після завершення своєї роботи.
Що змінилося із запровадженням CI та DevOps?
Anonymous Quiz
95%
Розробники об'єднують зміни коду в репозиторії, збірка й тестування виконуються автоматично
3%
За кожне оновлення відповідає конкретний розробник. Він контролює, щоб апдейт відбувався без помилок
1%
Розробники регулярно зберігають лише важливі зміни
1%
Потрібно менше тестувальників – розробники тепер тестують самі
👆 А ось правильна відповідь: Розробники постійно відправляють зміни коду в репозиторій. За відсутність помилок відповідає сервіс безперервної інтеграції. Він автоматично виконує збірку та запуск модульних тестів для змін коду, і це допомагає миттєво розуміти, де є помилки.
#devopsспитав_devopsвідповів
Навіщо потрібні Jenkins Agents?
Якщо у нас є Build Executor Status, все, що ми будемо запускати, запускатиметься на нашій машині, ресурси якої «не гумові». Наприклад, ми маємо п'ять віртуальних машин, які простоюють, а робити build на одній машині ми не хочемо. Що робимо? Створюємо agent – віддалену машину, на яку завантажуватиметься вся корисна робота: build, check-out, tests тощо.
Така машина може бути більшою, ніж master (головний Jenkins сервер). На ній може стояти необхідна операційна система, різні характеристики, ICTU плагіни. Агенти дозволяють горизонтально масштабувати, розподіляти мікросервіси. Це досить вигідно і зручно для великих компаній, тому Jenkins і є популярним. Для порівняння, TeamCity agents платні, щоправда, є обмежена кількість безкоштовних. Jenkins рятує великі команди з open source проєктами, де постійно велика кількість білдів.
До того ж agents дозволяють балансувати своє навантаження – певні jobs запускати на певних агентах, які можна вибирати, керувати ними, включно з поведінкою, кроками. Наприклад, один крок робимо на одному агенті, другий – на іншому.
Навіщо потрібні Jenkins Agents?
Якщо у нас є Build Executor Status, все, що ми будемо запускати, запускатиметься на нашій машині, ресурси якої «не гумові». Наприклад, ми маємо п'ять віртуальних машин, які простоюють, а робити build на одній машині ми не хочемо. Що робимо? Створюємо agent – віддалену машину, на яку завантажуватиметься вся корисна робота: build, check-out, tests тощо.
Така машина може бути більшою, ніж master (головний Jenkins сервер). На ній може стояти необхідна операційна система, різні характеристики, ICTU плагіни. Агенти дозволяють горизонтально масштабувати, розподіляти мікросервіси. Це досить вигідно і зручно для великих компаній, тому Jenkins і є популярним. Для порівняння, TeamCity agents платні, щоправда, є обмежена кількість безкоштовних. Jenkins рятує великі команди з open source проєктами, де постійно велика кількість білдів.
До того ж agents дозволяють балансувати своє навантаження – певні jobs запускати на певних агентах, які можна вибирати, керувати ними, включно з поведінкою, кроками. Наприклад, один крок робимо на одному агенті, другий – на іншому.
👍5🤔1