Правильно понимаю, что coreOS, это в стиле alpine linux?

нет.

Alpine используется как система внутри образов контейнеров, а CoreOS - это та система, из которой контейнеры запускаются

ну, alpine можно и снаружи использовать. Фишка alpine - размер, безопасность, удобный пакетный менеджер СО ВСЕГДА СВЕЖИМИ пакетами. А не то, что в убунте и центоси

кореос - это про другое, это атомарно обновляемая ОСь, которая выступает хостом для контейнеров. Ключевое - атомарно. Поэтому пакетного менеджера и пр. в ней нет, да и не нужно оно.

главная фишка Alpine - образы контейнеров получаются маленькими) про безопасность и всегда свежие пакеты - это спорно) некоторые админы считают, что возможно только 1 из двух

в CoreOS, да, особенность в том, что нет пакетного менеджера, то есть использовать её саму внутри образа контейнера, наверное, было бы странно)

главная фишка Alpine - образы контейнеров получаются маленькими) про безопасность и всегда свежие пакеты - это спорно) некоторые админы считают, что возможно только 1 из двух

нихера

Чем больше пакетов ты ставишь в эльпайн, тем меньше выгода от убунту

ты хотя бы раз в нем устанавливал numpy, panda, scikit?

с одной стороны - да, эльпайн получается меньше, а с другой стороны - время компиляции этих пакетов в разы дольше, чем на бубунту

к сожалению

чудес не бывает

ну, вообще, питонячьи пакеты обычно ставятся через питонячьи менежеры пакетов

ну, вообще, питонячьи пакеты обычно ставятся через питонячьи менежеры пакетов

ну я про это же

ты делаешь pip install numpy. Он обнаруживает, что бинарных пакетов под эльпайн нет. Выкачивает все исходники, начинает компилировать. Здесь больше претензия к тому, что это попросту долго

ну, и то что я написал выше - чем больше ты устанавливаешь пакетов в эльпайн, то тем меньше выгода по размеру по сравнению с ubuntu

на Dockerhub'е обычно есть 2 версии образов - на Debian и на Alpine, основной критерий в пользу Alpine - меньший размер образа

даже если подчистить Debian, всё равно у Alpine'а образ будет меньше, это и был основной критерий, почему они делали образы контейнеров на Alpine'е

если не руководствоваться принципами "нужно минимизировать размер образа", то у Alpine'а реально нет преимуществ перед Debian'ом / Ubuntu, а так как последние популярнее, то и внимания к ним больше... что касается безопасности, то нельзя одновременно позиционировать дистрибутив как безопасный и как дистрибутив с новыми пакетами, тут просто 1 из 2, или так или так) безопасность Alpine'ы - это некий маркетинговый буллшит, её там нет, как раз по причине того, что пакеты новые нормальный подход - когда системные пакеты умеренно стабильные (как в Ubuntu LTS), а те либы, которые нужны для проекта, свежие, тех версий, которые нужны (опять же, если приложение на питоне - то через pip или pipenv ставятся новые версии или те, которые проекту нужны)

даже если подчистить Debian, всё равно у Alpine'а образ будет меньше, это и был основной критерий, почему они делали образы контейнеров на Alpine'е

несомненно.

еще раз - в базовых случаях - alpine меньше. Я не спорю.

Я тебе говорю о том, когда тебе нужно в образ засунуть вагон и маленькую тележку пакетов, то разницы по размеру alpine vs ubuntu нет

и, да, можно брать debian-slim, если хочется маленького размера

«безопасность Alpine'ы - это некий маркетинговый буллшит, её там нет, как раз по причине того, что пакеты новые» согласись, что чем меньше пакетов, то тем меньше векторов атаки

к тому же я верю, что те же разработчики буста (это библиотека для с++ - практически стандартная), например, не будут выкатывать говнорелизы

вообще история с релизами очень сложная, потому что недостаточно просто наваять новый релиз какого-то ПО. Его еще нужно проверить в разных окружениях. И хочется верить, что те же мейтейнеры дебиан и убунту это делают качественно. Хотя иногда у них случаются серьезные проколы то же

«безопасность Alpine'ы - это некий маркетинговый буллшит, её там нет, как раз по причине того, что пакеты новые» согласись, что чем меньше пакетов, то тем меньше векторов атаки

чтобы система стала небезопасной, достаточно найти 1 дыру в 1 пакете, безопасность - это не про количество пакетов, каждый из установленный пакетов должен быть достаточно стабильным, (если нужно пользователю - он может поставить самую новую версию, на свой страх и риск, я сейчас не про эти пакеты, которые нужны пользователю, а про все остальные, которые не так важны для целевого приложения внутри образа)

чтобы система стала небезопасной, достаточно найти 1 дыру в 1 пакете, безопасность - это не про количество пакетов, каждый из установленный пакетов должен быть достаточно стабильным, (если нужно пользователю - он может поставить самую новую версию, на свой страх и риск, я сейчас не про эти пакеты, которые нужны пользователю, а про все остальные, которые не так важны для целевого приложения внутри образа)

эм. Любая уязвимость может быть использована только в определенных условиях. Я уж не говорю про случаи, когда нужно несколько разных уязвимых пакетов.

https://habr.com/ru/post/415513/

просто оставлю это тут

