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

Тем не менее развернуть лабу из нескольких устройств с множеством сетевых интерфейсов и подключений, к примеру, для проверки BGP, в том числе между устройствами разных производителей, задача нетривиальная.  Можно, конечно, писать плейбуки Ansible для развертывания виртуалок на ESXi и последующей конфигурации устройств, но это само по себе достойная задача. Может быть что-то с vagrant изобразить…

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

Решил исправить. Вдруг кому-то еще облегчит жизнь.

Начиная с первых версий .NET Core для сборки приложений, компания Microsoft предоставляет простой и удобный интерфейс командной строки (.NET CLI). Его возможности покрывают большинство потребностей по сборке, упаковке и тестированию приложений. Несмотря на это, по мере роста приложения, увеличения количества его составных частей/сборок/пакетов, усложнения процессов тестирования и развертывания, рядом с проектом часто появляются такие файлы сценариев как build.ps1, build.sh, build.cmd или даже полноценные инфраструктуры автоматизации построения приложений. В статье TeamCity C# script runner была предложена еще одна альтернатива - сценарии C#, которые особенно полезны, когда необходимо эффективно автоматизировать какой либо аспект сборки силами .NET разработчиков или  DevOps, знакомыми с синтаксисом C#. Тогда же была упомянута идея расширить встроенный API сценариев для более глубокой интеграции с TeamCity и для поддержки наиболее частых вариантов использования. Предполагая, что API сценариев чаще всего будет задействован при сборке приложений, мы в первую очередь решили расширить именно его. В этой статье будут приведены примеры использования этого API.

Напишем вместе HTTP-сервис на golang с нуля? Я уверен, что это довольно несложно. Для тех, кто каждую неделю этим занимается, моя статья не будет особенно интересна, но я все равно рекомендую взглянуть и оценить, возможно, ваши комментарии спасут кому-то жизнь. А может кое-какие из моих рассуждений спасут вашу.

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

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

• Выработаем понимание структуры и жизненного цикла приложения.
• Формализуем наше представление жизненного цикла на языке go.

Я давно искал какой-нибудь инструмент для низкоуровневой отладки сети Linux. Linux позволяет создавать сложные сети, запускаемые прямо на хосте, используя комбинацию из виртуальных интерфейсов и сетевого пространства имен. Когда что-то идет не так решение возникших проблем утомительно. Если это проблема маршрутизации L3, mtr (Matt's traceroute) имеет неплохие шансы принести пользу. Однако, если проблема на более низком уровне, обычно все заканчивается тем, что я вручную проверяю каждый интерфейс / мост / пространство имен сети / iptables и пару раз запускаю tcpdump в попытках понять что происходит. Если вы не знакомы с настройками сети, то при решении проблем в ней, вас ждет запутанный лабиринт.

Существует несколько программ с графическим интерфейсом, предназначенных для создания Live USB-дисков.

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

Проект начатый китайским разработчиком longpanda примерно полтора года назад, в марте 2020-го, успел набрать популярность и уже включён в состав репозиториев некоторых дистрибутивов linux. И неспроста.

Развёртывание в Kubernetes из GitLab

Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.

А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.

Желательны но необязательны базовые знания

• Docker;
• Kubernetes;
• Git;
• Node.js;
• React;
• Bash.

В дальнейшем мы сделаем следующее.

• 🧱 Познакомимся c нашим приложением, обсудим из чего оно состоит.
• 🐳 Докеризуем наше приложение.
• ☸️ Развернём наше приложение в Kubernetes локально на Docker Desktop.
• ☁️ Обсудим особенности GCP и как нужно изменить наше приложение, а затем ещё раз развернём наше приложение в Kubernetes но уже в GCP.
• 🦊 Завершим наш туториал созданием конвейера для развертывания приложения в GCP при помощи GitLab.

- Ребята, кажется, вы таймаутите. Вот трейс, на котором видно, что мы не дождались от вас ответа за 2 секунды. 

- Ничего подобного, у нас все норм — мы за 200 миллисекунд отвечаем в 99% запросов. А вот вы по какой-то причине часто преждевременно обрываете соединение. 

Такой разговор однажды произошёл у нас в Ozon между моей командой личного кабинета продавца и коллегами, которые пишут сервис аутентификации. Причина проблемы оказалась в дефолтных настройках Go для пула HTTP-соединений. Как так вышло, как мы обнаружили проблему и как исправлять подобные ситуации в микросервисах на Go – об этом моя сегодняшняя история. 

Сетевой стек — одна из самых запутанных вещей в Linux. И не только из-за сложности некоторых концепций и терминов, но и из-за изменения смысла некоторых параметров в разных версиях ядра. В этой статье приведена информация для ядра 2.2 и выше, а также, там где это возможно, указано различие между версиями вплоть до 5.5.

О том как изменять параметры ядра, описываемые здесь, можно прочитать в статье Linux Kernel Tuning for High Performance Networking: Configuring Kernel Settings.

По роду своей деятельности я занимаюсь системным администрированием. Поскольку сам по себе я человек ленивый, я люблю максимально всё автоматизировать. Отсюда и любовь ко всяким средствам "Everything-as-Code".

Прочитав монументальную серию статей о подключении LCD экрана к роутеру мне захотелось сделать то же самое. Однако многообразие используемого стека (openwrt, stm32, usb) в сочетании с отсутствием полных исходников кода но может плохо искал несколько затруднило задачу. Я решил начать с малого — написать свою реализацию framebuffer для raspberry и вывести графическую среду raspberry на LCD. Что из этого получилось, описываю далее.

В рамках современной микросервисной архитектуры мы можем разделить микросервисы на две основные группы в зависимости от их взаимосвязи и взаимодействия. Первая группа представляет из себя внешние микросервисы, которые напрямую доступны пользователям. В основном это API на основе HTTP, которые используют обычные текстовые сообщения (JSON, XML и т. д.), оптимизированные для использования сторонними разработчиками, использующие передачу репрезентативного состояния (REST) ​​в качестве коммуникационной технологии. 

Распространенность и хорошая поддержка REST играют решающую роль в успехе внешних микросервисов. OpenAPI предоставляет четко определенные спецификации для описания, создания, использования и визуализации REST API. Для таких API существуют системы управления API, которые обеспечивают безопасность, ограничение скорости, кеширование и монетизацию наряду с реализацией бизнес-требований. В качестве альтернативы REST API на основе HTTP можно использовать GraphQL, но это уже тема для отдельной статьи.

Привет, Хабр! Приглашаем на бесплатный Demo-урок «Параллельный кластер CockroachDB», который пройдёт в рамках курса «PostgreSQL». Также публикуем перевод статьи Тома Брауна — Principal Systems Engineer at EnterpriseDB.

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

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Статья подготовлена в преддверии старта курса «Администратор Linux»

В Red Hat Enterprise Linux 8 приоритетным низкоуровневым решением является nftables. В этой статье мы поговорим о том, как начать использовать nftables. Наиболее актуальной она будет для системных администраторов и DevOps-специалистов. Там, где это имеет смысл, мы поговорим о различиях между nftables и его предшественником — iptables.

Для начала необходимо отметить, что nftables – это userland-утилита, nft и подсистема ядра. Внутри ядра она строится на базе подсистемы netfilter. В этой статье мы будем говорить о взаимодействии пользователя с утилитой nft.

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