Да, думаю что может. Одно время я занимался оптимизацией и улучшением производительности запросов в MS SQL (2008 — 2012 версий). В том числе через донастройку индексов. Описанное в статье выглядит очень знакомым и, в общем смысле, применимо к MS SQL. Вплоть до ситуации с WHERE… OR и ее решением через UNION — частый случай у нас был, хотя и в более изощренной форме.
proxmox вроде давно платный, а бесплатный вариант урезан как-то + апдейты там были только из ветки «для разработчиков». Или что-то поменялось с тех пор, когда я на него смотрел?
мне кажется, к теме безопасности (равно как и целостности контейнера) это не относится. Вызов какого-то скрипта (утилиты) Healthcheck это лишь проверка «работает ли процесс внутри контейнера должным образом». И то — если такая возможность представляется самим процессом. Как это повышает безопасность?
Я бы еще добавил пункт о том, что пользователь хоста, имеющий доступ к сокету Докера (или иным способом имеющий возможность управлять контейнерами) по сути имеет полный доступ к хосту.
Как пример — включение в группу docker (без включения возможности sudo) позволяет прокинуть в контейнер корень ФС и изнутри контейнера спокойно «что-то запрещенное почитать\исправить».
EXPOSE эта инструкция указывает какой набор портов прослушивает контейнер во время выполнения
Не совсем так. Это лишь декларация типа «возможно, что что-то внутри контейнера будет слушать указанный порт». Не более того. EXPOSE может вообще отсутствовать в Dockerfile, что никак не помешает сетевому взаимодействию с контейнером из этого образа.
Единственное на что эта директива влияет, это на запуск контейнера через docker run с ключом -P. Тогда Докер автоматом прокинет указанные в EXPOSE порты на 0.0.0.0
Я почему акцентирую на этом внимание — изначально, изучая Докер, назначение и суть EXPOSE я понял «только с третьей попытки». Ибо в документации и разных статьях оно было описано невнятно.
Почему упомянута UnionFS, разве в Докере не OverlayFS (а ранее AuFS)?
>Данная ФС реализует механизм копирования при записи (Copy-On-Write, COW)
Разве там есть COW? Или имеется ввиду выделение отдельного read-write слоя для «жизни контейнера»?
> т.к. в отличие от VM, виртуализируют ОС, а не аппаратное обеспечение.
мне кажется, формулировка некорректная. Виртуализации там нет. ОСь никто не «виртуализирует», разве что окружение. Ядро и его ресурсы все-равно общие.
>Dockerfile может содержать такие команды как:
описание очень поверхностное. Извините, но вот например это «CMD — запускает создание нового контейнера на основе образа» очень странная формулировка. Директива CMD к «созданию контейнера» отношения не имеет. Про EXPOSE — тоже не совсем корректно, и не указано зачем на самом деле он нужен.
P.S. и, как мне кажется, не освещено главное отличие контейнеров от ВМ — первые выполняются на одном общем ядре ОС, вторые — имеют свои отдельные ядра ОС. Да, это банальщина, я понимаю. Но тут как бы тема статьи такая — про банальные вещи.
В Докере OverlayFS с некоторых пор. А до этого была AuFS. Откуда тут UnionFS появился?
я ошибаюсь или docker service доступен только если хост в режиме Swarm? Т.е. «просто так» этого не сделать. Может стоит указывать такое в тексте?
мне кажется, к теме безопасности (равно как и целостности контейнера) это не относится. Вызов какого-то скрипта (утилиты) Healthcheck это лишь проверка «работает ли процесс внутри контейнера должным образом». И то — если такая возможность представляется самим процессом. Как это повышает безопасность?
Я бы еще добавил пункт о том, что пользователь хоста, имеющий доступ к сокету Докера (или иным способом имеющий возможность управлять контейнерами) по сути имеет полный доступ к хосту.
Как пример — включение в группу docker (без включения возможности sudo) позволяет прокинуть в контейнер корень ФС и изнутри контейнера спокойно «что-то запрещенное почитать\исправить».
под Вин Докер уже научился использовать Windows Containers, естественно «там где оно есть». Майкрософт за тему с Докером серьезно взялись.
Не совсем так. Это лишь декларация типа «возможно, что что-то внутри контейнера будет слушать указанный порт». Не более того. EXPOSE может вообще отсутствовать в Dockerfile, что никак не помешает сетевому взаимодействию с контейнером из этого образа.
Единственное на что эта директива влияет, это на запуск контейнера через docker run с ключом -P. Тогда Докер автоматом прокинет указанные в EXPOSE порты на 0.0.0.0
Я почему акцентирую на этом внимание — изначально, изучая Докер, назначение и суть EXPOSE я понял «только с третьей попытки». Ибо в документации и разных статьях оно было описано невнятно.
>Данная ФС реализует механизм копирования при записи (Copy-On-Write, COW)
Разве там есть COW? Или имеется ввиду выделение отдельного read-write слоя для «жизни контейнера»?
> т.к. в отличие от VM, виртуализируют ОС, а не аппаратное обеспечение.
мне кажется, формулировка некорректная. Виртуализации там нет. ОСь никто не «виртуализирует», разве что окружение. Ядро и его ресурсы все-равно общие.
>Dockerfile может содержать такие команды как:
описание очень поверхностное. Извините, но вот например это «CMD — запускает создание нового контейнера на основе образа» очень странная формулировка. Директива CMD к «созданию контейнера» отношения не имеет. Про EXPOSE — тоже не совсем корректно, и не указано зачем на самом деле он нужен.
P.S. и, как мне кажется, не освещено главное отличие контейнеров от ВМ — первые выполняются на одном общем ядре ОС, вторые — имеют свои отдельные ядра ОС. Да, это банальщина, я понимаю. Но тут как бы тема статьи такая — про банальные вещи.