В прошлой части я разобрал хранилища — тома, bind mount, tmpfs. В третьей части (в этой) планировалось добраться до сети. До неё дойдём, но прежде чем разбирать, как сервисы общаются друг с другом, стоит на секунду остановиться и разобрать сам файл, в котором мы всё это описываем. Потому что compose.yaml — это спецификация со своими top-level разделами, правилами слияния, подстановкой переменных и кучей мелких нюансов, которые легко упустить, если читать документацию по верхам.

Эта часть, по сути, большой справочник по структуре Compose-файла: держите статью под рукой и возвращайтесь к ней, когда понадобится конкретный атрибут.

Docker и хранение данных: тома, bind mount, tmpfs и не только

Разбираемся, какие способы хранения данных есть в Docker, чем они отличаются друг от друга и что выбирать в реальных сценариях. В статье — тома, подключение хост-каталогов, tmpfs, нюансы docker compose, SELinux, volume-subpath, --volumes-from, драйверы хранения и бэкап томов на практике.

Я очень рад, что существует такая технология, как Docker, и внедряю её в проекты и инфраструктуру клиентов. Однако есть одно «но»: многие не понимают, что это и зачем оно нужно, а объяснять иногда достаточно сложно (особенно повторять каждый раз каждому человеку, да и есть шанс что-то упустить). В этой статье вы узнаете базу по Docker, где найти практику и актуальные знания. Технология будет полезна многим: от специалистов по безопасности до разработчиков. А сама статья будет познавательна для тех, кто только изучает работу Docker и хочет узнать ответы на вопросы, которые часто задаются на собеседованиях, где требуется Docker. Приступим!

Продолжаем серию о Linux. В прошлой части разбирали права доступа, а теперь переходим к одной из самых важных тем в Linux — процессам. Любая программа в системе в конечном итоге существует как процесс: nginx, postgres, docker, sshd, systemd, ваш shell и даже потоки ядра. Понимание того, как процессы создаются, живут, взаимодействуют с ядром и завершаются, — это база для понимания и диагностики Linux-систем. Цель этой статьи — рассказать кратко и простым языком всю нужную информацию как для начинающих, так и для опытных пользователей и админов, чтобы освежить знания. Важно: для практики, если обучаетесь, лучше всего использовать виртуалку с Linux.

Это вторая часть цикла про mTLS. В первой разобрали теорию: как работает рукопожатие, от каких атак защищает и где принципиально бессилен. Здесь — практика. Разберём реальный сценарий: homelab на одном сервере с Traefik и Dokploy. Пройдём путь от модели угроз до конкретных попыток атаковать собственный сервер — с командами и объяснениями, что происходит.

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

Продолжаем серию рубрики Linux. В прошлой серии разобрали пользователей и группы – UID, GID, /etc/passwd. Теперь разберём что ядро делает с этими числами когда процесс пытается открыть файл или войти в директорию. Про права доступа легко выучить команды – chmod 755, chown user file – но не понимать что происходит под капотом. Тогда начинаются странные ситуации: «я же владелец, почему Permission denied?». Цель этой статьи – кратко но в достаточной форме рассказать про права доступа.

Вся статья построена на практике: каждый раздел можно пройти руками. Для большинства примеров достаточно обычного пользователя, для части нужен sudo. Где нужен – отмечено явно. Серия в основном под Ubuntu/Debian.

В конце статьи будет бонус который даст вам возможность изучить права доступа в Linux ещё доступнее и возможно проще.

Обновление статьи: 2026-05-14

Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.

Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.

Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.

Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.

Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.

Если вы когда-либо выставляли сервис в интернет и смотрели на логи — вы знаете, что происходит в первые минуты. Сканеры, боты, перебор паролей. Firewall помогает, но не всегда. VPN — хорошо, но не всегда удобно и сами протоколы в России к примеру не работают. А что если сервер будет просто отказывать в соединении всем, у кого нет нужного криптографического сертификата — ещё до того, как они увидят страницу логина? Это и есть mTLS.

В статье разберём: что такое mTLS и как работает рукопожатие, как это связано с Zero Trust, от каких атак защищает и где принципиально бессилен, какие риски несёт сама PKI-инфраструктура и где чаще всего ошибаются при реализации. В конце — практика: как мы в Opensophy сделали mtls.sh, bash-скрипт для управления mTLS-сертификатами под Traefik, и почему архитектура «промежуточный CA на каждого клиента» позволяет мгновенно отзывать доступ без CRL и OCSP в Traefik.

Статья будет полезна всем, кто хочет защитить свои сервисы — будь то домашняя лаборатория, панели управления вроде Proxmox или Portainer/Dokploy, внутренние API или любой сервис, который не должен быть доступен всем подряд. Если коротко: если вы выставляете что-то в интернет и не хотите, чтобы туда мог зайти кто угодно — mTLS для этого и существует.

Продолжаем прохождение linux! Сразу уточню что статья может обновляться после адекватной критики и уточнений от сообществ @opensophy(там где офицально статья была опубликована от opensophy), свежие обновления всегда происходят на hub.opensophy.com, если вы только начинаете изучать линукс или хотите освежить память можете вернуться в прошлую серию рубрики “Учим Linux: Файлы, навигация и поиск”. В этой части я попытался расписать довольно кратко т.к. информации и так много и тот же новичок может не сразу все выучить но по комментариям из Хабра я буду создавать что-то вроде чеклиста оперативных вопросов(это если я пропустил что-то из важной информации). Приступим.

Статья объясняет, как в Linux устроена система пользователей и групп и как через неё управляется доступ к ресурсам. Разбирается, что такое UID/GID, как система хранит данные о пользователях (/etc/passwd, /etc/shadow), как создаются и изменяются аккаунты, как работают группы и права по умолчанию.

Отдельное внимание уделено практическому администрированию: useradd, usermod, sudo, управлению доступом, безопасности и типичным ошибкам.

Начинаю серию «Linux Base» из 11 частей — структурированная база для DevOps, DevSecOps и всех, кто работает с Linux.

Часть 1 — Файлы, навигация и поиск: разбираем структуру каталогов (/etc, /proc, /var и др.), навигацию, работу с файлами, просмотр содержимого и поиск через grep, awk, sed.

в конце также вас ждет Linux commands cheatsheet!

В современном мире веб-разработки выбор стратегии рендеринга сайта является одним из ключевых решений, определяющих его производительность, оптимизацию для поисковых систем (SEO) и пользовательский опыт. От того, как и где генерируется HTML-код вашего приложения, зависит скорость загрузки, интерактивность и даже стоимость инфраструктуры. В этой статье мы подробно рассмотрим основные типы рендеринга — Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR) и набирающие популярность React Server Components (RSC) — их преимущества, недостатки, влияние на SEO и производительность, а также приведем примеры технологических стеков для каждого подхода.

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

Это руководство объединяет две методологически таблицы - одну для концептуальных моделей (OSI и TCP/IP) и одну для конкретных протоколов и технологий. При обнаружении ошибок / неточностей - сообщите в комментариях, после проверки действительно ли есть ошибки / неточность - информация дополниться.

Обновлено 20.01.2026