Комментарии 37
Не вижу проблем в больших базовых образах. Слои переиспользуются и редко меняются. Но чисто ради спортивного интереса — почему бы и нет
Особенно, если вас 400 человек в одном помещении и все пытаются пропихнуть гигабайты :)
Слои базового образа скачаются только 1 раз для 1 ноды. В дальнейшем они не будут скачиваться, пока их хеш не изменится. А он не изменится, если ты не сделаешь изменений в базовом образе
Но вот прихожу я на мероприятие. У меня уже скачан Python:3.6. Команда такая — а мы всё на ноде делаем. И я начинаю качать гигабайт с небольшим ноды.
Я говорю — делаем всё как взрослые, с БД. Вся остальная команда начинает качать Postgress.
Отлично, все всё скачали, началась работа. Первый билд… Собрали. Кто-то запушил в докер регистри. Ждёт, пока гигабайт уедет.
Что-то поменяли — снова пуш — снова ожидание. Если в команде есть художники или непрограммисты, которые сами не собирают — они каждый раз будут с регистри выкачивать актуальный 1,5 ГБ готовый образ с приложением.
В результате, что вафля, что 3g/4g в этой локации в этот момент времени подаёт признаки издыхающего ленивца.
А потом вы делаете аналог proxy_pass в nginx и ваш сервис ломается, потому что нет ни одного корневого сертификата, а вам нужен https. Базовые образы не просто так придуманы
На докер хабе образы в сжатом виде лежат. Опцию --compress используют?
И слои нового базового образа тоже скачаются только 1 раз! Причем только те слои, которые изменились. И при запуске контейнер не займет места весом в образ. И при масштабировании тоже. Место займут только изменения в фс в рантайме
Если эта статья в контексте какого-то соревнования по мегабайтам, то конечно я не прав. Но выглядит как без контекста. Т.е., ничего страшного в этом нет
если вы запретите обновлять хеш базового образа при создании своих. И я даже не хочу представлять последствия такого решения.ну вообще полезно этим заняться, только с другой стороны: своевременно везде обновлять базовый образ, чтобы уязвимости закрывать. Это та же проблема, и также решается — настройкой сборки, выносом версий базовых образов куда-то в глобальное место, и т.д.
Постоянно все редеплоитьмы тут контейнеры вроде как обсуждаем, а для них это — нормальная жизненная ситуация. Если вы используете контейнеры, но для вас это выглядит ненормальным — это вопрос к вашим процессам видимо.
Согласен с предыдущим коментатором, что образы многократно используются и поэтому не создают проблемы при запуске большого количества контейнеров, но все равно, образ веб-сервера размером 6k — это потрясающе :)
Почему же они не применяются для микроверсисов?
Подозреваю, что сам по себе http сервер никому не интересно.
Я даже готов согласиться с вами что «Он не зависнет» в будущем. Но отрицать свой собственный опыт не стану.
То есть, проблема скорее в самом софте, а не в микроконтроллере. Я об этом.
А вообще попахивает DevOps-демосценой )
Что за правило Мареко?
- Зайди на hacker news
- Найди понравившуюся статью
- Переведи
- Filler-контент для корпоративного блога на эту неделю сгенерирован
https://github.com/vincenthsu/nweb/blob/master/nweb23.c
лёгкий и удобный, для меня, сервер.
Просто бинарник задеплоить совсем никак? Надо обязательно образ использовать?
Слабо поднять такой крошечный контейнер? Создаем контейнеризованный HTTP-сервер на 6kB