Знали ли вы, что поды могут становиться «невидимыми»?
Проверьте свои знания Kubernetes, попробуйте найти невидимый pod в этом челлендже: https://labs.iximiuz.com/challenges/kubernetes-invisible-pod-0bf2109b
Никаких подсказок и решений. Готовьтесь к жёсткой задаче😈
👉 DevOps Portal
Проверьте свои знания Kubernetes, попробуйте найти невидимый pod в этом челлендже: https://labs.iximiuz.com/challenges/kubernetes-invisible-pod-0bf2109b
Никаких подсказок и решений. Готовьтесь к жёсткой задаче
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6💊2
Быстрый совет по Linux
Хочешь повторно использовать последний аргумент из предыдущей команды? Используй
Сбережёшь своё драгоценное время✌️
👉 DevOps Portal
Хочешь повторно использовать последний аргумент из предыдущей команды? Используй
!$Сбережёшь своё драгоценное время
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤8🔥1
Упрощённое визуальное руководство по CI/CD
Непрерывная интеграция (CI) — практика частого слияния изменений кода в общий репозиторий с автоматической проверкой их целостности
Непрерывное развёртывание (CD) — автоматизирует релиз и деплой изменений кода в продакшен, обеспечивая отлаженный и надёжный процесс
Этот визуальный гайд поможет быстро разобраться, как это работает
👉 DevOps Portal
Непрерывная интеграция (CI) — практика частого слияния изменений кода в общий репозиторий с автоматической проверкой их целостности
Непрерывное развёртывание (CD) — автоматизирует релиз и деплой изменений кода в продакшен, обеспечивая отлаженный и надёжный процесс
Этот визуальный гайд поможет быстро разобраться, как это работает
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Совет дня по Linux
В Linux оператор конвейера (|) полезен, когда нужно направить вывод одной команды на вход другой для дальнейшей обработки:
Однако это не перенаправляет ошибки. Если файл не существует, команда
Что если нужно перенаправить и обработать как ошибки, так и обычный вывод?
Здесь на помощь приходит оператор перенаправления
Этот оператор направляет как стандартный вывод (stdout), так и стандартные ошибки (stderr) первой команды через конвейер на стандартный ввод (stdin) второй команды. Посмотрите на следующий пример:
Обратите внимание на разницу: команда
Оператор
👉 DevOps Portal
В Linux оператор конвейера (|) полезен, когда нужно направить вывод одной команды на вход другой для дальнейшей обработки:
$ cat data.txt | grep "No such file"
Однако это не перенаправляет ошибки. Если файл не существует, команда
grep не даст результата.Что если нужно перенаправить и обработать как ошибки, так и обычный вывод?
Здесь на помощь приходит оператор перенаправления
|&.Этот оператор направляет как стандартный вывод (stdout), так и стандартные ошибки (stderr) первой команды через конвейер на стандартный ввод (stdin) второй команды. Посмотрите на следующий пример:
$ cat data.txt |& grep "No such file"
Обратите внимание на разницу: команда
grep смогла найти совпадение.Оператор
|& в bash является сокращением для оператора перенаправления 2>&1 |:$ cmd-1 2>&1 | cmd-2
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16❤2
Мы все знаем, что у AWS недавно случился даунтайм. Давайте разберём, что именно произошло.
Регион US-EAST-1 — один из крупнейших и наиболее критичных дата-центров AWS, где размещена инфраструктура тысяч крупных сайтов и приложений. Когда у DynamoDB, ключевого сервисa баз данных, начали расти ошибки, это вызвало эффект домино по взаимосвязанным системам AWS. Сбои стали массовыми, потому что многие приложения полагаются на DynamoDB для операций хранения и выборки данных.
DynamoDB глубоко интегрирован в архитектуру control plane AWS. Многие сервисы AWS используют его внутри для хранения метаданных, информации о состоянии и конфигураций сервисов. Поэтому, когда API-эндпоинт DynamoDB стал недоступен через DNS, зависящие от него сервисы потеряли доступ к критически важным операционным данным. Сбой одновременно затронул более 36 сервисов AWS.
Когда упала DNS-резолюция, клиенты просто перестали находить нужные эндпоинты DynamoDB. Это запустило фидбек-луп, похожий на тот, что произошёл во время даунтайма DynamoDB в сентябре 2015 года: каждый повторный запрос потреблял больше ресурсов, вызывал новые таймауты, которые, в свою очередь, генерировали ещё больше ретраев - и так по кругу, пока система не ушла в штопор.
AWS, вместо того чтобы ждать, пока найдут и устранят одну конкретную корневую причину, сразу пошёл по нескольким параллельным сценариям восстановления.
Основное исправление заключалось в стабилизации инфраструктуры DNS-резолвинга для эндпоинта DynamoDB. Команды инженеров AWS, вероятно:
🔹 переконфигурировали или перезапустили DNS-резолверы, обслуживающие DynamoDB
🔹 временно перевели трафик на альтернативные пути DNS-резолвинга
🔹 применили аварийные настройки DNS-кэширования
Этот инцидент отражает взаимозависимость и хрупкость крупномасштабных облачных экосистем, где даже единственная точка отказа в базовом сервисе способна за минуты вызвать каскад проблем в десятках систем.
P.S. Это лишь часть деталей и предположений, которые я нашёл в интернете и сформировал на основе собственного понимания. Точные и подробные данные AWS ещё не раскрыл.
👉 DevOps Portal
Регион US-EAST-1 — один из крупнейших и наиболее критичных дата-центров AWS, где размещена инфраструктура тысяч крупных сайтов и приложений. Когда у DynamoDB, ключевого сервисa баз данных, начали расти ошибки, это вызвало эффект домино по взаимосвязанным системам AWS. Сбои стали массовыми, потому что многие приложения полагаются на DynamoDB для операций хранения и выборки данных.
DynamoDB глубоко интегрирован в архитектуру control plane AWS. Многие сервисы AWS используют его внутри для хранения метаданных, информации о состоянии и конфигураций сервисов. Поэтому, когда API-эндпоинт DynamoDB стал недоступен через DNS, зависящие от него сервисы потеряли доступ к критически важным операционным данным. Сбой одновременно затронул более 36 сервисов AWS.
Когда упала DNS-резолюция, клиенты просто перестали находить нужные эндпоинты DynamoDB. Это запустило фидбек-луп, похожий на тот, что произошёл во время даунтайма DynamoDB в сентябре 2015 года: каждый повторный запрос потреблял больше ресурсов, вызывал новые таймауты, которые, в свою очередь, генерировали ещё больше ретраев - и так по кругу, пока система не ушла в штопор.
AWS, вместо того чтобы ждать, пока найдут и устранят одну конкретную корневую причину, сразу пошёл по нескольким параллельным сценариям восстановления.
Основное исправление заключалось в стабилизации инфраструктуры DNS-резолвинга для эндпоинта DynamoDB. Команды инженеров AWS, вероятно:
Этот инцидент отражает взаимозависимость и хрупкость крупномасштабных облачных экосистем, где даже единственная точка отказа в базовом сервисе способна за минуты вызвать каскад проблем в десятках систем.
P.S. Это лишь часть деталей и предположений, которые я нашёл в интернете и сформировал на основе собственного понимания. Точные и подробные данные AWS ещё не раскрыл.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍23❤11
Kubernetes позволяет добавлять собственные API
В Kubernetes есть мощный механизм под названием API Aggregation Layer.
Он помогает добавлять кастомные API в кластер.
Это означает, что вы можете создавать собственные типы ресурсов и заставлять Kubernetes делать больше, чем он умеет из коробки.
Классический пример использования Aggregation Layer в Kubernetes - это реализация Metrics Server.
Metrics Server реализует Metrics API как дополнительный API-сервер, используя Aggregation Layer.
Это означает, что хоть Metrics Server и является отдельным сервисом, к его API можно обращаться так, как будто он - нативная часть Kubernetes API.
В целом, поток запросов выглядит так:
- Когда вы запускаете
- Когда вы запускаете
Prometheus Adapter также использует этот механизм, чтобы отдавать кастомные метрики по адресу
👉 DevOps Portal
В Kubernetes есть мощный механизм под названием API Aggregation Layer.
Он помогает добавлять кастомные API в кластер.
Это означает, что вы можете создавать собственные типы ресурсов и заставлять Kubernetes делать больше, чем он умеет из коробки.
Классический пример использования Aggregation Layer в Kubernetes - это реализация Metrics Server.
Metrics Server реализует Metrics API как дополнительный API-сервер, используя Aggregation Layer.
Это означает, что хоть Metrics Server и является отдельным сервисом, к его API можно обращаться так, как будто он - нативная часть Kubernetes API.
В целом, поток запросов выглядит так:
- Когда вы запускаете
kubectl get pods, запрос уходит на /api/v1/pods и маршрутизируется в Core API Server.- Когда вы запускаете
kubectl top pods, запрос уходит на /apis/metrics.k8s.io/v1beta1/ и маршрутизируется в Metrics Server.Prometheus Adapter также использует этот механизм, чтобы отдавать кастомные метрики по адресу
/apis/custom.metrics.k8s.io/Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Свежий сбой в AWS (US-EAST-1)
Самое время пересмотреть стратегии аварийного восстановления в облаке (объяснённые простым языком)
Любая стратегия Disaster Recovery начинается с определения:
🔹 RTO (Recovery Time Objective) —
сколько простоя вы можете себе позволить?
🔹 RPO (Recovery Point Objective) —
какую потерю данных вы готовы терпеть?
Стратегии Disaster Recovery:
1. Backup and Restore → регулярные бэкапы и восстановление после инцидента
RTO: от нескольких часов до нескольких дней, RPO: момент последнего бэкапа
2. Pilot Light → ядро системы находится в standby и разворачивается при необходимости
RTO: от минут до часов, RPO: зависит от частоты репликации
3. Warm Standby → укороченная «живая» копия среды, которую можно быстро расшscaleить
RTO: минуты, RPO: от нескольких минут до часов
4. Hot / Multi-Site → оба сайта работают активно с мгновенным фейловером
RTO: близок к нулю, RPO: секунды
👉 DevOps Portal
Самое время пересмотреть стратегии аварийного восстановления в облаке (объяснённые простым языком)
Любая стратегия Disaster Recovery начинается с определения:
сколько простоя вы можете себе позволить?
какую потерю данных вы готовы терпеть?
Стратегии Disaster Recovery:
1. Backup and Restore → регулярные бэкапы и восстановление после инцидента
RTO: от нескольких часов до нескольких дней, RPO: момент последнего бэкапа
2. Pilot Light → ядро системы находится в standby и разворачивается при необходимости
RTO: от минут до часов, RPO: зависит от частоты репликации
3. Warm Standby → укороченная «живая» копия среды, которую можно быстро расшscaleить
RTO: минуты, RPO: от нескольких минут до часов
4. Hot / Multi-Site → оба сайта работают активно с мгновенным фейловером
RTO: близок к нулю, RPO: секунды
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍4
Уменьшили размер Docker-образа с 588 MB до 47,7 MB
Исходная сборка:
🔹 Полноценный базовый образ Python 3.9
🔹 Множество инструкций RUN, создающих лишние слои
🔹 Отсутствие .dockerignore
🔹 Одностадийная сборка со всеми зависимостями
Применённые оптимизации:
1. Более лёгкий базовый образ
- Перешли на Python 3.9-alpine
- Образ стал легче на ~95% и быстрее скачивается
2. Оптимизация слоёв
- Объединили связанные команды
- Убрали избыточные инструкции RUN
3.
- Исключили venv, кэши и временные файлы
- Сократили контекст сборки
4. Multi-stage build
- Отдельный stage для сборки зависимостей
- Production-stage с минимальным runtime-набором
Результат:
🔹 Размер образа: 47,7 MB (с 588 MB)
🔹 Снижение размера: −91,89%
🔹 Более быстрый старт контейнера
🔹 Меньше времени деплоя и меньше места в registry
Маленькие оптимизации дают большой эффект. Каждый сэкономленный мегабайт ускоряет каждый билд.
👉 DevOps Portal
Исходная сборка:
Применённые оптимизации:
1. Более лёгкий базовый образ
- Перешли на Python 3.9-alpine
- Образ стал легче на ~95% и быстрее скачивается
2. Оптимизация слоёв
- Объединили связанные команды
- Убрали избыточные инструкции RUN
3.
.dockerignore- Исключили venv, кэши и временные файлы
- Сократили контекст сборки
4. Multi-stage build
- Отдельный stage для сборки зависимостей
- Production-stage с минимальным runtime-набором
Результат:
Маленькие оптимизации дают большой эффект. Каждый сэкономленный мегабайт ускоряет каждый билд.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22👍7😁3🌚3
Cовременная, легковесная дашборда для Kubernetes, которая предоставляет метрики в реальном времени, поддержку мультикластерных окружений, редактирование YAML и управление ресурсами через интуитивно понятный UI
GitHub: kite
👉 DevOps Portal
GitHub: kite
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤2
Быстрый совет по Linux
Логи упакованы в
Используй инструменты с префиксом
Эти команды позволяют анализировать сжатые логи без предварительной распаковки, идеально для быстрых сеансов устранения неполадок✌️
👉 DevOps Portal
Логи упакованы в
.gz? Их не нужно распаковывать, чтобы читать или искать по содержимому.Используй инструменты с префиксом
z прямо по месту:zcat — просмотреть файлzless — пролистывать содержимоеzgrep — искать внутри файлаzegrep — искать с расширенными регулярками (ERE)zfgrep — искать по фиксированным строкамzcmp/zdiff — сравнивать файлыЭти команды позволяют анализировать сжатые логи без предварительной распаковки, идеально для быстрых сеансов устранения неполадок
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25❤4
This media is not supported in your browser
VIEW IN TELEGRAM
В чём разница между этими двумя DNS-запросами?
На вид они похожи, но на самом деле показывают совершенно разные вещи.
В первом случае:
—
Ты обращаешься к своему дефолтному DNS-резолверу (роутер или DNS от провайдера).
✅ Рекурсивный lookup — он пройдёт по всей цепочке CNAME до финального IP.
❌ Non-authoritative — ответ может быть из кэша и потенциально устаревшим.
Во втором случае:
—
Ты напрямую спрашиваешь авторитативный DNS-сервер.
✅ Ответ приходит прямо из первоисточника.
❌ Он покажет только то, что знает сам сервер — lookup остановится на первом CNAME.
И что же лучше? Зависит от задачи.
- Используй дефолтный резолвер, если тебе просто нужен конечный IP как можно быстрее.
- Обращайся к авторитативному серверу, если нужно проверить, кто чем реально управляет.
👉 DevOps Portal
На вид они похожи, но на самом деле показывают совершенно разные вещи.
В первом случае:
—
nslookup http://academy.networkchuck.comТы обращаешься к своему дефолтному DNS-резолверу (роутер или DNS от провайдера).
Во втором случае:
—
nslookup http://academy.networkchuck.com http://ns.cloudflare.comТы напрямую спрашиваешь авторитативный DNS-сервер.
И что же лучше? Зависит от задачи.
- Используй дефолтный резолвер, если тебе просто нужен конечный IP как можно быстрее.
- Обращайся к авторитативному серверу, если нужно проверить, кто чем реально управляет.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤6🔥5
Основы сетей - Проброс портов
Древний трюк, который может помочь сделать сервис доступным на другом порту без рестарта, либо подключиться к базе данных внутри приватного VPC.
Практика:
🔸 socat: https://labs.iximiuz.com/challenges/port-forwarding-using-socat
🔸 netcat: https://labs.iximiuz.com/challenges/port-forwarding-using-netcat
🔸 без прокси: https://labs.iximiuz.com/challenges/port-forwarding-without-proxy
👉 DevOps Portal
Древний трюк, который может помочь сделать сервис доступным на другом порту без рестарта, либо подключиться к базе данных внутри приватного VPC.
Практика:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤4🔥4
Как HTTP(S)-порты пробрасываются из VM, у которых есть только приватные IP-адреса
- У каждого bare-metal хоста есть только один публичный IP-адрес
- DNS-запись
- Каждый раз, когда наружу пробрасывается порт VM, генерируется новый случайный поддомен
- Этот рандомный поддомен не существует за пределами конкретного хоста, он известен только соответствующему bare-metal серверу
- Все запросы к этому поддомену приходят на единственный публичный IP хоста, где слушает ingress-прокси (Envoy)
-Интерфейс VM виден только внутри её «обёртки» — Docker-контейнера (для дополнительной изоляции), поэтому Envoy не может достучаться до VM напрямую
- Вместо этого Envoy прокидывает запросы к поддомену в локальный UNIX-сокет, смонтированный в контейнер-обёртку VM
- Этот UNIX-сокет открыт специальным процессом-forwarder’ом (крошечный Go-сервис), который работает внутри контейнера-обёртки
- Forwarder делает
Профит! Десятки полностью изолированных VM на одном bare-metal хосте, и у каждой свой публичный URL
👉 DevOps Portal
- У каждого bare-metal хоста есть только один публичный IP-адрес
- DNS-запись
*.node-xyz.iximiuz.com и wildcard-сертификат Let’s Encrypt указывают на этот IP- Каждый раз, когда наружу пробрасывается порт VM, генерируется новый случайный поддомен
- Этот рандомный поддомен не существует за пределами конкретного хоста, он известен только соответствующему bare-metal серверу
- Все запросы к этому поддомену приходят на единственный публичный IP хоста, где слушает ingress-прокси (Envoy)
-Интерфейс VM виден только внутри её «обёртки» — Docker-контейнера (для дополнительной изоляции), поэтому Envoy не может достучаться до VM напрямую
- Вместо этого Envoy прокидывает запросы к поддомену в локальный UNIX-сокет, смонтированный в контейнер-обёртку VM
- Этот UNIX-сокет открыт специальным процессом-forwarder’ом (крошечный Go-сервис), который работает внутри контейнера-обёртки
- Forwarder делает
io.Copy(UNIX socket, VM's private IP:port)Профит! Десятки полностью изолированных VM на одном bare-metal хосте, и у каждой свой публичный URL
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍4
Если вы хотите избавиться от сотен уязвимостей (CVE) в своих контейнерных образах, первым шагом будет понять, откуда они берутся
Типичные источники:
- «Толстый» базовый образ
- Забытые инструменты сборки
- Устаревшие зависимости
Простое решение? Многоэтапная сборка с более свежим и лёгким базовым образом.
Пример анализа базового образа: Более глубокий взгляд на Docker-образы Node.js: «Помогите, в моём Node-образе есть Python!»
👉 DevOps Portal
Типичные источники:
- «Толстый» базовый образ
- Забытые инструменты сборки
- Устаревшие зависимости
Простое решение? Многоэтапная сборка с более свежим и лёгким базовым образом.
Пример анализа базового образа: Более глубокий взгляд на Docker-образы Node.js: «Помогите, в моём Node-образе есть Python!»
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Найдите недавно изменённые файлы за последние 5 минут:
find . -type f -mmin -5
Полезно, когда вы устраняете неполадки и хотите знать, какие файлы были недавно изменены
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤7
Совет по Docker
Вот как проанализировать, что раздувает образ
Как вы знаете, любой Docker-образ состоит из слоёв.
Каждый слой добавляется отдельной строкой в вашем Dockerfile.
И по этим слоям можно понять, почему образ получился большим, медленно собирается или плохо кэшируется.
Вот как можно инспектировать слои и увидеть, что изменилось в каждом слое.
Можно использовать утилиту dive.
Она даёт визуальное представление:
✅ Каждый созданный слой
✅ Какие файлы были добавлены или изменены
✅ Сколько места занимает каждый слой
Когда вы начинаете анализировать слои образа, вы сможете выявить:
- Какая команда добавляет лишний вес
- Как оптимизировать Dockerfile для более маленьких и эффективных сборок
Утилита также показывает оценку эффективности образа, которая отражает, сколько данных дублируется или тратится впустую между слоями
👉 DevOps Portal
Вот как проанализировать, что раздувает образ
Как вы знаете, любой Docker-образ состоит из слоёв.
Каждый слой добавляется отдельной строкой в вашем Dockerfile.
И по этим слоям можно понять, почему образ получился большим, медленно собирается или плохо кэшируется.
Вот как можно инспектировать слои и увидеть, что изменилось в каждом слое.
Можно использовать утилиту dive.
Она даёт визуальное представление:
Когда вы начинаете анализировать слои образа, вы сможете выявить:
- Какая команда добавляет лишний вес
- Как оптимизировать Dockerfile для более маленьких и эффективных сборок
Утилита также показывает оценку эффективности образа, которая отражает, сколько данных дублируется или тратится впустую между слоями
Please open Telegram to view this post
VIEW IN TELEGRAM
👍20❤9
Многие не до конца понимают, чем отличаются конвейеры CI/CD в DevOps и GitOps
В DevOps-конвейере CI/CD весь процесс выполняется единым потоком - от коммита кода, тестов, сборки, создания образа до прямого деплоя в кластер Kubernetes.
Такой подход быстрый и централизованный, но жёстко связывает деплой с процессом CI, оставляя мало возможностей для разделения или дополнительного контроля.
В GitOps-конвейере CI отвечает за тесты и сборку, а деплой выполняется через Git-коммиты: контроллер синхронизирует изменения из репозитория с кластером.
Вот инфографика, чтобы помочь вам лучше разобраться👍
👉 DevOps Portal
В DevOps-конвейере CI/CD весь процесс выполняется единым потоком - от коммита кода, тестов, сборки, создания образа до прямого деплоя в кластер Kubernetes.
Такой подход быстрый и централизованный, но жёстко связывает деплой с процессом CI, оставляя мало возможностей для разделения или дополнительного контроля.
В GitOps-конвейере CI отвечает за тесты и сборку, а деплой выполняется через Git-коммиты: контроллер синхронизирует изменения из репозитория с кластером.
Вот инфографика, чтобы помочь вам лучше разобраться
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤7🔥2
Вот интересный факт о Linux
Вы можете запустить полноценное отдельное ядро Linux внутри одного процесса на своей машине. Без root-доступа и без какого-либо ПО для виртуализации.
Это User-Mode Linux (UML) - специальный порт ядра, который работает как обычное пользовательское приложение.
Вместо взаимодействия с аппаратным обеспечением оно общается с вашей хостовой ОС. Файл используется как жёсткий диск, а ваш терминал становится его консолью. Вы можете загрузить систему, войти в неё и запускать программы, как в виртуальной машине, но всего одной командой.
Это мощный инструмент для разработки и отладки ядра, а также для создания изолированных тестовых окружений за считанные секунды.
Хотите разобраться глубже? Ознакомьтесь с полной статьей: тык
👉 DevOps Portal
Вы можете запустить полноценное отдельное ядро Linux внутри одного процесса на своей машине. Без root-доступа и без какого-либо ПО для виртуализации.
Это User-Mode Linux (UML) - специальный порт ядра, который работает как обычное пользовательское приложение.
Вместо взаимодействия с аппаратным обеспечением оно общается с вашей хостовой ОС. Файл используется как жёсткий диск, а ваш терминал становится его консолью. Вы можете загрузить систему, войти в неё и запускать программы, как в виртуальной машине, но всего одной командой.
Это мощный инструмент для разработки и отладки ядра, а также для создания изолированных тестовых окружений за считанные секунды.
Хотите разобраться глубже? Ознакомьтесь с полной статьей: тык
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤4
Actions Runner Controller (ARC) — это контроллер Kubernetes для self-hosted раннеров GitHub Actions.
С помощью ARC вы можете:
🔹 Развертывать self-hosted раннеры в кластерах Kubernetes простым набором команд
🔹 Автоматически масштабировать раннеры по требованию
GitHub: actions-runner-controller
👉 DevOps Portal
С помощью ARC вы можете:
GitHub: actions-runner-controller
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍5
Forwarded from Мир Linux
Принёс швейцарский нож для сетевиков: Networking Toolbox
Это офлайн-набор из 100+ сетевых инструментов в одном приложении. Конвертация данных, диагностика серверов, сетевые вычисления, проверка конфигов, всё под рукой и без интернета
Никаких сторонних зависимостей и опенсорс. Забираем здесь
@linuxos_tg
Это офлайн-набор из 100+ сетевых инструментов в одном приложении. Конвертация данных, диагностика серверов, сетевые вычисления, проверка конфигов, всё под рукой и без интернета
Никаких сторонних зависимостей и опенсорс. Забираем здесь
@linuxos_tg
❤9