company_banner

10 мифов о Docker, которые пугают разработчиков

https://habrahabr.ru/company/centosadmin/blog/323554/
  • Перевод

Источник: 'Nova typis transacta navigatio' (Linz: s.n., 1621), p.12 (British Library, G.7237).


Часто во время разговоров о Docker я слышу мнения, с которыми не совсем согласен.


«Docker по своей сути предназначен для крупных компаний»

«под OSx у него экспериментальная поддержка, под Windows работает еле-еле»

«Я не уверен, что смогу быстро развернуть его локально»

… и еще много всякого.

В этих утверждениях есть доля истины (см. ниже мифы 3 и 5), но она мала, и по большей части реальная картина получается искаженной.


А есть еще и наполненные жаргоном статьи о том, как при использовании немалого количества фреймворков обрабатывать 10к миллионов запросов в секунду. И это с помощью всего лишь 30к контейнеров при автоматизации 5к микросервисов, размещенных на шести сотнях облачных виртуальных машин…


Что ж, нетрудно догадаться, почему Docker окружен таким количеством мифов.


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


Давайте поговорим о самых распространенных мифах – тех, с которыми я сталкивался и в которые верил, – и попробуем найти в них истину, а также решения, если таковые имеются.


Миф № 10: С Docker я не смогу заниматься разработкой…


потому что я не могу редактировать Dockerfile


Для разработки мне нужны специальные инструменты и настройки окружения. При этом мне вполне справедливо указали, что редактировать используемый в промышленной эксплуатации Dockerfile нельзя.


Боевой Docker-образ должен быть сконфигурирован только для нужд промышленной эксплуатации и не более.


Как же быть? Если я не могу добавить в Dockerfile мои инструменты и настройки, как мне тогда вообще разрабатывать в Docker?


Я могу скопипастить боевой Dockerfile в собственный и внести в копию необходимые изменения. Но дублирование может привести к неприятным последствиям.


Решение


Вместо копирования Dockerfile, которое может привести к дополнительным трудностям, лучше использовать функциональность Docker по созданию одних образов на основе других.


Я и так создаю production-образ со своим приложением на основе другого образа (что-то типа “node:6”). Так почему бы мне не сделать “dev.dockerfile”, который будет создавать нужный образ на его основе?


Dockerfile

FROM node:6

# ... production configuration

Production Build

$ docker build -t myapp .

dev.dockerfile

FROM myapp

# ... development configuration

Development Build

$ docker build -t myapp:dev -f dev.dockerfile .

Теперь я могу модифицировать dev.dockerfile по своему усмотрению, зная, что в нем используется точно такая же конфигурация, как и в production-образе.


Хотите увидеть, как это делается?


Посмотрите эпизод Creating a Development Container, который является частью Guide to Building Node.js Apps in Docker.


Миф № 9: Я ничего не вижу в этом контейнере


потому что я вообще не могу посмотреть внутрь контейнера!


Docker — это виртуализация приложений (контейнеризация), здесь нет полноценных виртуальных машин.


Но разработчику часто необходимо взаимодействовать с контейнером так, как будто это виртуальная машина.


Мне нужны логи (помимо консольного вывода моего приложения), отладочные сообщения и общая уверенность в том, что все изменения образа отработали корректно.


Если контейнер — это не виртуальная машина, как мне понять, что происходит? Как я увижу файлы, переменные окружения и другие необходимые вещи?


Решение


Хотя Docker-контейнер и не является полноценной виртуальной машиной, под его капотом работает дистрибутив Linux.


Да, этот дистрибутив может быть очень сильно обрезан (например, как Alpine Linux), но в нем все равно есть как минимум доступ к простейшей командной оболочке, что дает возможность заглянуть внутрь контейнера.


В общем случае есть два способа это сделать.


Способ № 1: Подключиться к командной оболочке работающего контейнера

Если контейнер уже запущен, для получения полного доступа к нему я могу выполнить команду “docker exec”.


$ docker exec -it mycontainer /bin/sh

Это дает доступ к содержимому контейнера, аналогичный тому, что я получаю при входе в систему под управлением обычного дистрибутива Linux.


Способ № 2: Запустить оболочку в качестве команды контейнера

Если у меня нет работающего контейнера, я могу запустить новый с командной оболочкой в качестве стартовой команды.


$ docker run -it myapp /bin/sh

Теперь у меня есть новый контейнер с командной оболочкой, которая позволяет посмотреть, что там внутри.


Хотите увидеть, как это работает?


Посмотрите эпизоды из Guide to Learning Docker и Guide to Building Node.js Apps in Docker.



Миф № 8: Мне придется писать код внутри Docker-контейнера


и я не смогу использовать мой любимый редактор?!


Когда я в первый раз увидел Docker-контейнер, в котором выполнялся мой Node.js-код, меня очень заинтересовали и обрадовали его возможности.


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


Нужно каждый раз пересоздавать образ? Но это будет занимать слишком много времени, поэтому такой вариант отпадает.


Может быть, нужно подключаться к командной оболочке контейнера и кодить в vim? Возможно, при этом придется использовать не ту версию, которая мне нужна.


Допустим, это работает. А если мне нужна IDE или редактор получше?


Если у меня есть доступ только к консоли контейнера, как использовать мой любимый текстовый редактор?


Решение


В контейнерах Docker с помощью опции "volume mount" можно монтировать директории из хост-системы.


$ docker run -v /dev/my-app:/var/app myapp

С этой командой “/var/app” будет указывать на локальную директорию “/dev/my-app”. Изменения, внесенные на хост системе в “/dev/my-app”(конечно же, с помощью моего любимого редактора), будут сразу видны в контейнере.


Хотите увидеть, как это работает?


Посмотрите эпизод editing code in a container, который является частью Guide to Building Node.js Apps in Docker.


Миф № 7: Мне придется использовать консольный отладчик…


а я хочу тот, который есть в моей IDE


Мы уже можем редактировать код внутри контейнера и подключаться к его командной оболочке. До отладки остался один шаг.


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


Безусловно, внутри Docker-контейнера можно использовать консольный отладчик для выбранного языка программирования, но это не единственная опция.


Как же тогда в контейнере запустить отладчик из моей IDE или любимого редактора?


