Comments 75
docker build --squash
Если не нравятся простыни, то можно вынести их в отдельный образ и залить на докерхаб)) И рабочий докерфайл будет более чистым.
Туда же https://bash.im/quote/394695
docs.docker.com/develop/develop-images/multistage-build
FROM ubuntu:latest
Использование тэгаlatestприводит к непредсказуемым последствиям.
а вот устанавливать пакеты последних версий это уже нормально, да?
apt-get -y install libpq-dev imagemagick gsfonts nodejs
Допустим, базовый образ у вас используется в 10 микросервисах. Как только вы делаете новую версию базового образа, вам сразу же надо перетестировать все 10 микросервисов.
Разумеется, после письменного уведомления.
Можно.
Но, по моему мнению, лучше донести до разработчиков необходимость и ценность своевременного обновления.
И это возможно, проверено))
Мне, не нравиться, любые механизмы, где что-либо происходит насильно.
Это по-человечески понятно, но иногда консенсус невозможен — у какой-то команды релиз, им какая-то вещь нужна ну прям счас, и непременно на этой версии, а на апгрейд времени нет. И не было. Может, в конце года, после запуска. И вообще, у них приоритеты, что вы тут со своими апгрейдами, мы тут прибыль делаем (и дальше по списку).
Кстати, почитайте про liberum veto, к слову. Для общего, так сказать, развития.
Кажется, докеру тоже нужны свои лок-файлы...
Блин, я вот читаю такие статьи и вспоминаю, что совсем недавно вот совсем совсем недавно говорили, что цепочки вызовов команд это плохо, потому что это всё рассчитано только на успешный путь выполнения и для конфигурации системы нужно использовать ansible и идемпотентные скрипты декларативного характера.
И тут опять шелл скрипт для конфигурации системы, только в докере. Что же с нами стало? Как так вышло то? Почему это опять хорошо?
История циклична. Уверен, рано или поздно придумают "ansible для Dockerfile":)
Спасибо. Прикольно. Интересно, надо будет попробовать и протестировать.
Оказалось, он уже депрекейт. А на смену ему пришел: https://github.com/ansible-community/ansible-bender
А тут разные ниши — Docker предполагает сборку нового артефакта, а не изменение существующего сервиса. Если что-то в цепочке падает — это повод сборке немедленно остановиться, заорать и заставить пересмотреть процесс сборки до того, как этот артефакт будет выкачен.
Можно конкретный пример, как правильный Ansible помог бы отдебажить такой плавающий баг в сравнении с правильным Docker-ом?
И "перезапустить, а потом проверять" — это правильный подход. Сначала быстро решить проблему с лежащим сервисов, потом копать причину.
Можно пример бага, пожалуйста?
Как ансибл бы решил проблему с битым пакетом в одном из зеркал?
Что значит "не успевал вытянуть зависимость" — у вас ограничение по времени на сборку докера? Или (фу-фу) зависимости подтягиваются в момент запуска контейнера? Как Ansible решил бы аналогичную проблему?
Ну вот в корневом комментарии противопоставляют Docker и Ansible — что-де опять шелл-скрипты вместо идемпотентого Ansible.
Вопрос в том, зачем здесь идемпотентность и логируемость и как она в конкретном случае иммутабельного артефакта, собираемого на CI, помогает решить проблему.
Пока ветка выглядит примерно так:
- Ansible лучше
- чем лучше?
- чем Docker
Не надо так.
По мне, тут вопрос не в том, что лучше ansible или Docker.
Это, все-таки разные инструменты. И вопрос, похож на: а что лучше помидоры или сотовый телефон.
Тут, идея, что bash портянки такое себе, и было бы круто собирать docker через yml.
было бы круто
Почему?
С мутабельными серверами и зоопарком систем — да, круто — не надо следить за исходным состоянием каждого индивидуального сервера.
Что даст дополнительный уровень абстракции в докерфайле, когда состояние гарантировано (если не делать глупости типа использования latest и apt-get update)?
Что будет точно хуже — дополнительная зависимость от версий плейбуков и отвалившееся кеширование слоев (как раз из-за того, что порядок действий не будет задан явно).
Что именно там перезапустят при упавшей сборке?
Кто-нибудь расскажет мне вообще для чего docker нужен-то?.. Это реторический вопрос админа старовера не нужно отвечать. Мне нужно просто выговориться.
Не уверен, что есть такая практика для ruby, но для дотнет обычно в одном образе билдят, а во втором запускают, предварительно скопировав артефакты:
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS build
WORKDIR /app
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /app/aspnetapp
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2 AS runtime
WORKDIR /app
COPY --from=build /app/aspnetapp/out ./
ENTRYPOINT ["dotnet", "aspnetapp.dll"]Не удобнее ли будет поступить так же, что бы не вычищать образ?
Так же, такой подход, хорош когда надо скопировать статику на фронт.
Для тех случаев, когда продакшн-образ содержит только самое необходимое, также встречал вариант, когда существуют как минимум два образа:
1) минимальный — для запуска продакшна
2) с компилятором/исходниками/полным рантаймом/дебаггером (ненужное в зависимости от языка — вычеркнуть) — для локальной разработки
FROM scratch MAINTAINER Developer <developer@company.example> COPY binary-artifact / ENTRYPOINT ["/binary-artifact"]
Сам `binary-artifact` возникал в пайплайне bitbucket.
Ну и наконец, помнишь, в начале я говорил про идеологию Docker «один контейнер — один процесс»? Это означает, что supervisor не нужен. Так же не стоит устанавливать systemd, по тем же причинам. По сути, Docker сам является supervisor. И когда ты пытаешься запускать в нем несколько процессов, это как в одном процессе supervisor запускать несколько приложений.
У меня есть проект на node.js в Docker. Он запускается через pm2. Можно ли выкинуть pm2?
Docker: невредные советы