Хочешь ворваться в DevOps и наконец понять, как работают Kubernetes, Docker и CI/CD?
Ребята из Merion Academy (того самого Youtube-канала про IT), создали курс, который помогает не просто смотреть уроки, а реально учиться:
✔️ Грамотно подобранная программа курса.
✔️ Много практики.
✔️ Помогают разобраться с затыками.
✔️ Отдельно помогут с карьерой: как составить резюме, пройти собеседования и найти работу.
Что интересного в программе:
1. Построение CI/CD пайплайнов в GitLabCI и Jenkins
2. Настройка мониторинга с Zabbix, Prometheus и Grafana
3. Понимание DevSecOps, ZTNA, SASE, Defense in Depth
4. Работа с Docker, включая Docker Compose и Multistaging
5. Infrastructure-as-Code: Terraform и Ansible
5. Работа с хранилищем данных Redis
Какие технологии освоишь: Docker, Ansible, Grafana, Kubernetes, Terraform, Zabbix, ELK, Jenkins, Prometheus
Какие еще есть плюшки: у ребят очень доступные цены за счет того, что курс хоть и с ментором, но рассчитан на самостоятельное обучение – т.е. учишься в любое время, когда тебе удобно в образовательной платформе.
❇️ Первые 2 урока бесплатные — попробуй и реши, твое ли это.
Подробнее о курсе
Ребята из Merion Academy (того самого Youtube-канала про IT), создали курс, который помогает не просто смотреть уроки, а реально учиться:
✔️ Грамотно подобранная программа курса.
✔️ Много практики.
✔️ Помогают разобраться с затыками.
✔️ Отдельно помогут с карьерой: как составить резюме, пройти собеседования и найти работу.
Что интересного в программе:
1. Построение CI/CD пайплайнов в GitLabCI и Jenkins
2. Настройка мониторинга с Zabbix, Prometheus и Grafana
3. Понимание DevSecOps, ZTNA, SASE, Defense in Depth
4. Работа с Docker, включая Docker Compose и Multistaging
5. Infrastructure-as-Code: Terraform и Ansible
5. Работа с хранилищем данных Redis
Какие технологии освоишь: Docker, Ansible, Grafana, Kubernetes, Terraform, Zabbix, ELK, Jenkins, Prometheus
Какие еще есть плюшки: у ребят очень доступные цены за счет того, что курс хоть и с ментором, но рассчитан на самостоятельное обучение – т.е. учишься в любое время, когда тебе удобно в образовательной платформе.
❇️ Первые 2 урока бесплатные — попробуй и реши, твое ли это.
Подробнее о курсе
Merion Academy
DevOps-инженер с нуля
Стань DevOps-инженером с нуля и научись использовать инструменты и методы DevOps
🤡4🔥2👍1👏1💊1
TCP Tuning для высокой нагрузки
В больших сервисах стандартные сетевые настройки ядра Linux иногда становятся узким местом.
Например, при сотнях тысяч одновременных соединений сервер может «терять» пакеты SYN, а TCP-сессии застревать в TIME_WAIT. Чтобы этого избежать, настраивают несколько параметров через sysctl.
Основные параметры
1️⃣ net.core.somaxconn
Определяет максимальное количество ожидающих соединений в очереди listen().
2️⃣ tcp_max_syn_backlog
Размер очереди незавершённых TCP-соединений (SYN). Важно при пиковых нагрузках.
3️⃣ tcp_fin_timeout
Время удержания соединений в FIN_WAIT2, которое может «засорять» сервер.
4️⃣ tcp_tw_reuse и tcp_tw_recycle (внимание: tcp_tw_recycle устарел и опасен для NAT)
Позволяет повторно использовать TIME_WAIT-сессии для новых соединений.
Проверка эффекта
➖ Посмотреть количество TIME_WAIT-соединений:
➖ Нагрузить сервер с помощью ab или wrk и сравнить, сколько соединений сервер держит без потерь.
Автоматизация
Чтобы настройки сохранялись после перезагрузки, добавьте их в /etc/sysctl.conf:
и примените:
В больших сервисах стандартные сетевые настройки ядра Linux иногда становятся узким местом.
Например, при сотнях тысяч одновременных соединений сервер может «терять» пакеты SYN, а TCP-сессии застревать в TIME_WAIT. Чтобы этого избежать, настраивают несколько параметров через sysctl.
Основные параметры
Определяет максимальное количество ожидающих соединений в очереди listen().
# посмотреть текущее значение
sysctl net.core.somaxconn
# увеличить до 65535
sudo sysctl -w net.core.somaxconn=65535
Размер очереди незавершённых TCP-соединений (SYN). Важно при пиковых нагрузках.
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
Время удержания соединений в FIN_WAIT2, которое может «засорять» сервер.
sudo sysctl -w net.ipv4.tcp_fin_timeout=15
Позволяет повторно использовать TIME_WAIT-сессии для новых соединений.
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
Проверка эффекта
ss -s | grep timewait
Автоматизация
Чтобы настройки сохранялись после перезагрузки, добавьте их в /etc/sysctl.conf:
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
и примените:
sudo sysctl -p
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍8
Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4🔥3👎1
Secure Copy больших файлов: rsync vs scp
При работе с десятками гигабайт через SSH обычный scp начинает тормозить.
Почему?
Потому что он копирует файл целиком, без возможности возобновления, и каждый раз создаёт новое TCP-соединение.
Rsync через SSH решает это:
⏺ Передача только изменений (--partial и --inplace)
⏺ Можно включить сжатие (-z)
⏺ Поддерживает батчевую передачу и возобновление
Примеры:
Копирование одного большого файла с rsync:
Если соединение обрывается, можно повторно выполнить команду — rsync продолжит с места прерывания.
Копирование каталога с контрольным мультиплексированием SSH:
А затем:
Все повторные подключения будут идти через уже открытое TCP-соединение, экономя время.
scp с мультиплексом и сжатием:
Но для больших директорий rsync остаётся более гибким и надёжным, особенно если нужно резервное копирование или синхронизация.
При работе с десятками гигабайт через SSH обычный scp начинает тормозить.
Почему?
Потому что он копирует файл целиком, без возможности возобновления, и каждый раз создаёт новое TCP-соединение.
Rsync через SSH решает это:
Примеры:
Копирование одного большого файла с rsync:
rsync -avz --progress /local/largefile user@remote:/backup/
Если соединение обрывается, можно повторно выполнить команду — rsync продолжит с места прерывания.
Копирование каталога с контрольным мультиплексированием SSH:
Host remote
HostName 203.0.113.10
User admin
ControlMaster auto
ControlPath ~/.ssh/cm-%r@%h:%p
ControlPersist 10m
А затем:
rsync -avz /local/dir remote:/backup/dir
Все повторные подключения будут идти через уже открытое TCP-соединение, экономя время.
scp с мультиплексом и сжатием:
scp -o ControlMaster=auto -o ControlPath=~/.ssh/cm-%r@%h:%p -C /local/largefile remote:/backup/
Но для больших директорий rsync остаётся более гибким и надёжным, особенно если нужно резервное копирование или синхронизация.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍8❤3
Sysctl для серверов с большим числом подключений
Когда сервер обслуживает сотни тысяч TCP-сессий, стандартные настройки ядра Linux могут стать узким местом.
TIME_WAIT, переполнение очередей сокетов и медленный отклик — типичные признаки. Тут на помощь приходят параметры sysctl.
Основные настройки
⏺ net.ipv4.ip_local_port_range — диапазон локальных портов для исходящих соединений. Увеличение диапазона помогает избежать исчерпания портов при массовых подключениях.
⏺ net.ipv4.tcp_tw_reuse — разрешает повторное использование сокетов в состоянии TIME_WAIT для новых исходящих соединений.
⏺ net.ipv4.tcp_tw_recycle — ускоряет очистку TIME_WAIT (не рекомендуется для NAT).
⏺ net.core.netdev_max_backlog — размер очереди пакетов в драйвере сети. Увеличение помогает при пиках входящего трафика.
Измеряем эффект
➖ До изменений:
➖ Применяем sysctl:
➖ После изменений: повторяем измерения TPS (запросов в секунду) и TIME_WAIT.
➖ Вывод: больше соединений проходит без ошибок, очередь пакетов меньше переполняется, нагрузка на сервер равномернее.
Когда сервер обслуживает сотни тысяч TCP-сессий, стандартные настройки ядра Linux могут стать узким местом.
TIME_WAIT, переполнение очередей сокетов и медленный отклик — типичные признаки. Тут на помощь приходят параметры sysctl.
Основные настройки
Измеряем эффект
ss -s | grep TIME-WAIT
cat /proc/sys/net/core/netdev_max_backlog
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.core.netdev_max_backlog=5000
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3
Bcachefs теперь «внешне поддерживаемая»
Это значит, что ядро больше не принимает её изменения, а дальнейшая разработка ведётся вне основной кодовой базы.
⏺ Причина — конфликты с автором проекта Кентом Оверстритом: он присылает крупные изменения в неподходящее время, нарушая процесс ядра.
Торвальдс считает, что поздние релизы должны лишь исправлять ошибки, а Оверстрит настаивает на срочном исправлении багов для сохранности данных. Bcachefs остаётся экспериментальной ФС.
28 августа 2025 года Линус Торвальдс перевёл файловую систему Bcachefs в режим Externally maintained.
Это значит, что ядро больше не принимает её изменения, а дальнейшая разработка ведётся вне основной кодовой базы.
Торвальдс считает, что поздние релизы должны лишь исправлять ошибки, а Оверстрит настаивает на срочном исправлении багов для сохранности данных. Bcachefs остаётся экспериментальной ФС.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍2🤔1
Logrotate для нестандартных приложений
Стандартные сервисы вроде Nginx или syslog ротируются автоматически, а вот для нестандартных daemon или собственных приложений нужно использовать postrotate, sharedscripts и правильно обрабатывать сигнал HUP.
⏺ postrotate — команды после ротации (например, сигнал процессу перечитать лог).
⏺ sharedscripts — если несколько файлов ротируются, скрипт выполняется один раз.
⏺ HUP — заставляет daemon перечитать файл без перезапуска.
Пример для PostgreSQL:
Здесь логи сжимаются и хранятся неделю, пустые файлы не ротируются, а PostgreSQL после ротации продолжает писать в новый файл.
Пример для Nginx:
Можно добавить уведомление админа через mail или Slack.
Стандартные сервисы вроде Nginx или syslog ротируются автоматически, а вот для нестандартных daemon или собственных приложений нужно использовать postrotate, sharedscripts и правильно обрабатывать сигнал HUP.
Пример для PostgreSQL:
/var/log/postgresql/*.log {
daily
rotate 7
compress
delaycompress
notifempty
missingok
sharedscripts
postrotate
systemctl reload postgresql > /dev/null 2>/dev/null || true
endscript
}Здесь логи сжимаются и хранятся неделю, пустые файлы не ротируются, а PostgreSQL после ротации продолжает писать в новый файл.
Пример для Nginx:
/var/log/nginx/*.log {
daily
rotate 14
missingok
notifempty
sharedscripts
postrotate
[ -f /run/nginx.pid ] && kill -HUP `cat /run/nginx.pid`
endscript
}Можно добавить уведомление админа через mail или Slack.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤3