Потребность в обработке информации растет с большой скоростью. Увеличиваются вычислительные мощности, растет пропускная способность каналов связи, появляются новые, требовательные к ресурсам highload приложения – все это выдвигает повышенные требования к мощностям Центров Обработки Данных (ЦОД), и в частности к сетевой инфраструктуре. Но прежде, чем начать рассмотрение различных вариантов дизайна сетей ЦОД, давайте вообще определимся, что же из себя представляет Центр Обработки Данных.

- Вы работали с Кафкой?
- Нет, только читали.

За несколько десятилетий развития ИТ систем разработчики накопили огромный опыт хранения и обработки данных. Различные СУБД позволяют с помощью запросов извлекать нужные данные за определенный период и обрабатывать их так как необходимо. Однако, со временем увеличились вычислительные мощности серверов, пропускная способность каналов связи, и соответственно, возникла необходимость обрабатывать бОльшие объемы данных за единицу времени. И тут выяснилось, что при всем многообразии различных решений для хранения данных, отсутствуют решения для обработки непрерывных потоков больших объемов данных. Для решения этой проблемы стали появляться различные системы, такие как системы обмена сообщениями и агрегирования журналов. Но они не могли в полной мере обеспечить нужную производительность на больших, непрерывных потоках данных.

Для решения этой проблемы в LinkedIn решили создать нужное решение что называется с нуля. Разработчики решили отказаться от хранения больших объемов данных, как в реляционных базах данных, хранилищ пар «ключ/значение», поисковых индексов или кэшей, а рассматривать данные как непрерывно развивающийся и постоянно растущий поток и проектировать информационные системы и архитектуру данных — на этой основе. Так появилось решение Apache Kafka, которое изначально использовалось для обеспечения функционирования работающих в реальном масштабе времени приложений и потоков данных социальной сети. Но сейчас это решение используется во многих крупных компаниях. Посмотрим подробнее как оно устроено.

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

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

Веб платформа ASP.NET за последние десятилетия получила достаточно широкое распространение. С ее помощью разрабатывают веб-сайты и веб-приложения с помощью таких средств как HTML, CSS и JavaScript. Также с помощью ASP.NET можно создавать веб-API и веб сокеты.

Одной из основных проблем при разработке в контексте безопасности является невозможность функциональной проверки у того, или иного приложения. То есть, при разработке приложения мы не можем просто подключить какие-то библиотеки, сделать какие-то настройки при сборке проекта, и затем сказать, что все, наше приложение защищено и можно передавать его в продакшен. Так не бывает. На практике возможны два основных сценария: худший когда мы узнаем о проблемах с безопасностью нашего приложения из СМИ и интернета, например, когда приложение взломали или, когда в сеть утекли данные, обрабатываемые нашим приложением (да, обычно эти утечки организуют бывшие или действующие сотрудники, и это не совсем вина приложения, но, как говориться  осадочек все-равно остается). Более мягким является сценарий, когда мы узнаем об уязвимостях в нашем приложении в результате пентеста или когда сознательные исследователи сами сообщают разработчикам о найденных уязвимостях, например в рамках баг баунти. В таком случае нас скорее всего еще не скомпрометировали и репутационного ущерба для компании разработчика не будет. Ну а срочные баг фиксы выпускают все.

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

Задачи автоматизации развертывания какого-либо ПО или изменения настроек системы практически всегда связаны с использованием учетных записей, обладающих необходимым набором прав для выполнения данных действий. И одна из самых важных проблем при использовании различных скриптов автоматизации состоит в том, что в этом сценарии приходится указывать учетные данные в открытом виде. Соответственно возникает проблема обеспечения безопасности этих данных, ведь к исходному коду скрипта может получить доступ любой пользователь, обладающий соответствующими правами. Кроме того, репозитории, в которых хранится исходный код сценариев тоже нуждаются в защите, так как здесь тоже любой имеющий доступ на чтение может узнать пароли. Конечно, можно попробовать хранить секретную информацию в отдельных файлах и считывать при выполнении сценария, но это не всегда возможно и часто требует дополнительного ручного труда, что несколько снижает преимущества автоматизации.

