TGViewer
Channel Public Channel
CORTEL

CORTEL

@cortel_cloud

Помогаем ИТ-директорам, DevOps и системным инженерам снижать TCO и поднимать SLA. Кейсы, инструменты и гайды.

Сайт:
https://cortel.cloud

Cотрудничество:
@ivan_cmo
Subscribers
4.07K
Photos
2K
Videos
165
Links
1.7K

Showing posts older than #2786 · Back to latest

Older Posts 20 shown
Post #2785 1.35K
🖥 AWK — мощный язык обработки текста, заточенный под построчный разбор данных по колонкам.

Назван по фамилиям создателей (Aho, Weinberger, Kernighan). Незаменим там, где нужно вытащить, отфильтровать или пересчитать данные из таблиц, логов и вывода других утилит.

В отличие от grep (ищет строки) и sed (правит текст потоком), AWK мыслит записями и полями. Каждая строка — это запись, разбитая на колонки. Это превращает обработку структурированного вывода (ps, df, /etc/passwd, CSV, логи) в простые однострочники.

Программа на AWK — это набор правил вида:


awk 'паттерн { действие }' файл


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

➡️ Ключевые встроенные переменные:

$0 — вся строка целиком
$1, $2, ... — поля (колонки) по порядку
NF — количество полей в строке (Number of Fields)
NR — номер текущей строки (Number of Records)
FS — разделитель полей на входе (по умолчанию — пробелы/табы)
OFS — разделитель полей на выходе

➡️ Основные параметры

-F — задать разделитель полей (-F: для /etc/passwd, -F, для CSV)
-v — передать переменную внутрь программы (-v threshold=80)
-f — взять программу из файла, а не из строки

🔵Блоки BEGIN и END

BEGIN выполняется до чтения файла, END — после. Удобно для заголовков и итогов.

✅ Примеры

Вывести только нужные колонки (имя пользователя и shell из passwd):


awk -F: '{print $1, $7}' /etc/passwd

root /bin/bash
daemon /usr/sbin/nologin


Найти процессы, потребляющие больше 50% CPU:


ps aux | awk '$3 > 50 {print $2, $11}'


Отфильтровать строки лога по коду ответа nginx и посчитать количество 5xx:


awk '$9 ~ /^5/ {count++} END{print "5xx errors:", count}' access.log


AWK — это полноценный мини-язык.
Для разовых однострочников он экономит десятки строк на grep | cut | sort, а в скриптах закрывает всю обработку табличных данных без выхода в Python.

#линуксятина
  • ❤ 8
  • 👍 5
  • 🔥 2
Post #2783 1.4K
💸 Как ДИТу говорить с бизнесом на языке денег

TCO, RTO, RPO, SLA, MTTR сами по себе ничего не объясняют.

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

😎 Смотрите в выпуске по ссылке на любой удобной платформе
▶️ Rutube
▶️ YouTube
▶️ VK Видео
  • 👍 3
  • ❤ 2
  • 🔥 2
Post #2782 1.21K
💻 StatefulSet vs Deployment vs DaemonSet: три способа управлять подами

В Kubernetes важно не просто запустить под, а выбрать правильный контроллер.
Не тот контроллер может привести к потерянным данным, лишним подам на нодах или странному поведению БД.

💬 Deployment — для stateless-нагрузок

Управляет ReplicaSet'ом, который поддерживает заданное число одинаковых, взаимозаменяемых подов.
— Поды получают случайные имена (app-7d4b9c8f6-x2k9p)
— При обновлении старые поды удаляются, новые создаются с нуля — история не важна
— Поддерживает RollingUpdate и Recreate — стратегии обновления
— Любой под может заменить любой другой без последствий

Подходит для: API, фронтенд, воркеры без сохраняемого состояния.

💬 StatefulSet — для нагрузок с сохранением состояния

Гарантирует стабильную идентичность каждого пода — то, чего Deployment принципиально не даёт.
— Имена подов предсказуемы и постоянны (db-0, db-1, db-2)
— Каждый под получает свой PersistentVolumeClaim, который сохраняется при пересоздании пода
— Поды создаются и удаляются строго по порядку (0 → 1 → 2 и обратно)
— Требует headless Service для сетевой идентичности — DNS-имя вида db-0.db-service.namespace.svc.cluster.local

