DevOps *

Эта статья фокусируется на примере использование библиотеки DCMTK при создании DICOM-файлов. Как говорит Википедия, DICOM - Digital Imaging and Communications in Medicine, это стандарт создания, хранения, передачи и визуализации медицинских изображений. Стандарт включает в себя часть, которая описывает структуру DICOM-файла, и другую, описывающую передачу DICOM-данных по сети.

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

Современные МРТ и КТ устройства по умолчанию создают медицинские изображения и передают их на PACS-сервер для хранения, используя стандарт DICOM. Но цифровые медицинские изображения не обязательно должны быть топографическими, а могут быть обычными цветными или черно-белыми фотографиями, например, снимок сетчатки глаза. Такие снимки зачастую хранятся в виде: описание пациента + jpg снимок. Чтобы хранить такие изображения на PACS-серверах, их нужно преобразовать в DICOM.

В данной статье мы углубимся в практическую сторону вопроса, рассмотрев конкретный пример создания файла DICOM из изображения формата *.dcm на языке C++ для последующей его отправки на PACS-сервер.

Мы в Ivinco помогаем нашим клиентам строить, развивать и поддерживать инфраструктуру. C некоторыми из них мы работаем уже более 10 лет, с другими только начинаем. Все это естественным образом предполагает, во-первых, гетерогенную среду для работы и, во-вторых, соседство легаси и современных систем и подходов. И поскольку поддержка инфраструктуры само собой подразумевает ее мониторинг, то мы обязаны следить за всем этим IT ландшафтом и оперативно реагировать на инциденты. 

Долгое время основным инструментом мониторинга у нас был Nagios. Те, кто имеет опыт работы с ним, знают, что это хороший инструмент, но его GUI абсолютно не функционален. Поэтому мы использовали nagios API от проекта Zorkian и самописный GUI. У нас были вопросы по производительности и к API, и к нашему собственному GUI, однако в целом нам этого хватало. Но по мере роста количества проектов добавлялись новые системы мониторинга: Zabbix, Prometheus. А поскольку мы предоставляем услугу по поддержке 24/7, то нам крайне важно, чтобы дежурный инженер получал актуальную информацию о событиях с разных систем из разных проектов на одном экране. Так мы пришли к пониманию, что нам нужен алерт менеджер, который способен агрегировать  алерты из разных инструментов мониторинга.

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

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

Привет, Хабр! Меня зовут Кирилл, я работаю в IT более 13 лет. Сначала инженером по внедрению, потом DevOps, потом SRE, также работал руководителем группы сопровождения. Сейчас SRE в VK Рекламе, поэтому знаю, как важно делать правильные инструменты для анализа проблем. 

В любом проекте и компании я иногда сталкивался, а иногда сам создавал проблему: огромное количество дашбордов. Вспомните ситуацию, когда вы в Grafana ищете какой-нибудь дашборд, пишете, например, «Tarantool», и вам выпадает огромный список дашбордов, которые кто-то до вас насоздавал. Это могут быть кастомные дашборды, которые кто-то делал для какого-нибудь инцидента, или просто созданные другими специалистами. Часто бывает, что половина этих дашбордов нерабочие или на них нет чего-то полезного. 

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

Первоначальная документация YDB, опубликованная в рамках open-source запуска в 2022 году, имела структуру, на которую в значительной степени повлиял закон Конвея. Создание проекта с открытым исходным кодом значительно повышает планку того, что ожидается от документации по технологии. В нашем случае для быстрого создания большого количества контента перед запуском потребовалась командная работа по принципу «разделяй и властвуй». На раннем этапе такое четкое владение каждым фрагментом было полезным. Однако, поскольку общий объем документации со временем продолжает расти, читателям становится всё труднее находить нужную им информацию. Чтобы решить эту проблему, мы перепроектируем структуру документации, чтобы она была ориентирована на пользователя. Таким образом, если вы являетесь командой, работающей с кластером YDB, каждый может иметь свою собственную любимую директорию в документации в соответствии со своей ролью в команде и не отвлекаться на контент, ориентированный на читателей с другой ролью.

Эта реструктуризация ещё в процессе: появился новый раздел для DevOps-инженеров, а также дополнительные разделы для администраторов баз данных, разработчиков приложений, инженеров по безопасности, аналитиков и т.д. Перемещение контента может потребовать выработки новых привычек, но в долгосрочной перспективе такая структура должна упростить навигацию. Мы создаём перенаправление со старого URL на новый при перемещении любой страницы документации, чтобы свести неудобства к минимуму.

Привет, Хабр! Меня зовут Марат Цконян, я из солнечной Испании, университет Аликанте. Компьютерный инженер по образованию, по опыту работы — системный администратор.

В прошлом году я наткнулся на исследование отечественного DevOps-рынка за 2022 год: там Холдинг Т1 проводил аналитику трендов, а также формализовал проблематику индустрии. Теперь же благодаря Хабру мне предоставилась возможность обсудить накопившиеся вопросы непосредственно с авторами этой работы. 