Решение


Короткий ответ: «удаленная отладка».


Развернутый ответ очень сильно зависит от языка и рабочего окружения.


С Node.js, например, я могу использовать удаленную отладку по TCP/IP (порт 5858). Чтобы настроить отладку кода внутри Docker-контейнера, мне нужно открыть соответствующий порт в образе, создаваемом с помощью “dev.dockerfile”.


dev.dockerfile

# ...

EXPOSE 5858

# ...

Теперь я могу подключиться к командной оболочке контейнера и запустить сервис отладки Node.js, а затем использовать его с моим любимым отладчиком.


Хотите увидеть отладку находящегося в контейнере Node.js-кода в Visual Studio?


Посмотрите эпизод debugging in a container with Visual Studio Code, который является частью Guide to Building Node.js apps in Docker.


Миф № 6: Мне придется каждый раз запускать “docker run”


и я не смогу запомнить все опции “docker run”…


Без сомнения, у Docker огромное количество опций командной строки. Листание его справки напоминает чтение ветхого тома по мифологии исчезнувшей цивилизации.


Когда наступает время запустить (run) контейнер, я, что не удивительно, частенько путаюсь и даже начинаю злиться, поскольку с первого раза не могу подобрать нужные опции.


Более того, каждый запуск “docker run” создает из образа новый экземпляр контейнера.


Это замечательно, если мне нужен новый контейнер.


Но когда я захочу запустить ранее созданный контейнер, результат выполнения “docker run” мне совсем не понравится.


Решение


Нет нужды выполнять “docker run” каждый раз, когда нужен контейнер.


Вместо этого контейнеры можно останавливать (stop) и запускать (start).


Этим также достигается сохранение состояния контейнера между запусками. Если в нем были изменены какие-то файлы, эти изменения сохранятся после остановки и повторного запуска.


Хотите увидеть, как это работает?


На WatchMeCode есть много эпизодов Guide to Learning Docker и Guide to Building Node.js Apps in Docker, в которых используется эта техника.


Но если идея для вас в новинку, рекомендую посмотреть basic image and container management, в котором рассказывается об остановке и запуске одного экземпляра контейнера.


Миф № 5: Docker под macOS и Windows толком не работает...


а я как раз использую Mac / Windows


Еще несколько месяцев назад это, в общем-то, было правдой.


В прошлом Docker под Mac и Windows требовал использования полноценной виртуальной машины с утилитой “docker-machine” и дополнительным программным обеспечением для обмена данными с виртуальным окружением.


Это работало, но с очень большими потерями производительности и ограниченным набором функций.


Решение


К счастью, разработчики Docker прекрасно понимают необходимость поддержки не только Linux в качестве базовой ОС.


Во второй половине 2016 года были выпущены официальные релизы Docker для Mac и Windows.


Теперь установка Docker на эти платформы не составляет труда. Регулярно выпускаются обновления, а функциональность находится практически на уровне версии под Linux, и я не помню, когда в последний раз мне нужна была опция, недоступная в Docker под Mac или Windows.


Хотите установить Docker на Mac или Windows?


На WatchMeCode можно найти бесплатные эпизоды по установке на обе платформы (а также на Ubuntu Linux!)



Миф № 4: С Docker можно работать только в командной строке


а мне удобнее GUI


Поскольку Docker родом из мира Linux, не удивительно, что командная строка — это основной его интерфейс.


Однако изобилие команд и опций порой обескураживает. Для разработчика, который пользуется консолью нерегулярно, это может стать причиной снижения продуктивности.


Решение


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


В Docker для Mac и Windows есть базовые средства интеграции с Kitematic, например, GUI для управления образами и контейнерами на локальной машине.


Kitematic позволяет с легкостью находить образы в репозиториях Docker, создавать контейнеры, а также управлять настройками установленных и работающих контейнеров.


Хотите увидеть Kitematic в действии?


Посмотрите эпизод о Kitematic в Guide to Learning Docker.


Миф № 3: Я не могу развернуть в контейнере базу данных.


Будут проблемы с масштабированием… и я потеряю свои данные!


Контейнеры по своей природе являются эфемерными: они должны без колебаний уничтожаться и создаваться заново по мере необходимости. Но если данные моей базы хранятся внутри контейнера, его удаление приведет к их потере.


Более того, системы управления базами данных имеют свои особенности при масштабировании: вертикально (более мощный сервер) и горизонтально (больше серверов).


Docker, похоже, специализируется на горизонтальном масштабировании: когда нужно увеличить мощность, создается больше контейнеров. С другой стороны, большинство СУБД требуют специфических настроек при масштабировании.


Да, все так. Боевую базу в Docker лучше не разворачивать.


Тем не менее мой первый удачный опыт работы с Docker был связан именно с базой данных.


Oracle, если быть точным.


Для нужд разработки мне понадобился Oracle, но у меня не получилось развернуть его в виртуальной машине. Я урывками занимался этим вопросом около двух недель, но к успеху даже не приблизился.


А через 30 минут после того, как я узнал, что существует образ Oracle XE для Docker, у меня была рабочая база.


В моем окружении для разработки.


Решение


Docker может быть не лучшим решением для размещения боевой БД, но для разработчиков он может творить чудеса.


У меня работали MongoDB, MySQL, Oracle, Redis, а также другие системы, требующие сохранения состояния между перезапусками, и меня все устраивало.


Ну а если говорить об «эфемерности» контейнеров Docker, то не следует забывать о возможности подключения внешних томов.


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


Теперь я могу в любое время создавать и удалять контейнеры, зная, что продолжу с того же места, на котором остановился.


Миф № 2: Я не смогу использовать Docker в своем проекте


потому что Docker — это «все или ничего»


Когда я впервые увидел Docker, то подумал: или разрабатывать, дебажить, деплоить и «девопсить» все с Docker (и двумя сотнями дополнительных инструментов и фреймворков, чтобы оно все работало автоматически), или не использовать Docker совсем.


Случай с Oracle XE доказал обратное.


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


Решение


Docker, как и большинство инструментов разработчика, можно начинать использовать постепенно.


Начните с малого.


Запустите в контейнере базу данных разработки.


