🐳 Твой Docker-образ весит 1 GB. Хотя мог бы весить 50 MB.

Вижу эту ошибку постоянно.

Разработчики просто делают:
COPY . .
RUN npm install
И считают, что всё отлично.

Но вместе с приложением в прод уезжают:

❌ компиляторы
❌ dev-зависимости
❌ webpack, TypeScript и прочие инструменты сборки
❌ кеш npm

То, что никогда не понадобится во время запуска приложения.

✅ Решение - Multi-stage Build

Используй два `FROM` в одном Dockerfile.

🔨 Stage 1 - Builder

Здесь происходит всё тяжёлое:

* установка зависимостей;
* сборка проекта;
* компиляция;
* создание готовых артефактов.

🚀 Stage 2 - Runtime

Берём чистый образ (`alpine` или `distroless`) и копируем только то, что нужно для запуска.

Без лишнего мусора.

📊 Реальный результат

До:

📦 1.2 GB

После:

📦 58 MB

Что получаем:

⚡ быстрее деплой
⚡ быстрее docker pull
⚡ меньше уязвимостей
⚡ меньше расход дискового пространства

💡 3 правила, которые стоит запомнить

1️⃣ Копируй package.json отдельно
COPY package*.json ./
RUN npm ci
COPY . .
Так Docker сможет использовать кеш слоёв и не будет заново устанавливать зависимости при каждом изменении кода.

2️⃣ Используй лёгкие runtime-образы

Вместо:
node:18
Лучше:
node:18-alpine
или Distroless.

Разница может составлять сотни мегабайт.

3️⃣ Используй npm ci

В CI/CD всегда лучше:
npm ci
а не
npm install
Преимущества:

✅ быстрее
✅ воспроизводимая сборка
✅ строго по package-lock.json

🔍 Проверь прямо сейчас
docker images
Если обычный сервис весит 200+ MB, скорее всего его можно уменьшить в несколько раз всего за несколько минут.

Поверьте, ваш CI/CD скажет вам спасибо. 🚀
Пример докерфайла приложил

#docker

Ещё 3 огонька 🔥 - и выкладываю оставшиеся 61 вопрос с собеседований по Linux.​​​​​​​​​​​​

🐧 Как обещал - все 91 вопрос по Linux

Собрал в один файл, ничего не потеряется.

Формат удобный: блоки по темам, можно открыть на телефоне и прогнать себя перед собесом.

Что внутри:
- Файловая система и inode
- Процессы и сигналы
- Память и cgroups
- Сеть и iptables
- Bash и скриптинг
- Безопасность и SSH
- Трабшутинг реальных сценариев

Подсказка: MD формат удобно читать через github например, запушил туда файликом и у тебя всегда под рукой вопросы в одном месте

Если хотите получить все 91 с ответами, примерами команд и ловушками на собесе - давайте наберём 30 🔥

#linux #library

📚 Навигация по каналу

Чтобы не листать всё подряд - используй хэштеги.

🛠 Технологии
#docker #kubernetes #linux #cicd #git
#terraform #ansible #helm #network #database

📖 Обучение
#library - книги, курсы, шпаргалки
#resources - ссылки на полезные источники

💼 Карьера
#career - собесы, советы, факты из индустрии

Нажми на хэштег → увидишь все посты по теме.

📚 3 книги по Linux для DevOps-инженера

Не «топ лучших книг всех времён». Просто три, которые реально читаются и дают результат.

1. Linux Pocket Guide - Daniel Barrett

Не для чтения от корки до корки. Открываешь когда забыл флаг у grep или как работает chmod. Файловая система, SSH, процессы, права доступа, sed/awk всё коротко и по делу. Лежит открытой на второй вкладке.

2. How Linux Works - Brian Ward

Вот эту читаешь именно как книгу. Объясняет что происходит когда ты включаешь сервер: загрузка, ядро, systemd, сеть, память. После неё перестаёшь угадывать начинаешь понимать.

3. The Linux Command Line William Shotts

Если терминал до сих пор вызывает дискомфорт начни отсюда. Bash, пайпы, перенаправление, простые скрипты.

