В этой статье мы продолжим рассмотрение файловой системы BTRFS и, в частности, поговорим о том, как работать в этой файловой системе с RAID массивами.

В начале я немного напомню о том, что такое RAID массив и какие они бывают. А то вдруг кто-то забыл или на собеседовании спросят. И затем мы перейдем уже к непосредственной настройке этого функционала в BTRFS.

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

Для запуска Kafka можно использовать решения для управления кластером, такие как ZooKeeper или KRaft. В статье мы рассмотрим работу с ZooKeeper. Zookeper это распределенное приложение для управления кластером, состоящим из большого количества узлов.

В предыдущей статье мы поговорили о надежности ЦОД и начали рассмотрение темы дизайна  сетей ЦОД. В этой статье мы продолжим данную тему и поговорим о кабельной инфраструктуре. Эта тема не очень популярна у ИТ-шников. Мы привыкли втыкать шнурок в Ethernet розетку и там появляется сеть, а может даже Интернет, но мы не особо задумываемся о том, как эта сеть построена на физическом уровне. Но, между тем, кабельная инфраструктура в ЦОД имеет большое значение ведь именно она обеспечивает сетевую доступность ресурсов ЦОД.

Для проектирования различных систем ЦОД существует серия стандартов EN 50600-x, которая предоставляет всесторонний и независимый комплекс определений и требований к проектированию и эксплуатации всех сооружений и инфраструктуры ЦОД. К кабельной инфраструктуре относится стандарт EN 50600-2-4, который охватывает несколько типов кабельных систем.

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

Итак, файловая система BTRFS (B-Tree Filesystem) предназначена для работы в Unix-подобных операционных системах. Она была разработана компанией Oracle в 2007 году. BTRFS построена по принципу CoW (Copy on Write), то есть при чтении области данных используется общая копия, в случае изменения данных — создается новая копия. Данная технология используется для оптимизации многих процессов, происходящих в операционной системе.

Потребность в обработке информации растет с большой скоростью. Увеличиваются вычислительные мощности, растет пропускная способность каналов связи, появляются новые, требовательные к ресурсам 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, так как он повторяет основные моменты теории резервного копирования.

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

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