Ещё можно использовать Kubernetes. Там всё это уже готовое. DNS-ресолвер, статические IP-адреса у сервисов, масштабирование количества инстансов, etcd для склеивания всего этого вместе, kube-proxy вместо haproxy.
Директории тоже нужно место на диске, чтобы хранить список файлов. Если создать дохрениллион файлов, то и размер директории будет длинным. Для чтения перечня файлов или открытия файла надо пролистать всю директорию, пока файл не будет найден. Возможно, там был баг, который не позволял прервать системный вызов, пока файловая система не найдёт хотя бы один файл. А невозможность прервать системный вызов — это значит процесс, не реагирующий на сигналы, например.
Интересно, а что будет с юридической точки зрения, если спутник вообще нигде не зарегистрирован. Понятно, что сейчас его не запустить без привлечения огромных контор типа Роскосмоса или SpaceX, за которыми внимательно следят. А вот завтра, когда топливо станет более энергоэффективным, и набор для запуска можно будет купить на кассе в супермаркете…
Он вас не слушает. Я хотел большой коммент написать про измерение сферического коня в вакууме. Но вы уже это разжевали так, что по-моему больше даже вопросов быть не может.
Ну если быть совсем педантом, то и отдельные тестовые серверы не нужны. Можно развернуть тестовую копию сервиса на тех же серверах, но в отдельных контейнерах. Если поменьше реплик сделать, то можно всё протестировать без ущерба продакшну :)
Я не вижу, почему надо в крайности бросаться. Хотите везде одинаковые версии библиотек — у вас наверняка есть какая-то своя политика — например "использовать только debian stable и ни шага в сторону". И, скажем, у вас есть свой дополнительный репозитарий, где вы храните более новые версии тех пакетов, которые вас не устраивают из stable. Делаете базовый контейнер на основе debian stable, добавляете туда свой репозитарий, и скажем раз в сутки по крону его обновляете (вызываете docker build && docker push).
Дальше заставляете программистов (диктатура операторов) использовать только ваш базовый образ и добавлять туда пакеты только через apt-get. В результате если разработчик вызовет у себя docker build <каталогспроектом>, то он получит свежий контейнер своего приложения, основанный на свежей версии вашего базового образа. Со всеми секьюрити патчами, без собственной секьюрити-тим, совершенно без всяких лишних телодвижений. И запускают свой софт у себя на машине в нормальном окружении — за секунды. Удобно всем.
Огород из костылей — это примитивный шелл-скрипт из нескольких вызовов docker build, чтобы собрать все приложения. А если есть continuous integration, то и вообще ничего делать не надо — коммитите новую версию базовой ОС в docker-репозитарий и откидываетесь на кресле.
apt-get upgrade не создаёт state, он делается на этапе создания контейнера, а не в рантайме. У вас просто получается новая версия контейнера — она у вас потом автоматически тестируется на CI, и если что-то не взлетает, то проблема уже решается по мере поступления.
Без докера у вас будут ровно те же самые проблемы — сделали apt-get upgrade на боевом сервере и внезапно сломалось приложение (у меня такое было — perl 5.20 поставился — и всё рухнуло — оказалось, что код, скопмилированный и предкешированный на диске от Inline::C стал несовместим с новой версией). Были бы контейнеры, это бы всё поймалось на тестовых серверах.
пересборка контейнера подразумевает обновление установленного в нём софта, правку конфигов, разрешение конфликтов
Так точно. У вас базовый образ может быть ваша безопасная ОС, в Dockerfile пишется ADD /ваш/уникальный/конфиг, и запуск docker build на основе свежей версии ОС добавит тот же самый конфиг и соберёт новый образ. Понятно, что при обновлении ОС может формат конфига поменяться, но вы это легко заметите на стейджинге, если у вас что-то не поднимется. По-любому та же самая проблема есть при любом способе развёртывания.
их перезапуск — штука достаточно дорогостоящая (в плане ресурсов, производительности, etc.)
Ну а если вы обновляете libssl или ещё какую библиотеку (и тем более ядро), всё равно же перезапускать надо программу, вне зависимости от того, докер это или не докер.
он получит доступ к тому (базы/сети), к чему есть доступ у работающего в контейнере сервиса.
Угу. Кстати, если приложению они не нужны, в контейнер совсем не обязательно складывать bash, ps, ssh, scp и прочие полезные для злоумышленника штуки. У меня большая часть приложений в контейнерах написана на компилируемых языках. В контейнере лежит несколько so-шников от libc и бинарник с программой, а то и вообще один бинарник, слинкованный статически. Даже если хакер найдёт способ исполнить произвольный код, ему нужно будет огромных размеров payload закачивать, чтобы что-то вредное сделать.
Дальше — каталог с данными остаётся на хосте, контейнер с postgres подключает этот каталог как volume. Зачем тут нужен докер? Чтобы иметь железобетонные гарантии точного соответствия окружения в dev и production средах. Если надо мигрировать базу данных на другой хост, всё становится сложнее — докер чудес не добавляет. Можно сделать сетевое распределённое хранилище, можно при развёртывании контейнера реплицировать данные на локальную машину, тут много вариантов.
Пересборка контейнера — это запуск docker build. Обновление тысяч контейнеров по всему парку машин можно сделать одной командой, если использовать систему для оркестрации типа Kubernetes. Вы не делаете перезапуск вручную — вместо этого система автоматически в нужной последовательности: 1. запустит новый контейнер, 2. убедится, что он успешно поднялся, 3. добавит его в кластер, т.е. направит на него трафик, 4. снимет трафик с старого контейнера, 5. убьёт его. Перезапуск машин (для обновления ядра, например) делается совершенно аналогично — запускаются новые копии всех контейнеров, которые работают на машине, где-нибудь в другом месте; трафик направляется на новую машину, снимается со старой, машина перезапускается и возвращается в строй обратно.
Насколько я знаю, сейчас в коде ядра сам по себе рут практически не даёт никаких привилегий — всё настраивается через capabilities. Рут, который в докере, именно что урезанный, без capabilities. Т.е. UID 0 даёт возможность любой файл читать (из доступных в контейнере), открывать любые порты (но только на виртуальном интерфейсе, который в контейнере есть), но ни обратиться к устройствам, ни сделать ещё какую пакость, он не может.
Самое интересное начнется, если вы из прототипа будете делать игру. Внезапно окажется, что игровой логики станет столько, что при онлайне в 50 человек одного ядра процессора перестанет хватать, и захочется не только оторвать бизнес-логику от обработчиков вебсокетов, но и разделить ее на несколько серверов. Вот тогда будет настоящее бэкенд-проектирование.
Дальше заставляете программистов (диктатура операторов) использовать только ваш базовый образ и добавлять туда пакеты только через apt-get. В результате если разработчик вызовет у себя docker build <каталогспроектом>, то он получит свежий контейнер своего приложения, основанный на свежей версии вашего базового образа. Со всеми секьюрити патчами, без собственной секьюрити-тим, совершенно без всяких лишних телодвижений. И запускают свой софт у себя на машине в нормальном окружении — за секунды. Удобно всем.
Без докера у вас будут ровно те же самые проблемы — сделали apt-get upgrade на боевом сервере и внезапно сломалось приложение (у меня такое было — perl 5.20 поставился — и всё рухнуло — оказалось, что код, скопмилированный и предкешированный на диске от Inline::C стал несовместим с новой версией). Были бы контейнеры, это бы всё поймалось на тестовых серверах.
Так точно. У вас базовый образ может быть ваша безопасная ОС, в Dockerfile пишется ADD /ваш/уникальный/конфиг, и запуск docker build на основе свежей версии ОС добавит тот же самый конфиг и соберёт новый образ. Понятно, что при обновлении ОС может формат конфига поменяться, но вы это легко заметите на стейджинге, если у вас что-то не поднимется. По-любому та же самая проблема есть при любом способе развёртывания.
Ну а если вы обновляете libssl или ещё какую библиотеку (и тем более ядро), всё равно же перезапускать надо программу, вне зависимости от того, докер это или не докер.
Угу. Кстати, если приложению они не нужны, в контейнер совсем не обязательно складывать bash, ps, ssh, scp и прочие полезные для злоумышленника штуки. У меня большая часть приложений в контейнерах написана на компилируемых языках. В контейнере лежит несколько so-шников от libc и бинарник с программой, а то и вообще один бинарник, слинкованный статически. Даже если хакер найдёт способ исполнить произвольный код, ему нужно будет огромных размеров payload закачивать, чтобы что-то вредное сделать.
Насколько я знаю, сейчас в коде ядра сам по себе рут практически не даёт никаких привилегий — всё настраивается через capabilities. Рут, который в докере, именно что урезанный, без capabilities. Т.е. UID 0 даёт возможность любой файл читать (из доступных в контейнере), открывать любые порты (но только на виртуальном интерфейсе, который в контейнере есть), но ни обратиться к устройствам, ни сделать ещё какую пакость, он не может.