Язык программирования Java является одним из самых распространенных языков программирования. На нем написано множество сложных приложений как под Linux, так и под Windows. Однако, как и у любого другого языка программирования, у Java есть свои уязвимости.

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

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

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

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

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

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

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

Сегодняшняя статья будет посвящена обеспечению безопасности Kubernetes. Мы рассмотрим специфику защиты Kubernetes, и начнем мы с рассмотрения вопросов безопасности контейнеров.  

Kubernetes пожалуй является самым распространенным средством оркестрации контейнеризированных приложений. С его помощью можно автоматизировать развертывание, масштабирование и координацию работы с контейнером в условиях кластера. Благодаря этим свойствам Kubernetes (который также называют k8s) существенно сокращает время сборки, поставки и масштабирования контейнерных приложений.

Одним из замечательных свойств контейнеров k8s является их неизменяемость, то есть, если мы закрываем контейнер, то вся информация, хранящаяся в нем теряется. Это очень удобно для всевозможных тестовых и учебных сред, решений типа “песочница” и аналогичных. Суть сводится к тому, что что бы мы не делали с контейнером, после его закрытия все будет уничтожено. Мы можем запустить подозрительный файл в контейнере не опасаясь за последствия (если конечно у нас правильно настроено монтирование) и через пару минут уничтожить этот контейнер, также без последствий.

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

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

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

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

О необходимости выполнения резервного копирования для любых важных данных, будь то файлы, образ ОС или базы данных, написано множество статей. Поэтому убеждать читателя в необходимости бэкапить СУБД MySQL я не буду. Напомню лишь, что помимо бэкапа необходимо регулярно проверять резервные копии на возможность восстановления.

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

В первой статье мы рассмотрели шаблоны проектирования, применимые в программировании приложений. Однако сейчас сложно представить серьезное бизнес-приложение без базы данных. Большие объемы данных требуют хранения и обработки. И то насколько оптимально построена связь между уровнем прикладного кода и уровнем БД во многом зависит быстродействие системы в целом. Поэтому важно правильно построить взаимодействие с СУБД. В этой статье мы рассмотрим шаблоны взаимодействия с базами данных. Правильно выбранный шаблон взаимодействия позволит избежать многих проблем при разработке и получить качественное приложение.

В этой статье сначала настроим репликацию данных на второй сервер, а затем рассмотрим различные варианты секционирования.

Про Kubernetes написано огромное количество статей. Установка, настройка, мониторинг и безопасность все эти аспекты рассматриваются достаточно подробно. При этом, отдельным пунктом идет создание и настройка контейнеров. И если для решения глобальных задач  администрирования нужен Kubernetes уровня продакшен, то для работы с контейнерами промышленные мощности как правило не требуются, по крайней мере до этапа нагрузочного тестирования. Например, программисту нужно создать контейнер со своим приложением. Для этого ему будет вполне достаточно Minikube который позволит работать с контейнерами локально.

В этой статье мы рассмотрим использование minikube для работы с контейнерами. Поговорим о том, чем Minikube отличается от «большого» Kubernetes. Но начнем мы с процесса установки Minikube.

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

В этой статье мы будем говорить о том, как устроено логирование событий в ОС Linux. В качестве примера будет рассматриваться Ubuntu Linux 22.04, однако в других дистрибутивах основные элементы будут сходными.   

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

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

Представленный в статье материал предполагает знакомство читателя с основами объектно-ориентированного программирования.

В сегодняшней статье мы поговорим об устройстве дисковой подсистемы в ОС Linux. Конечно, многие скажут, что на эту тему написано уже множество статей и все и так прекрасно знают, как устроен Линукс и в том числе, как он работает с дисками. Однако, как показывает практика, даже многие администраторы при работе с дисковой подсистемой ограничиваются только начальным разбиением диска при установке операционки. Да и то, с параметрами по умолчанию. Так что я предлагаю подробнее рассмотреть такие вопросы дисковой подсистемы, как: работу с правилами правила системы udev, инструменты для работы с блочными устройствами и планировщики системы ввода/вывода.