DevOps *

Сегодня мы познакомимся с понятиями data source и output; посмотрим, как применяются изменения в уже существующей инфраструктуре.

Доброго времени суток, дорогой читатель!

Последние несколько лет в решении бизнес задач прогрессирует тренд использования Искусственного Интеллекта. Перед специалистами, отвечающими за инфраструктуру встают вопросы о том, какие решения они могут предложить ML-специалистам для закрытия их потребностей в отказоустойчивой и гибкой инфраструктуре с учетом специфических потребностей сферы ML. В том числе растет число инструментов и фич, которые они предоставляют, и многие задаются вопросом: как собрать свой MLOps-стек, чтобы он был удобный, (желательно) бесплатный и закрывал большинство распространенных потребностей.

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

Вчера мы остановились на инициализации terraform. Сегодня мы поднимем одну машину в дефолтной сети с дефолтными настройками. И Яндекс и aws изначально создают вам одну VPC и подсети в ней.

Terraform за 15 дней (AWS/Yandex). День 1

Мы от простого к сложному, поднимем небольшую инфраструктуру на aws и Яндекс (актуальность последнего я думаю объяснять не нужно). Так что по итогу вы сможете сказать: “Я изучал terraform от простого к сложному”.

Я постараюсь добавить все необходимые ссылки на документации и доп. источники, так что вы сможете дополнить необходимые знания, но данный курс (если это можно так назвать) скорее рассчитан на тех, кто в общем знаком с облачными технологиями. Это не пособие по terraform. Цель - помочь новичкам в данном вопросе начать изучать IaC и облака в целом. Некий quick start в terraform.

Накопить за 7 лет терабайты данных в монолите и решить, что пора оптимизировать систему и разбивать её на микросервисы — страшный сон для айтишника. Добавим сюда ещё база на решениях от 1С и необходимость обеспечить непрерывность процесса. Стало страшно? А для нас — возможность показать экспертность и решить нетривиальную задачу. О том, как «кролик» помог сдвинуть гору рассказал архитектор 1С компании «Автомакон» Виталий Осиповский.

С 2013 года ВкусВилл проводил внутреннюю автоматизацию с использованием программ на базе 1С. За годы активного развития и эксплуатации база увеличилась до нескольких терабайт, кратно выросло количество операций, что спровоцировало большой объем работы для администраторов, оптимизаторов и команды разработчиков. Например, тяжелые алгоритмы планирования, закрытий, генерации документов могли негативно влиять на работу всей базы.

Любые сбои и простои были неадекватно затратны и влияли на все компоненты системы в целом. А сама система не годилась для быстрого масштабирования бизнеса. Поэтому уже в 2020 году приняли решение о поэтапном разделении монолита на отдельные программные компоненты.  

Бортовой лог №1, 23.08.20xx. Говорит Денис Кораблёв, капитан одного из научно-исследовательских кораблей Positive Technologies. Я поручил нашему ай-ай открыть шампанское: сегодня вышел из беты DAST-сканер PT BlackBox.

Что такое DAST-сканер? Какие функции он выполняет? Почему без него в разработку не внедрить качественные практики DevSecOps? И кто такой ай-ай?.. Ответы дадут собранные в этом посте бортовые логи. А если вы уже разбираетесь в DevSecOps, то логи раскроют тонкости нашей работы и расскажут о её результате — PT BlackBox.

Этой ночью представят новую версию Kubernetes. Среди главных изменений на первое место разработчики поставили стабилизацию функции CSI Migration — отказ от внутренних плагинов хранилищ в пользу CSI-драйверов. Также в этой версии устаревший контроллер PodSecurityPolicy заменен на новый PodSecurity Admission.

По традиции в обзоре рассказываем обо всех новых функциях (alpha), а также упоминаем те, что перешли на уровень выше (beta, stable).

Привет, Хабр!

И снова в эфире Юрий Шабалин, главный архитектор компании Swordfish Security. Мы уже достаточно давно занимаемся консалтингом в области построения процессов безопасной разработки для своих клиентов. В процессе мы постоянно сталкиваемся с различными нюансами и сложностями при реализации практик DevSecOps. Ранее мы уже обсуждали SAST и OSA, а сегодня я бы хотел поговорить про практику автоматизированного динамического анализа приложений (DAST). А именно, какие подводные камни нас ждут при внедрении данной практики, какие особенности следует учитывать и как избежать проблем.

