DevOps *

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

На практике основными причинами появления нарушений безопасности являются недостатки реализации механизмов защиты, уязвимости в коде приложения, недостатки конфигурации. Очень часто контроль со стороны службы информационной безопасности проводится на последних этапах жизненного цикла приложения. Такой сценарий несовместим с современными методиками DevOps и Agile, которые сокращают сроки циклов поставки ПО до нескольких недель.

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

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

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

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

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

Сразу скажу, что это немного идеалистичная картина для нашего российского IT. У нас еще мало компаний, которые дейсвительно используют R&D в качестве основного зарабатывающего бизнес-юнита. В основном лишь частично внедряются практики, взаимодействие и культуру DevOps. Но это не значит, что туда не надо идти. Если у вас это вызовет отторжение: «Такого не бывает, это не работает», то предлагаю превратить это в вопрос: «Такого не бывает? Это не работает?» 

Меня зовут Александр Титов, первые DevOps-практики я начал использовать еще до того, как появилось само слово DevOps. Сейчас я управляющий партнер в компании Экспресс 42, которая помогает ставить DevOps в компаниях.

Как быть, когда вокруг вроде бы девопсы, аджайлы и скрамы, но разработка и тестирование по-прежнему не живут в одном пайплайне душа в душу?

Из-за того, что необходимо преодолевать эту стену и находить общий язык, мы даже создали конференцию Heisenbug, предназначенную одновременно для тестировщиков и разработчиков. А ещё мы проводим Java-конференции, и осенью Артём Ерошенко выступил там с докладом «Как правильно (не) использовать тестировщиков». На примере Java-проекта он поделился своей болью и рассказал, что считает нужным делать.

И теперь, в преддверии нового Heisenbug и нового JPoint (обе конференции пройдут в формате «офлайн + онлайн»), мы решили сделать хабрапост на основе его доклада. Дальше повествование от имени Артёма.

Привет, Хабр!
Приглашаем начать “давайте после майских” с митапа :)  Ждем вас 12 мая в 18:00 на новый CROC&TALK – в этот раз будем обсуждать DevSecOps. 

Поговорим о том, как запустить процесс безопасной разработки, не выстрелить себе в колено, а спецам по информационной безопасности и разработке заговорить на одном языке. Будет 2 доклада по практическим кейсам и дискуссия. Подробности – под катом или сразу на странице мероприятия.

Важно: митап будет офлайн+онлайн, если вы в Москве, ждем в нашем офисе на пиццу и приятное общение :) 

Кажется это уже стало традицией: каждый раз, когда я выхожу на новое рабочее место, моя деятельность начинается с бенчмарков различных SDS-решений. Мой приход во «Флант» не стал исключением. Я попал в команду разработки Kubernetes-платформы Deckhouse, где решили развивать возможность запуска виртуальных машин в Kubernetes. Но для этого сначала потребовалось найти простое и надежное хранилище блочного типа, которое можно предложить клиентам платформы.

Я взял несколько свободных решений и протестировал, как они поведут себя в тех или иных условиях. В первую очередь интересовала производительность DRBD в различных конфигурациях и сравнение с Ceph.

Но рынок программно-определяемых хранилищ не стоит на месте и постоянно растёт. Появляются новые амбициозные проекты, включая недавно релизнутый Mayastor и pet-проект моего товарища-соратника Vitastor. Результаты оказались очень интересными.

Так же, как и многие другие компании, мы долго и счастливо использовали целый стек популярных облачных сервисов (Github, Slack, Jira, Confluence и т.д.) и связывал это все Google Workspace, который выступал в том числе и как SSO для всех используемых сервисов.

В связи с последними событиями нам пришлось достаточно быстро искать и реализовывать альтернативу из отечественных сервисов и open source продуктов. При этом одним из требований стало использование общей с «офисными»
и почтовыми сервисами точки аутентификации.

В этой статье я расскажу о том, как мы решали задачу создания SSO поверх выбранного поставщика почтового и «офисных» сервисов для используемых нами приложений с помощью Keycloak и с какими проблемами мы при этом столкнулись.

В этой статье мы рассмотрим основные принципы миграции БД без даунтайма и дадим быстрые рецепты для наиболее распространенных случаев.

В этой серии статей мы рассмотрим, как на основе готовых моделей создавать приложения, использующие машинное обучение, и организовывать доступ пользователей к ним. Начнем с создания Web-приложения для классификации изображений на Streamlit и развертывания его на облачной платформе Heroku в бесплатном аккаунте. Этот подход подойдет для прототипов и персональных или учебных проектов.

В своей предыдущей статье я уже упоминал, что создаю своё микрооблако. Точнее, ну как своё, это будет облако как продукт, а не как услуга. Поэтому оно такое же моё, как и ваше. Как и всего мира. То есть каждый сможет его развернуть на своё железо, будь то датацентр или пара-тройка виртуальных машин и пользоваться им в своё удовольствие, запуская на нем свои потрясающие проекты. Можно даже найти какой-то готовый проект, который лежит где-нибудь на гитхабе и давно просится на старт, только автору исходного кода запускать его было негде, потому что хранение исходников у нас бесплатное, а вот поддержка работы своего сервиса к дешевому сегменту экономики на мой взгляд не относится. А я такой запустил облако, вкинул туда чужой проект и помог миру увидеть то, что так и могло остаться в глубинах гитхаба. Но это фантазии, до реализации которых еще далеко, но путешествие в тысячу миль начинается с первого шага, главное не прекращать перебирать ногами. Поэтому мы продолжаем...

Так вот в прошлом посте в рамках проекта kubos мы остановились на том, что объединили все машинки нашего будущего облака в общую виртуальную сеть. Теперь пора сделать так, чтобы машинки видели друг друга не только по IP-адресам, но и по именам. Для этого нужно запустить и настроить DNS сервер, чем мы сейчас и займемся. Для этого я отвел в гитлабе отдельную ветку, где и будет приведен полный код ansible и не только скриптов, о которых пойдет речь ниже.

Промышленные решения, основанные на машинном обучении — это гораздо больше, чем просто модель. Три ключевые концепции, охватывающие управление версиями, тестирование и конвейеры, являются основой для операций машинного обучения (MLOps), которые помогают группам по анализу данных быстрее и увереннее выпускать модели.

Настройка LEMP-сервера с помощью docker для простых проектов. Часть третья: docker-compose, Dockerfile.

Мы продолжаем цикл обучающих статей для начинающих системных администраторов. В этом материале мы разберем Dockerfile, docker-compose и как поднять полноценный веб-сервер с помощью docker. Отмечу, что если вы являетесь опытным администратором, можете смело пропускать данный материал. Эта статья призвана простыми словами объяснить, что такое контейнеры, виртуализация и все, что с этим связанно.

trdl (сокр. от “true delivery”) обеспечивает безопасный канал доставки обновлений от Git-репозитория до хоста пользователя. В состав trdl входят три ключевых компонента, которые помогают защищать систему обновления от потенциальных атак: HashiCorp Vault, TUF-репозиторий и Git.

Расскажем, как работает решение, от каких минусов существующих систем обновления избавлено и как начать им пользоваться.

Рассказываем о том, как автоматизировать процессы онбординга и развёртывания инфраструктуры в iOS проекте с помощью Ansible.

Продолжаю делиться новостями ченджлогов. В этот раз небольшой апдейт.