4-6 сентября в Санкт-Петербурге, в конференц-зале Selectel пройдет трехдневный Слёрм DevOps.

Мы строили программу, исходя из мысли, что теоретические труды по DevOps, как и мануалы к инструментам, каждый может прочитать самостоятельно. Интересны только опыт и практика: объяснение, как делать надо и не надо, и рассказ, как делаем мы.

В каждой компании, у каждого администратора или разработчика свой уровень DevOps. Одни неправильно используют Git, другие внедряют SRE. Курс организован так, чтобы каждый нашел что-то актуальное, что можно внедрить здесь и сейчас.

Мы начинаем с Git, потом смотрим на разработку приложения, взаимодействие кода и инфраструктуры, строим CI/CD, описываем инфраструктуру как код (IaC), тестируем получившееся решение, настраиваем мониторинг, собираем и изучаем логи, и в конце доходим до SRE: превращаем надежность в измеряемую и управляемую историю.

• коробка — это Helm (это самое подходящее, что есть в последнем релизе Emoji);
• замок — безопасность;
• человечек — решение проблемы.

• Кратко, что такое Helm, если вы не знали или забыли. Какие проблемы он решает и где находится в экосистеме.
• Рассмотрим архитектуру Helm. Ни один разговор о безопасности и о том, как сделать инструмент или решение более безопасным, не может обойтись без понимания архитектуры компонента.
• Обсудим компоненты Helm.
• Самый животрепещущий вопрос — будущее — новая версия Helm 3. 

Установка

«Но за всей этой красотой скрывается хаос и безумие». — Tanner Walling

Почему?

Чем быстрее процесс разработки, тем быстрее развивается технологическая компания.

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

Эти пайплайны обычно имеют узкое применение, медленно работают и не отличаются надежностью. Разработчики должны сначала создать их вручную, а потом управлять ими, и компании часто нанимают для этого целые команды DevOps.

От скорости этих пайплайнов зависит скорость разработки. У лучших команд развертывание занимает 5–10 минут, но обычно все делается гораздо дольше, и для одного развертывания требуется несколько часов.

Привет! Мы продолжаем серию митапов Backend United. Четвёртая встреча называется «Окрошка», и посвящена она будет инцидентам. Вместе с коллегами из Tutu.Ru, Ozon и Авито поговорим про работу с инцидентами, об инструментах для улучшения incident response и о ценности техдолга.

Встреча пройдёт 10 августа, начало в 12:00. Регистрируйтесь сами и приглашайте коллег. Под катом — тезисы выступлений, ссылки на регистрацию и видеотрансляцию митапа.

Пару лет назад главными трендами были автоматизация, DevOps-практики и ускорение поставки ценностей на рынок. Банк Хоум Кредит решил не отставать и взял курс на развитие технологий, тем более что по опенспейсу всё громче разносился недовольный шепоток пользователей, уставших по несколько дней ждать новых ресурсов для своих важных проектов.

Мы решили начать с процесса согласования заявок подразделениями, который, как и во многих крупных компаниях, требовал сил и времени. В качестве первой задачи выбрали процесс создания виртуальной машины безотносительно среды виртуализации. Составляя список задач, мы поняли, что нужно будет интегрироваться с другими системами, используемыми в инфраструктуре нашего банка, например по API.

Tic Tac Toe: содержание цикла статей

В этой статье рассмотрим Непрерывную Интеграцию/Сontinuous Integration на примере использования Travis CI.

Вводные

• Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
• Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
• В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.

Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:

update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.

Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.

Шаг номер 1: Откуда пришёл RESUME?

1. На первом DUMP Екатеринбург было 154 участника, а на DUMP 2019 уже 1608.
2. Организаторы IT-митапов и конференций в Казани говорили, что люди идут на них неохотно, даже на бесплатные, и вряд ли получится собрать больше 100 человек за 1,5 месяца.

Почти 9 лет назад Cloudflare была крошечной компанией, а я не работал в ней, был просто клиентом. Через месяц после запуска Cloudflare я получил оповещение о том, что на моем сайтике jgc.org, похоже, не работает DNS. В Cloudflare внесли изменение в Protocol Buffers, а там был поломанный DNS.