Подходит для: БД (PostgreSQL, MongoDB), очереди (Kafka), etcd — всё, где важны порядок запуска, стабильный сетевой адрес и привязка к своему тому.

💬 DaemonSet — для нагрузок на каждой ноде

Гарантирует, что копия пода будет запущена на каждой (или на выбранном подмножестве) ноде кластера — не больше и не меньше.
— Число подов = число подходящих нод, а не заданное значение replicas
— При добавлении новой ноды под создаётся автоматически
— При удалении ноды под удаляется вместе с ней
— Игнорирует обычный scheduler в пользу собственной логики размещения, учитывает nodeSelector и taints/tolerations

Подходит для: агенты мониторинга (node-exporter), сборщики логов, CNI-плагины на каждом хосте.

👀 Выбор контроллера

— Если поды одинаковые и могут спокойно заменять друг друга — это Deployment.
— Если каждому поду нужны своё имя, сетевой адрес и отдельное хранилище — это StatefulSet.
— Если под должен запускаться на каждой подходящей ноде — это DaemonSet.

#заметкиИнженера
  • ❤ 5
  • 👍 3
  • 🔥 2
Post #2781 1.2K
🛠 Поддержка инфраструктуры

«Поддержка 24/7» — чтобы понять, что это значит на самом деле, нужно заглянуть в договор.

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

Если этого нет, то круглосуточная поддержка остаётся общей формулировкой, а в момент аварии начинается ручное управление и поиск того, кто должен включаться в работу.

👉 В новом материале разобрали, что должно стоять за поддержкой инфраструктуры 24/7, как отличить зрелую эксплуатацию от формальной техподдержки и какие вопросы задать подрядчику до подписания договора.

#статья
  • 👍 4
  • ❤ 1
  • 🔥 1
Post #2780 1.2K
💻 kube-controller-manager: компонент, который следит за состоянием кластера

В Kubernetes всё построено вокруг одной идеи: пользователь описывает, каким должен быть кластер, а система сама приводит реальность к этому описанию.

За это отвечает kube-controller-manager — компонент control plane, который запускает встроенные контроллеры и непрерывно сверяет желаемое состояние с фактическим.

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

🔢 Контроллер — это бесконечный цикл согласования (reconciliation loop).

Его работа сводится к трём шагам:
— Наблюдение — через watch-механизм API-сервера контроллер получает события об изменении ресурсов.
— Сравнение — сопоставляет желаемое состояние (spec) с текущим (status).
— Действие — если есть расхождение, создаёт, удаляет или изменяет объекты, чтобы устранить разницу.

Цикл повторяется бесконечно. Удалили под вручную — контроллер заметит расхождение и создаст новый.

💬 Внутри kube-controller-manager работают:
— Deployment / ReplicaSet controller — поддерживает заданное число реплик. Именно он разворачивает ReplicaSet из Deployment, а тот создаёт поды.
— Node controller — следит за состоянием узлов. Если нода перестаёт слать heartbeat, помечает её NotReady и инициирует выселение подов.
— Job / CronJob controller — управляет жизненным циклом задач и их запуском по расписанию.
— EndpointSlice controller — связывает Service с подами, обновляя списки эндпоинтов при изменении состава подов.
— ServiceAccount & Token controller — создаёт сервис-аккаунты и связанные с ними секреты в новых namespace.
— Namespace controller — корректно удаляет все ресурсы внутри namespace при его удалении.

➡️ Пример: выполнение масштабирования


kubectl scale deployment nginx --replicas=5


Дальше происходит цепочка:

➡️ kubectl отправляет запрос на kube-apiserver, тот записывает новое значение replicas=5 в etcd.
➡️Через watch событие об изменении Deployment получает kube-controller-manager.
➡️Deployment controller обновляет связанный ReplicaSet.
➡️ReplicaSet controller видит: желаемо 5 подов, фактически 3. Создаёт 2 новых пода через API-сервер.
➡️Новые поды попадают в очередь — их подхватывает kube-scheduler и назначает на ноды.
➡️kubelet на этих нодах запускает контейнеры и докладывает о статусе обратно в API.