Затем создайте в контейнере библиотеку и выясните, как она работает.


Далее создайте микросервис, но такой, чтобы требовал лишь нескольких строк кода.


Переходите к более серьезным проектам, уже вовлекающим небольшую команду специалистов.


Не нужно бросаться в омут с головой.


Миф № 1: Я не смогу получить пользу от Docker… Вообще…


потому что Docker — это “enterprise” и “devops”


Этот был самый серьезный ментальный барьер, который мне нужно было преодолеть после знакомства с Docker.


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


И совсем не удивительно, что я так думал.


В блогах и на конференциях то и дело возникает шумиха типа «Такая-то корпорация автоматизировала 10 000 000 микросервисов с помощью Docker и Kubernetes» и т. д. и т. п.


Docker может быть отличным инструментом для “enterprise” и “devops”, но и обычный разработчик – как вы и я – может использовать его преимущества.


Решение


Попробуйте Docker.


Опять же, начните с малого.


У меня запущена одна виртуальная машина с 12 Гб ОЗУ, на которой размещены 3 веб-проекта для одного из клиентов. По нынешним меркам это весьма скромный сервер. Но я рассматриваю Docker – чистый Docker сам по себе – как способ использовать этот сервер более эффективно.


У меня есть второй клиент, у которого частично заняты пять разработчиков (все вместе не отрабатывающие 40 часов в неделю). Эта небольшая команда также использует Docker для автоматизации процессов сборки и развертывания.


В настоящее время большинство своих open source-библиотек я пишу на Node.js под Docker.


Каждый день с помощью Docker я нахожу новые и зачастую более удобные способы управления программным обеспечением, установленным на моем ноутбуке.


Помните:


Не обращайте внимания на шумиху и не верьте мифам


Docker-мифология появилась благодаря веским причинам. Но она не помогает разработчикам.


Если вы, прочитав эту статью, все еще сомневаетесь, прошу вас выделить немного времени и попробовать пересмотреть свое отношение к Docker.


Если у вас есть вопросы по поводу того, каким образом разработчик может эффективно использовать Docker, свяжитесь со мной. Буду рад постараться вам помочь.


При желании изучить основы Docker и методы разработки приложений с его использованием можно начать с просмотра Guide to Learning Docker (с нуля) и Guide to Building Node.js Apps in Docker на WatchMeCode.


Оригинальный текст представлен по адресу: derickbailey.com/2017/01/30/10-myths-about-docker-that-stop-developers-cold/ (отсутствие активной ссылки обусловлено тем, что автор оригинального текста перенаправляет на сторонние ресурсы всех посетителей, пришедших по активным ссылкам на других сайтах).

