RP
раньше докер был внутри Kubernetes как его часть, потом они его выпилили оттуда
Да, точно, я читал про podman! Но меня напрягает RedHat. Там всё по-другому. Оно на Debian/Ubuntu есть?
Size: a a a
2020 June 03
AO
Docker has raised a total of $307.9M in funding over 10 rounds. Their latest funding was raised on Nov 13, 2019
RP
и поэтому их Docker выпилили даже из Kubernetes в итоге
Раньше он был единственным и дефолтным. Потом кубы подросли и стали смотреть на контейнеры шире.
RP
Щас спокойно кубы с докером работают.
AO
Раньше он был единственным и дефолтным. Потом кубы подросли и стали смотреть на контейнеры шире.
да, он был самым громким, были и альтернативы частично, systemd-nspawn до сих пор есть, к нему был wrapper rkt, который закрылся как проект
AO
были и другие попытки сделать альтернативу
RP
Реестр образов от докера подходит к подману?
MB
lol, docker стал стандартом де-факто в мире контейнеров, сколько бы на него не жаловались. Если ваши приложения написаны следуя принципам 12 factor app и имеют понятный Dockerfile - переход на podman будет быстрый и безболезненный. Другой вопрос, что кажется в текущий момент логичней сидеть на docker
AO
у podman'а есть некоторые технические преимущества, выше я скинул ссылку на это
AO
Реестр образов от докера подходит к подману?
про Docker Hub ничего не знаю, наверное, никуда не переходит, он так и останется собственностью Docker'а
AO
но в каждой организации же свои обычно
RP
про Docker Hub ничего не знаю, наверное, никуда не переходит, он так и останется собственностью Docker'а
У меня свой реестр.
RP
у podman'а есть некоторые технические преимущества, выше я скинул ссылку на это
А чего не LXC?
AC
У меня есть джанго-приложениие с базой данных, так же есть парсер, который должен заливать информацию в эту базу данных.
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
RP
У меня есть джанго-приложениие с базой данных, так же есть парсер, который должен заливать информацию в эту базу данных.
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
Ответ: как тебе будет удобнее.
MB
У меня есть джанго-приложениие с базой данных, так же есть парсер, который должен заливать информацию в эту базу данных.
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
Вопрос: лучше использовать django-orm или использовать sql_alchemy для этого дела?
Кажется что орм будет проще, но оно плохо работает, когда парсер полностью отделён от самого джанго-приложения
Мб засунуть в Django проект? Могу ошибаться, но кажись так проще
AC
Мб засунуть в Django проект? Могу ошибаться, но кажись так проще
Согласен, но приложение хостится на хероку, а парсер сложно будет держать там же
AC
Ладно, буду юзаь алхимию
MB
Согласен, но приложение хостится на хероку, а парсер сложно будет держать там же
Почему? Какой-нибудь крон(плохо, но проще) или задачка на celery/dramatiq