Сам controller-manager при этом не запускает контейнеры и не назначает поды на ноды — он лишь приводит число объектов к нужному, а грязную работу делают scheduler и kubelet.

kube-controller-manager — это целый цех автономных регуляторов, каждый из которых отвечает за свой кусочек кластера.
Именно он превращает декларативный манифест в живую, самовосстанавливающуюся систему.

#заметкиИнженера
  • ❤ 3
  • 👍 2
  • 🔥 2
Post #2779 1.17K
⚠️ SLA на инфраструктуру

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

Здесь важно не смешивать доступность сервиса с RTO, RPO, DR, бэкапами и поддержкой всего подряд.

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

Всё остальное — гостевые ОС, доступы, приложения, интеграции и изменения внутри контура — нужно отдельно фиксировать в договоре.

👉 В новом материале разобрали, что на самом деле измеряет SLA, чем отличаются модели сопровождения, почему изменения часто становятся причиной конфликтов и какие вопросы стоит задать подрядчику до аварии.

#статья
  • 👍 3
  • 🔥 3
  • 👏 2
Post #2778 1.2K
🖥 logrotate — утилита для автоматической ротации, сжатия и удаления логов в Linux.

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

logrotate не работает постоянно в фоне.
Его запускает cron (/etc/cron.daily/logrotate) или systemd-таймер (logrotate.timer), обычно раз в сутки.

При запуске утилита читает конфиги, проверяет условия ротации и выполняет действия, если файл подходит под заданные правила.

➡️ Где лежат конфиги?

— /etc/logrotate.conf — основной файл с глобальными настройками.
— /etc/logrotate.d/ — каталог с отдельными конфигами для каждого сервиса (nginx, postgres и т.д.)

➡️ Пример конфига для приложения:

Допустим, нужно ротировать логи своего приложения в /var/log/myapp/.
Создаётся файл /etc/logrotate.d/myapp:


daily
rotate 14
size 100M
compress
delaycompress
missingok
notifempty
create 0640 myapp myapp
sharedscripts
postrotate
systemctl reload myapp >/dev/null 2>&1 || true
endscript
}


➡️Что задано:

— daily — проверять ротацию каждый день.
— rotate 14 — хранить 14 архивных копий.
— maxsize 100M — ротировать файл при проверке, если он превысил 100 МБ.
— compress — сжимать старые логи.
— delaycompress — сжимать файл на следующем цикле ротации.
— missingok — продолжать работу, если лог-файл отсутствует.
— notifempty — не ротировать пустой файл.
— create 0640 myapp myapp — создать новый лог-файл с нужными правами и владельцем.
— sharedscripts — выполнить postrotate один раз для всей группы файлов.
— postrotate ... endscript — выполнить команду после ротации.

➡️ Полезные команды

➡️ Проверить конфиг без изменений (dry-run):


logrotate -d /etc/logrotate.d/myapp


➡️ Принудительно запустить ротацию, игнорируя расписание:


logrotate -f /etc/logrotate.conf


➡️ Подробный вывод того, что происходит:


logrotate -v /etc/logrotate.conf


👀 Обычно logrotate уже настроен при установке сервисов. Но его правила стоит проверять: от них зависит, как долго хранятся логи, когда они сжимаются и сколько места занимают на диске.

#линуксятина
  • ❤ 7
  • 👍 4
  • 🔥 2
Post #2777 1.19K
💪 Анатомия высоких нагрузок:
как строится отказоустойчивая инфраструктура


🔍 Обычно всё начинается с симптомов: сервисы проседают в пиковые часы, восстановление после сбоя занимает непредсказуемое время, новый продукт сложно запустить, а текущий контур уже не выдерживает рост.

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

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

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

👉 В новом материале разобрали, как строится инфраструктура под высокие нагрузки: от первого запроса и инженерного разбора до проектирования, тестирования, запуска и передачи в эксплуатацию.

#статья
  • 👍 3
  • 🔥 3
  • ❤ 2
Post #2776 1.16K
💻 Probes в Kubernetes:
как кластер понимает, что под работает и готов принимать запросы