Метки:
Southbridge 63,44
Обеспечиваем стабильную работу серверов
Поделиться публикацией
Похожие публикации
Комментарии 72
  • 0
    Шумиха, мифы — слова из журнала домохозяйек о том как не боятся и начать вязать.
    Разработчик зайдет, прочтет документацию и сам для себя решит — подходит для него инструмент или нет. А заголовок я бы поменял на «10 советов при работе с Docker»
    • +14

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

    • +2
      Так почему бы мне не сделать “dev.dockerfile”, который будет создавать нужный образ на его основе

      Потому что это прямо противоречит смыслу создания докер-образов.
      Теперь я могу модифицировать dev.dockerfile по своему усмотрению, зная, что в нем используется точно такая же конфигурация, как и в production-образе.

      Зачем тогда это всё, если у вас дев и прод одинаковые?

      Какие-то надуманные проблемы, с решением копипастой из документации.
      • +23

        Основные проблемы, с которыми сталкиваюсь при попытках перевести разработку на докер:


        • права в томах, примонтированных на хост — по умолчанию приложения в докере работают от рута либо от чётко заданного пользователя, заставить чтобы запускались по docker run и ко от текущего пользователя хоста весьма нетривиальная задача, особенно через docker-compose, а без этого или контейнер валится с permission denied, либо обнаруживаешь, что не можешь в IDE файл посмотреть или git checkout сделать
        • проброс текущего окружения в контейнер — прежде всего DNS и файлов в ~/.ssh
        • использование окружения контейнера на хосте — прежде всего DNS и изменяющихся файлов типа логов
        • проблемы с томами, которые шарятся между контейнерами, например docroot между контейнерами nginx и php-fpm — тома нужны для шаринга, но их природа (заполнение из "ведущего" контейнера только при первичном создании) мешает активной разработке, если файлы в томах создаются/изменяются/удаляются с хоста
        • очень слабый контроль над созданием образа (docker build) — прежде всего не примонтировать тома с хоста во время сборки
        • конфликты портов на хосте

        Ну а самое интересное начинается когда худо-бедно порешаешь это всё, запустишь приложение локально в десятке контейнеров, отладишь (постоянно чертыхаясь, что то не удалил том после исправления одной опечатки, то удалил на автомате то, что не нужно, и теперь жди когда "кэши прогреются") и тебе говорят "молодец, деплой на продакшен", на котором докером и не пахнет. Вот тут и начинаешь понимать, что основные прелести докера раскрываются только в относительно крупных компаниях, которые могут себе позволить CD на продакшен (читай — могут себе позволить специалиста, основной задачей которого будет автоматизация CD и прочий devops), неважно либо в виде докера на продакшене (за года полтора работі с ним так и не решил даже для себя, готов ли он к продакшену в условиях где почти все сервисы критичны для работы, но при этом не дублируются), либо в виде какой-то иной трансляции части разработческого окружения на него.

        • +12
          Срочно пишите статью по этим проблемам. Вот ЭТО было бы полезно :)
          • 0
            Поддерживаю Caravus насчет статьи. Я с docker-ом пока на вы и почитал бы, как вы боролись с описанными проблемами.
            • 0
              1. Проблему наблюдал только на маках, так как docker machine
              2, 3: skydns
              5. Да, это реально проблема.
              6 не замечал такой проблемы, видимо опять же docker machine
              • +1
                1. Православная Ubuntu, проект на php, структура типа


                  /
                  src/
                  tmp/
                  web/
                  web/uploads/

                  запускаем что-то вроде docker run -v ./:/app image и root/www-data/… кто угодно, но не юзер с uid=1005 на рабочей машине и uid=1000 на личной начинает писать в tmp и uploads отнюдь не от текущего пользователя


                2. Дано: приватный DNS-сервер типа 10.0.0.1 в рабочей сети для доменов типа gitlab.local, к которой из дома подключаешься по vpn, а в докерфайле что-то вроде RUN git clone ssh://gitlab.local/user/repo, причём доступ к гитлабу ограничен по ssh-ключам


                3. Речь о внутреннем DNS докера, по которому контейнеры друг с другом связываются, с хоста к нему доступа в общем случае нет


                4. В проекте два контейнера, экспозящих, например, 8080 порт, пускай с именами app1 и app2, для отладки хорошо бы в браузере на хосте набрать http://app1:8080 или http://app2:8080, а приходится http://localhost:8080 и http://localhost:8081, и хорошо если на хосте 8080 и 8081 не заняты чем-то другим или другой веткой проекта, а пробрасывать на хост без захардкоженных портов — постоянно смотреть куда заммапился
                • +2
                  1. Сделайте userns-remap. В контейнер будут от рута, — локально от вашего юзера.
                  • +2
                    1. С каких пор Ubuntu стала православной для докер контейнеров? Вы на размер образов после сборки смотрели?
                    2. не надо делать git clone в Dcokerfile
                    3. зачем вам внутренний DNS ?
                    4. в таких случаях создается прокси контейнер (nginx, caddy, etc), который по имени приложения раскидывает в нужный контейнер
                    • 0
                      С каких пор Ubuntu стала православной для докер контейнеров? Вы на размер образов после сборки смотрели?

                      Лучше конечно alpina, но есть нюанс — у альпины еще количество пакетов отстает от ubuntu. Это я в разрезе PHP. Можно конечно собирать нужные пакеты вручную и т.д, но это геморрой дополнительный.
                      У меня контейнер с php-fpm собран на убунте, а остальные (nginx, mongo,mysql, gearman) на alpine.
                      • 0
                        В Best practices рекомендуют Дебиан.
                        • 0

                          Это рекомендация для начинающих.
                          Базовый образ debain — latest 51 MB
                          Базовый образ alpine — latest 2 MB


                          Идем дальше:


                          NodeJS:
                          latest — 259 MB
                          slim — 87 MB
                          alpine- 20 MB


                          PHP:
                          fpm — 155 MB
                          fpm-alpine — 31 MB


                          Ruby:
                          latest — 266 MB
                          slim — 85 MB
                          alpine — 27 MB


                          OpenJDK:
                          latest — 244 MB
                          jre — 124 MB
                          jre-alpine — 56 MB


                          И это только базовый образ, мы еще даже свое приложение не добавили, не говоря уже о зависимостях


                          В итоге у любителей убунты простое приложение для показа аналитики из Гугла и Яндекса получается 1Gb+
                          Просто поменяв базовый образ на Alpine у меня получилось его уменьшить до 300Mb


                          Пока вы программист локалхоста, конечно пофигу сколько там оно занимает, а вот когда это идет в продакшн — тут уже немного другие критерии

                          • +1
                            • Во-первых, о продакшене вообще речи нет, пост для разработчиков как бы.
                            • Базовый образ закачивается на сервер/рабочую станцию только один раз для всех контейнеров.
                            • Разработка образов под что-то отличное от хорошо знакомых дистров значительно усложняется, начиная с банальной установки нужных пакетов, заканчивая необходимостью сборкой софта для отсутствующих пакетов, а разрабатывать образ могут люди вообще ничего в жизни ни разу не собиравшие, только apt/yum install php php-mysql
                            • работа изнутри образа тоже может заметно отличаться от привычной среды
                            • 0
                              1. А вы разработчик, результат труда которого потом выбрасывают?
                              2. Для этого в команде должны быть инженеры
                              3. bash/sh/zsh и остальное работает абсолютно одинаково
                              • +2
                                1. Я разработчик, который выполняет задачи и старается облегчить себе и другим жизнь. Докерезацией приложения в дев и тест окружениях я облегчаю жизнь себе, другим разработчикам, тестировщикам и немного админам
                                2. Инженеры (если вы имеете в виду админов) не заинтересованы в докере на продакшене — "работает — не трогай". Я, как ведущий разработчик, в целом тоже не заинтересован, по крайней мере не настолько, чтобы заявлять "у нас дев и тест средах работает всё под докером — давайте и на прод его пустим, все проблемы с ним я решать буду сам".
                                3. Я даже не знаю какой пакетный менеджер в alpine, и есть подозрение, что с его помощью смогу установить заметно меньше пакетов, чем с помощью apt под ubuntu.
                                • +1
                                  1. вы молодец
                                  2. у вас нет такой необходимости, ок, это тоже кейс, но ведь это частный случай
                                  3. это вы так оправдываетесь? :) на мой взгляд незнание инструмента не является единственной причининой для отказа от него
                                  • +1
                                    1. Спасибо, но это больше эгоистичной желание иметь на своей рабочей станции легко разворачиваемое окружение для каждого проекта максимально приближенное к продакшенам. И эгоистичное желание уменьшить траты своего рабочего времени на разворачивания для других разработчиков, тестировщиков и т. п :)
                                    2. Необходимости в контейнеризации, мне кажется, нет в большинстве случаев. Может кому-то упростить жизнь, может улучшить надежность/утилизацию, но может жизнь и усложнить вплоть до остановки бизнеса из-за отказов на уровне самой системы контейнеризации (докера), с которыми непонятно, что делать. Отказы на не продакшен-окружениях бизнес только в исключительных случаях могут остановить (не успели разработать/отладить фичу, без которой запрещено работать законом), потому зачастую там даётся полная свобода разработчикам. Но внедрение контейнеризации на продакшене — другое дело, разработчики могут только предложение сделать, но решающий голос у эксплуатации.
                                    3. Для перехода на новый инструмент, особенно предположительно менее функциональный/производительный в некоторых случаях, и гарантированно увеличивающий зоопарк технологий в компании (не менять же на всех серверах, как докер-хостах, так и классических (хост)-ос с ubuntu на alpine только из-за меньшего размера докер-образов), нужны веские причины. Да даже для нормального изучения этого инструмента с целью оценки плюсов и минусов перехода они нужны. Очевидный плюс apline в виде экономии пары сотни метров в размере образа пока для нас веской причиной начинать изучать переход не является, а других мы и не знаем.
                        • 0

                          Там в официальном образе PHP есть хелперы для сбора недостающих модулей

                          • 0

                            Небольшого подмножества модулей. И, да, полноценная сборка бинарных библиотек из С-исходников.

                            • 0

                              А никто не говорил что одной командой "apt-get install" :)

                              • 0

                                Эта сборка — один из двух основных моментов, почему я принял решение не использовать официальный образ php в дев-окружениях. Второй — корпстандарт на продакшене, где докером не пахнет, у нас ubuntu, иногда при веских основаниях типа "только под ней 1С нормально работает" — centos

                  • +1
                    права в томах, примонтированных на хост

                    У меня в phpstorm написан external tool, который делает chown на нужную мне папку или файл и забинден на хоткей. Вернуть себе права секундное дело.

                    Плюс я внутрь контейнера выполняю команды через маленькую обёртку (главный сервис в docker-compose.yml у нас всегда называется app) В конце которой меняю владельца файлов на себя.

                    app
                    #!/bin/sh
                    
                    COMPOSE="docker-compose run --rm app"
                    if docker top `docker-compose ps -q app` 1>/dev/null 2>&1; then
                        COMPOSE="docker-compose exec app"
                    fi
                    
                    if [ -z $1 ]; then
                    	${COMPOSE} sh -c "if type \"bash\" > /dev/null; then bash; else sh; fi"
                    else
                        ${COMPOSE} "$@"
                    fi
                    
                    fix-permission
                    


                    fix-permission
                    #!/bin/sh
                    
                    docker run --rm -v `pwd`:/app -w /app alpine sh -c "chown `id -u`:`id -g` -R ." &
                    



                    Не буду утверждать, что способ идеальный, но работает и проблем вроде не доставляет.

                    проблемы с томами, которые шарятся между контейнерами

                    Мы проблему не решили, но пока ушли от неё поменяв php-fpm на apache.

                    конфликты портов на хосте

                    После неудачных танцев с dnsmasq я написал маленький демон, который при появлении контейнера с указанным hostname прописывает его в /etc/hosts. Соответственно порты контейнеров я не публикую. Но работает это только для линукса.
                    • 0
                      Статью! :D
                    • +2
                      Для тех, кто хочет контейнеризацию без лишних напрягов для себя или в небольшую команду, рекомендую ознакомиться с LXC. Это _не кроссплатформенное_ решение (OSX/Windows отпадают), но с контейнерами LXC можно просто работать как с обычными виртуальными машинами. Для dev/staging окружения вообще идеально, на продакшн всё же приятнее иметь низкоуровневую виртуализацию, но можно и там с контейнерами работать.

                      А так да, докер без DevOps-инженеров — это боль и страдания.
                      • 0
                        У LCX есть аналог docker-compose?
                        • 0
                          Там он просто не нужен. У них свой формат конфигов изначально, его можно оркестрировать через Ansible или просто руками.
                          • +4

                            С ручной или сторонней оркестрацией, докер бы так не взлетел, скорее всего. Вся прелесть именно для разработчика: склонировал репу, docker-compose up и система с многими процессам у тебя поднялась, полностью связанная внутри, но наружу почти ничего не выбрасывающая.

                      • 0
                        Миф #1 — ИМХО, вполне себе не миф. Ну вот допустим, есть проект которому уже больше 5 лет, и на котором работают full-time 5-7 разработчиков. Проект большой, сложный, но он никогда, ну вот гарантировано никогда не будет разворачиваться на десятках серверов сразу, или делать что-то подобное. Это обычный сайт который живёт себе на одном сервере, обновляется через git, и горя не знает. Какая тут будет выгода от Docker, кроме лишней головной боли?
                        • 0
                          А как вы разрабатываете? Ставите веб-сервера на компы разработчиков? Работаете на выделенном сервере? Может быть «фигачите прямо в прод»?
                          • 0
                            У каждого на рабочей машине стоит вагрант-бокс чётко под проект. Развернуть рабочее окружение для нового разработчика — элементарно. Установил нужный бокс, зачекаутился с гита, накатил базу с последнего бекапа — готово!
                            • +4
                              Ну то есть вы делаете то же самое только через вагрант, а не через докер :) Можно точно также «зачекаутился с гита, запустил докер». У меня ещё и пхп-шный контейнер миграции сам накатывает, так что… те же яйца…
                              • +1
                                Просто на vagrant намного меньше порог вхождения получается, не надо изучать десятки ключей и специальных команд. Один раз vagrant init — а потом только vagrant up или halt. Надо заглянуть внутрь — просто подключаемся по ssh, как к обычному серверу, и не надо гуглить способы плясок с бубном в стиле
                                $ docker exec -it mycontainer /bin/sh
                                Надо работать в удобной IDE — не надо ни о чём думать, всё и так в лежит в общей папке и видно из под хост-системы, работаем как обычно. Это всё, конечно, ИМХО, я ни в коем случае не претендую на самое правильное мнение. Просто моя точка зрения.
                                • 0
                                  Ну я бы не сказал. То что вы описываете — справедливо и для докера. У вас же не посто так «vagrant init» кто-то же должен сначала написать конфиги. Про ссш — там что просто «ssh», или всё-таки своя колбаса которую нужно помнить? :) С «лежит в общей папке и видно из под хост-системы» точно так же проблем нет.
                                  Порог входа конечно есть, но он есть везде. Без труда…
                                  • 0
                                    А мне наоборот докер показался проще и понятнее вагранта. Дело вкуса, вероятно.
                                • +2

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

                              • +3

                                Навскидку теоретическая польза:


                                • забыть о несоответствиях среды разработки, тестирования и продакшена, прежде всего набора и версий системных пакетов и их конфигов. Ни разу не было, что разработчик что-то себе на машину установил для решения задачи, но по дороге до продакшена информация об этом потерялась? Или даже конфиг веб-сервиса или СУБД поправил у себя, который не в репе проекта, а на продакшене он другой?


                                • забыть о настройках среды разработки для нового члена команды


                                • обеспечить локально полностью всё окружение — не то, что у каждого разработчика своя СУБД, а под каждую ветку git'а он поднимает за несколько секунд полностью изолированную от других веток


                                • обеспечить плавный и быстрый перенос продакшена с сервера на сервер (всякое бывает, за 5 лет и хостер может смениться, и проекту тесно стать на сервере, хотя бы СУБД вынести на отдельный может быть хорошей мыслью)

                                На самом деле очень удобно, когда всё настроено уже и из ветки мастер проекта всегда можно развернуть полный аналог продакшена на голой машине буквально в три команды (псевдокод): install git docker && git clone && docker up и никакой возни с конфигами, адресами, именами и т. п. Только доступными ресурсами разве что будут отличаться

                                • 0
                                  Это не факт ни разу. Простой пример: я у себя нашел старый ноут. на него неожиданно для меня встала бунта 16.04. и шустро так работает! дай, думаю, посмотрю, как на нем докерная сборка запустится!
                                  А никак. Не запускается. Полчаса потратил — не взлетело.

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

                                  Дальше больше. Я понимаю, что это может быть не очень правильно, использовать образ на базе :latest. но это отличный способ получить зоопарк! Наприемр, в разработке образа пересобираются постоянно, версия всегда новая. а на боевом сервере? как часто ребилдится образ? Никогда? ну и получите сюрприз при очередном деплое.
                                  • 0
                                    Ноут был 32-битный?
                                • 0
                                  Это обычный сайт который живёт себе на одном сервере, обновляется через git, и горя не знает. Какая тут будет выгода от Docker, кроме лишней головной боли?

                                  Например докер дает повторяемый деплой, а git, по моему опыту, нет. Допустим, у вас после деплоя очередной версии под нагрузкой проявляется какой-то критичный баг. Сколько времени у вас займет возврат к рабочей версии, если проблема вызвана сменой версии какой-то из зависимостей (как pip/npm/watever, так и системной библиотеки)?
                                • 0
                                  Миф №11 — каждый процесс должен находится в отдельном контейнере.
                                  • +4
                                    Мифы автор конечно развеял, но не забыл раз 10 прорекламировать свой платный сервис — WatchMeCode
                                    • +1
                                      > Во второй половине 2016 года были выпущены официальные релизы Docker для Mac и Windows.
                                      А разве для Windows это доступно не только в сентябрьском 2016 обновлении на Pro версии?
                                      Как насчёт Win7 Home?
                                      • 0
                                        Win 7 не поддерживается (ну т.е. будет виртуальная машина), и похоже что не будет. Так что насчет windows это никакой не миф. Поддежка ОС ограничена, и вряд ли будет расширяться на старые ОС,
                                        • 0
                                          MacOS тоже только определенные версии поддерживаются :(
                                          • 0
                                            Ладно с ним Win7, Win10 Home поддерживается?
                                            • 0
                                              Там Hyper-V нету, не поддерживается. Из первоисточника:
                                              The current version of Docker for Windows runs on 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later). In the future we will support more versions of Windows 10.
                                        • +1
                                          потому что я не могу редактировать Dockerfile

                                          Dockerfile должен подвергаться редактированию только в том случае, если изменения касаются и production серверов.
                                          Если разработчик не может менять поведение сборки или запуска в зависимости от задач разработки не трогая Dockerfile, то у Вас просто не правильно написан Dockerfile. Поведением сборки можно управлять через build_args, а запуском environments.
                                          • 0

                                            Что значит "неправильно"? В чём плюсы сложного докерфайла, который без кучи ключей и не сбилдтся вообще, по сравнению с двумя докерфайлами, один из которых дополняет другой? Два минуса одного сложного по сравнению с двумя простыми для меня очевидны:


                                            • разработчик, желая облегчить себе разработку, может нечаянно затронуть и общие, и продакшен-ветви сложного файла, тем более что ветвления в самом докере толком нет, где-то внутри RUN оно всё будет в основном, ветвления через bash или аналоги, которые разработчики обычно не очень знают. Хорошо, если что-то простое, типа лишний системный пакет в образе будет, а если какое-то влияние на продакшен-логику окажет?
                                            • билд и запуск такого образа потребует сложной командной строки, в которой опять-таки легко ошибиться
                                            • +1
                                              Что значит «неправильно»?

                                              «неправильно» значит можно было сделать так, чтобы он удовлетворял всем задачам.

                                              В чём плюсы сложного докерфайла

                                              Dev окружение должно быть идентично prod'y. Это не говорит, что Dockerfile должен быть один, но наличие второго файла, который разработчик может изменить как ему угодно существенно повышает риск получить разное окружение. Можно получить расхождение и в предложенном мною варианте, но это не проблема подхода, ибо возможности расширения не должны допускать возможность выстрелить себе в ногу.

                                              без кучи ключей и не сбилдтся вообще

                                              Все возможные «кучи» ключей имеют значение по умолчанию, которые соответствуют production версии. Соответственно prod версия при запуске сборки не требует ввода параметров, за исключением токена к github'y для установки приватных пакетов.

                                              В идеале разработчикам приложения вообще не нужно лезть в Dockerfile и что-то там делать, особенно если они:
                                              обычно не очень знают


                                              билд и запуск такого образа потребует сложной командной строки, в которой опять-таки легко ошибиться

                                              Для запуска dev окружения у нас написан docker-compose.yml со всеми возможными параметрами, которые разработчик может менять для своих нужд. Точнее у нас docker-compose.yml.dist, а docker-compose.yml в gitignore.

                                              лишний системный пакет в образе будет, а если какое-то влияние на продакшен-логику окажет?

                                              Поэтому у нас запрещено трогать Dockerfile. Все необходимые библиотеки для разработки уже имеются внутри образа. Если кому то требуется что-то дополнительное и он может это обосновать, то его без проблем добавляют в сборку для всех.
                                              • 0

                                                Вроде как основной docker-flow cостоит в том, что прежде всего разработчики пишут докерфайлы, что результат их работы — образ в докер-репозитории, а не принятый мерж-реквест в гит-репозитории. Ну и пост собственно разработчикам адресован, чтобы не боялись докера, а если докерфайлы и ко пишут специально обученные люди, то чего, собственно бояться?

                                                • 0
                                                  Образ в докер-репозитории собирает CI на основе всё того же Dockerfile.

                                                  Что это, простите, за сборная солянка, где каждый результат работы имеет разные Dockerfile'ы? Это получается на prod может залететь всё что угодно?

                                                  прежде всего разработчики пишут докерфайлы

                                                  Разработчики должны писать приложение, а не окружение к нему. Окружение нужно один раз грамотно написать и использовать. Я имею ввиду, что это не та часть приложения, которая обычно меняется каждый день.

                                                  Ну и пост собственно разработчикам адресован, чтобы не боялись докера, а если докерфайлы и ко пишут специально обученные люди, то чего, собственно бояться?


                                                  Вроде суть в том, что люди в принципе боятся его трогать и не используют ни в prod ни в dev. А вовсе не о том, что в одном и том же проекте каждый должен написать свой Dockerfile.
                                                  • 0
                                                    Образ в докер-репозитории собирает CI на основе всё того же Dockerfile.

                                                    Если не собрала, то чья эта ответственность? Если разработчик должен разбираться почему, то и у вас результат работы разработчика — образ в репозитории.


                                                    Это получается на prod может залететь всё что угодно?

                                                    Если у вас контролируется всё, что на прод уходит, то и вредные изменения в Dockerfile не пройдут. Если не контролируется, то и так почти что угодно может залететь.


                                                    это не та часть приложения, которая обычно меняется каждый день.

                                                    Конфиги приложения обычно тоже не каждый день меняются, но обычно их задаёт разработчик, и только для некоторых их частей разработчик предусматривает штатную возможность изменения при разворачивании, типа одного parameters.ini.dist когда общее число конфигов за десяток.


                                                    Вроде суть в том, что люди в принципе боятся его трогать и не используют ни в prod ни в dev. А вовсе не о том, что в одном и том же проекте каждый должен написать свой Dockerfile.

                                                    С чего начинается "трогание"? Установили, запустили busybox, чтобы проверить что работает, и пишем свой докерфайл для своего приложения, постепенно (иногда почти моментально) выясняя, что не всё так просто как в примерах в хвалебных статьях, где, например, образ собирается исключительно из публичных репозиториев и никакие секреты ему не нужны. А увидишь пример из реальной жизни типа докерфайла с десятком билдаргументов и тремя десятками енв-переименных для запуска и как-то страшно становится :)

                                                    • 0
                                                      Если не собрала, то чья эта ответственность?

                                                      Не собраться он может только в одном случае, если разработчик там что-то поменял. Ибо он лежит по умолчанию рабочий. Я даже больше скажу, на CI сервере он лежит в кеше. И когда разработчик пушит свой код, в Dockerfile отрабатывает только копирование файлов в контейнер и не больше. Если был изменён composer.json то слой с установкой зависимостей тоже пересобирается. Все остальные низкоуровневые задачи в виде установки расширений к php и прочее лежит в глубоком кеше и пересобирается крайне редко. Может быть чуть чаще, чем выходит новая версия php.

                                                      Если у вас контролируется всё, что на прод уходит, то и вредные изменения в Dockerfile не пройдут.

                                                      Изменения в Dockerfile в 99% случаях просто не нужны. Если у Вас в него постоянно вносятся изменения, поделись, какого рода изменения. Мне интересно, зачем каждому разработчику свой персональный Dockerfile.

                                                      Конфиги приложения обычно тоже не каждый день меняются, но обычно их задаёт разработчик, и только для некоторых их частей разработчик предусматривает штатную возможность изменения при разворачивании, типа одного parameters.ini.dist когда общее число конфигов за десяток.

                                                      Не совсем понял о чём речь. У нас почти любой параметр из конфига можно переопределить передав его через ENV при старте контейнера. Эти параметры разработчик может менять как угодно, при чём тут сборка контейнера?

                                                      • 0

                                                        Не факт, там может быть composer install тянущий какой-то пакет, у которого сто требованиях стоит ext-*.


                                                        Не каждому разработчику, а в каждый проект. Те же расширения PHP устанавливать, например. Ну а в случае дев-окружения там много чего может быть. Кому-то mc хочется, кому-то htop и vim и т. п. — тут уже можно подумать о Dockerfile.dev.dist в репе и Dockerfile.dev в игноре.


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

                                                        • 0
                                                          Не факт, там может быть composer install тянущий какой-то пакет, у которого сто требованиях стоит ext-*.

                                                          Это как раз повод изменить Dockerfile. Ибо как вы без этих изменений собираетесь это на prod выкладывать? И эти изменения в итоге коснутся всех, когда PR будет принят, а не только dev окружения одного конкретного разработчика.

                                                          Не каждому разработчику, а в каждый проект.

                                                          Ну естественно, один проект — один Dockerfile.

                                                          Ну а в случае дев-окружения там много чего может быть. Кому-то mc хочется, кому-то htop и vim и т. п.

                                                          Зачем? Файлы проекта в dev окружении лежат на машине и доступны из IDE. Если надо что-то подправить в конфиге где то в /usr/local/etc/php, его тоже можно пробросить с хоста.
                                                          По поводу htop, процессы запущенные внутри контейнера видны в htop с локальной машины как локальные (в линуксе)
                                                      • +2
                                                        Как раз недавно начал «трогать» этого зверя. Где-то неделя в ленивом режиме(часов 10 максимум) на изучение кучи примеров, мануалов, docker-flow и написание своего билда. Да, практически каждый шаг требовал гугления, но гугление проходило без проблем, и решение относительно быстро находилось. У меня как раз кейс переноса среды веб разработки в докер, ибо при переезде на новую машину захотелось избавиться от зоопарка левых библиотек на компе, которые накопились при разработке десятка вполне «однотипных» проектов с небольшими отличиями.

                                                        Можно считать минусом то, что написание конфига для докера требует знаний в администрировании, но это так же и плюс — есть возможность подучить что-то новое. Но даже если нет ни знаний, ни желания их получать — копипаста куска конфига из гугла + допиливание напильником по результатам гугления ошибки позволяют собрать контейнер.

                                                        Можно назвать минусом ужасные на вид неофита конфиги, но на самом деле это не так часто нужно для работы. Мне для создания окружения пришлось создать всего один короткий DockerFile — чтобы к базовому образу php:5.6-fpm добавить либы mysqlnd, mysqli, redisphp. Nginx, Redis и mariaDB без проблем подтянулсь и настроились из официальных образов. В результате у меня на проект есть — аккуратный docker-compose.yml, один DockerFile для php, два конфиг файла для нгинкса, плюс папки с приложением, логами и БД которые мапятся в нужные контейнеры.

                                                        И для других разрабатываемых приложений я просто скопирую этот набор, максимум внесу небольшие правки в него, если понадобится новый модуль или поменять версию одного из текущих, и запущу docker-compose.

                                                        Так же, если в фирму придёт новый разработчик на один из проектов для которых у меня готов билд — вместо того чтобы объяснять ему что он должен поднять на своей машине это, то, вот то, а вот это настроить вот так — я ему скину архив с docker проектом, или ссылку на git, если к тому моменту залью это в наш репозиторий.

                                                        Я не рассматриваю использование докера на проде, но конкретно для разработчика, особенно если приходится переключаться между разными проектами — он очень удобен. Впрочем, мой коллега вполне успешно для тех же целей использует вагрант.
                                            • 0
                                              > В Docker для Mac и Windows есть базовые средства интеграции с Kitematic, например

                                              А в Docker для Linux? раз уж это миф — так развенчайте для всех платформ.
                                              • +1
                                                Под Linux можно использовать portainer.
                                              • 0

                                                Выше советовали LXC, а я посоветую стек Vagga+Lithos (vagga.readthedocs.io) для дев+прод.
                                                Довольно много проблем докера тут просто не по чувствуются (как и фишки типа изоляции сети, но насколько я знаю работа в этом направлении идёт.

                                                • +1
                                                  К счастью, разработчики Docker прекрасно понимают необходимость поддержки не только Linux в качестве базовой ОС.
                                                  Во второй половине 2016 года были выпущены официальные релизы Docker для Mac и Windows.


                                                  На маке volumes нещадно тормозят, проблема открыта с марта 2016 года (актуально для Docker for Mac)
                                                  https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076
                                                  • 0

                                                    Да, активно слежу за этой веткой. Сижу на докер бета и периодически в обновлениях пишут что-то типа fix mounted volumes CPU, но к сожалению как тормозило безбожно так и продолжает. Надеюсь разработчики не забили на эту проблему. Пробовал разные сторонние решения типа d4m nfs, но с ним другие проблемы возникают, ибо костыль

                                                    • 0
                                                      Мы откатились на docker toolbox/docker machine.

                                                      Вообще тенденция развития docker inc слегка настораживает, уж больно сильно начинает пахнуть упором на платные enterprise-подписки и тотальным vendor lock-in.

                                                      elasticsearch почему-то перенёс имаджи в свой приватный репозиторий.
                                                      • 0
                                                        Кстати да, как получил письмо о создании Docker Enterprise-чототам, расстроился малость.
                                                        • 0
                                                          +1, отпочковывание community edition на днях меня не сильно порадовало. Еще и вместо хаба какой-то новый стор… Печально это
                                                    • 0
                                                      Чтобы использовать docker for windows нужна поддержка hyper-v, а она, к сожалению, доступна не во всех редакциях windows -> ссылка
                                                      • +4
                                                        А давайте начистоту:

                                                        1. Докер сложный.

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

                                                        2. Докер глючный.

                                                        И не говорите, что это не так. Колонка issues на гитхабе цветёт и пахнет, многие вещи подпираются костылями или ожидают внимания со стороны комьюнити очень долго. Самый простейший пример из важных — приложение в докере не получает правильный ip клиента (в Swarm mode), костыль в виде использования publish mode=host и глобального режима достаточно сомнителен, чтобы называть это изящным решением.

                                                        3. На маке он действительно безбожно тормозит.

                                                        Об использовании volume mounts не может быть и речи. О полноценном продакшене тоже, он частенько просто перестаёт запускаться при перезагрузке операционки.

                                                        4. У докера отвратительная документация.

                                                        Последняя версия доки по Remote API — вообще абзац.

                                                        В общем, создав и поддерживая систему, обеспечивающую работу более полутора тысяч приложений на докере, иногда подумываю, что можно было обойтись и chroot'ом, единственный минус которого — балансировщик пришлось бы руками писать.
                                                        • +2
                                                          А то, что настройка сетевой коммуникации между контейнерами со временем превращается в ад, это миф?
                                                          • +1
                                                            А можно по-подробнее? Я с таким еще не сталкивался, звучит пугающе
                                                          • 0
                                                            Статья полна ошибок, которые очень хорошо показывают насколько хорошо автор понимает природу контейнеров. Мне было бы стыдно переводить такую статью. Примеры:

                                                            While a Docker container may not technically be a full virtual machine, it does run a Linux distribution under the hood.

                                                            Docker, как и LXC, не имеет ничего общего с виртуализацией. И поэтому там просто не может быть Linux под капотом. Все контейнеры используют cgroups Linux'ового ядра на «хост-машине». В контейнер можно конечно запихнуть весь userspace обычного Linux'а (как это делается в LXD), но сам Linux не «под капотом», а снаружи (банально внтури контейнера можно выполнить uname -a и будет видно что используется ядро хост-машины)

                                                            In the past, Docker on Mac and Windows required the use of a full virtual machine with a “docker-machine” utility and a layer of additional software proxying the work into / out of the vm.

                                                            Для работы с Docker (или любым другим cgroups toolchain, таким как LXC например) на Darwin/Windows всегда придется использовать виртуализацию, она просто не может уйти в прошлое, так как (повторяюсь) все контейнеры это обертка к linux cgroups, до тех пор пока Windows и Darwin не перейдут на GNU Linux в качестве ядра, нативных контейнеров там никогда не будет.
                                                            • 0

                                                              Насчёт винды есть нюансы. С одной стороны, МС объявила об "эмуляции" Linux Kernel API в последних виндах, с другой — есть нативные контейнеры, рассчитанные на то, что ядро NT, а не Linux.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое