Здравствуйте! В статье это описывается (просто разбросанно по разделам, извините, если с этим возникли трудности при изучении). В конце будет раздел FAQ на основе вопросов/комментариев, для удобства — типа вспомнить, в чём отличие, и так далее.
Если вкратце про различия:
Торможение из-за виртуализации на Win/Mac у bind mount.
UID/GID хоста — можно словить permission denied, или потом файлы без sudo не удалить (раздел 3.2).
Том всегда изолирован от хоста, bind mount — нет: контейнер получает прямой доступ на запись к реальному пути на диске. (Само по себе это не минус, для например разработки это и есть смысл bind mount) Если перепутать путь при монтировании, можно задеть что-то на хосте. С томом такая случайность исключена в принципе.
А в остальном это просто разная потребность — где-то удобнее bind mount рядом с compose, где-то нужна управляемость тома, тут уже от задачи и проекта зависит.
Ну это ручным способом бэкап будет? В целом да можно такое сделать. Я сделал себе так для переносимости нормальной(ну по моему мнению). Т.к. если Docker крутится не на том хосте, откуда идёт бэкап (удалённый докер, драйвер тома не local, а NFS/S3/rclone-плагин и т.п.), пути /var/lib/docker/... просто не будет на диске.
Допустим в проекте папка my project files/app.py, и Dockerfile рядом.
Без скобок:
COPY my project files /app/
Докер видит это как четыре отдельных слова и последнее всегда destination. Получится: скопировать my, project, files в /app/ — и упадёт с ошибкой, потому что файла с именем my не существует.
Со скобками:
COPY ["my project files", "/app/"]
Тут первый элемент массива — это my project files целиком, второй — /app/. Докер копирует папку как единый путь, пробелы внутри него уже не мешают.
Для COPY скобки нужны только если в пути есть пробелы — без них докер режет строку по пробелам, и my project files распадётся на три части. COPY ["my project files", "/app/"] фиксирует это как один элемент.
Возможно про Dockerfile будет отдельная часть, там поподробнее разберём.
У вас огромный потенциал для роста/привлечение клиентов. Я бывал в нескольких компаниях, где у специалистов поддержки такой хаос в документации, что без LLM уже сложно обойтись. Хотя, конечно, в идеале документацию изначально нужно вести качественно.
Единственное, что меня смущает: если дополнять базу знаний с помощью LLM, нужно быть уверенным, что модель не сможет повредить документацию из-за jailbreak-атак или prompt injection. Иначе есть риск, что некорректные или вредоносные инструкции попадут в базу знаний.
Здравствуйте! Критика без конкретики мало чем помогает ни автору, ни читателям. Статья основана на официальной документации Docker и разборе записей собеседований junior–middle DevOps. Если вы нашли фактическую ошибку, пожалуйста, укажите: что именно написано неверно и как должно быть правильно. Это будет полезно всем.
Спасибо за дополнение! Про nginx и модель изоляции — добавил в статью. Про namespaces и cgroups — да, планирую, это логичное продолжение. cgroups частично затронуты уже в этой части, а namespaces войдут в отдельный раздел серии, ближе к теме контейнеризации либо в серии по Docker.
Спасибо за замечания, оба учёл в обновлении статьи.
Про PSS — добавил объяснение разницы с RSS: почему суммарный RSS завышает реальное потребление при shared libraries, и когда что использовать (RSS для оценки пикового потребления одного процесса, PSS для расчёта потребления по всей системе). Добавил и команду через smaps_rollup.
Про ulimit vs cgroup — добавил явное указание что ulimit ограничивает виртуальную память, а cgroup физическую, с примером Go GC как раз по вашему описанию.
В статье не предусматривал раздел для быстрого перехода по якорному содержанию, поскольку статья также выходит на сайте opensophy, где есть TOC-панель справа. Хабру в копилку идею создать слева меню с TOC-панелью.(думаю это хорошая фича чтобы не писать содержание всё время в тексте)
Про /sys — не стал делать упоминание, поскольку о нём больше и подробнее будет возможно в следующих частях серии по Linux.
Здравствуйте! Тут многое зависит от контекста использования системы. В типичном администрировании — да, зомби явление +/- редкое. А вот если тестировать сторонние инструменты какие-нибудь, то могу из личного опыта сказать: проверял несколько инструментов на базе Puppeteer, 2 из 5 оказались с багом в управлении дочерними процессами и стабильно плодили зомби(не прям много но всё же.)
Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в env могут лежать чувствительные данные, но не стал углубляться в вопросы доступа через /proc и особенности контейнерных окружений, счёл эту информацию на другую часть статьи по безопасности Linux.
Автор, горжусь вами! У меня почти похожая история(буквально тоже начинал с дизайна, потом веб и теперь devsecops изучаю.) Буду рад если совместно в будущем что-нибудь сделаем :)
Здравствуйте! Насчёт IMEI я в теории чисто написал (поэтому написал что нужен какой-то слой) — имел в виду что нужен какой-то идентификатор устройства.
Здравствуйте! Да, Вы правильно всё поняли. Насчёт DDoS: тестировал на своём оборудовании тысячи незавершённых рукопожатий — в основном страдает CPU. Rate limit + Fail2ban неплохо сработали, но при распределённой атаке (к примеру с тысяч IP банить поштучно уже малоэффективно я думаю), пока не нашел ещё варианты как реализовать более мощнее слой против DDoS.
Насколько я знаю, в самом сертификате нет, нужен слой который будет привязывать сертификат к устройству. Как пример Аппаратные ключи и хранилища или по IMEI
Если у вас есть вопросы по mTLS или предложения/идеи по дополнительному тестированию сервера на возможные векторы атак — пишите в комментариях. Интересные и новые методы атак, предложенные вами, я добавлю в статью вместе с результатами.
Здравствуйте! Да, вы правильно уловили проблему, пример получился скорее демонстрацией механики проверки прав ядром, чем реальной схемы использования групп.
Смысл того примера был показать, что права owner/group не суммируются: если процесс является владельцем файла, ядро использует только owner-биты и до group уже не доходит. Я уточню в статье отдельно, чтобы пример с ivan не создавал впечатление, будто группы «не работают как ожидается». Большое спасибо!
Важное примечание: В этой статье намеренно остановились на «продвинутой базе». Тема прав доступа в контексте безопасности продолжится в следующих частях серии (и немного разберем их ещё в логи и мониторинг.)
Здравствуйте! В статье это описывается (просто разбросанно по разделам, извините, если с этим возникли трудности при изучении). В конце будет раздел FAQ на основе вопросов/комментариев, для удобства — типа вспомнить, в чём отличие, и так далее.
Если вкратце про различия:
Торможение из-за виртуализации на Win/Mac у bind mount.
UID/GID хоста — можно словить permission denied, или потом файлы без sudo не удалить (раздел 3.2).
Том всегда изолирован от хоста, bind mount — нет: контейнер получает прямой доступ на запись к реальному пути на диске. (Само по себе это не минус, для например разработки это и есть смысл bind mount) Если перепутать путь при монтировании, можно задеть что-то на хосте. С томом такая случайность исключена в принципе.
А в остальном это просто разная потребность — где-то удобнее bind mount рядом с compose, где-то нужна управляемость тома, тут уже от задачи и проекта зависит.
Ну это ручным способом бэкап будет? В целом да можно такое сделать. Я сделал себе так для переносимости нормальной(ну по моему мнению). Т.к. если Docker крутится не на том хосте, откуда идёт бэкап (удалённый докер, драйвер тома не local, а NFS/S3/rclone-плагин и т.п.), пути /var/lib/docker/... просто не будет на диске.
Допустим в проекте папка
my project files/app.py, и Dockerfile рядом.Без скобок:
Докер видит это как четыре отдельных слова и последнее всегда destination. Получится: скопировать
my,project,filesв/app/— и упадёт с ошибкой, потому что файла с именемmyне существует.Со скобками:
Тут первый элемент массива — это
my project filesцеликом, второй —/app/. Докер копирует папку как единый путь, пробелы внутри него уже не мешают.Для COPY скобки нужны только если в пути есть пробелы — без них докер режет строку по пробелам, и
my project filesраспадётся на три части.COPY ["my project files", "/app/"]фиксирует это как один элемент.Возможно про Dockerfile будет отдельная часть, там поподробнее разберём.
вы про dockerfile? типа COPY [“my project files”, “/app/”]
У вас огромный потенциал для роста/привлечение клиентов. Я бывал в нескольких компаниях, где у специалистов поддержки такой хаос в документации, что без LLM уже сложно обойтись. Хотя, конечно, в идеале документацию изначально нужно вести качественно.
Единственное, что меня смущает: если дополнять базу знаний с помощью LLM, нужно быть уверенным, что модель не сможет повредить документацию из-за jailbreak-атак или prompt injection. Иначе есть риск, что некорректные или вредоносные инструкции попадут в базу знаний.
Здравствуйте! Критика без конкретики мало чем помогает ни автору, ни читателям. Статья основана на официальной документации Docker и разборе записей собеседований junior–middle DevOps. Если вы нашли фактическую ошибку, пожалуйста, укажите: что именно написано неверно и как должно быть правильно. Это будет полезно всем.
Спасибо за дополнение! Про nginx и модель изоляции — добавил в статью. Про namespaces и cgroups — да, планирую, это логичное продолжение. cgroups частично затронуты уже в этой части, а namespaces войдут в отдельный раздел серии, ближе к теме контейнеризации либо в серии по Docker.
Спасибо за замечания, оба учёл в обновлении статьи.
Про PSS — добавил объяснение разницы с RSS: почему суммарный RSS завышает реальное потребление при shared libraries, и когда что использовать (RSS для оценки пикового потребления одного процесса, PSS для расчёта потребления по всей системе). Добавил и команду через smaps_rollup.
Про ulimit vs cgroup — добавил явное указание что ulimit ограничивает виртуальную память, а cgroup физическую, с примером Go GC как раз по вашему описанию.
Здравствуйте! Спасибо за замечание :)
В статье не предусматривал раздел для быстрого перехода по якорному содержанию, поскольку статья также выходит на сайте opensophy, где есть TOC-панель справа. Хабру в копилку идею создать слева меню с TOC-панелью.(думаю это хорошая фича чтобы не писать содержание всё время в тексте)
Про /sys — не стал делать упоминание, поскольку о нём больше и подробнее будет возможно в следующих частях серии по Linux.
Здравствуйте! Тут многое зависит от контекста использования системы. В типичном администрировании — да, зомби явление +/- редкое. А вот если тестировать сторонние инструменты какие-нибудь, то могу из личного опыта сказать: проверял несколько инструментов на базе Puppeteer, 2 из 5 оказались с багом в управлении дочерними процессами и стабильно плодили зомби(не прям много но всё же.)
Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в env могут лежать чувствительные данные, но не стал углубляться в вопросы доступа через /proc и особенности контейнерных окружений, счёл эту информацию на другую часть статьи по безопасности Linux.
Автор, горжусь вами! У меня почти похожая история(буквально тоже начинал с дизайна, потом веб и теперь devsecops изучаю.) Буду рад если совместно в будущем что-нибудь сделаем :)
Здравствуйте! Насчёт IMEI я в теории чисто написал (поэтому написал что нужен какой-то слой) — имел в виду что нужен какой-то идентификатор устройства.
Здравствуйте! Да, Вы правильно всё поняли. Насчёт DDoS: тестировал на своём оборудовании тысячи незавершённых рукопожатий — в основном страдает CPU. Rate limit + Fail2ban неплохо сработали, но при распределённой атаке (к примеру с тысяч IP банить поштучно уже малоэффективно я думаю), пока не нашел ещё варианты как реализовать более мощнее слой против DDoS.
Насколько я знаю, в самом сертификате нет, нужен слой который будет привязывать сертификат к устройству. Как пример Аппаратные ключи и хранилища или по IMEI
Если у вас есть вопросы по mTLS или предложения/идеи по дополнительному тестированию сервера на возможные векторы атак — пишите в комментариях. Интересные и новые методы атак, предложенные вами, я добавлю в статью вместе с результатами.
Спасибо за замечание! Добавил в раздел 4 объяснение разницы между +x и +X.
Здравствуйте! Да, вы правильно уловили проблему, пример получился скорее демонстрацией механики проверки прав ядром, чем реальной схемы использования групп.
Смысл того примера был показать, что права owner/group не суммируются: если процесс является владельцем файла, ядро использует только owner-биты и до group уже не доходит. Я уточню в статье отдельно, чтобы пример с ivan не создавал впечатление, будто группы «не работают как ожидается». Большое спасибо!
Важное примечание: В этой статье намеренно остановились на «продвинутой базе». Тема прав доступа в контексте безопасности продолжится в следующих частях серии (и немного разберем их ещё в логи и мониторинг.)