Pull to refresh
26
0
Роман @softaria

User

Send message
С яваскриптовыми ботами можно как-то бороться. А вот таких отличить от человека вообще не получается. Там при записи сценария ты показываешь прямоугольную область экрана и координаты клика отсчитываются от неё. Когда скрипт запускается он повторяет такой клик (ему еще можно сказать слегка рандомизировать клики — прибавлять маленькое случайное число к обоим координатам). Если скрипт не находит на экране заданную область, он просто перестает работать и сообщает о проблеме.
Ловить таких очень дорого и сложно.
Важный момент тут. Дырка в системе-образе не особенно важна, поскольку сама эта система не запускается.
Процесс докера работает а host-системе и взаимодействует с ядром host-системы.
Проблемой может быть только такая уязвимость, благодаря которой уязвимым станет сам бинарник процесса еще на этапе сборки.
Ответ простой — там, кроме бинарника были еще какие-то файлы, которые он использовал. Они тоже часто менялись (в том числе и их набор)
Можно, конечно, было передавать все архивом и раскладывать файлы по местам, а старые удалять. Но это — неустойчиво к человеческим ошибкам.
Тут, кстати, самыми проблемными являются не js боты, а те, которые тупо кликают мышью по окну честно открытого браузера, ориентируясь по заранее записанным фрагментам картинки.
Иногда, есть. Пример — браузерные игры, где прокачка персонажей ботами убивает у других игроков интерес к игре.
А есть ли смысл бороться именно с phantom? Ведь ботов можно написать на чем угодно.
Разумеется, докер — не универсальное решение любой задачи.

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

kill -9

Дети останутся. Так же они останутся, если докер демон закрэшится из-за внутренней ошибки. Именно об этом шла речь.
Да, это так.
Авторы докера еще не рекомендуют запускать в контейнере более одного процесса.
А вот эти авторы очень популярного base image другого мнения.

У любого решения есть плюсы и минусы. Взвешивать их и принимать решения только тому, кто несёт ответствнность за результат.
разных паролях и хостах с БД

Здесь проще всего задать пароль, имя пользователя, хост и имя базы данных переменными окружения, передаваемыми самому контейнеру с СУБД. Так, чтобы они совпали с вашими.

разных требованиях к памяти и CPU affinity

Здесь обычно создаётся volume с конфигурацией, этот volume мэпится на директорию хост системы и там конфигурация правится руками. Некоторые параметры тоже можно передавать переменными окружения. Другой вариант — отнаследовать production image от development image и поменять там конфигурацию, просто перекрыв её новой при помощи директивы COPY.

запрете разработчикам подключаться к прод-серверам

Тут даже не скажу. Я написал «некоторые считают, что deployment исчезнет», но это не значит, что он уже исчез конкретно у нас.
Думаю, можно поступить также, как с конфигурацией, вынесенной на отдельный volume. Или опять отнаследовать образ.
Но сам я такого не делал.
У докера есть понятие томов (volumes). Вы можете объявить volume в докер файле.
Как то так:

VOLUME ["/opt/tomcat/logs"]

Данные, сохраненные контейнером в эту директорию не будут удалены вместе с контейнером.
Можно также мэпить тома на директории host системы.
Пожалуйста!
Интересный вопрос. Спрошу у лида этого проекта и напишу.
Вы правы. Я ошибся.
Тогда отвечу так: я понятия не имею :)
То же, что и насчет ansible или puppet.
Их проблема в исполнении кастомного кода во время установки.
Это — бОльшая хрупкость, по сравнению с докером у которого кастомный установочный код выполняется во время сборки образа.
В первом случае для устранения сбоев при установке нужен доступ на production.
Во втором сбои устраняются заранее во время сборки образа.

Другими словами, первая группа инструментов отправляет в продакшен код, который должен там исполниться в незнакомой среде хост системы.
Докер отправляет в продакшен заранее собранный процесс и требуемые ему данные. Здесь нет стадии исполнения кода во время установки. А нет исполнения — нет ошибок.
Разница здесь в том, что puppet/chef запускает на продакшен серверах команды, чтобы добиться там появления кастомной конфигурации, созданной пользователем.
Эта задача заведомо более сложная, чем то, что делает докер — тупо запускает заранее подготовленные процессы — никакой кастомной логики во время установки не выполняется.
Другими словами, в случае с паппетом есть чему ломаться во время установки на продакшен.
В случае с докером поломки будут не во время установки, а во время сборки образа. То есть для их устранения не нало иметь доступ на production server.
Не намного. Хотя вот сам докер демон тоже что-то съест.
Вот тут, например, обсуждают мажину с 12гб памяти 12 свопа, где запущено 183 контейнера и там докер съел 5гб виртуальной памяти.

Вообще, процесс докера работает через cgroups и использует системные вызовы ядра хост системы. Он не тащит с собой дополнительный линукс в свою память.
Только в виде виртуальной машины с линуксом.
Vendor lock in обычно означает привязку к коммерческому продукту. Или к продукту, контролируемому узкой группой лиц.
Докер — бесплатный, с открытыми исходниками, предоставляется по лицензии Apache 2.
То есть vendor lock in здесь такой же, как при использовании Linux.

Information

Rating
Does not participate
Location
Ян де нова о-ва
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Software Architect
Lead
Java
Docker
React
TypeScript
Java Spring Framework
Designing application architecture
High-loaded systems