Kubernetes не может оценить состояние приложения без специальных проверок. Процесс может быть запущен, но при этом висеть в дедлоке или ещё не успеть прогрузить кеш.

Для этого и существуют probes — проверки, по результатам которых kubelet принимает решения о перезапуске и направлении трафика.

➡️ Виды probe

— livenessProbe — контролирует работоспособность контейнера. При провале kubelet перезапускает контейнер. Применяется, когда приложение может «зависнуть» без падения процесса.
— readinessProbe — проверяет, готов ли контейнер принимать трафик. При провале под убирается из конечных точек сервиса, но не перезапускается. Используется для прогрева, ожидания зависимостей (БД, кеш).
— startupProbe — проверяет, успело ли приложение стартовать. Пока она не пройдена, liveness и readiness заморожены. Нужна для медленно стартующих приложений, чтобы их не убивало раньше времени.

➡️ Как работают?

Каждая probe выполняется одним из трёх способов:

— httpGet — HTTP-запрос на путь и порт, успех при коде 200–399
— tcpSocket — проверка, что порт открыт
— exec — выполнение команды внутри контейнера, успех при коде возврата 0


containers:
- name: app
image: my-app
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 0
periodSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
failureThreshold: 2


🔧 Основные параметры

— initialDelaySeconds — задержка перед первой проверкой
— periodSeconds — как часто выполнять проверку
— timeoutSeconds — таймаут одной проверки
— successThreshold — сколько успехов подряд считать восстановлением (для liveness/startup всегда 1)
— failureThreshold — сколько провалов подряд считать отказом

Пример со startupProbe выше даёт приложению до 30 × 10 = 300 секунд на запуск, после чего управление переходит к liveness.

Probes — это не формальность в манифесте, а контракт между приложением и кластером. Liveness помогает kubelet принять решение о перезапуске контейнера, readiness показывает, можно ли направлять на pod трафик, startup даёт приложению время на корректный запуск. Разделение этих ролей напрямую влияет на стабильность сервиса при деплоях и сбоях.

#заметкиИнженера
  • ❤ 5
  • 👍 3
  • 🔥 3
Post #2775 1.09K

Forwarded from DevOps FM

Приглашаем инженеров на DevOps Lab: ML in Production!

Не планируйте ничего на 26 июня! Открыли регистрацию на закрытую встречу в Новосибирске, где DevOps-инженеры и технические руководители разберут, как выстроить безопасную инфраструктуру для ML-сервисов на практике.

🟡Что вас ждет?
• инфраструктура инференса
• безопасность ML-пайплайнов
• наблюдаемость моделей в производственной среде
• Кофе-брейк и возможность задать неудобные вопросы напрямую

На DevOps Lab мы соберёмся небольшим кругом, чтобы послушать три практических доклада, обсудить кейсы и немного подебажить с коллегами из индустрии. Регистрируйтесь, количество билетов ограничено :)

📌 26 июня, 18:00 | г. Новосибирск, офис Никсис
📌 Регистрация: по ссылке

#девопс #никсис #митап
  • 👍 3
  • 🔥 2
  • 👏 2
  • ❤ 1
Post #2774 1.02K
📝 Шпаргалка по проектированию безопасных систем.

Помогает быстро проверить, какие направления защиты нужно учесть при проектировании ИТ-системы: доступы, данные, сеть, API, контейнеры, подрядчики, реагирование на инциденты и восстановление.

🔐 Основные направления защиты

— Authentication
Проверка того, кто входит в систему. Сюда относятся парольная политика, MFA, доступ сотрудников к внутренним сервисам и защита учётных записей.

— Authorization
Управление правами после входа. Роли, уровни доступа, принцип минимальных привилегий и регулярный пересмотр выданных прав.

— Encryption
Защита данных при передаче и хранении. TLS, шифрование чувствительной информации, управление ключами и контроль доступа к ним.

— Vulnerability Management
Работа с уязвимостями. Патчи, регулярное сканирование, мониторинг и проверка критичных обновлений.

— Audit & Compliance
Журналы, проверки и соответствие требованиям. Для российской инфраструктуры сюда можно отнести 152-ФЗ, 187-ФЗ, требования ФСТЭК/ФСБ и внутренние регламенты компании.