Ну что же, приступим.

Требования к сети в Kubernetes

• Под в кластере должен свободно взаимодействовать с любым другим подом без использования Network Address Translation (NAT).
  
• Любая программа, работающая на узле кластера, должна взаимодействовать с любым подом на том же узле без использования NAT.
  
• У каждого пода есть собственный IP-адрес (IP-per-Pod), и любой другой под может обратиться к нему по этому адресу.
  

1. Как убедиться, что контейнеры в одном и том же поде ведут себя как на одном хосте?
   
2. Может ли под обращаться к другим подам в кластере?
   
3. Может ли под обращаться к службам? Обрабатывают ли службы запросы о балансировке нагрузки?
   
4. Может ли под получать трафик извне кластера?
   

Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело — показывать осмысленные данные.

Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.

Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.

В этой статье будет следующее:

• Заведение DNS домена на reg.ru.
• Управление DNS зоной в Yandex DNS c помощью terraform.
• Создание Kubernetes в Yandex Cloud.
• Резервируем внешний статический IP адрес.
• Установка Jenkins c помощью terraform модуля helm_release.
• Создание ClusterIssue(Issue) для создания letsencypt сертификата.

Не так давно мы решили добавить в нашу Kubernetes-платформу Deckhouse поддержку Cilium. Однако в процессе разработки модуля cni-cilium неожиданно столкнулись со сложностями, для преодоления которых пришлось даже обращаться к авторам проекта. Теперь, когда модуль успешно доведен до рабочего состояния, можно перевести дух и поделиться ощущениями от полученного опыта и использования этого продукта в целом.

Эксперты Слёрма — Антон Черноусов, Павел Селиванов, Денис Наумов и Владислав Килин — собрались, чтобы обсудить, какой язык больше подходит для админов, инженеров и devops.

Дисклеймер. Этот материал не претендует на звание истины в последней инстанции. Статья создана на основе рабочего (и жизненного) опыта экспертов, которым они поделились на этом митапе.

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

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

В целом, компании всегда ищут способы увеличить свою продуктивность на всех уровнях: инфраструктура, люди, процессы и др. Зачастую продуктивность достигается за счет внедрения автоматизированных процессов для облегчения работы и увеличения темпов производства. Подобная автоматизация требует эволюции, адаптации или даже полной трансформации концептов, используемых ранее. Это включает в себя обеспечение и контроль политик безопасности.

В самом деле, с появлением новых методов работы, основанных на гибкости (вроде DevOps), некоторые принципы безопасности пришлось адаптировать к темпам развития и управления компонентами инфраструктуры. Сегодня одна из наиболее безопасных практик - это как можно раньше переместить эти контрольные точки в цепи интеграции, чтобы быстрее обнаруживать любые аномалии, заслуживающие особого внимания.

Piper - это фреймворк, позволяющий собрать полноценную ML-систему из набора готовых или кастомных модулей и развернуть систему в нужной среде.

В статье рассказываем, как мы пришли к написанию своего фреймворка, в чем его основная концепция, а также покажем как Piper ускоряет создание ML-системы на примере конкретного проекта.

CI система GitHub Actions достаточно свежа по сравнению со своими конкурентами, но продолжает радовать сочетанием легкости использования и постепенным расширением функционала. На мой взгляд, шаблонизация используемых пайплайнов это безумно важная составляющая, и в конце 2021 года GitHub закрыли этот вопрос, представив на наш суд Reusable Workflows. В данной статье я попробую поделиться собственным опытом построения проекта полностью на основе шаблонов workflow и порассуждать о применимости этого подхода.

Меня зовут Игорь Латкин, я системный архитектор в компании KTS.

Делимся нашей внутренней разработкой — Kubernetes-контроллером mirrors. Мы создали его внутри нашего DevOps-отдела для копирования Kubernetes-секретов между неймспейсами кластера. В итоге mirrors превратился в универсальный инструмент синхронизации данных из разных источников.

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