DevOps *

Перед вами подборка бесплатных книг, которые помогут разобраться в DevOps-практиках и стать сильнее как специалист. Вся литература — на английском языке, если не указано другого.

Меня зовут Рустем и я занимаю должность Senior DevOps Engineer в компании IBM, город Краков. Сегодня я хотел бы Вам показать и рассказать, как можно подружить Openshift и Jenkins и использовать их связку в CI-процессе.

Сегодня речь пойдет не о списке инструментов, которые необходимо изучить. Не о сетевых моделях взаимодействия, и даже не о протоколах. Сегодня я, DevOps Automation Engineer в компании Altenar, расскажу вам, почему DevOps - это целая философия, и, по сути, каждый IT-шник в своей мере DevOps.

Немецкая компания SUSE известна в Open Source-сообществе своими дистрибутивами Linux. Но этим ее деятельность не ограничивается. В конце прошлого года SUSE представила новый проект с открытым кодом — гиперконвергентное решение Harvester. Как говорит компания, Harvester — это альтернатива существующим гиперконвергентным платформам enterprise-уровня типа VMware vSAN и Nutanix HCI, адаптированная к cloud native-среде, к тому же полностью бесплатная.

В статье сделаем небольшой обзор Harvester: посмотрим на компоненты, возможности, сильные и слабые стороны.

«You Only Live Twice», (1967)

Развитие микроэлектроники, ИТ технологий и широкого спектра программных продуктов открыло новые возможности по контролю всего. Датчики, камеры, цифровые следы… Магнитофон в чемодане уже неактуален.

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

Все предыдущие публикации.

Писать, собирать, агрегировать и сохранять логи для последующего анализа важно: это наиболее подробное представление того, как работает система.

Логи можно собирать и отправлять в централизованную систему по-разному, например используя библиотеки в самом приложении или сторонние агенты вроде Filebeat, Fluent Bit, Vector. Есть множество систем хранения вроде Elasticsearch, Loki, Splunk, файлы на диске или объекты в S3.

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

Сегодня организации сталкиваются с угрозами кибербезопасности, которые становятся все более разнообразными, сложными и изощренными. В тоже время, не каждая компания обладает отделом специалистов по кибербезопасности. Но любая современная 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), которые помогают группам по анализу данных быстрее и увереннее выпускать модели.