DevOps *

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

Так было не всегда. Когда .NET был еще совсем молод, большинство приложений работали в рамках одного домена Windows. Обычно в файле web.config не нужно было хранить пароли; права доступа к базе данных предоставлялись непосредственно учетной записи пользователя, под которой работало приложение.

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

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

В этой обзорной статье мы рассмотрим основные решения для реализации IaC и поговорим об их достоинствах и недостатках.

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

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

Прим. переводчика: автор статьи предлагает реализацию honeypot'а («приманки») на основе виртуального кластера Kubernetes, чтобы обнаруживать попытки взлома K8s-инфраструктуры. Также в статье рассматриваются отличия низкоинтерактивных и высокоинтерактивных приманок.

Если не вдаваться в детали, главная задача приманок — соблазнять злоумышленников, отвлекая от реальных целей, и попутно собирать информацию об их деятельности. Сегодня мы попытаемся создать такую приманку с помощью vcluster и Falco.

В первой части серии речь пойдет о том, как собрать простую SSH-ловушку для выявления атак, направленных на среду исполнения.

Семь Open Source и два low-code-продукта для визуализации BI-аналитики от AFFINAGE

Для решение клиентских задач мы постоянно ищем способы сделать лучше. И очень часто сделать лучше значит сменить продукт. Поэтому мы постоянно анализируем рынок различных nocode-решений. Мы решили поделиться накопленными знаниями о такой важной задаче как построение аналитических дашбордов.

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

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

Сегодня я поделюсь нашей историей запуска инструмента Kafka Cruise Control от LinkedIn. Наш путь по запуску на наших объёмах был тернист, и получился интересным, почти детективным рассказом. А если вы думаете, как автоматизировать рутинные операции по администрированию Kafka-кластеров, то, уверен, почерпнёте для себя что-то полезное. 

В серии из трех статей рассказываем о переходе с монолитной на микросервисную архитектуру. Разбираемся, когда и кому это действительно нужно, рассматриваем 7 миграционных шаблонов и самый больной вопрос: «Как быть с данными?».

Есть такая классическая и одновременно забытая технология отладки FirmWare как интерфейс командной строки поверх UART.

В этом тексте я напишу про достоинства и недостатки отладки через UART Shell.

У большинства популярных DNS-провайдеров есть API, с помощью которого можно управлять записями. Это позволяет автоматизировать заказ и продление SSL-сертификатов через DNS01.

В Kubernetes для работы с сертификатами используется cert-manager. Чтобы заказать сертификат в кластере, нужно объявить ресурс центра сертификации — например, ClusterIssuer, который используются для подписи CSR (запросов на выпуск сертификата). К сожалению, не для каждого DNS-провайдера существует CusterIssuer. Однако cert-manager позволяет написать свою реализацию. У нас такая потребность возникла в проекте одного из клиентов, который пользовался услугами DNS-провайдера REG.RU.

Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:

Введение

В новой статье говорим про безопасность в Linux: как настроить и что важно учитывать в процессе. Дополнительно разбираем PAM и модули аутентификации, рассматриваем iptables. 

За основу взят один из уроков нашего практического курса «Администрирование Linux Мега».

От любой системы, которую внедряем в проект, мы ждём стабильной работы. Jenkins не исключение. Когда мы выбираем его в качестве инструмента CI/CD, он начинает напрямую влиять на time to market приложения и, соответственно, на деньги, которые может заработать компания. В случае сбоя Jenkins мы получаем влияние не только на команду разработки, но и на бизнес. Чтобы минимизировать риски, необходимо правильно настроить инструмент. В статье рассказываем о best practice, которые должен знать каждый администратор Jenkins.

В мире кровавого энтерпрайза есть некоторое количество проектов-мамонтов. Они большие, у них базы данных на SQL Server, в этих базах тысячи и десятки тысяч объектов, миллионы строк кода T-SQL, огромная вариативность данных, всё хрупкое, неидемпотентное, недетерминированное и фигово документированное. Короче, как писал Roy Osherove в своей The art of unit-testing:

