Сейчас в связи с санкциями публичный Terraform репозиторий https://registry.terraform.io блокирует доступ из подсанкционных регионов.

Как я пришёл к тому, что сделал опенсорс зеркало.

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

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

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

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

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

В микросервисной архитектуре приложение разбивается на несколько отдельных служб, которые выполняются в отдельных процессах. Существует другая база данных для разных функций приложения, и службы взаимодействуют друг с другом с использованием HTTP, AMQP или двоичного протокола, такого как TCP, в зависимости от характера каждой службы. Межсервисное взаимодействие также может осуществляться с использованием очередей сообщений, таких как RabbitMQ , Kafka или Redis .

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

Приветствую, читатели Хабра! Сегодня я хочу поделиться с вами тем, как мы можем создать приложение для генерации документов с использованием CarboneJS, Minio и NodeJS. Приложение будет использовать CarboneJS для генерации документов, Minio в качестве сервера объектного хранилища и NodeJS как среду выполнения. Давайте начнем!

Заметили, что мир становится намного красочнее, пестрее, ярче и контрастнее?

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

Сейчас же парадигма сместилась в сторону скроллинга ярких картинок, фотографии и видео, и на первый план вышло яркое представление, а не качество внутри.

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

https://github.com/paulbuzakov/tmuxconfig

Ровно два года назад, 16 марта 2022 года, ваш покорный слуга рассказал про нехитрые телодвижения, которые с помощью rclone позволяют сохранить локально ваши корпоративные Google shared drives (не путать с личным Google Drive).

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

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

Чтобы не изобретать велосипед, мы решили рассмотреть известные операторы, позволяющие разворачивать базы данных PostgreSQL в Kubernetes и управлять ими.

Всем привет! Меня зовут Максим, я работаю системным инженером в Yandex Cloud и в Яндекс Практикуме на курсе «Системный администратор». В этой статье я опишу свой субъективный взгляд на путь развития системного инженера (DevOps‑инженера, SRE, системного администратора).

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

В дополнение к этой статье я создал:

- диаграмму на roadmap.sh;

- git‑репозиторий со ссылками на ресурсы для изучения (жду ваших пул‑реквестов).

Hashicorp Vault - прекрасный продукт для централизованного хранения всех паролей и других секретов компании. При этом, многие знают, что удобная ключница - это идеальный способ потерять все ключи одновременно. Когда я работал в крупном телекоме, то DRP-протоколы с восстановлением данных учитывали даже запрет на сбор более двух Хранителей Ключей в одном месте. Чисто на случай очень неудачного корпоратива с совместным полетом на воздушном шаре, дегустацией домашних грибов или другими подобными факторами. Короче, если вы внедряете подобную систему, то вам надо очень внимательно подходить не только к вопросам эксплуатации, но и резервного копирования и восстановления.

Сегодня я не буду глубоко касаться темы организации правильного хранения фрагментов ключей Шамира. Вместо этого, я попробую рассказать о том, как развернуть с нуля отказоустойчивый кластер Hashicorp Vault в community edition. Для этого поднимем основной и тестовый кластер Vault в нескольких регионах и датацентрах. Тестовый кластер у нас одновременно будет служить и резервным в рамках процедуры DRP.

Чтобы было совсем интересно, настроим процесс таким образом, чтобы тестовый кластер был односторонней репликой продуктивного с отставанием в несколько суток. Разумеется, все развертывание мы будем проводить в парадигме Infrastructure-as-a-code с Terraform и Ansible в качестве основных инструментов.

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

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

Привет, Хабр.

Последнее время DevOps и CI/CD де-факто стали повсеместным стандартом независимо от размера команды, в интернетах хватает статей, почему это важно, в чём собственно идея, полезных практик и других материалов. Я же решил подойти с несколько другой стороны и максимально доступным языком на практических примерах рассмотреть отдельные задачи и их решения в рамках концепции.

Одной из таких задач, которую я хотел бы рассмотреть первой, является задача создания сборочного цеха базовых docker-образов, используемых в репозиториях и процессах проекта. 