Все три на английском это нормально. Большинство документации тоже на английском, лучше привыкать сразу. При желании можно найти перевод, ссылки давать к сожалению не могу.

#linux
#library

5 огней и дополню файлик ответами

30 огней собрали, ура!
Полный сборник вопросов по Linux с собеседований, забирайте и проходите успешно собесы!

Формат: 🗣 Устный ответ → 💡 Запомни → 💻 Код → ⚠️ Ловушка

так же в md формате чтобы не терять

#linux
#library

Мнения разделились 50 на 50, поэтому делаю пост + видео:



🔴 Почему в IT стало так сложно найти работу?

Кто хочет послушать, а не читать - https://www.youtube.com/watch?v=0qPi7yJfDdQ

Я собрал открытые данные рынка труда, зарплатные исследования и большие выборки вакансий за 2025-2026 год. Не мнение - цифры.

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

Проблема не в количестве кандидатов. Проблема в разрыве между тем, что умеют люди, и тем, что реально нужно бизнесу.

Новичков много. Тех, кто знает слова Docker, Kubernetes и Terraform, тоже. Но компании ищут не знание слов. Им нужен человек, которому можно доверить боевой сервис: разобраться в инциденте ночью, не уронить кластер при обновлении, выкатить деплой так, чтобы пользователи не заметили.

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

⏳ Воронка найма удлинилась. HR-скрининг, техническое интервью на 60-90 минут, поведенческая секция, system design, финал с менеджером. На серьёзные позиции процесс растягивается на месяц. Топ жалоб кандидатов: нет обратной связи, слишком много этапов, тестовое выполнил — получил отказ без объяснений.

💰 По зарплатам: Middle DevOps по медиане 150-280 тысяч. Senior уходит выше 350-500 тысяч. Финтех и маркетплейсы платят на 40-60% выше среднего, потому что цена ошибки там другая.

🏢 Удалёнки стало меньше. 77% российских компаний вернули команды в офис или гибрид. Полная удалёнка сократилась до 7%. Гибкость остаётся у тех, кто редкий и сильный.

🤖 AI не убил рынок, но поднял планку. Простые задачи автоматизируются. Рутина стоит меньше. Ответственность, production-мышление и умение работать с инцидентами стоят больше.

Рынок IT не умер. Изменились правила. Компании платят не за список технологий в резюме, а за способность брать ответственность и приносить результат.

Следующий выпуск: Roadmap DevOps на 2026 год. Не по курсам, а по тому, что действительно ищут компании.

#resources
#career

Свежие вакансии, заодно можно рыночек оценить, так себе конечно)

