DevOps *

Добрый день, уважаемые читатели.

Я - Владимир, меня зовут девопс. Говорят, что девопс - это болезнь и я это вам сегодня докажу.

Ответа на вопрос "зачем?" вы тут не найдете, это кликбейт, я и сам не знаю. Все происходящее мотивируется девизом "бекоз ай кен".

Если без шуток, то можно прогонять процесс сборки, создавать изолированные тест-кейсы, прогонять через автотесты, SonarQube и прочие SAST-ы

Итак. Дано. Один безумный девопс, один несчастный андроид-разработчик, собирающий апк локально. Ситуация, увы, распространенная.

Под катом описание Dockerfile с подробностями и нюансами.

Вместе с изменениями рынка меняется и наша объединенная конференция DevOps Conf & TechLead Conf 2022. Мы запустили дополнительный Сall for Paper, собрали заявки и отобрали самые горячие антикризисные доклады. Никаких банальностей, которые легко гуглятся или читаются в документации — не будет. Участники конференции, как обычно, поделятся собственным опытом и свежеобкатанными идеями.

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

В этой статье мы рассмотрим новый экспериментальный режим совместной работы Open Source-утилиты werf и инструмента для непрерывной доставки Argo CD, объединяющий в себе возможности и удобства обоих проектов в рамках одного CI/CD-процесса. Сейчас идет активная разработка этих возможностей werf, но в первом приближении функционал уже доступен и готов к использованию.

Привет, Хабр! Меня зовут Рустем, являюсь Senior DevOps Engineer в компании IBM, город Краков. Недавно я рассказал, как можно задеплоить приложение в кластер Openshift в IBM Cloud, а сегодня расскажу, как за этим всем следить. Нам понадобится кластер в IBM Cloud и LogDNA для мониторинга и алертинга.

Infrastructure as Code — это подход, который подразумевает описание инфраструктуры в виде коде с его последующим применением для внесения необходимых изменений. Но, как именно писать код, IaC не говорит, только даёт инструменты. Один из таких инструментов — Terraform.

21 мая в Слёрм пройдёт практический интенсив «Terraform Мега». Мы пообщались с его автором Павлом Селиванов, архитектором Yandex.Cloud. Он рассказал, каких принципов нужно придерживаться, когда описываешь инфраструктуру, чтобы на выходе не получить непонятный и плохо поддерживаемый код. 

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

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

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