Комментарии 9
«немутабельны (immutable)» — может всё-же «неизменяемы»?
PS. ЛС недоступно, сорри.
PS. ЛС недоступно, сорри.
Думаю, что «неизменяемый» и «немутабельный» — это всё-таки разные вещи.
Вот, например, терминология 1С: http://kb.mista.ru/article.php?id=941.
Прямую аналогию с докеровскими образами и контейнерами провести сложно, но, исходя из опыта, можно сказать, что англоязычные авторы применяют этот термин вместо «constant», «read-only» или «unchangeable» неслучайно, т. е. они вкладывают в него несколько иной смысл.
Вот, например, терминология 1С: http://kb.mista.ru/article.php?id=941.
Прямую аналогию с докеровскими образами и контейнерами провести сложно, но, исходя из опыта, можно сказать, что англоязычные авторы применяют этот термин вместо «constant», «read-only» или «unchangeable» неслучайно, т. е. они вкладывают в него несколько иной смысл.
В реальной системе фронтенду помимо логов и пидов надо писать еще в пяток мест (загруженные пользовательские файлы и картинки, они же после изменения размера/кропа, всякие кеши, в особо забавных случаях — «скомпилированные» в php шаблоны). Еще многие CMS любят хранить куски PHP кода внутри базы данных.
Иммутабельность кода сайта — это очень хорошо, но не всегда достаточно для того, чтобы «одним движением» откатить все изменения. Надо еще скрупулезно чистить все кеши на старте системы, разрешать выполнение скриптов только в тех местах, где это надо, и разрешать запись фронтенда в базу только в те таблицы (или даже столбцы), которые реально нужно менять пользователям.
Иммутабельность кода сайта — это очень хорошо, но не всегда достаточно для того, чтобы «одним движением» откатить все изменения. Надо еще скрупулезно чистить все кеши на старте системы, разрешать выполнение скриптов только в тех местах, где это надо, и разрешать запись фронтенда в базу только в те таблицы (или даже столбцы), которые реально нужно менять пользователям.
Это, конечно, получше чем рекурсивный chmod в read only для всех файлов движка
Но на практике разница не велика.
Но на практике разница не велика.
На практике, в Docker'e можно выделить отдельные Volume для пользовательских данных, для конфигов и для кеша, и при необходимости банально убивать volume с кешем.
А исполняемый контейнер — да, выставить в read-only.
А исполняемый контейнер — да, выставить в read-only.
Можно, конечно. Мой посыл был в том, что зловредители могут залить шеллскрипт в volume с картинками — и это легко откатить не получится. Полной иммутабельности нет, т.к. откатить все состояние контейнера до исходного нельзя. Максимум, что можно (и нужно) сделать — это убедиться, что скрипты выполняются только там, где это реально нужно.
При запуске пишет
Unable to find image 'diogomonica/phphack:latest' locally
Pulling repository docker.io/diogomonica/phphack
docker: Error: image diogomonica/phphack:latest not found.
Unable to find image 'diogomonica/phphack:latest' locally
Pulling repository docker.io/diogomonica/phphack
docker: Error: image diogomonica/phphack:latest not found.
Во-первых https://github.com/diogomonica/apachehackdemo/blob/master/setup.sh
Во-вторых, докер-команды, чтобы понять, что у вас вообще имеется на данный момент
И наконец, имена для образов и контейнеров докер придумывает сам, если не указано конкретное значение (docker build, -t, --tag value Name and optionally a tag in the 'name:tag')
Во-вторых, докер-команды, чтобы понять, что у вас вообще имеется на данный момент
- docker images -a //all images
- docker ps -a // all containers
И наконец, имена для образов и контейнеров докер придумывает сам, если не указано конкретное значение (docker build, -t, --tag value Name and optionally a tag in the 'name:tag')
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Увеличиваем стоимость атаки с помощью Immutable Infrastructure