Энтерпрайзное контейнеростроение
https://www.redhat.com/en/blog/working-linux-containers-rhel-8-podman-image-builder-and-web-console
RH продвигает NIH-вариант докера под названием podman, а также NIH-вариант прометеуса под названием pcp. Ну и надрачивают на OCI/Open Containers Initiative.
1. Осталось придумать, как это всё сделать менее энтерпрайзанутым и более соответствующим идеологии моего vz. Первые позывы - оставить runc и systemd юниты, как планировалось. А podman использовать как мост между докером и OCI.
2. Чтобы 2 раза не вставать - обнаружил вариант runc на расте вместо го (разумеется этого поделия в центосе нет, так что нахуй). Но он не работает в i686 из-за непереносимого кода. Впрочем, мне не особо нужна i686, просто так было сделано с 6-м центосом. Идея не рыпаться и продолжать собирать имиджи на archlinux86.
3. Обнаружил, что runc умеет создавать config.json. Но там 177 строк, карл. В-основном указание на то какой фрагмент dev монтировать в контейнер. Напомнило дефолтовые таблицы в MSI.
3а. Помимо бойлерплейта - это очевидная поверхность для атаки. Ну то есть атака на репу с неподписанными имиджами позволяет подменить контейнер на дырявый и получить рута на кластере. Ну то есть контейнер рантайм должен проверять что сеттинги не дырявые, но тут пространство для ошибок, по сравнению с вариантом "дефолтовые пуленепробиваемые сеттинги зашиты в рантайм, а имидж только указывает дельту".
4. В pcp понравилась их идея делать удалённые версии коммандлайновых тулзов типа ps. Но они опять же делали это "вообще без секурности" по традиции SNMP, а потом кое-как накрутили TLS.
5. В создании имиджей вспомнил свою проблему - у меня вот есть базовый имидж, в котором нихуя нет, кроме куска ноды, и мне надо сделать Dockerfile, который туда положит мои сорцы с правильными пермишенами. Проблема в том что через ADD это делать не получается. Альтернатива лепить busybox мне не очень нравится, ибо разрушает идеологическую чистоту имиджа.
6. Из EPEL пропал trac. Вопрос какие теперь есть варианты, если мне ну очень хочется поставить трак на CentOS8. Для другого проекта использую mercurial-server. Его тоже нет.
7. В винде теперь штатно есть ssh-клиент из openssh, но он неюзабельный, так как нет мыши, в отличие от PuTTY. Но как emergency годится, багов не замечено.
8. Есть особое приседание, чтобы положить публичный ключ из pageant на хост. Для этого надо зайти на промежуточный хост поставив в PuTTY галку "enable agent forwarding", и оттуда сделать ssh-copy-id на целевой хост. Недостаток, понятно, что может положить больше ключей, чем нужно.
9. Начал курить OpenShift. Подозрение что оно там столь же энтерпрайзанутое, как OpenStack и Kubernetes. Что в моём понимании в-основном означает ненужную поверхность атаки с объяснением "у нас же SSL!!111" и высокие системные требования ввиду ориентированности на целые сервера вместо VPS - то есть объяснение "гиг сюда гиг туда похуй ибо 128 гб сервера по цене грязи".
10. Обнаружил тут minikube. Но там тоже 2GB+. Как они это делают?
11. Обнаружил что RH купила CoreOS, а также что шапошники делают RHCOS - CoreOS на основе rpm-ostree.
12. Дока по OpenShift использует хороший термин "control plane". То есть, можно говорить всем, что vz - это OpenShift для систем без control plane, где единственный control plane agent это sshd, и весь цикл provision-development-management выполняется человеком через Ansible, не используя никаких соединений кроме, SSH
13. etcd по-прежнему с нами - то есть OpenShift это энтерпрайз кореос. Что в сочетании с предыдущими пунктами делает невозможным использование его мной, надо раз-энтерпрайзить и засекьюрить.
14. Reverting your cluster to a previous version, or a rollback, is not supported. Блядь вы это серьезно?
15. Чтение спецификации https://github.com/opencontainers/image-spec/blob/master/layer.md#whiteouts вызывает у меня головную боль. Тем более, что они всё равно полагаются на tar. Соответственно, остановлюсь на своём говно-решении tar + vcdiff. См. тж. крики в https://github.com/opencontainers/image-spec/issues/24
16. Ещё из рубрики "блядь вы это серьёзно?". Dockerfile поддерживает сборку имиджей в несколько этапов: мы запускаем билд-скрипт нашего приложение в контейнере. Затем из этого контейнера копируем только нужные билд-продукты в новый контейнер. Так вот, держитесь:
---
The COPY instruction copies new files from and
adds them to the filesystem of the container at path .
... All new files and directories are created with mode 0755
and with the uid and gid of 0.
---
Ну то есть в целевом контейнере мы либо забиваем на пермишены, либо держим "чмод", что и раздувает контейнер, и error prone, что в свою очередь дискредитирует всю идею многоэтапных билдов.
RH продвигает NIH-вариант докера под названием podman, а также NIH-вариант прометеуса под названием pcp. Ну и надрачивают на OCI/Open Containers Initiative.
1. Осталось придумать, как это всё сделать менее энтерпрайзанутым и более соответствующим идеологии моего vz. Первые позывы - оставить runc и systemd юниты, как планировалось. А podman использовать как мост между докером и OCI.
2. Чтобы 2 раза не вставать - обнаружил вариант runc на расте вместо го (разумеется этого поделия в центосе нет, так что нахуй). Но он не работает в i686 из-за непереносимого кода. Впрочем, мне не особо нужна i686, просто так было сделано с 6-м центосом. Идея не рыпаться и продолжать собирать имиджи на archlinux86.
3. Обнаружил, что runc умеет создавать config.json. Но там 177 строк, карл. В-основном указание на то какой фрагмент dev монтировать в контейнер. Напомнило дефолтовые таблицы в MSI.
3а. Помимо бойлерплейта - это очевидная поверхность для атаки. Ну то есть атака на репу с неподписанными имиджами позволяет подменить контейнер на дырявый и получить рута на кластере. Ну то есть контейнер рантайм должен проверять что сеттинги не дырявые, но тут пространство для ошибок, по сравнению с вариантом "дефолтовые пуленепробиваемые сеттинги зашиты в рантайм, а имидж только указывает дельту".
4. В pcp понравилась их идея делать удалённые версии коммандлайновых тулзов типа ps. Но они опять же делали это "вообще без секурности" по традиции SNMP, а потом кое-как накрутили TLS.
5. В создании имиджей вспомнил свою проблему - у меня вот есть базовый имидж, в котором нихуя нет, кроме куска ноды, и мне надо сделать Dockerfile, который туда положит мои сорцы с правильными пермишенами. Проблема в том что через ADD это делать не получается. Альтернатива лепить busybox мне не очень нравится, ибо разрушает идеологическую чистоту имиджа.
6. Из EPEL пропал trac. Вопрос какие теперь есть варианты, если мне ну очень хочется поставить трак на CentOS8. Для другого проекта использую mercurial-server. Его тоже нет.
7. В винде теперь штатно есть ssh-клиент из openssh, но он неюзабельный, так как нет мыши, в отличие от PuTTY. Но как emergency годится, багов не замечено.
8. Есть особое приседание, чтобы положить публичный ключ из pageant на хост. Для этого надо зайти на промежуточный хост поставив в PuTTY галку "enable agent forwarding", и оттуда сделать ssh-copy-id на целевой хост. Недостаток, понятно, что может положить больше ключей, чем нужно.
9. Начал курить OpenShift. Подозрение что оно там столь же энтерпрайзанутое, как OpenStack и Kubernetes. Что в моём понимании в-основном означает ненужную поверхность атаки с объяснением "у нас же SSL!!111" и высокие системные требования ввиду ориентированности на целые сервера вместо VPS - то есть объяснение "гиг сюда гиг туда похуй ибо 128 гб сервера по цене грязи".
10. Обнаружил тут minikube. Но там тоже 2GB+. Как они это делают?
11. Обнаружил что RH купила CoreOS, а также что шапошники делают RHCOS - CoreOS на основе rpm-ostree.
12. Дока по OpenShift использует хороший термин "control plane". То есть, можно говорить всем, что vz - это OpenShift для систем без control plane, где единственный control plane agent это sshd, и весь цикл provision-development-management выполняется человеком через Ansible, не используя никаких соединений кроме, SSH
13. etcd по-прежнему с нами - то есть OpenShift это энтерпрайз кореос. Что в сочетании с предыдущими пунктами делает невозможным использование его мной, надо раз-энтерпрайзить и засекьюрить.
14. Reverting your cluster to a previous version, or a rollback, is not supported. Блядь вы это серьезно?
15. Чтение спецификации https://github.com/opencontainers/image-spec/blob/master/layer.md#whiteouts вызывает у меня головную боль. Тем более, что они всё равно полагаются на tar. Соответственно, остановлюсь на своём говно-решении tar + vcdiff. См. тж. крики в https://github.com/opencontainers/image-spec/issues/24
16. Ещё из рубрики "блядь вы это серьёзно?". Dockerfile поддерживает сборку имиджей в несколько этапов: мы запускаем билд-скрипт нашего приложение в контейнере. Затем из этого контейнера копируем только нужные билд-продукты в новый контейнер. Так вот, держитесь:
---
The COPY instruction copies new files from and
adds them to the filesystem of the container at path .
... All new files and directories are created with mode 0755
and with the uid and gid of 0.
---
Ну то есть в целевом контейнере мы либо забиваем на пермишены, либо держим "чмод", что и раздувает контейнер, и error prone, что в свою очередь дискредитирует всю идею многоэтапных билдов.