Finally, as a friend once said, a good bottle of vodka never hurts when dealing with legacy code.

В вольном переводе "Да там без поллитры не разберёшься!"

И вот у этих проектов есть беда — большие контуры тестирования и разработки, часто так или иначе модифицированные и уменьшенные копии основного продуктового контура. Да-да-да, тут сразу поналетят умные да в белой одежде и начнут объяснять, что надо писать тестовые наборы данных (а кто спорит?), что тестовый контур должен быть небольшим (а кто спорит?), что код должен быть переносимым между СУБД (спасибо, Кэп!), что всё было бы лучше, если бы проект переписали N лет назад (ха-ха) и прочие "станьте ёжиками" и "пусть едят пирожные". Нет, дорогие мои. Просто представьте, что у вас есть БД SQL Server с 25К объектов (таблиц и ХП) и миллионами строк запросов, и часть объектов создана с SET ANSI NULLS ON, а часть с SET ANSI NULLS OFF. И точно известно, что в части запросов эта разница используется. И БД на десятки ТиБ. И однодневный простой системы стоит больше, чем квартиры всех разработчиков, которые за последние 20 лет трогали этот код (из которых, кстати, сейчас работает только 7 последних самураев). Одно это может не давать перейти с SQL Server 2008 R2 на что-то более свежее пару лет.

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

Когда зарубежные облака перестали принимать наши карты, перед многими бизнесами возникла срочная необходимость мигрировать свою инфраструктуру в Россию. К счастью, рынок отечественных облачных сервисов очень большой. Самыми крупными считаются Yandex Cloud, VK Cloud и SberCloud. Можно сказать, это наша «большая тройка». Еще есть Selectel, КРОК, MTS Cloud, DataLine — список можно продолжать достаточно долго. Хотя не все так радужно.

Архитектор Yandex Cloud Павел Селиванов рассказывает о Terraform в условиях ухода «большой тройки» облаков с российского рынка, отечественных облачных сервисах и IaC.

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

Иногда взрослые думают, что школьные проекты — это что-то несерьёзное, задания упрощённые, а получаемый результат нельзя внедрить в реальный IT-мир. Мы, шесть школьников, участвовавших в научно-технологической программе «Большие вызовы-2022» на базе образовательного центра «Сириус» в составе команды банка ВТБ, попытаемся доказать вам, что большие данные и машинное обучение — это не прерогатива умудрённых опытом разрабов и что даже школьник (не простой, а мотивированный и подготовленный) может стать дата-сайентистом и планировать свою будущую карьеру до поступления в ВУЗ.

Наша конференция DevOops — уже на следующей неделе. А что вообще значит «конференция про девопс»? О чём должны быть доклады на таком мероприятии?

Есть определённые инструменты и технологии, о них можно делать доклады, тут всё понятно. Но ведь девопс — это не просто набор инструментов, а культура взаимодействия разработки и эксплуатации. И если в компании используют Kubernetes, это ещё не значит, что там магически расцвёл девопс. Как тогда правильнее, говорить о процессах или о технологиях?

Мы решили, что правильнее не «или», а «и». Поэтому разделили программу на разные блоки. Есть большой блок про «культурную» составляющую — скажем, доклад о выстраивании подхода DocOps отправляется туда. А есть блоки про облака, безопасность, SRE — и вот там могут разбирать узкие технические вопросы и конкретные инструменты (например, Linkerd). 

Рассказываем Хабру, какие именно доклады в этот раз будут в каждом из блоков. А все остальные подробности о конференции (и билеты на неё) доступны на её сайте.

Я знаю многое о велосипедах в Enterprise-разработке. Видел издали, катался на них, собирал сам, но наступают моменты, когда типичные задачи пора перевести на типичные решения. В статье расскажу о 4 self-hosted сервисах, которые освобождают уйму времени на действительно важные вещи.