Кому, собственно, это может пригодиться? Я бы сказал, что почти кому угодно, кто хочет организовать ту компоненту CI/CD, которая отвечает за построение и релизный цикл базовых образов внутри инфраструктуры вашей компании или даже персональных проектов (зародился он именно в процессе приведения в порядок моих пет-проектов).

Какой практический пример может быть без публичного репозитория с MIT-лицензией? Если вам не интересно читать статью, то можно прямо из превью перейти по ссылке и напитаться кодом. Репозиторий же можно копировать как целиком, так и кусками, буду только рад, если он кому-нибудь пригодится. На любые вопросы — готов ответить в комментариях или issues.

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

Для личных нужд я использую bare-metal сервер от Hetzner, порезанный на виртуалки и, с недавних времен, VPS на HostHatch для мониторинга и резервирования. Также есть маленькая ВМка у TietoKettu (для ВПН, экспериментов и прочее).

Так как IPv4-адресов мало, то хостинги обычно дают дополнительные айпишки за дополнительные деньги, а вот IPv6-сети выделяют щедро. Изначально, я объединил все виртуалки, у которых был публичный IPv4-адрес в Wireguard mesh сеть, но потом когда выяснилось, что надо бы присоединить ещё одну ВМку, пришлось переделать mesh на IPv6-адреса и тут понеслось...

Сначала выяснилось что у HostHatch нет связности с ElmoNet (TietoKettu использует их адреса), после недели-двух бодания с техподдержкой HostHatch-a связность появилась. Однако недели две назад от них приходит письмо, о техобслуживании нод, где живут мои ВМки. И что вы думаете? После обслуживания туннель до этих ВМок так и не восстановился. В итоге, оказалось что обе вмки исчезли их IPv6-интернета. На этот раз связность починили только через 3 дня, хотя я создал срочный тикет.

В итоге, я перевёл туннели обратно на IPv4 и переключился на DN42, но в один выходной мне на глаза попалась статья на Reddit и я решил воскресить идею о "своем" куске Интернета. Масла в огонь подбавил Vultr, который наглухо заблокировал доступ на свои ресурсы (даже IP calculator) с Hetzner.

В одном из комментов, к вышеупомянутой статье, была ссылка на IPv6-сообщество в Discord. Я присоединился и стал задавать много вопросов в канале #asn-newbies.

Думаю, что кому-нибудь мой опыт и набитые шишки будет полезен. Если это так, то прошу под кат.

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

Как подготовить для этого данные я детально описывал в "Где 15 минут пешком от дома до метро в Москве" "Где в Москве жить «неплохо»". В публикации "Жилье в 500м от сетевых продуктовых магазинов в Москве." я столкнулся со специфичным трафиком с желтушных публикаций и сообщество OSMеров предложило мне отличный вариант, когда визуализация не требует чтения исходной статьи.

Карта теперь доступна на сайте и использует DuckDB Wasm для запросов к данным прямо из браузера!

Возможно, у вас была мысль запустить собственную услугу Infrastructure as a Service (IaaS) либо разместить свои проекты на Kubernetes, но не платить за managed-услуги, или ваш проект — это и есть self-managed Kubernetes. У full-stack-разработчика и предпринимателя Нейта Бакареффа эти желания сошлись воедино.

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

При нашей работе мы используем подход «Инфраструктура как код». Однако в процессе его использования мы столкнулись с проблемой написания пайплайнов для инфраструктуры.

Во всём «виноват» terragrunt: каждому модулю terragrunt нужна отдельная джоба в пайплайне на plan и apply, но для каждого модуля они во многом повторяют друг друга. Подобное постоянное написание одинаковых частей CI/CD пайплайна при добавлении новых баз и бакетов навевало тоску.

Рассказываем, как мы создали генератор джоб в Gitlab CI/CD и навсегда забыли о ручном написании пайплайнов для развёртывания элементов инфраструктуры.

Как загрузить список из 500 доменов на mikrotik, чтоб он их преобразовал в IP-адреса?

Как заставить Mikrotik резолвить домены по wildcard?

Как поднять Shadowsocks\VLESS на ROS?

Никак

Я задался этими вопросами, достал hAP ac lite из шкафа и посмотрел, на что способна ROS 7 в конце 2023 года. Потестил всем известные способы, а также попробовал запихать много доменов в address-lists.