— Network Security
Защита сети. Межсетевые экраны, сегментация, IDS/IPS, защищённый DNS и контроль сетевых потоков между системами.

— Endpoint Security
Защита рабочих станций, ноутбуков и других конечных устройств. Антивирус, EDR, управление устройствами и шифрование дисков.

— Incident Response
Реагирование на инциденты. План действий при атаке, утечке, DDoS или компрометации учётной записи, а также регулярные тренировки команды.

— Container Security — безопасность самих контейнеров: доверенные реестры и образы, сканирование на уязвимости, минимальная база, запуск без root, контроль runtime.

— Kubernetes Security — безопасность кластера: RBAC, network policies, Pod Security Standards, защита control plane и etcd, управление секретами.

— API Security
Защита публичных и внутренних API. OAuth 2.0, API-ключи, rate limiting, валидация входных данных и контроль подозрительной активности.

— Third-Party Management
Работа с подрядчиками и внешними сервисами. Оценка поставщиков, безопасный обмен данными, контроль интеграций и внешних доступов.

— Disaster Recovery
Восстановление после сбоя или атаки. DR-план, резервное копирование, резервирование систем и регулярная проверка восстановления.

Такая карта хорошо показывает, что безопасность системы начинается ещё на этапе архитектуры. Чем раньше эти направления учтены в проектировании, тем меньше хаоса будет при эксплуатации, проверках и реальных инцидентах.

#полезное
  • ❤ 5
  • 🔥 3
  • 👍 2
Post #2773 980
💰 Экономия на архитектуре, которая увеличивает TCO

Самые дорогие ошибки в инфраструктуре часто выглядят как разумная экономия на старте.

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

А последствия появляются позже:
— Сетевую схему приходится менять уже после запуска.
— СХД не выдерживает реальный профиль нагрузки: растут задержки, проседают сервисы.
— Проблемы с инфраструктурой становятся заметны по жалобам пользователей.
— Бэкапы есть, но восстановление не проверялось — в момент инцидента это превращается в отдельный риск.

Так экономия превращается в рост TCO.
Потому что в стоимость инфраструктуры входят эксплуатация, риски, восстановление, масштабирование и цена будущих переделок.

👉 В новом материале разобрали, где компании чаще всего экономят при построении ИТ-инфраструктуры, как эти решения возвращаются дополнительными расходами и почему иногда «дешевле на старте» означает дороже в три раза.

#статья
  • 🔥 4
  • 👍 2
  • ❤ 1
  • 👏 1
Post #2772 1.26K
📖 Как освоить современный Linux

Полный справочник по современной Linux-среде: от базовых принципов работы ОС до ядра, оболочек, файловых систем, сетевого взаимодействия, контейнеров и систем мониторинга.

🔍 Рассматривается:

— что такое современный Linux и где он используется;
— архитектура Linux и устройство ядра;
— процессы, память, системные вызовы и модули ядра;
— работа с терминалом, оболочками и скриптами;
— управление пользователями, правами и доступом;
— файловые системы и виртуальная файловая система;
— приложения, systemd и управление пакетами;
— контейнеры и современные менеджеры пакетов;
— основы сетевого взаимодействия, TCP/IP и DNS;
— журналирование, мониторинг и наблюдаемость;
— виртуальные машины и межпроцессное взаимодействие;
— современные дистрибутивы Linux и перспективные возможности системы.

Автор:
Майкл Хаузенблас

Издательство:
O’Reilly / русское издание, 2026 г.

#книги #полезное
  • 🔥 7
  • 👍 3
  • 👏 2
  • 👎 1
Post #2771 1K
🖥 systemd-resolved — компонент systemd, который отвечает за разрешение сетевых имён. По сути — это небольшой кеширующий DNS-сервер, который крутится прямо на вашей машине и работает посредником между приложениями и реальными DNS-серверами.

📍 Зачем он нужен?

Раньше DNS-серверы прописывались в один файл /etc/resolv.conf, и за него дрались все подряд: DHCP, VPN, NetworkManager. Кто последний записал — тот и победил, а остальные настройки терялись. systemd-resolved решает это и даёт сверху:

