«Контейнер изолирован» — фраза, которую повторяют на каждом собеседовании и которая сама по себе ни о чём не говорит. Изолирован от чего? Проверил на ALT Linux с podman и вот где проходит настоящая граница. Всё ниже — измерения на одной машине: 203 процесса на хосте, три лаборатории в /opt, веб-сервис на 8080 и sshd на 22. Процессы. В контейнере видно ровно его собственные: $ podman run --rm busybox ps PID USER TIME COMMAND 1 root 0:00 ps ← это сам ps, больше никого на хосте:...
Собрал первый образ на podman. Не на docker — на ALT Linux его в репозиториях нет, зато podman есть, и разница между ними обнаружилась уже на второй команде. Эта статья — про один вопрос: как взять текстовый файл и получить из него запускаемый образ. Без теории про слои на первой странице, только команды и то, что они напечатали. $ podman --version podman version 4.9.5 $ podman pull docker.io/library/busybox:latest Trying to pull docker.io/library/busybox:latest... Copying blob sha256:37bb94b0940b...
Инструкции в интернете начинаются с настройки: «откройте такой-то файл, поменяйте параметр». Это удобно ровно до момента, когда вы не знаете, что именно сломалось. А это самая частая ситуация на сервере — не «как настроить», а «почто перестало работать». Я сделал себе скрипт, который честно отвечает на второй вопрос. Он ничего не чинит. Он показывает, где плохо, и говорит, какой командой это проверить. $ sudo ./server-check.sh Нужен root: часть проверок (эффективные параметры sshd, содержимое shadow, правила iptables) без него не читается...
Есть скрипты настройки сервера. Написал один, отдал коллеге, он его запустил. Потом коллега запустил его ещё раз, потому что что-то забыл поправить. Конфиг превратился в: listen = 8080 workers = 4 admin_email = ops@example.local log_level = info admin_email = ops@example.local log_level = info admin_email = ops@example.local log_level = info Три копии. Скрипт же честно отработал, код возврата ноль, ошибок нет. Именно это и страшно: он выглядел как успешный, пока не открыли файл. Свойство, которого у скрипта не было, называется идемпотентность...
Я написал скрипт деплоя. Как и большинство таких скриптов — он копировал файлы, перезапускал службу и радостно рапортовал об успехе. А потом я сделал то, что никто не делает: намеренно сломал новую версию и посмотрел, что сделает скрипт. Скрипт сказал, что всё прошло. Сервис при этом был мёртв. Потому что скрипт не задавал себе вопрос «а работает ли оно теперь, или я просто красиво перезапустил». Он копировал файлы и рапортовал. Это и есть настоящая разница между «скопировать на сервер» и «задеплоить»...
«Диск заполнился, сервисы падают, что удалять?» — вопрос, в котором чаще всего совершают что-то необратимое. Обычно начинают с du по всему подряд и через десять минут удаляют что-нибудь не то. Порядок действий простой, и в конце есть одна ловушка, из-за которой место не освобождается, хотя файл удалён. $ df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda3 58G 6.1G 49G 12% / Смотрите на Avail, а не на Free. Свободное место «для root» и место для всех остальных — разные числа, и именно Avail покажет, когда обычный пользователь упрётся в стену...