Я поговорил с Евгением Калашниковым, соавтором исследования и директором по продуктам инженерных инструментов платформы «Сфера». Мы обсудили исследование, поняли, что такое DevOps и кто такие девопсеры, порассуждали, существуют ли DevSecOps и зачем компаниям облака. Заодно заглянули в будущее, узнав, что нас ждёт в исследовании за 2023 год.

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

Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной доставки Continuous Delivery в CI/CD платформе Gitorion на базе Jenkins. В данной статье мы подробно рассмотрим тонкости внедрения системы единого входа Single Sign-On (SSO) во все сервисы CI/CD платформы Gitorion при помощи Keycloak.

В этой статье я расскажу о том какие есть способы оптимизации image при сборке в Docker - кэш, многошаговая сборка и прочее!

В этой статье я расскажу о том что такое docker compose, как его написать и разобраться во всех возможных конфигурациях этого файла!

В этой статье я расскажу об инструкциях Docker, о том как написать Dockerfile и о существующих best practice для этого!

В этой статье я расскажу о том, что такое Docker, Docker Desktop и как этим пользоваться! Два способа создания image, значения вкладок Docker Desktop

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

Поговорим мы о секретах в общем, но с практической точки зрения сфокусируемся именно на работе с секретами на машинах разработчиков: как их туда безопасно доставить и употребить.

Этот текст — продолжение серии CI/CD в каждый дом, в прошлый раз мы обсуждали, как организовать сборочный цех базовых docker-образов.

TL;DR: На dev-тачках должны светиться только персональные/локальные секреты. Короткоживущие секреты лучше вечных. Храним безопасно. Передаём шифрованно. Употребляем сессионно.

Всем привет. На этот раз хотел бы поделиться материалом, связанным непосредственно с devops работой. Недавно возникла потребность раскатить kafka кластер в kubernetes. В ходе развертывания возникло очень много сложностей, встречено множество подводных камней, и, естественно, в большинстве случаев рецепта в интернете найдено не было, поэтому приходилось искать решения самостоятельно методом проб и ошибок. Все, что здесь будет описано это сугубо личный опыт на одном из проектов. Сегодня я расскажу как с нуля раскатить dev контур bitnami/kafka кластера с помощью helm чартов, как обезопасить ваш кластер kafka и какие сложности могут вам встретиться.

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

Этот перевод статьи от learnk8s познакомит вас с принципами работы etcd, чтобы вы могли глубже понять внутреннюю работу Kubernetes и получить дополнительные инструменты для устранения неполадок в вашем кластере. Мы установим и сломаем кластер etcd с тремя нодами и узнаем, почему Kubernetes использует etcd в качестве базы данных.

Всем привет! Меня зовут Андрей, я DevOps инженер.

Когда я начинал изучать Kubernetes (K8s), я перечитал много статей, и, что в статьях, что в документации, информация была сильно разрознена, обрывочна. Сложно было скомпоновать информацию в единое целое.

На тот момент, мне бы хотелось найти одну большую статью, пусть и не полностью, но достаточно подробно описывающую процессы управления кластером K8s, деплоя и обслуживания приложений в нём.

Примерно такую статью я постарался написать.

В этой статье мы рассмотрим, как настроить пайплайн CI/CD в GitHub: подготовим репозиторий, зальём туда приложение, создадим файлы конфигурации GitHub Actions, в которых опишем, как собирать наше приложение и деплоить его в кластер Kubernetes, развёрнутый под управлением Deckhouse Kubernetes Platform. Деплоить будем с помощью Open Source CLI-утилиты werf. Она помогает организовать полный цикл доставки приложений в Kubernetes и рассматривает Git как единый источник истины для состояния развёрнутого приложения. Статья рассчитана на тех, кто только начинает свой путь в мире облаков и кластеризации.

Хочу написать небольшую серию постов о том, как я автоматизировала или ставила на конвейер какие‑то процессы, с разной степенью успешности, из личного и рабочего опыта. По функционалу это Python, SQL с привлечением Airflow, гитлаба и других стандартных инструментов.

Не поймите меня не правильно, я люблю людей, и своих коллег тоже (да, они тоже люди). Но когда им резко что‑то надо именно сейчас (ad‑hoc), и таких нуждающихся 30 человек‑ то я люблю их чуть меньше.

«Давай игнорировать ошибки» — бодро предложила я, и моя коллега меня поддержала. «Будет весело» — говорили они.

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

Привет! Меня зовут Михаил Кажемский, я Lead DevOps в IT‑интеграторе Hilbert Team. В последнее время к нам часто обращаются заказчики, которым нужна помощь с организацией хранения долгосрочных метрик в российских облаках. Так как для многих эта задача сейчас актуальная, в данной статье мы с моим коллегой Денисом Бабичевым решили рассказать, как мы используем мощные возможности ClickHouse для эффективного долгосрочного хранения метрик Prometheus. В статье вы найдете рекомендации по использованию инструмента и описание альтернативных решений, таких как Thanos, Grafana Mimir и Victoria Metrics.