Есть множество путей развернуть свой Kubernetes. Все они разные, выбор зависит от вашего бюджета, от того, какие задачи вы планируете решать, для каких нагрузок и что в конечном итоге вы планируете получить. В этой статье мы быстро пройдёмся по различным способам инсталляции, а затем попробуем развернуть свой K8s кластер на виртуальных машинах, воспользовавшись гипервизором второго типа (VirtualBox). Но это будет не условная Ubuntu, на которую мы будем ставить необходимые компоненты, а целая операционная система, разработанная специально для Kubernetes - Talos Linux!

Год назад мы выпустили «Маскировщик» — промышленный софт, который обезличивает персональные данные, сохраняя их качество и смысл. То есть гендерный баланс; социально‑демографическую структуру; родственные связи; страну и оператора в телефоне; валидность паспортов, ИНН, СНИЛС. В общем, «Маскировщик» делает так, чтобы вы тестировали продукты и обучали ML‑модели будто бы на «живых» ПД.

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

Есть отличный термин self hosted, который очень популярен в англоязычном интернете.
Но он плохо переводится, почти как open source - хотя википедия и пытается дать ужасно звучащий термин "самохостинг"...

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

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

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

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

В моей домашней лаборатории основная платформа виртуализации - Proxmox VE. Так как это все же дом, к интернету она подключена вместе со всеми остальными устройствами через обычный роутер с прошивкой OpenWRT.  

В большинстве экспериментов я практикую подход "если что-то пойдет не так... разберемся, а потом просто перезапустим терраформ". В ходе очередного такого эксперимента мне понадобилось перенастроить пару вещей глубоко внутри OpenWRT роутера, и внезапно пришло понимание, что домашний роутер совсем не эфемерный ресурс. На вопрос: «Если я окирпичу роутер, то смогу ли я его оживить без отвертки, паяльника и, самое главное, без доступа в интернет?» ответ был «¯\_(ツ)_/¯».  

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

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

Как бороться с типовыми причинами отказа? А самое главное — как их обнаружить? Рассмотрим лучшие элементы инженерной практики, обеспечивающие высокую доступность системы и оперативное расследование инцидентов. Коснёмся памяти, разберём базу данных, поговорим про ТСР-соединения.

Меня зовут Константин, я работаю в Газпромбанке. Занимаюсь транзакционными системами: платежами, переводами, также участвовал в разработке системы СБП в Газпромбанке. В своей практике столкнулся с десятками языков программирования, но в настоящий момент остановился на Java и Kotlin. Поэтому я буду рассказывать про проблемы backend разработки на этих языках.

Всем привет. Меня зовут Максим, и уже почти два года я содержу домашний сервер.

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

Эта статья является продолжением краткого туториала по переводу приложений на .Net Aspire. В ее рамках будет рассмотрено развертывание Aspire приложения в локальном кластере Kubernetes.

Не так давно в свет вышел .NET Aspire - продукт для упрощения создания и публикации микросервисных приложений от Microsoft. В рамках данной статьи будет рассмотрен ручной переход на Aspire в "игрушечном" случае: пара небольших проектов, один из которых обращается к Postgres'у.

Я люблю автоматизацию, гаджеты и IoT

Поэтому, места где я живу, рано или поздно становятся автоматизированными и обвешанными интернетом вещей

Да чего там, у меня даже бойлер по расписанию работает!

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

Привет, Хабр! После написания двух статей про недостатки Windows и непонимание развития системы, я решил устроить бунт на своем компьютере, пересев на Линукс. Не то, чтобы я прям планировал всерьёз менять операционную систему, но чётко осознавал, что мои «знания» о линуксе сильно устарели, так как помимо хостинга и деплоя, я им пользовался дома очень давно, практически 15 лет назад. Тогда было много проблем со стабильностью как различных приложений, так и графический окружений в частности. Ну и как-то не очень объективно сравнивать современные версии от майкрософт со своими старыми воспоминаниями о линуксе, ведь прогресс не стоит на месте, дистрибутивы развиваются, а интерфейс приложений становится все более дружелюбным и приятным для использования. Так ведь?

Привет! На связи Олег Казаков из Spectr. 

Мы продолжаем публикацию цикла статей, где делимся опытом и наработками и рассказываем, из чего состоит DevSecOps и как его внедрить в процесс разработки. 

В предыдущей части статьи я рассказал о том, что представляет собой процесс DevSecOps в целом, из каких этапов он состоит, и подробно остановился на первом этапе — Pre-commit Checks. Сегодня пришло время для обзора стадии Commit-time Checks и ее инструментов. Поговорим о каждом инструменте отдельно и расскажем, на чем мы все-таки остановили свой выбор.

Для любого разработчика глубокое понимание основных принципов системного проектирования является необходимым условием для создания стабильных и масштабируемых программных систем, способных обеспечивать высокую производительность. Системное проектирование (System Design) включает разработку архитектуры и структуры программной системы, направленную на удовлетворение специфических требований и обеспечение требуемых показателей производительности.

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

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

Привет! В этой статье мы развернем dev-cluster kafka последней версии (3.7 на момент написания статьи), без использования zookeeper. Также в нашей сборке будет web-ui и все для мониторинга. В представленной конфигурации настроены SASL, SSL, ACL.

В чем полезность статьи? В статье представлен готовый docker-compose.yml для использования, который будет вам полезен если вы не сильно искушены в вопросах администрирования kafka и docker-compose, но уже хотелось бы начать заниматься разработкой, используя кластер kafka. Беглый поиск в интернет не дал результата в виде готового docker-compose.yml для конкретно такой конфигурации, которая потребовалась нам, поэтому было решено выложить полученный результат.

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

Мой первый on-call выдался нелегким. Недели тренингов и обучения не подготовили меня к тому что придется бегать по Slack каналам различных команд и искать того, кто может что либо знать о какой-то из частей системы. Оказалось что многие страницы в корпоративной Wiki уже не обновлялись несколько лет. Команды хранили свою документацию кто где хотел: кто в Wiki, кто в Google Docs, кто в GitHub и т.д. Наш on-call был не идеален: 2 человека выходили на дежурство 24/7. Один был ответственен за всю инфраструктуру (MySql, Cassandra, Kafka, ElasticSearch, Nomad и т.д.), второй же был Developer on-call и отвечал за все микросервисы и различные легаси системы, что в сумме давало около 300 различных сервисов от 7 команд на самых различных стеках и фреймворках (Java, Scala, Node, Go). Но что меня больше всего раздражало - так это невозможность быстро оценить на высшем уровне как проходит и обрабатывается запрос от пользователя. Диаграммы для разных бизнес частей точно также были либо устаревшими, либо без прилегающей документации, либо для какой-то бизнес логики не было ничего. И вот тогда мне пришла идея, что было бы неплохо иметь диаграммы, в которых можно не только нажать на любой элемент и добыть о нем более детальную информацию, но также получить ссылки на другие диаграммы и динамически их подгружать. Мне хотелось иметь возможность быстро разобраться в неизвестной распределенной системе, не переключаясь между диаграммой и документацией в Google Docs или Wiki. Именно так я начал работать над проектом Schem.io.

Предупреждение: в статье содержится большое количество GIF-изображений.

Привет! Меня зовут Александр Попов, я tech lead команды маркетплейса 05.ru. Сейчас мы занимаемся бэком маркетплейса и некоторыми другими сервисами на рынке Дагестана. 

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