Docker на prod- сервере: Плюсы-минусы?

Sly32, покажи

docker stats --no-stream

docker stats --no-stream

CONTAINER ID        NAME                 CPU %               MEM USAGE / LIMIT    MEM %               NET I/O             BLOCK I/O           PIDS

cea169cd8fe2        bel_nginx_1       0.00%               4.242MiB / 512MiB    0.83%               1.6MB / 14.3MB      8.78MB / 0B         5

6a03d1559328        bel_web_1         0.01%               180.6MiB / 512MiB    35.27%              294kB / 717kB       167MB / 0B          9

d6a877e533ec        bel_db_1          0.01%               6.527MiB / 1019MiB   0.64%               120kB / 221kB       62.7MB / 174MB      6

f342bd92f6e9        bel_memcached_1   0.02%               1.352MiB / 512MiB    0.26%               12.7kB / 0B         6.55MB / 0B         10

Какой то странный у вас рабочий процесс. Обычно git и билд и пуш в свой репозиторий делается на машине разработчика (ну или на CI сервере отдельном), а на проде делается docker-compose pull && docker-compose up -d

Вы предлагаете хранить в репо несколько гигов сбилдженных образов/контейнеров и их закачивать? Смысл?

---------- Добавлено 27.03.2019 в 14:57 ----------

Вы предлагаете хранить в репо несколько гигов сбилдженных образов/контейнеров и их закачивать? Смысл?

Sly32, конечно в репозитории должны храниться все собранные образы. Смысл - они версионированные и всегда можно откатиться к нужной версии. Почему они у вас "несколько гигов"? Неправильно собираете, не удаляя промежуточные какие-то файлы из сборки?

может так и правильно, но я так не делаю. Насчет размеров... Ну вот пример Докер-контейнера:

FROM python:3.7-stretch

MAINTAINER Viachaslau Kazakou <sly.kazakoff@gmail.com>



RUN groupadd -r docker && useradd -r -g docker docker



RUN apt-get update && apt-get install -y \

    gettext \

    libmemcached-dev \

    libpcre3 \

    libpcre3-dev \

    postgresql-client \

    rsync \

    --no-install-recommends && rm -rf /var/lib/apt/lists/*



COPY docker-entrypoint.sh /

RUN chmod 755 /docker-entrypoint.sh

ENTRYPOINT ["/docker-entrypoint.sh"]

RUN mkdir -p /app

COPY requirements.txt /app/

RUN pip install --upgrade pip \

    && pip install --no-cache-dir -r /app/requirements.txt



COPY project /app/project

#COPY media /app

#COPY static /app

COPY manage.py /app/manage.py

RUN chown -R docker:docker /app



WORKDIR /app

(про устаревшее я знаю, да)

он занимает 1.24 гига. Что лишнее?

Зачем мне его пушить целиком когда разворачивание занимает минуты, а версионость обеспечить гит, пересобрать же контейнер вообще в мгновение ока?

Опять же - я не спорю, просто интересно

Если вас именно размер образа беспокоит, то лишнее "FROM python:3.7-stretch", замените на "FROM python:3.7-alpine":

REPOSITORY                              TAG                 IMAGE ID            CREATED             SIZE
python                                  3.7-stretch         2053ca75899e        4 hours ago         929MB
python                                  3.7-alpine          bb1ccaa5880c        2 weeks ago         86.7MB

Вы же понимаете, что данные в образе хранятся слоями, т.е. если у вас от базового образа изменения несколько файлов, то только они и будут запушены? И если в репозитории у вас 10 версий вашей программы на основе базового образа, то это не будет 10 гигабайт?

Да, конечно) Альпайн мне не понравился, хоть он и гораздо легче - слишком много в него дособирать и нкоторые вещи не заработали как надо) Возможно, к каких то проектах и будет нужен ваш подход, в моем случае мне проще в гите хранить только проект, а сами образы билдить непосредственно. В любом случае спасибо за полезную инфу

---------- Добавлено 27.03.2019 в 16:39 ----------

Да, конечно) Альпайн мне не понравился, хоть он и гораздо легче - слишком много в него дособирать и нкоторые вещи не заработали как надо) Возможно, к каких то проектах и будет нужен ваш подход, в моем случае мне проще в гите хранить только проект, а сами образы билдить непосредственно. В любом случае спасибо за полезную инфу