— Раздельный DNS под каждый интерфейс (per-link) — VPN, Wi-Fi и Ethernet больше не затирают настройки друг друга.
— Кеширование — повторные запросы не уходят в сеть, резолвинг быстрее.
— Современные протоколы — DNSSEC, DNS-over-TLS (DoT), а также LLMNR и mDNS для имён в локальной сети.

📍 Как работает?

Поднимает локальный DNS-сервер на адресе 127.0.0.53:53 — это так называемый stub-резолвер (заглушка). /etc/resolv.conf превращается в симлинк на /run/systemd/resolve/stub-resolv.conf, где прописан единственный nameserver те самые 127.0.0.53.

Все приложения отправляют запросы на этот локальный адрес. Дальше resolved сам решает, на какой реальный upstream-сервер переслать запрос в зависимости от интерфейса, домена и настроек.

📍 Основные команды

Главная утилита — resolvectl

Полный статус с DNS-серверами по каждому интерфейсу:


resolvectl status

Global
Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth1)
Current Scopes: DNS
Protocols: +DefaultRoute +DNSSEC
Current DNS Server: 77.88.8.8
DNS Servers: 77.88.8.8 77.88.8.1


Резолвинг имени через resolved:


resolvectl query cortel.cloud

cortel.cloud: 95.181.181.7 -- link: eht1
-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no


Сброс DNS-кеша:


resolvectl flush-caches


systemd-resolved — это локальный кеширующий резолвер, который наводит порядок в DNS: разводит серверы по интерфейсам, кеширует ответы и поддерживает современные протоколы вроде DoT и DNSSEC. На большинстве свежих Ubuntu/Debian он включён по умолчанию.

#линуксятина
  • 👍 12
  • 🔥 4
  • ❤ 2
  • 👏 1
Post #2770 966
💻 etcd — распределённое хранилище данных Kubernetes.

В нём хранится состояние кластера: поды, деплойменты, секреты, конфигурации, ноды, правила доступа и другие объекты.

По этим данным управляющий контур понимает, что сейчас есть в кластере и какое состояние нужно поддерживать.

➡️ Особенности

С etcd напрямую работает API-сервер Kubernetes.
Остальные компоненты получают данные уже через него.

Так Kubernetes централизованно проверяет запросы, права доступа и изменения в состоянии кластера.

Данные в etcd хранятся с версиями.
Когда объект меняется, Kubernetes видит это изменение и реагирует: создаёт под, обновляет конфигурацию, приводит сервис к нужному состоянию.

➡️ Как работает

Обычно etcd работает как кластер из нескольких узлов.

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

Изменения в etcd фиксируются только после подтверждения большинством узлов. Поэтому в production чаще используют 3 или 5 узлов: так проще сохранить кворум при отказе и продолжить работу управляющего контура.

Потеря etcd без актуального бэкапа может привести к потере управляемого состояния Kubernetes-кластера.

Сами ноды при этом могут быть живы, но Kubernetes уже не сможет нормально управлять объектами, конфигурациями и доступами.

Поэтому снимок состояния etcd — обязательная часть эксплуатации.

➡️ Снять снимок можно командой:


etcdctl snapshot save /backup/etcd-$(date +%F).db


➡️ Проверить состояние узлов:


etcdctl endpoint status --cluster -w table


etcd хранит состояние Kubernetes-кластера. Поэтому бэкап должен быть не просто настроен, а проверен: снимок нужно уметь восстановить до того, как это потребуется в аварийной ситуации.

#заметкиИнженера
  • ❤ 5
  • 🔥 4
  • 👍 2
Post #2769 1.18K
🧩 Импортозамещение виртуализации без переделок

Переход на отечественные решения начинается раньше, чем миграция виртуальных машин.

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

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

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

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

#статья
  • 🔥 5
  • ❤ 2
  • 👍 2
Post #2768 1.17K
⚙️ Xargs — классическая Unix-утилита, которая берёт данные со стандартного ввода и подставляет их как аргументы другой команде.

Звучит просто, но именно она помогает превращать пайплайны в мощные однострочники для массовых операций.

Многие команды (rm, cp, mv, kill) не читают список целей из stdin напрямую. Они ждут аргументы. xargs решает эту задачу: принимает поток данных, разбивает его на элементы и передаёт следующей команде уже в нужном формате.