чтобы система стала небезопасной, достаточно найти 1 дыру в 1 пакете, безопасность - это не про количество пакетов, каждый из установленный пакетов должен быть достаточно стабильным, (если нужно пользователю - он может поставить самую новую версию, на свой страх и риск, я сейчас не про эти пакеты, которые нужны пользователю, а про все остальные, которые не так важны для целевого приложения внутри образа)

т.е. предлагаешь не использовать alpine совсем? варианты?

т.е. предлагаешь не использовать alpine совсем? варианты?

ну, я ничего не предлагаю) я сам использую Alpine и именно потому что в моём случае размер образа меньше) если бы он не был бы меньше - я бы использовал минимальные образы Debian'а или Ubuntu

я говорю лишь о том, что если не рассматривать размер образа как преимущество, то других у Alpine Linux'а нет

тогда уж можно собирать from scratch 🙂

да, некоторые так делают

https://dzone.com/articles/minideb-a-minimalist-debian-based-docker-image

еще bitnami можно

да, некоторые так делают

для гошных бинарей - ок

вообще, сейчас тренды направлены в сторону serverless, там, где это возможно, конечно) то есть умы человечества думают над тем, как бы заменить образ контейнера на пачку serverless-функций на IaaS (Google Cloud Functions, AWS Lambda и другие), там где это возможно... думаю, вот эта тема с выбором лучшей ОС для образа контейнера немного задержалась на пару лет

то есть пару лет назад была актуальна CoreOS, люди сами ставили себе Kubernetes, сейчас на рынке уже много предложений, когда можно самому ничего не админить, а взять готовое (Digital Ocean, Google Cloud и другие предлагают Kubernetes как услугу), а дальше всё ведёт к тому, что уже и образы контейнеров надо будет собирать всё меньше, используя serverless там, где это возможно

сейчас потребность самому поднимать CoreOS, самому настраивать Kubernetes и что-то там админить есть только у крупных компаний, мелким проще взять Google Cloud или AWS, там и дешевле и быстрее

ну, ты не прав

есть еще регуляторные штуки. «мы не можем покупать облако у потенциальных врагов»

касательно FaaS - он реально сложен. Т.е. наговнякать код - проблем нет. Проблема его аккуратно вывести в продакшн. Там же все зависимости на уровне платформы остаются. Т.е. мы переносим сложность с одного уровня на другой. Я уж не говорю о том, что мониторить этот зоопарк становится страшно

действительно за этим будущее…. но нужны соответствующие технологии и инструменты

действительно за этим будущее…. но нужны соответствующие технологии и инструменты

AstraLinux? 😊

AstraLinux? 😊

чебурнет с чебоблаком

@ArtemBruchanov будет жить. Поприветствуем!

serg ryabukha будет жить. Поприветствуем!

@nord_x будет жить. Поприветствуем!

@vrutkovs будет жить. Поприветствуем!

Просто оставлю это здесь, для любителей протестировать новое: ostree remote add --set=gpg-verify=false fedora-coreos-ci https://ci.centos.org/artifacts/fedora-coreos/prod/repo/ && rpm-ostree rebase fedora-coreos-ci:fedora/29/x86_64/coreos && systemctl reboot

#whois Инженер в Red Hat, работаю над инсталлятором OpenShift - openshift-ansible, installer, metalkube и т.д.

#whois Инженер в Red Hat, работаю над инсталлятором OpenShift - openshift-ansible, installer, metalkube и т.д.

Вопрос: А существует ли Quay.io в опенсорсе? или он теперь только в составе openstack

Вопрос: А существует ли Quay.io в опенсорсе? или он теперь только в составе openstack

Еще не существует, но обещают скоро. Он будет в составе OpenShift Dedicated

не знаю что там в openstack

Привет. Кто знает, можно ли в cloud-config изменять тип файловой системы или это через ignition?

@corsars77 будет жить. Поприветствуем!

Hi !

Привет всем еще разок ! А простите куда делся docker system df ?

Привет всем еще разок ! А простите куда делся docker system df ?

щито это?

хотел посмотреть место свободное

ну а далее уже prune - почистить

что то синтактис отличается

ну я всегда руками смотрел

зачем в докере такая команда хз

mbp-gaal:~ gaal$ docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 7 2 1.184GB 1.016GB (85%) Containers 2 0 130B 130B (100%) Local Volumes 3 2 45.92MB 0B (0%) Build Cache 0 0 0B 0B

может от версии зависит

mbp-gaal:~ gaal$ docker version Client: Docker Engine - Community Version: 18.09.1 API version: 1.39 Go version: go1.10.6 Git commit: 4c52b90 Built: Wed Jan 9 19:33:12 2019 OS/Arch: darwin/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 18.09.1 API version: 1.39 (minimum version 1.12) Go version: go1.10.6 Git commit: 4c52b90 Built: Wed Jan 9 19:41:49 2019 OS/Arch: linux/amd64 Experimental: false

скорее всего у тебя более старый, да?

да я по старинке

точнее я все из старых перевожу в CoreOS

впечатлений море

и положительные

давай, накидывай еще.

а то !

помимо https://www.webhive.ru/2018/06/13/what-is-wrong-with-coreos/

да да 😉

все это детали которые решаеются

мне ее показали оппоненты Ubuntu 😉

которые даже не знают про транзакции в yum centos