Ответы пользователя по тегу Docker
  • Автоматическое копирование вольюмов Docker?

    Tyranron
    @Tyranron
    Нужно разделять stateless-сервисы и stateful-сервисы. Первые Вы можете раскладывать по нескольким хостам и не париться, а вот другие надо думать как именно их масштабировать, и какие гарантии нужны. По хорошему, само Ваше приложение должно быть stateless, и не монтировать никаких директорий, куда бы складывало файлы на длительное хранение, а заливало бы эти файлы для длительного хранения на другой специальный файловый сервер хоть по S3 bucket интерфейсу, хоть по, прости господи, FTP.

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

    Каковы есть/приходят на ум варианты:
    1. Поднять на всех хостах распределенную файловую систему (CephFS, GlusterFS, и т.п.). Монтируем в контейнер приложения volume под этой системой и тупо пишем туда файлы как обычно. Распределенная ФС самостоятельно размажет файлы по хостам в зависимости от желаемых настроек. Читаем файлы из той же директории.
      Плюсы: не нужно менять код приложения, легко использовать, простая концепция в понимании.
      Минусы: при интенсивной работе с файлами может не хватать производительности (подобные ФС считаются медленными), при отвале части хостов может не работать запись (так как требуется кворум n/2 + 1), эксплуатация/поддержка подобных систем может быть не самой тривиальной задачей (веселой починки сломавшегося Ceph-кластера).
    2. Поднять на всех хостах Minio (свой poor man's S3 bucket), либо другой свой отдельный файловый сервер. Работает в двух режимах: single (одна нода работает только со своими файлами, запись в несколько надо надо делать на стороне приложения, и фоновую синхронизацию тоже самостоятельно) и distributed (ноды обьединены в кворумный кластер с размазыванием файлов).
      Плюсы: S3 bucket интерфейс, легкая эксплуатация, можно монтировать как ФС.
      Минусы: возможно нужно менять код приложения (чтобы уметь работать с S3), производительность на чтение в distributed режиме медленная (сравнима с распределенными ФС из пункта 1).
    3. Просто монтировать на каждом хосте локальную директорию, для которой настроить постоянную фоновую синхронизацию через BitTorrent Sync какой-то (а может даже просто rsync).
      Плюсы: производительность обычной ФС, никаких кворумов (а значит блокировок на запись), легко использовать (монтируешь и вперёд).
      Минусы: файлы доступны на других хостах только через какое-то время, а значит приложение должно уметь это учитывать, возможна потеря данных (нода приняла файлы и сгорела не успев их отсинхронизировать на другие), если файлы не влезают на один хост - то вариант не подходит, либо шардить (размазывать) придётся руками самостоятельно в приложении.
    4. Использовать готовое отказоустойчивое облако: AWS Bucket, DigitalOcean Space и т.п.
    Ответ написан
    2 комментария
  • Как донастроить Gitlab-omnibus с внешним nginx и https?

    Tyranron
    @Tyranron
    Вы на Nginx'е, получается, TLS-терминацию делаете, а GitLab при этом у Вас тоже пытается слушать по HTTPS. Вам нужно сказать GitLab'у, чтобы слушал обычный HTTP, и что он позади reverse proxy. И обращаться к нему не по unix-сокету Workhorse (именно на это у Вас ругается Nginx), а напрямую на нужный порт.

    Что-то вроде этого:
    external_url 'https://gitlab.mydomain.com'
    nginx['listen_port'] = 80
    nginx['listen_https'] = false
    nginx['proxy_set_headers'] = {
      "Host" => "$http_host_with_default",
      "X-Real-IP" => "$remote_addr",
      "X-Forwarded-For" => "$proxy_add_x_forwarded_for",
      "X-Forwarded-Proto" => "https",
      "X-Forwarded-Ssl" => "on",
      "Upgrade" => "$http_upgrade",
      "Connection" => "$connection_upgrade"
    }

    ports:
        - '8080:80'
        - '2022:22'

    proxy_pass http://gitlab:8080;

    Но конкретно в данной ситуации не совсем понятно, зачем Вам нужен ещё один фронтовый Nginx рядом. Вы ведь можете просто потюнить на предмет сертификатов/шифров тот Nginx, который уже идёт внутри omnibus образа.
    Ответ написан
    8 комментариев
  • Как правильно настроить контейнеры nginx + fpm?

    Tyranron
    @Tyranron
    В конфиге Nginx недостаёт передачи SCRIPT_FILENAME Fast-CGI параметра. Нужно добавить следующее:
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    Ответ написан
    Комментировать
  • Как решаете проблему отсутствия локального smtp сервера в docker?

    Tyranron
    @Tyranron
    Ну, вообщем, Вы всё сами правильно ответили.

    Я использую указанный Вами 2й вариант. В Dockerfile добавляется слой с ssmtp и всё. В качестве ENTRYPOINT небольшой sh-скрипт, который конфигурирует sssmtp при старте контейнера в зависимости от переменных окружения. Все письма пересылаются на внешний центральный Postfix, который уже крутит всю бодягу с DKIM подписями и прочими email-прибамбасами.

    Если Вы посадите этот Postfix внешний на ту же машину, где у Вас крутится и приложение, то вероятность потери такая же, как и в "традиционном" случае без Докера (ведь у Вас на машине Postfix или Exim все равно крутятся).

    Также, как вариант, если есть возможность, можно предусмотреть retries для отправки email в самом коде приложения, если это настолько критично.

    По поводу примерного docker-compose.yml:
    version: '3'
    
    services:
      fpm:
        container_name: fpm
        image: my/app
        depends_on:
          - mailserver
        expose:
          - "9000"     # php-fpm
        environment:
          - SMTP_SERVER=mailserver:587
          - SMTP_USER=testing@moderation.test
          - SMTP_PASSWORD=qweqweqwe
      nginx:
        container_name: nginx
        image: nginx:stable-alpine
        depends_on:
          - fpm
        ports:
          - "80:80"    # http
        volumes:
          - .dev/nginx.vhost.conf:/etc/nginx/conf.d/default.conf:ro
      mailserver:
        container_name: mailserver
        image: tvial/docker-mailserver:v2
        hostname: mail
        domainname: mydomain.test
        ports:
          - "25:25"    # smtp
          - "143:143"  # imap
          - "587:587"  # smtp-auth
          - "993:993"  # imap-secure
        volumes:
          - .dev/mail/accounts.cf:/tmp/docker-mailserver/postfix-accounts.cf:ro
    Ответ написан
  • Docker и базовые образы с разными дистрибутивами Linux?

    Tyranron
    @Tyranron
    Я понимаю что ядро одно, но окружение слишком разнообразное, мне нужна одна система.

    Зачем?

    Как использование кучи дистрибутивов скажется на производительности, если она очень важна вопреки удобству?

    Вообще никак.

    У Вас в контейнерах запускаются не дистрибутивы, и не "линуксы".
    В контейнерах запускаются процессы. И если это не кастомный образ, куда понапихано куча процессов с супервизором всего этого дела, то процесс запускается один. Вопрос производительности - это вопрос производительности Вашего процесса, и того как он работает. Если Вы запускаете, к примеру, mysqld, то какие там файлы остальные в контейнере лежат - по-барабану, потому что производительность mysqld зависит от него самого, его конфигурации, и ресурсов машины, а не от того, по чьему фэн-шую разложены файлы, CentOS'овскому, или Debian'овскому.
    Ответ написан
    Комментировать
  • Как настроить Debug режим, если исходники лежат в Docker?

    Tyranron
    @Tyranron
    У Вас в конфиге Xdebug указан порт 9001.
    xdebug.remote_port=9001

    А в контейнере этот порт у Вас выставлен наружу через expose.
    expose:
          - "9000"
          - "9001"

    Документация ясно говорит что в этом случае порт доступен только другим сервисам из docker-compose.yml.
    Expose ports without publishing them to the host machine - they’ll only be accessible to linked services.


    PHPStorm'а в docker-compose.yml не видно, а значит он и не может видеть Xdebug на том порту, что Вы ему скармливаете.

    Что нужно сделать?
    1. Перенести порт 9001 в ports:.
    2. В настройках IDEA указать Host: localhost для Xdebug (сейчас у Вас там какой-то левый IP).
    Ответ написан
  • Как запустить filebeat внутри Docker контейнера?

    Tyranron
    @Tyranron
    По умолчанию предполагается, что в одном контейнере бежит всего один процесс. Если Вам нужно более одного процесса - либо разносите по отдельным контейнерам (Tomcat отдельно, Filebeat отдельно), либо добавляйте в контейнер какой-то супервизор, который будет курировать несколько процессов и смотреть дабы они не падали. Для Docker образов обычно используют s6 супервизор, который можно удобно использовать через s6-overlay.
    Ответ написан
  • Как запустить многоконтейнерное Docker приложение локально?

    Tyranron
    @Tyranron
    Не допускать опечаток в именах образов.

    У Вас в выводе docker images название iqmen_ru/iqpr-postrgres, а в docker-compose.yml уже iqmen_ru/iqpr-postgres.

    Ещё раз, наглядно:
    iqmen_ru/iqpr-postrgres
    iqmen_ru/iqpr-postgres
    Ответ написан
    Комментировать
  • Как разрешить доступ к MongoDB, которая находится в Docker'е, только определенным ip адресам?

    Tyranron
    @Tyranron
    Через iptables и делается. Все правильно пробовали.
    Осталось только чуть больше исследовать тему. Вам нужно использовать FORWARD chain, а не INPUT, а INPUT только если Вы делаете --network=host.
    Эта статья должна прояснить ситуацию:
    tomasre.com/2016/03/07/securing-coreos-with-iptables
    Ответ написан
    Комментировать
  • Как установить imagick для PHP7.1 (docker, alpine)?

    Tyranron
    @Tyranron
    В таких случаях через sub-shell можно скормить команде то, чего просит.
    Например:
    # Install Xdebug
    RUN apk add --update --no-cache --virtual .tools-deps \
                autoconf g++ libtool make \
     && (yes | pecl install xdebug) \
     && apk del .tools-deps \
     && rm -rf /var/cache/apk/*
    Ответ написан
    2 комментария
  • Docker: alpine+nginx+php-fpm - не взлетает nginx?

    Tyranron
    @Tyranron
    Запихнуть в один контейнер больше одного процесса можно, но не самая хорошая идея, так как уже требуется супервизор для управления ими.
    В данном случае, считаю, Вам не нужно устанавливать nginx в этот же контейнер. Просто запустите официальный nginx образ отдельным контейнером и слинкуйте директорию Вашего приложения туда.
    Важные моменты:
    • Ваши файлы должны располагаться под одинаковым путем в обоих контейнерах.
    • Лучше чтобы nginx и php-fpm бежали от имени одного и того же пользователя. Для этого можно использовать уже присутствующего в обоих образах пользователя nobody.
    Ответ написан
    2 комментария
  • Как защитить код?

    Tyranron
    @Tyranron
    Теоретически, Docker при этом может помочь:
    1. Исходный код проекта закрыт и нигде не публикуется, то же касается Dockerfile. Вы распространяете только уже готовые Docker-образы.
    2. При сборке Docker-образа шифруем файлы самой программы, будь то .jar'ник, бинарник или голые php'шные сорцы.
    3. Для расшифровки требуется лицензионный ключ, который должен пробрасываться в контейнер при старте через переменные окружения. Ним файлы программы расшифровуются и программа стартует.


    На практике же, получится то же самое что и с пиратством различного софта сегодня:
    • Тот, кто обладает ключем, может выложить его в открытый доступ. Этот момент можно обойти, если придумать какую-либо централизованую верификацию ключа на своих серверах (см. как делают JetBrains). Или под каждый ключ генерить отдельный уникальный Docker-образ. Опять же, тот кто обладает ключем, обладает и соответствующим образом, и ним он тоже может поделиться.
    • Тот, кто обладает ключем, может спокойно расковырять контейнер через docker exec. И если файлы программы сами по себе отражают хорошо исходный код (например PHP-скрипты, или бинарники Go), то тут утекает уже и исходный код Вашего продукта, что не комильфо. Так что обфускацией кода и другими техниками защиты результатов компиляции пренебрегать не стоит.


    В общем, палок в колеса вставлять можно "ого-го-го", но полного решения данной проблемы, ИМХО, нету. Потому пиратство и процветает, ибо оно возможно.
    Ответ написан
    4 комментария
  • Как заставить systemd запускать контейнеры через docker-compose?

    Tyranron
    @Tyranron
    1. Чтобы при перезапуске машины контейнеры сами стартовали, нужно всего лишь соответствующий systemd service сделать enabled. Cron здесь не нужен.
    sudo systemctl enable docker-project.service

    2. Любой systemd service - это всего лишь абстракция. А что именно он выполняет - решать именно Вам. Что у Вас ExecStart'ом будет стартовать один контейнер через docker run, что связка контейнеров через docker-compose up, для systemd и CoreOS принципиальной разницы нет.

    3. В приведенной Вами декларации systemd service'а в секции [Unit] есть следующие строки:
    Requires=docker-project.service
    After=docker-project.service

    Они означают, что декларируемый Вами service должен быть запущен только после того, как был запущен docker-project.service. Но, насколько я понимаю из Вашего описания, это и есть декларация docker-project.service. То есть Вы говорите systemd что сервис должен быть запущен после запуска самого себя. Это не есть гуд. Эти строки, судя по всему, должны быть такими:
    Requires=docker.service
    After=docker.service

    Дабы systemd пытался запустить этот сервис только после того, как будет запущен Docker daemon.

    4. В файлике docker-up.sh у Вас docker-compose up запускается в foreground'е. Первая связка контейнеров то запустится, а что со второй - не понятно. Наверное, все же стоило их запускать с -d ключиком, а в systemd декларации в секции [Service] указать Type=forking, если прям так нужно обе связки контейнеров запускать одним systemd service. Но вообще, имхо, на каждый docker-compose.yml должен быть свой отдельный systemd service, и никаких forking.
    Также, заворачивать docker-compose команды внутрь docker-up.sh было не самой хорошей идеей. Вам ничего не мешало написать несколько ExecStart'ов подряд, тем самым не размазывая декларацию по нескольким файлам, и было бы видно на каком именно шаге оно отваливается при systemctl start docker-project.service.

    5. Логи наше все. Используйте journalctl --unit=docker-project.service дабы глянуть что там вообще произошло, и кто на кого ругается.

    В заключение:
    Вообще, честно говоря, видно полное профанство с Вашей стороны по данному вопросу. Это нормально, ведь невозможно знать все технологии и инструменты, и постоянно приходится что-то изучать. Не нормально то, что ничего не мешает заглянуть в официальную документацию по тому же systemd. 20-30 минут чтения хотя бы этой страницы, и подобного непонимания бы просто не было.
    Пожалуйста, не поленитесь, потратьте немного времени и почитайте доки. Systemd умеет ещё много чего, что сможет Вам помочь в решении Ваших задач, и даст понимание что, куда, и как.

    К размышлению:
    Раз уж Вы используете CoreOS, посмотрите в сторону Kubernetes для запуска сервисов/контейнеров. Ставится на CoreOS он в пол-оборота, а возможностей, гибкости и вкусных абстракций уж гораздо поболее, нежели у systemd/fleet.
    Ответ написан
    1 комментарий
  • Как использовать докер для разового выполнения приложений?

    Tyranron
    @Tyranron
    Можно. Но приложения внутри контейнера видят только файловую систему контейнера. Вам нужно подмонтировать Ваш файлик test.py внутрь контейнера сначала.
    docker run --rm -it -v $(pwd)/test.py:/test.py:ro python python34 /test.py

    Если в результате выполнения test.py у Вас создаются какие-то файлы, позаботьтесь о том, чтобы они тоже писались в подмонтированую директорию, иначе по завершению работы они останутся закупорены внутри контейнера (и удалены вместе с контейнером, т.к. используется --rm флаг).
    Ответ написан
    2 комментария
  • Как запустить внутри docker "composer require" добавив ssh-key?

    Tyranron
    @Tyranron
    Попробуйте подмонтировать в контейнер ключ (и ssh.config, по желанию).

    Если команда php composer.phar install выполняется от имени root внутри контейнера, то примерно следующие строки должны быть в `docker-compose.yml`:
    version: '2'
    services:
      php:
        ...
        volumes:
          ...
          - /path/to/my.key:/root/.ssh/repo.key:ro
          ...
        ...
    Ответ написан
  • Как правильно делать deploy с помощью docker registry?

    Tyranron
    @Tyranron
    Официальную документацию надо все же читать, проявив усидчивость. Тогда не будет путаницы в базовых понятиях, из-за которой возникает каша в голове.

    Давайте разберемся с инструментами и их предназначением, которые Вы используете:
    • Комманда docker - это консольный интерфейс (CLI) для работы с Docker
    • docker build создает по заданному Dockerfile образ контейнера
    • docker tag присваивает указанному образу указанный тег (опция -t для build делает то же самое)
    • docker pull скачивает указанный образ из удаленного регистра на текущую машину
    • docker push заливает указанный образ в удаленный регистр
    • docker run запускает новый контейнер из указанного образа
    • docker ps выводит список текущих "бегущих" контейнеров

    Команда docker не жонглирует файлами, она жонглирует образами и контейнерами, а они от нас абстрагированы Docker'ом, как что-то эфемерное. То есть выполняя комманду docker pull Вы не скачиваете образ в ту папку, где выполняете команду, и уж точно не скачиваете какие-либо файлы. Все что Вы делаете этой командой - это скачиваете образ в локальное хранилище Docker'а, дабы Docker daemon мог запустить контейнер на основании этого образа.

    Команда docker-compose - это уже совсем другая команда. Все что она делает - это читает указанный YAML-манифест и выполняет соответствующие команды Docker. Это всего лишь позволяет декларативно указывать желаемые сценарии при работе с Docker в удобном формате. Но ни команда docker, ни docker-compose, не предоставляют ничего для того, чтобы транспортировать/обновлять версии Ваших манифестов где-то там. Docker, опять таки, жонглирует образами и контейнерами, не более.

    У Вас в манифесте указана директива build:. Таким образом docker-compose пытается сначала собрать контейнер, вместо того, чтобы просто запустить его из образа.

    Касательно совета docker-compose.yml под каждый env, все правильно советовали. Именно так это и задумывалось. Вы в манифесте указываете отнюдь не разные окружения (development, production), а набор контейнеров, которые должны бежать в одной связке одной логической единицей (концепция POD'ов). Ничего не запрещает делать и так, как сделали Вы, но это сродни использованию дуршлага в роли миски для еды: сегодня Вы нормально из него наворачиваете пельмени, а завтра супчик в нем уже куда-то не туда утекает.

    Воркфлоу в Вашем случае можно организовать следующим образом:
    1. На dev-машине у Вас один docker-compose.yml, согласно которому контейнер перед запуском собирается из сорцов.
    2. Когда у Вас готова новая версия приложения, Вы его собираете через docker build, присваиваете ему номер версии через docker tag и отправляете в удаленный регистр образов через docker push.
    3. На prod-машине у Вас отдельный docker-compose.ymlв котором указано запускать конкретную версию образа (и никаких build). Новая версия приложения - меняем тег образа в манифесте и перезапускаем контейнеры. При выполнении docker-compose образ автоматически скачается перед запуском, если его нет локально. Если же Вы обновили образ конкретной версии, которая уже была скачана ранее, то да, нужно выполнить docker pull перед стартом, дабы скачать новый образ.


    Дополнительный совет:
    Сборку образа и его заливку в удаленный регистр часто удобно автоматизировать с помощь Makefile'ов.
    Ответ написан
    3 комментария
  • Как правильно скрестить docker контейнеры?

    Tyranron
    @Tyranron
    Все зависит от модели взаимодействия между apache и php, которая Вам требуется.
    Грубо говоря: сколько процессов - столько и контейнеров.

    Если присмотреться к версиям образов php, то можно увидеть, что они предоставляют собой различные инструменты (смотрим на CMD в Dockerfile). Так, например, 7.0-fpm образ представляет собой процесс php-fpm демона. А вот 7.0-cli это просто запуск php-интерпретатора в интерактивном режиме (php -a). Версия 7.0-apache вообще являет собою Apache сервер, который умеет запускать php-скрипты.

    Соответственно, если Вам нужна модель Apache + php-fpm, значит берем контейнер apache и вяжем с контейнером php:fpm. Если Вам нужно, чтобы Apache напрямую запускал php-скрипты, берем один контейнер php:apache.
    Ответ написан
    Комментировать
  • Как в Dockerfile настроить Environment?

    Tyranron
    @Tyranron
    Закиньте megacopy комманду в задачник cron'а и запустите crond главным процессом контейнера (чтобы бежал в foreground).
    Вот пример под alpine.
    Ответ написан
    Комментировать
  • Как настроить подключение к базе на хосте из контейнера?

    Tyranron
    @Tyranron
    Пробросить контейнеру app через переменные окружения (environment variables) хост, логин и пароль для доступа к БД. В коде app взять параметры подключения к БД из проброшенных переменных окружения.
    Либо, подмонтировать в volumes папку с unix-сокетом базы данных и в коде app подключится к этому сокету. Но это будет работать только тогда, когда БД и app строго на одной машине.
    Ответ написан
    4 комментария
  • Docker как панацея для разработчика?

    Tyranron
    @Tyranron
    Для начала нужно понять "контейнер" и "контейнеризацию".
    Контейнеризируя процесс, мы его изолируем в своей среде, со своим личным user space. При этом ядро ОС (kernel) при работе контейнера используется то же самое, что и у основной ОС машины.

    Выгода здесь в том, что к контейнерам можно относиться как к этаким "бинарникам", грубо говоря. У Вас есть какое-то приложение, не важно какое-оно, будь то набор скриптов на PHP, либо уже скомпилированное что-то (postfix, nginx, apache, и т.п.). Вы это приложение и все его зависимости упаковываете в контейнер (создаете image) и на выходе получаете единое готовое "что-то", что Вы можете запустить и оно не требует более никаких зависимостей (кроме рантайма контейнеров - Docker, rkt, и т.п.). Полная аналогия с тем, как из вороха либ и исходников Вы компилите единый бинарник, который просто потом запускаете где хотите, без необходимости иметь исходники.
    Как мы привыкли в менеджерах зависимостей (composer, bower, другие) описывать и фиксировать зависимости исходного кода, так же и в контейнере мы делаем то же самое, но для окружения нашего приложения. Reproducibility во все поля.

    Это очень сильно упрощает жизнь. Вам больше не нужно заботиться о том, что для приложения нужно точно воспроизводить окружение на каждой машине, оно у Вас зафиксировано внутри контейнера. Никаких больше конфликтов между различными версиями jvm, php, python, ruby, nginx и т.д. Вы легко на одной и той же машине используете какие хотите приложения, каких хотите версий. Выкатка его же на другую машину больше не требует филигранной подгонки и согласования окружения в соответствие. У Вас больше не отвалится внезапно приложение, из-за недонастроенных апдейтов ОСи и внезапного обновления зависимых либ.

    А что Docker?
    Docker - это набор инструментов для работы с контейнерами.
    Docker daemon являет собой рантайм контейнеров, он их запускает, останавливает, отслеживает.
    Docker registry - это контроль версий созданных образов (images) приложения, по аналогии к контролю версий исходников приложения.

    Все. Концептуально ничего более Docker и контейнеризация не дают.

    Отвечая на Ваши вопросы:


    1. docker-daemon - это HTTP-сервер и он может взять на себя это работу на стороне сервера, т.е. nginx не нужен

      Нет. Docker daemon - это рантайм контейнеров. Он умеет "слушать" на определенных портах, но это сделано для взаимодействия с Docker runtime'ом, а не для выполнения функциональности HTTP-сервера. HTTP-сервер все ещё нужен, и он может (а по-хорошему и должен) быть запущен внутри контейнера.


    2. docker на дев-машине можно (как-то) связать с докером на хостинге

      Мы не жонглируем docker'ами. Docker - всего лишь инструмент для работы с контейнерами. Мы жонглируем контейнерами и приложениями, упакованными в них. Нет смысла связывать docker'ы на хостинге и на дев-машине. Вы создаете образ (image) и можете его запускать через docker как на дев-машине, так и на хостинге. Если Вам нужно, чтобы одни приложения на дев-машине общались с другими на хостинге, то это не вопрос к docker'у - это вопрос к организации связи между Вашими приложениями.


    3. и учитвыая предудущий пункт - docker можно использовать для деплоя

      ИМХО, нужно. Вы закатали в образ точную версию приложения и его окружения. Осталось теперь этот "бинарник" запустить где хочется.


    4. docker можно использовать для отката, если деплой не задался

      Легко. Просто тушим контейнер нового образа и подымаем обратно старый.


    5. пропадает необходимость в во всяких rbenv и pyenv, если нужна другая версия языка, то просто создается новый контейнер в котором и происходит установка

      Да. Вы в Dockerfile, по сути, точно декларируете свое окружение. Нужно другое окружение - меняем Dockerfile и создаем новый образ.


    6. докер очень быстрый, в т.ч. старты и рестарты

      Не понятно - быстрый в чем? Наверное, имеется в виду сравнение с виртуальными машинами. Да, накладные расзоды меньше, нежели у виртуалок, так как используется одно и то же ядро ОС. Просто процессы запускаются в разных user space'ах. В остальном скорость Docker - это скорость запуска, собственно, процессов. Если у Вас тяжелое приложение с медленным стартом (привет, FMS!) или остановкой, то Docker тут Вам ничем не поможет.

    Ответ написан
    4 комментария