LINUX.ORG.RU

Docker. Собственные образы или готовые?

 


0

3

Граждане, обсудите, пожалуйста, свои взгляды на следующую дилемму: создавать собственные образы на основе самых базовых (Debian или Alpine, например) или брать уже готовые для развертывания существующих, широко используемых приложений?

Например, стоит ли делать свои образы для Nginx/PostgreSQL и т.д.? Я предпочитаю делать свои, это дает возможность отслеживать, что там используется в качестве базового образа, нет лишних сущностей, которые вдруг могут приехать. Но, получается, могут быть какие-то ошибки с точки зрения конфигурации, и тратится больше времени (свои образы надо поддерживать и обновлять).

А что делает лоровец?

Заранее спасибо.

Озвучивает задачу целиком, формулирует threat model, только потом очерчивает trusted code base, делает выводы, не создаёт ниочемных тем.

t184256 ★★★★★ ()

Поиграть в вм на локалхосте - готовые. В прод - только собственные, чтобы не было сурпризов и задних дверей.

slowpony ★★★★ ()

всё зависит от поставщика контейнеров. Если это условные Nginx/PostgreSQL, то есть классные публичные ребята, которых я люблю, то я доверяю этим ребятам и использую то, что они собирают. Если это контейнер «васяна из интернета», либо кампания, к которой у меня нет доверия, то собираю свой по аналогии.

v9lij ★★★★★ ()

а что тебе мешает брать готовые и менять как нужно докер-файлы ?

Jopich1 ()
Последнее исправление: Jopich1 (всего исправлений: 1 )

Разумеется, готовые. Из регистра Red Hat, например.

i586 ★★★★ ()

Вот обидится автор образа и удалит его нафиг из реестра. А у вас из-за этого продакшен ляжет. Оно вам надо? Только собственные образы.

ugoday ★★★★★ ()
Ответ на: комментарий от slovazap

А если надо сделать балансировку нагрузки и поднять штук 20 инстансов одного приложения, то будет 20 виртуалок запущено и в отдельной 21-й виртуалке - балансировщик?

dimuska139 ★★ ()
Ответ на: комментарий от slovazap

А как тогда быть? Как запустить 20 инстансов одного приложения? На разных портах запустить каждое и настроить Nginx? Если да, то это ж такое себе, потому что это даже в том же docker-compose через scale делается в разы проще.

dimuska139 ★★ ()
Ответ на: комментарий от dimuska139

Ну у нас, например, не пишут на всяком однопоточном говне, поэтому приложения сами по себе масштабируются используя все ресурсы хоста, при этом не больше одного раза. А так есть более адекватные варианты вместо этого докерского пердолинга с портами, например вешать на v6 адреса, там ещё и anycast работает. А так системе оркестрации пофиг порты там или адреса - нарежет и запустит.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

Какое-то странное утверждение насчёт однопоточного говна. Вы хотите сказать, что приложение на JAVA/#C/Go не масштабируют? Масштабируют. И потоки там есть при этом.

dimuska139 ★★ ()
Ответ на: комментарий от dimuska139

Ну так и зачем их тогда запускать несколько на одной физической машине? А когда не нужно то и с портами не нужно пердолиться. Сервис запускается на своих машинах на своём порту.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

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

Если «не больше одного раза», то это не имеет ничего общего с горизонтальным масштабированием. Масштабирование - это когда к приложению добавляют новые дополнительные узлы для повышения общей производительности. То есть это может происходить как на одной машине, так и на нескольких. В случае JAVA, возможно, и есть смысл по разным машинам разносить, т.к. потоки есть, и они по ядрам могут распределяться - можно и один инстанс на машине держать, все ресурсы будут использоваться. Но тем не менее JAVA-приложения тоже масштабируют, поднимая новые инстансы, пусть и на других машинах. JAVA тоже, кстати, в Docker-контейнерах используют, но для чего именно - не знаю, это больше админ-девопский вопрос.

dimuska139 ★★ ()
Последнее исправление: dimuska139 (всего исправлений: 1 )
Ответ на: комментарий от dimuska139

Если «не больше одного раза», то это не имеет ничего общего с горизонтальным масштабированием. Масштабирование - это когда к приложению добавляют новые дополнительные узлы для повышения общей производительности. То есть это может происходить как на одной машине, так и на нескольких. В случае JAVA, возможно, и есть смысл по разным машинам разносить, т.к. потоки есть, и они по ядрам могут распределяться. Но тем не менее JAVA-приложения тоже масштабируют, поднимая новые инстансы, пусть и на других машинах. JAVA тоже, кстати, в Docker-контейнерах используют, но для чего именно - не знаю, это больше админ-девопский вопрос.

Не представляю что ты хотел сказать этим набором слов, но повторю ещё раз: на одной машине запускать несколько копий приложения - это впустую тратить ресурсы, и может понадобиться только если приложение - кусок говна не умеющий в многопоточность. Я с такими не работал. На много машин любое приложение масштабируется совершенно прозрачно. Докер не нужен ни в одном случае.

slovazap ★★★★★ ()

с сайта NixOS: minimal docker images и в заголовочном : alpine-redis= 7Mb, nix-redis=45.4 Mb, nix-redis-minimal: 2.02 Mb (yay, меньше чем alpine)

у меня только один вопрос: а под десяточку с WSL так можно или там только паравиртуализованный лицензионный Microsoft Debian ?

anonymous ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.