Привет, Хабр! Недавно я предложила вам перевод статьи о проблемах, связанных с использованием Service Mesh, и преимуществах Ambient Mesh. Сегодня я хочу привести несколько конкретных чисел в качестве дополнения. Представляю вашему вниманию перевод статьи "Istio Ambient Mesh Performance in Single vs Multiple Kubernetes Namespaces" автора Anupam Saha.
Представляю вашему вниманию перевод статьи "Demystifying Istio Ambient Mesh for Total Beginners" автора Antonio Berben. В этом посте мы рассмотрим проблемы, возникающие в режиме sidecar, и то, как Istio Ambient Mesh изобретательно решает их, минимизируя использование прокси-серверов, упрощая масштабируемость и поддерживая безопасность. Давайте разберемся.
Charmed Kubeflow - это готовая к производству сквозная платформа MLOps с открытым исходным кодом на базе нативных облачных технологий.
Charmed Kubeflow преобразует шаги Machine Learning в полноценные рабочие процессы, позволяя обучать, настраивать и отправлять модели Machine Learning (ML). Это позволяет автоматизировать рабочие процессы, повысить качество моделей и упростить развертывание рабочих нагрузок ML в производстве надежным способом.
Charmed Kubeflow удовлетворяет потребность в создании приложений ML структурированным и последовательным образом, способствуя повышению производительности и улучшению сотрудничества в командах Data Science.
Для Data Scientists и Machine Learning Engineers Charmed Kubeflow предоставляет расширенный набор инструментов для организации и масштабирования их работы.
Привет, Хабр! Меня зовут Валентин Лебедев, я отвечаю за мониторинг в Газпромбанке. Мой опыт в области построения систем мониторинга — более двенадцати лет, из которых последние шесть — строил мониторинг для крупного и сверхкрупного бизнеса.
Статья будет полезна специалистам, строящим ядро/платформу мониторинга, и пользователям, ежедневно с ним взаимодействующим.
Хотя MicroK8s разработан как сверхлегкая реализация Kubernetes, создание кластера MicroK8s все же возможно и полезно. В этой статье я расскажу о том, как добавлять и удалять узлы и что требуется для обеспечения высокой доступности кластера.
Microk8s - это легкий, простой в установке дистрибутив Kubernetes, обеспечивающий полнофункциональный кластер на одной виртуальной машине. В последние годы он завоевал популярность благодаря своей простоте и удобству использования, особенно в сравнении с другими подобными вариантами Kubernetes, такими как k3s и minikube. В этой статье мы подробно рассмотрим, что такое Microk8s, чем он отличается от управляемых кластеров Kubernetes и какие преимущества он имеет по сравнению с другими дистрибутивами Kubernetes. Мы также поделимся собственным опытом использования Microk8s в различных проектах, подчеркнув преимущества и пользу, которые он дает. И наконец, мы покажем, как настроить его на вашей виртуальной машине.
Мы с радостью объявляем о релизе GitLab 16.10 с семантическим версионированием каталога CI/CD, шаблонами вики-страниц, возможностью перенаправлять трафик CI на вторичные ноды Geo, новой интеграцией ClickHouse для высокопроизводительной аналитики DevOps и многими другими фичами!
Безопасная разработка является неотъемлемой частью непростого пути к безопасности приложений. И у всех руководителей и лидов R&D, кто задумывается о построении у себя AppSec, возникает вопрос — с чего же начать? А начать нужно с организации процессов: определить положение дел, понять, какие активности необходимо внедрить, какие оптимизировать, а какие убрать. В общем, оценить зрелость текущих процессов безопасной разработки и обозначить дальнейшие шаги в светлое AppSec-будущее компании. И тут на помощь нам приходят фреймворки по безопасной разработке.
В финальной статье мне хочется поделиться кейсом повышения безопасности одного из самых важных компонентов инфраструктуры — базы данных (в моём случае — PostgreSQL v14 с управлением через patroni). Расскажу про то, как повысить скорость анализа потенциальных инцидентов, как настроить процессы шифрования дисков, как сгенерировать SSL‑сертификаты для базы данных и обеспечить их двухстороннюю проверку. А ещё поговорим про бэкапы и wal‑g-backup. Надеюсь, статья поможет каждому избежать ошибок в планировании и узнать что-то новое.
Wireshark - это хорошо известный инструмент для захвата пакетов, анализа и устранения неполадок. Он может перехватывать текущий сетевой трафик и анализировать его в режиме реального времени на микроскопическом уровне, а также считывать и обрабатывать сохраненные файлы захвата. Wireshark может анализировать и отображать множество различных протоколов и обладает мощной системой фильтрации для сужения интересующего трафика.
Эта секция написана уже после статьи, чтобы читатель посмотрел, а надо ли ему что-то отсюда или нет, но это забавное приключение, как всегда.
Что будет ниже:
• Поиск open source решения для общения голосом, шаринга экрана, включения видео и чатов в режиме peer-to-peer, без лишних бекендов
• Запуск этого решения в открытую в github pages
• Заворачивание этого решения на приватный сервер
• Простенькое закрытие доступа туды через basic http auth
• Заключение с описанием некоторых замечаний и потенцевальных возможностей
Эта статья фокусируется на примере использование библиотеки 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-ремесла, загадок функционирования индустрии, а также почти философских дебатов о том, насколько отдельные решения имеют право на существование.
Привет всем! В предыдущей статье мы подробно рассмотрели реализацию непрерывной доставки CD в платформе Gitorion на базе Jenkins. В данной статье мы подробно рассмотрим тонкости внедрения системы единого входа Single Sign-On (SSO) во все сервисы платформы Gitorion при помощи Keycloak.
В этой статье я расскажу о том какие есть способы оптимизации image при сборке в Docker - кэш, многошаговая сборка и прочее!