1. System Administrator — Центурион-Инновации
middle · 195 000 ₽ · офис Москва
→ [Habr](https://career.habr.com/vacancies/1000167435)

2. Systems Engineer — Alber Blanc
senior · 380 000 ₽ · офис Лимасол
→ [Alberblanc](https://alberblanc.com/careers/senior-network-systems-engineer-521/)

3. DevOps Engineer — Сбер
intern · от 60 000 ₽ · гибрид Питер
→ [Hirehi](https://hirehi.ru/devops/devops-inzhener-57844)

4. Site Reliability Engineer — Яндекс Финтех
middle · 282 000 ₽ · удалёнка
→ [Hirehi](https://hirehi.ru/devops/site-reliability-engineer-58042)

5. Системный инженер — ASTON
middle · 175 000 ₽ · удалёнка
→ [Hirehi](https://hirehi.ru/devops/sistemnyi-inzhener-57152)

6. Системный инженер — Сбер
middle · 165 000 ₽ · офис Чебоксары
→ [Rabota](https://rabota.sber.ru/search/starshiy-spetsialist-po-informatsionnoy-bezopasnosti-ib-4443039/)

7. DevOps Engineer — МТС
middle · 227 000 ₽ · офис Москва
→ [Job](https://job.mts.ru/vacancies/678966233428658215)

8. DevOps Engineer — Greenway Global
lead · от 180 000 ₽ · офис Новосибирск
→ [Hirehi](https://hirehi.ru/devops/devops-inzhener-57589)

❌ «Я же знаю Kubernetes. Почему меня не взяли?»

Недавно вспомнил одну ситуацию с собеседования.

В вакансии было написано:

«Требуется DevOps с опытом Kubernetes.»

На техническом интервью мне задают вопрос:

Что происходит после kubectl apply?

Я начинаю объяснять:

• запрос уходит в API Server;
• объект сохраняется в etcd;
• Controller Manager замечает изменение;
• Scheduler выбирает Node;
• Kubelet получает новую задачу;
• containerd запускает контейнер;
• Pod проходит Readiness Probe и становится Ready.

Интервьюер кивает.

Следующий вопрос:

«Что произойдет, если Scheduler выберет Node, на которой закончилась память?»

Потом:

«Почему Pod может зависнуть в Pending?»

Потом:

«Чем ReplicaSet отличается от Deployment?»

Потом:

«Почему контейнер может уйти в CrashLoopBackOff?»

И только тогда я понял одну важную вещь.

Большинство людей готовятся к собеседованиям, запоминая команды.

kubectl get pods
kubectl logs
kubectl describe
kubectl exec

Но компании проверяют совсем другое.

Они хотят понять не то, знаешь ли ты команду.

Они хотят понять, понимаешь ли ты систему.

Можешь ли ты объяснить:

• почему всё работает именно так;
• какой компонент выполняет каждое действие;
• где искать проблему, если что-то пошло не так;
• как будет вести себя кластер в нестандартной ситуации.

Именно поэтому многие удивляются:

«Я же знаю Kubernetes. Почему меня не взяли?»

Потому что знать команды и понимать архитектуру — это две совершенно разные вещи.

Команды можно выучить за несколько дней.

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

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

💬 А какой самый неожиданный вопрос по DevOps задавали вам на собеседовании? Напишите в комментариях. Интересно собрать реальные истории и потом сделать отдельный пост с разбором.

#kubernetes
#career

🔥 Подборка актуальных вакансий DevOps / SRE / MLOps

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

1️⃣ Золотое Яблоко | DevOps Engineer
💪 Middle • 💰 ~254 000 ₽ • 🏠 Гибрид, Екатеринбург

2️⃣ Островок | MLOps Engineer
💪 Senior • 💰 ~356 000 ₽ • 🏠 Удалённо

3️⃣ Сбер | DevOps Engineer
💪 Senior • 💰 ~308 000 ₽ • 🏠 Гибрид, Москва

4️⃣ ВКонтакте | Site Reliability Engineer
💪 Senior • 💰 ~354 000 ₽ • 🏠 Удалённо по РФ

5️⃣ ВКонтакте | Site Reliability Engineer
💪 Senior • 💰 ~350 000 ₽ • 🏠 Удалённо по РФ

6️⃣ Т1 | Инженер технической поддержки
💪 Middle • 💰 ~145 000 ₽ • 🏠 Офис, Тюмень

7️⃣ Wildberries | Support Engineer
💪 Middle • 💰 ~173 000 ₽ • 🏠 Гибрид, Москва

8️⃣ Авито | Site Reliability Engineer
💪 Middle • 💰 ~250 000 ₽ • 🏠 Удалённо


💬 Нужна ссылка на конкретную вакансию? Напишите её номер в комментариях (например: «2» или «8»)- отправлю в личные сообщения.

🎮 Прокачай Git за один вечер

Читать теорию про git можно бесконечно. А потом всё равно путаешься в rebase и merge conflict на практике.

Есть простое решение - интерактивная игра, где ты реально руками решаешь задачи с ветками, а не просто читаешь про них.

Что цепляет:
– визуализация веток в реальном времени
– от простого checkout до сложного rebase и cherry-pick
– можно сразу увидеть свою ошибку, а не гадать что пошло не так

Рекомендую пройти минимум 5 раз. Первый раз будет больно, дальше пойдёт как по маслу.

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

→ learngitbranching.js.org

#git
#resources

📦 MLOps Roadmap 2026

Полная карта пути от DevOps до Production ML.

12 этапов: цель, что учить, какой стек - на каждом.

Не теория и не курс.
То, через что реально проходят инженеры.

Главная мысль:
MLOps - это не Kubeflow.
Это контроль всего жизненного цикла модели:
от данных до продакшена.
Хочешь двигаться дальше по этой карте?

Пиши «MLOps» в комментариях -
соберу Starter Pack с материалами по каждому этапу.

Наберем 80 комментариев выложу в тг сразу

#library

📦 Linux-собес

Собрал 6 вопросов, которые реально спрашивают на собеседованиях DevOps / SRE / Backend.

1. Что такое процесс?
Выполняющаяся программа в памяти. У неё есть своё адресное пространство, PID, регистры, стек и список открытых файлов. Ядро полностью изолирует процессы друг от друга.

2. Что такое ОС?
Прослойка между железом и приложениями. Управляет процессами, памятью, файловой системой и устройствами. Благодаря ОС один упавший процесс не роняет весь сервер.

3. Что такое файловый дескриптор?
Число, которое ядро выдаёт процессу для работы с файлами, сокетами или pipe. 0, 1 и 2 — это stdin, stdout и stderr.

4. Что такое inode?
Структура на диске, где хранятся метаданные файла: владелец, права, размер, время изменения и указатели на данные. Имя файла хранится отдельно в каталоге.

5. Какие бывают состояния процессов?
- R — выполняется или готов к выполнению
- S — спит (ждёт события), самое частое состояние
- D — ожидание диска (нельзя убить даже kill -9)
- Z — zombie (процесс умер, но родитель не забрал статус)

6. ext4 vs XFS?
- ext4 — универсальный и стабильный выбор по умолчанию.
- XFS — быстрее работает с большими файлами и высокой параллельной записью (хорошо для баз данных и хранилищ).

#linux
#career

Как маршрутизировать на разные Redis и другие сервисы через один LoadBalancer по SNI TCP routing используя Gateway API

https://habr.com/ru/articles/987652/

#resources

📦 Что происходит после нажатия кнопки Power? Как загружается Linux?

Каждый день мы запускаем серверы, контейнеры и виртуальные машины.
Но что на самом деле происходит между нажатием кнопки Power и появлением логина? 🤔
Разберём путь по шагам.

⚡ 1. BIOS / UEFI
Первым запускается BIOS (или UEFI).
Он проверяет оборудование:
• память;
• процессор;
• диски;
• устройства.
После этого ищет загрузчик.

🚀 2. GRUB
Обычно это GRUB.
Его задача проста:
• найти ядро Linux;
• загрузить initramfs;
• передать управление ядру.

🐧 3. Ядро Linux
Ядро распаковывает себя в память и начинает инициализацию системы:
• загружает драйверы;
• монтирует initramfs как временную файловую систему;
• находит настоящий root-раздел;
• выполняет switch_root;
• освобождает временную файловую систему из памяти.

⚙️ 4. PID 1 - systemd
Теперь запускается первый процесс в системе.
У него всегда PID = 1.
Сегодня почти во всех современных дистрибутивах это systemd.

🔥 Чем systemd отличается от старого init?

Он не запускает сервисы по очереди.
Вместо этого строит граф зависимостей и поднимает всё, что возможно, параллельно.
Затем система достигает нужного состояния:
🖥 graphical.target - рабочий стол.
🖧 multi-user.target - серверный режим.

Что такое Unit?

Очень многие думают, что Unit = Service.
На самом деле service - лишь один из типов unit.
Unit - это любой объект, которым умеет управлять systemd.
Самые популярные:

🔹 Service - запускает процессы.
🔹 Socket - открывает порт ещё до запуска сервиса (socket activation).
🔹 Target - объединяет несколько unit в одну цель.
🔹 Timer - выполняет задачи по расписанию (аналог cron).
🔹 Mount - монтирует файловые системы.

Посмотреть состояние unit

systemctl status nginx.service

Увидите:
• состояние сервиса;
• PID процесса;
• последние записи журнала;
• причины возможных ошибок.

📌 Вот и весь путь:

Power → BIOS/UEFI → GRUB → Kernel → initramfs → switch_root → systemd → ваши сервисы.
Именно так Linux проходит путь от кнопки питания до работающего приложения.

#linux
#career