Pull to refresh

Comments 37

Не вижу проблем в больших базовых образах. Слои переиспользуются и редко меняются. Но чисто ради спортивного интереса — почему бы и нет

Гонять гигабайты трафика между девмашиной, докер-регистри и демо/продмашинами — так себе удовольствие.
Особенно, если вас 400 человек в одном помещении и все пытаются пропихнуть гигабайты :)

Слои базового образа скачаются только 1 раз для 1 ноды. В дальнейшем они не будут скачиваться, пока их хеш не изменится. А он не изменится, если ты не сделаешь изменений в базовом образе

Понимаю это.
Но вот прихожу я на мероприятие. У меня уже скачан Python:3.6. Команда такая — а мы всё на ноде делаем. И я начинаю качать гигабайт с небольшим ноды.
Я говорю — делаем всё как взрослые, с БД. Вся остальная команда начинает качать Postgress.
Отлично, все всё скачали, началась работа. Первый билд… Собрали. Кто-то запушил в докер регистри. Ждёт, пока гигабайт уедет.
Что-то поменяли — снова пуш — снова ожидание. Если в команде есть художники или непрограммисты, которые сами не собирают — они каждый раз будут с регистри выкачивать актуальный 1,5 ГБ готовый образ с приложением.

В результате, что вафля, что 3g/4g в этой локации в этот момент времени подаёт признаки издыхающего ленивца.

А потом вы делаете аналог proxy_pass в nginx и ваш сервис ломается, потому что нет ни одного корневого сертификата, а вам нужен https. Базовые образы не просто так придуманы

Ну, надо разделять промышленную разработку и такие вот мероприятия, где есть цель выкатить прототип побыстрее и обогнать других NN команд. Там очень редко до https доходит, по моему опыту :)

Вот поэтому я и написал про спортивный интерес. Понятно, что нужно стремиться к уменьшению образа, но не ставить это в самый важный приоритет. Разница между 10 мб и 10 кб несущесттвенна, но она может избавить от большого количества проблем, о которых ты не подумал

На докер хабе образы в сжатом виде лежат. Опцию --compress используют?

UFO just landed and posted this here

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

если вы запретите обновлять хеш базового образа при создании своих. И я даже не хочу представлять последствия такого решения.
ну вообще полезно этим заняться, только с другой стороны: своевременно везде обновлять базовый образ, чтобы уязвимости закрывать. Это та же проблема, и также решается — настройкой сборки, выносом версий базовых образов куда-то в глобальное место, и т.д.
UFO just landed and posted this here
Передеплоить этот сервис, очевидно.
UFO just landed and posted this here
Постоянно все редеплоить
мы тут контейнеры вроде как обсуждаем, а для них это — нормальная жизненная ситуация. Если вы используете контейнеры, но для вас это выглядит ненормальным — это вопрос к вашим процессам видимо.
UFO just landed and posted this here
и если постоянно все редеплоить
эм, а вы их раз в год деплоите? Если это сервисы, которые не разрабатываются никем — ну грустно. Первые кандидаты на всякие уязвимости, если их никто не поддерживает и не накатывает секьюрити-апдейты.
UFO just landed and posted this here
Очень круто. Давно пользуюсь Docker, но про многоступенчаные сборки, например, даже не знал, спасибо.
Согласен с предыдущим коментатором, что образы многократно используются и поэтому не создают проблемы при запуске большого количества контейнеров, но все равно, образ веб-сервера размером 6k — это потрясающе :)
вопрос. есть веб-сервера на микроконтрллерах. Вроде написанны на чистом Си, а значит могут быть портированны…
Почему же они не применяются для микроверсисов?

Подозреваю, что сам по себе http сервер никому не интересно.

В микросервисах, «обычно», логика посложнее чем отдача статичных html)
Я где-то читал и лично сталкивался, что веб-сервера на микроконтроллерах ненадежны. Например, на ESP32, если во время выполнения запроса прилетает другой запрос, то микроконтроллер может запросто зависнуть.
В микроконтроллере мало памяти, заDOSить его значительно проще, чем сервер с 64 гигабайтами памяти.
Он не зависнет, он просто может отдавать очень ограниченное количество одновременных потоков (обычно исчисляется единицами), а на совсем простых вариантах вообще один поток только будет.
Знаете, очень сложно спорить с человеком, который имеет опыт. У меня он небольшой, но все же есть. И у меня МК зависал неоднократно при попытке одновременного обращение к веб серверу. Может быть, я еще что-то неправильно делал, я такое допускаю, но то, что МК зависал это точно.
Я даже готов согласиться с вами что «Он не зависнет» в будущем. Но отрицать свой собственный опыт не стану.
Я не ради спора. Даже охотно верю, что зависал. Я о другом: видимо, проблема с самим софтом. Может, просто слишком сырой http сервер или что-то типа этого. Просто сомневаюсь, что автор заложил функцию зависания при одновременном обращении.
То есть, проблема скорее в самом софте, а не в микроконтроллере. Я об этом.
Распространять свой неудачный опыт на всех и говорить «мк зависает при одновременных запросах» это плохая идея. Все равно что говорить «он зависает при включении холодильника рядом». На нормальных платах не зависает.
Если добавить к флагам линковки Go -s -w, а так же заюзать UPX с параметром --best, то можно еще раза в 2-4 уменьшить итоговый размер (у меня получилось 1.71 мб).
А вообще попахивает DevOps-демосценой )
  1. Зайди на hacker news
  2. Найди понравившуюся статью
  3. Переведи
  4. Filler-контент для корпоративного блога на эту неделю сгенерирован
Так можно про всё написать. Найди интересную тему -> напиши статью.
Просто не все читают все сайты в интернете. Есть люди, кто «hacker news» может не читать, а Хабр читает и будет интересно узнать что-то на эту тему.
Голосование к этой статье покажет интерес читателей.

Просто бинарник задеплоить совсем никак? Надо обязательно образ использовать?

Удачи вам с деплоем бинарника со всеми его зависимостями и depend-hell в современных линуксах. А если это не бинарник, а что-то скриптовое со своими либами и интерпретатором…
Слышали про статическую линковку?
Статическую линковку чего? Не библиотеками едиными живы зависимости. У вас бинарник может использовать кучу системного софта, например. Или не системного. Или внутри себя скриптовый язык гонять, вызывая внешний интерпретатор и бд. Вы все это хотите внутрь бинарника запихнуть?
Sign up to leave a comment.