Комментарии 16
с появлением компактного девайса с arm64 и 4 Гб ОЗУ
что за девайс?
Автору за отвагу и достигнутый результат, несомненно, плюсик, но зачем sshd внутри контейнера?.. Ну и делать docker-контейнер на debian (даже не -slim версии), с установкой внутрь него и vim, который был нужен один раз, и flask, который в итоге оказался не нужен... (в питоновской части тоже наверняка можно более минимальным вариантом ограничиться, но тут я не специалист) - это вот вообще не best practice. Контейнер должен быть минимальным. А потом ещё про его обновление подумать бы...
Контейнер можно использовать для масштабирования сервисов, а можно - как аналог виртуалки.
Вот в данном случае это и есть виртуалка - быстро создается, и сравнительно безопасно - можно понаустанавливать всяких программ, не рискуя снести рабочую систему. Накосячил - удалить образ и создать заново.
Поэтому и ssh, чтобы подключаться напрямую, и vim, чтобы был нормальный редактор.
Насчет flack вообще не в курсе, но так показалось что uwsgi именно его использует внутри себя. Но я python не знаю ))
Как аналог виртуалки обычно используют LXC, но хозяин - барин :) В любом случае поднимать внутри контейнера SSH несколько бессмысленно, т.к. можно просто вызвать "docker exec -it my_container /bin/sh". А так Вы пробросили SSH (да ещё и с рутом и парольным доступом) в контейнер, который собран руками и в нём даже критичные обновления безопасности устанавливаться не будут, пока Вы его вручную не пересоберёте.
Совершенно верно. Потому что стоит это физически в отдельном удаленном помещении, в отдельной сети, и для того чтобы можно было загрузить туда какой-нибудь файл теперь достаточно простого scp filename servername, а не плясок с бубном с заходами в ОС самого девайса.
Поскольку это у нас контейнер - не вижу принципиальной разницы между рутом в контейнере и юзером в этом же контейнере - и тот и другой могут при проникновении злоумышленника что-нибудь напортить, но и того и другого можно так же снести вместе с зараженным контейнером из базовой ОС, и восстановить из сохраненной копии.
А вот автообновления, даже критические - это зло, которое хуже чем вообще ничего не обновлять. Не должно оно САМО обновляться, иначе вас рано или поздно ждет сюрприз "у нас почему-то всё сломалось!!!111"
А вот автообновления, даже критические - это зло, которое хуже чем вообще ничего не обновлять.
Смелое утверждение. Конечно, лучше иметь тестовый контур, на котором предварительно раскатываются обновления и тестируется, что ничего не сломалось. Но это такое дорогое удовольствие и по времени, и по деньгам, поэтому если пара часов простоя не критичны - Debian stable / Ubuntu LTS с unattended-upgrades вполне себе компромисс. У меня годами так две дюжины серверов автообновляются, инциденты были единичными и для меня приемлемыми. Да и даже апгрейд на новый релиз (это уже вручную, само собой) редко что-то ломает.
а можно - как аналог виртуалки.
Нельзя. Потому, контейнеры для сервисов - это кусок архитектуры. Достаточно задаться вопросами: что произойдет если pid 1 (а его назначаете вы, при билде) в контейнере завершит работу (или умрет), что произойдет с вашим vim\ssh-соединением и прочим софтом
и что страшного? Оно вылетит. У вас никогда компьютер не выключался по питанию?
Вот, практический эксперимент буквально онлайн:
Захожу, PID 1 = /etc/startup, скрипт висит за счет sshd -D.
Убиваю sshd - всё, скрипт завершился, контейнер вырубился.
Что критичного произошло?
Во-первых, его можно перезапустить снаружи.
Во-вторых, можно завернуть sshd в бесконечный цикл while...
Просто тут контейнер используется не для запуска сервиса, а для запуска рабочей среды для программирования и отладки, вот и вся разница.
Правильнее назвать это "песочницей"
Убиваю sshd - всё, скрипт завершился, контейнер вырубился.
Что критичного произошло? Во-первых, его можно перезапустить снаружи.
Вы ответили на первую половину вопроса, но проигнорировали вторую:
...произойдет с вашим vim\ssh-соединением и прочим софтом
Ответ банален - он умрет. Все еще не видите проблемы? Давайте чтобы было понятнее рассмотрим через призму "У вас никогда компьютер не выключался по питанию?" Итак у вас есть ПК который при старте запускает ну... скажем word и при закрытии окна выключается. Когда это будет удобно? Когда вы писатель и кроме ворда ничем не пользуетесь - включил ПК, набрал текст, закрыл окно - все. Даже больше, система мониторит процесс ворда, и если он завис, система сама перезапустит весь ПК - вот это вот из перовой линии поддержки "перегрузите ПК".
Но вам лично мало ворда и накатываете внутрь Акцесс (БД), Эксель, почту и еще файловую шару делаете. И тут вы получаете оооогромный пучек проблем:
Во-первых, если кто-то писал в БД\файловую шару, а вы закрыли ворд, то что произойдет с остальными процессами? kill -9? а данные? Восстанавливали когда-нибудь поломанные БД? Отличный опыт (не для прода). Что произойдет если процессы подняты, как нормальные сервисы (или отдельные контейнеры) - kill 15, т.е. процессы могут спокойно записать данные, закрыть транзакции, соединения и спокойно умереть. И даже больше, если у вас упал любой сервис, можно написать обработчик ошибок, ну там не знаю "БД упала, пишем в текстовые файлики" или nginx отвалился - вот вам заглушка.
Во-вторых, мониторинг. У вас докер (или подман, или куб) мониторят этот самый pid 1, окей, допустим это сферический идеальный цикл. Но другие сервисы внутри контейнера берут и падают. Докер про них ничего не знает, по этому вы вкорячиваете туда агента мониторинга. Допустим monit - маленький, легкий, сам рестартит сервисы. И тут получается "отличная" история- ваши сервисами управляют аж две системы мониторинга. KISS нервно курит в сторонке
Есть еще пучек проблем типа распределения ресурсов, доступов (это вроде победили, но осадочек остался). В общем, перечисленные проблемы должны сказать вам что забивать гвозди микроскопом конечно можно, но нах*я зачем если есть молоток?
Посмотрите в сторону Alpine Linux, для докера на Arm отлично подойдет. Маленький шустрый дистрибутив.
Контейнер должен быть минимальным.
Как тебе такое Илон Маск?
REPOSITORY TAG IMAGE ID CREATED SIZE
build/trassir-daemon-cuda11.1 4.5.24.0-1232707-Release 695927c06b84 6 weeks ago 22.1GBОфициальная сборка системы видеонаблюдения (все по трассировским инструкциям). Про compose они видимо не слышали
у меня 2.3GB получилось ...
со всеми лишними пакетами. Есть куда расти ))
У меня 2.3GB получилось, со всеми лишними пакетами. Есть куда расти ))
Ааа!... :) Таких монстров не встречал в природе. Но вот полно любителей запихать в свой образ контейнера какой-нибудь nginx замшелой версии исключительно как reverse proxy, добавляющий HTTPS, и пофигу, что у меня свой nginx для этой задачи вообще на отдельной машине... бесят.
Улучшаем систему видеонаблюдения, ч.2