Базовый принцип

Без xargs:


echo "file1.txt file2.txt" | rm
# Не работает — rm не читает stdin


С xargs:


echo "file1.txt file2.txt" | xargs rm
# Превратится в: rm file1.txt file2.txt


Основные флаги


-n N — количество аргументов на одну команду.
-I {} — заменитель (placeholder), используется когда нужно вставить значение в середину команды, а не в конец.
-P N — параллельное выполнение в N процессов.
-0 — разделитель — нулевой байт.
-t — показать команду перед выполнением (verbose).
-p — спросить подтверждение для каждой команды.

Боевые примеры

Убить все процессы по имени


pgrep -f "old_script" | xargs kill -9


Удалить пустые файлы


find . -type f -empty -print0 | xargs -0 rm


Архивация найденных файлов:


find . -name "*.log" -mtime +30 -print0 | xargs -0 tar czf old_logs.tar.gz


Изменить права на всех скриптах:


find . -name "*.sh" -print0 | xargs -0 chmod +x


xargs нужен там, где поток данных нужно превратить в аргументы команды. За счёт этого обычные Unix-команды начинают работать с большими списками файлов, процессов и других объектов.

#линуксятина
  • ❤ 6
  • 👍 5
  • 🔥 2
Post #2767
CORTEL pinned «🔈 VPS от enterprise команды Выкатили новый сервис для аренды VPS/VDS — Serverum Пилили сначала для себя, теперь решили показать «своим» Да, у нас есть своя разработка и да, мы будем об этом иногда рассказывать 🙂 Сделали по-человечески: заходим, выбираем…»
Post #2765 1.48K
🔈 VPS от enterprise команды

Выкатили новый сервис для аренды VPS/VDS — Serverum

Пилили сначала для себя, теперь решили показать «своим»

Да, у нас есть своя разработка и да, мы будем об этом иногда рассказывать 🙂

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

Что внутри:
— собственная проприетарная платформа
— простые платежи
— очень низкие цены
— адекватная живая поддержка

Сейчас запускаем первых пользователей и собираем честный фидбек.

Если нужна VPS под сайт, бота, dev-среду, тестовый стенд или пет-проект — заходите, берите, гоняйте, будем рады.

Фидбек можно писать в личку: @ivan_cmo

Самому внимательному и вовлечённому — «та самая» толстовка в подарок 💎
👉 Serverum.ru
  • 👏 6
  • 🔥 5
  • 👍 2
Post #2764 1.3K
УЖЕ ЗАВТРА!

Друзья, это не учебная тревога‼️
Менее чем через 24 часа мы встретимся в прямом эфире с Вероникой Нечаевой, чтобы от и до разобрать модель угроз.

Расставим все точки и ответим на самые популярные вопросы.

⁉️ Это будет просто вебинар?
Нет, это практический мастер-класс в двух частях. Более 10 часов контента, возможность задать Веронике вопрос во время эфиров и после.

⁉️ Будет ли что-то помимо эфира?
Да, мы вышлем всем участникам шаблон модели угроз, чтобы вы в прямом эфире вместе с Вероникой могли подготовить МУ. Также будем на связи и после МК и ответим на все вопросы.

⁉️ Как попасть?
Чтобы быть завтра в прямом эфире, нужно зарегистрироваться по ссылке. Участие платное.

⁉️ Если я новичок в теме ПДн, мне подойдёт?
Нет. Если вы не знаете, что такое уровень защищённости ИСПДн, как выглядит схема ИС и пугаетесь при аббревиатуре СЗИ - мастер-класс вам не подойдёт. Он рассчитан на продвинутый уровень, на тех, кто знает, что такое модель угроз, техническое задание и проект и уже готовил документацию по ПДн.

⁉️ Когда повтор?
Повторов не планируем.

Если вы оттягивали до последнего - вот он, ваш выход. Просто поверьте, после этого МК вы будете знать о модели угроз всё и даже больше.

👉 ЗАРЕГИСТРИРОВАТЬСЯ 👈
  • 🔥 4
  • 👍 2
  • 😁 2
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →