Comments 36
Объясните мне кто-нибудь, а для чего мне все это нужно? Усть у меня сервер, на нем нормально крутится nginx + php + mysql и всякое такое.
Что мне дает запихивание этих сервисов в контейнеры? (стабильность, производительность etc...)
Где (dev / prod) это делать уместно, а где нет?
Как все это администрировать? Если обычно у меня есть "$service --status-all" [start|stop|resrtart|reload], что делать при перемещении сервисов в контейнеры?
В общем пока для меня докер создал больше вопросов, чем ответов.
Единственный действительно ощутимый плюс — кросплатформенность. В докере (на Deb 8) у меня отлично заработало приложение предназначенное исключительно для CentOS.
Что мне дает запихивание этих сервисов в контейнеры? (стабильность, производительность etc...)
Где (dev / prod) это делать уместно, а где нет?
Как все это администрировать? Если обычно у меня есть "$service --status-all" [start|stop|resrtart|reload], что делать при перемещении сервисов в контейнеры?
В общем пока для меня докер создал больше вопросов, чем ответов.
Единственный действительно ощутимый плюс — кросплатформенность. В докере (на Deb 8) у меня отлично заработало приложение предназначенное исключительно для CentOS.
Вот здесь есть удобная площадка для тренировки labs.play-with-docker.com
- воспроизводимость окружения, чтобы не случилось так, что разработчик говорит, что у него всё работает, а при разворачивании на сервере всё ломается из-за того, что разработчик забыл описать в требованиях какую-то зависимость.
- изолированость окружения, чтобы не случилось так, что для работы одному проекту нужна версия 1 какого-то инструмента, а другому проекту — версия 2, а одновременно на одну машину эти версии не становятся.
- поддержка чистоты на хост-машине, чтобы не случилось так, что для проекта нужно установить с десяток зависимостей, которые потом нужно долго и нудно выковыривать из системы, контейнер удаляется в одну команду, не зависимо от того, насколько глубоко пакеты в нём интегрированы в систему
- замена пакетному менеджеру(?), чтобы не случилось так, что для вашего дистрибутива или для вашего пакетного менеджера нет готовых бинарников нужного пакета, можно просто поднять его в докере и не морочить себе голову с курением мануалов (на самом деле этот пункт — лишь забавный побочный эффект от других преимуществ докера)
- простота разворачивания, чтобы можно было проще настраивать инструменты непрерывного развертывания
чтобы не случилось так, что для вашего дистрибутива или для вашего пакетного менеджера нет готовых бинарников нужного пакета, можно просто поднять его в докере и не морочить себе голову с курением мануалов
Не понимаю, внутри докера ОС ведь будет та же, что и на хосте? Или это похоже на OpenVZ контейнер, где можно поставить любую ОС?
Докер использует лишь ядро. ОС, а точнее, дистрибутив Линукса, по сути набор программ и утилит поверх ядра. Вот Докер так и делает
Да, в контейнере может быть любая система
Докер использует от хостового линукса только ядро (это если говорить упрощенно). Поэтому внутри контейнера можно поднять абсолютно любой дистрибутив. Часто там используются специально заточенные под использование внутри контейнера минимальные версии дистрибутивов. OpenVZ использует очень похожий подход, но сложнее в использовании и не имеет столь широкой базы готовых контейнеров
У меня есть web приложение, работающее на nginx + php + mysql + несколько консольных утилит, сейчас работает на отдельной физической машине. Docker подходит для запуска всего этого в контейнере? Хотелось бы избавиться от отдельной физической машины.
Я просто вчера почитал про docker и я так понял, что основной подход, который он проповедует, это одно приложение в одном контейнере. Может я не прав, но по моему это перебор. Например есть образы с одним только phpmyadmin или вообще только с одним composer, это же дикий overhead.
Я просто вчера почитал про docker и я так понял, что основной подход, который он проповедует, это одно приложение в одном контейнере. Может я не прав, но по моему это перебор. Например есть образы с одним только phpmyadmin или вообще только с одним composer, это же дикий overhead.
Для вас оптимально будет использовать docker-compose с тремя контейнерами — отдельно nginx, отдельно mysql (можно брать прямо официальные образы), отдельно php-fpm+утилиты (скорее всего придется сбилдить свой образ на основе официального, но это несложно, в него же можно прикрутить composer с phpmyadmin), возможно еще +контейнер под хранение файлов если связку предполагается таскать с машины на машину. Можно заводить отдельный контейнер на phpmyadmin, а можно и нет. Но работать с кучей небольших официальных образов контейнеров часто проще, чем городить один свой, в котором запихнуто всё. И вся эта конструкция будет элементарно запускаться/глушиться одной командой.
Спасибо.
А почему nginx и mysql не поставить в тот же контейнер, где и php-fpm с утилитами? Может mysql вообще на хост машине оставить с отдельной учетной записью?
Я, наверное, чего-то до конца не понимаю, но мне пока не очень понятна вот эта концепция с кучей контейнеров.
Да, еще nginx и утилиты у меня из исходников собранные, в docker не будет проблем со сборкой из исходников?
А почему nginx и mysql не поставить в тот же контейнер, где и php-fpm с утилитами? Может mysql вообще на хост машине оставить с отдельной учетной записью?
Я, наверное, чего-то до конца не понимаю, но мне пока не очень понятна вот эта концепция с кучей контейнеров.
Да, еще nginx и утилиты у меня из исходников собранные, в docker не будет проблем со сборкой из исходников?
А почему nginx и mysql не поставить в тот же контейнер, где и php-fpm с утилитами?
Потому что гораздо быстрее взять готовые образы и подключить их к связке, чем устанавливать их внутрь контейнера основного приложения. И бонусом получить горизонтальное масштабирование на проде
Внутри контейнера вообще может не быть никакого дистрибутива линукса, например если контейнер содержит в себе приложение Python, или Java. Или nginx например. Т.е. контейнер содержит только то что нужно для запуска приложения, для которого этот контейнер был создан.
Нет, хоть урезанный, но линукс будет. Откройте Dockerfile любого образа контейнера на докер хабе и посмотрите что там происходит. Обычно в самой первой директиве FROM описано какой дистрибутив взят за основу. Но даже если там написано FROM scratch, всё равно используется докеровский дистрибутив по умолчанию
Чтобы запустить приложение, нужен интерпретатор или JVM, а они ведь ОС-зависимые
Что мне дает запихивание этих сервисов в контейнеры?
Возможность поднять ещё десяток таких же серверов одной строкой.
что делать при перемещении сервисов в контейнеры?
docker logs, docker start, docker inspect...
Докер позволяет сформировать и сохранить стабильную и воспроизводимую в любом месте и количестве среду для работы приложений.
Соответственно, правильно собирая докерные кубики — можно быстро экспериментировать с композициями приложений, не отвлекаясь на артефакты установок-переустановок, общие зависимости и взаимные побочные эффекты.
Как все это администрировать? Если обычно у меня есть "$service --status-all" [start|stop|resrtart|reload], что делать при перемещении сервисов в контейнеры?
Простой ответ — docker ps.
Но учитывая, что у вас простое приложение и вы не задумываетесь о репликации, то вам не нужен докер.
Потому что, когда вам понадобится докер, вам понадобится:
1. Билд-сервер (Jenkins/TeamCity/etc), потому как не удобно готовить контейнеры ручками. А тут сервер, который берет из git-а и автоматизирует
2. Либо DockerHub, либо локальный репозитарий. Если репозитарий локальный, то вам понадобится сертификат (действительный, либо самоподписанный но который принимают сервера)
3. Watchdog на хост-сервере, чтобы следит за обновлениями в репозитарии.
В итоге, у вас будет инфраструктура, в которой по пушу будет собираться приложение, выкладываться в репозитарий и ставится в прод или в тест.
Предположим, вам нужно запустить 50 веб-приложений, причем у некоторых могут быть разные требования к версии Python или версии java.
И вы хотите, чтобы приложения крутились максимально независимо друг от друга, не знали друг о друге, и одним кликом вы могли бы их развернуть или тут или на другой машине.
Простое решение независимости — виртуальные машины.
Вопрос, сколько виртуальных машин вы запустите на вашем сервере?
А 50 докер контейнеров — могут вполне влезть, потому что с небольшим навеском, это по памяти и CPU практически сами приложения. Да и по диску неслишком больше.
И вы хотите, чтобы приложения крутились максимально независимо друг от друга, не знали друг о друге, и одним кликом вы могли бы их развернуть или тут или на другой машине.
Простое решение независимости — виртуальные машины.
Вопрос, сколько виртуальных машин вы запустите на вашем сервере?
А 50 докер контейнеров — могут вполне влезть, потому что с небольшим навеском, это по памяти и CPU практически сами приложения. Да и по диску неслишком больше.
Вопрос возможно дурацкий, но все же.
Насколько оно кроссплатформено в итоге?
Вот под windows, например, заведется линуксовый контейнер?
Docker можно запускать локально на Linux, Mac и Windows.
Насколько оно кроссплатформено в итоге?
Вот под windows, например, заведется линуксовый контейнер?
UFO just landed and posted this here
Ой, вот купился я на то, что под Windows можно легко и просто запускать Linux Docker контейнеры.
Сначала выяснили, что если это Windows сервер под VMWare, то во-первых важна версия. Ниже определенной не работает Hyper-V. Linux хостов это ограничение не касается, кстати.
Затем, когда проапгрейдили версию, все равно не заработало. Выделили физическую железку. Под ней тоже пляски с бубном: то оно сходу не поднимается, надо убить процесс, потом стартовать приложение под правами админа и тому подобное.
В GitHub issues for Windows уже пару лет не закрытые проблемы на винду.
Ну и самое обидное, что на рабочем виндовом компе всё работает.
Сначала выяснили, что если это Windows сервер под VMWare, то во-первых важна версия. Ниже определенной не работает Hyper-V. Linux хостов это ограничение не касается, кстати.
Затем, когда проапгрейдили версию, все равно не заработало. Выделили физическую железку. Под ней тоже пляски с бубном: то оно сходу не поднимается, надо убить процесс, потом стартовать приложение под правами админа и тому подобное.
В GitHub issues for Windows уже пару лет не закрытые проблемы на винду.
Ну и самое обидное, что на рабочем виндовом компе всё работает.
Учитывая, что если включить VMWare/Hyper-V, то, фактически, перестают работать другие виртуалки, то у нас многие не заморачиваются с «нативным» докером под виндой, а ставят в Virtualbox любой серверный линукс и ставят докер уже на него. С одной стороны, добавляется немного головной боли на пробрасывание ресурсов туда-сюда, с другой — нет проблем с несовместимостью VMWare/Hyper-V, всё отлично работает хоть из-под XP
UFO just landed and posted this here
Подскажите пожалуйста прав ли я. Использование Докера оправдано в том случае, если потом это же приложение будет работать в другом месте под Докером — тогда не надо будет ничего перенастраивать.
Если же я локально делаю что-то под докером, а потом переношу это (условно) на хостинг, где докерами и не пахнет, я имею точно такие же шансы заиметь проблемы с разными настройками, несовместимостями и т.п. как и если бы я разрабатывал приложение под обычной ОС?
Если же я локально делаю что-то под докером, а потом переношу это (условно) на хостинг, где докерами и не пахнет, я имею точно такие же шансы заиметь проблемы с разными настройками, несовместимостями и т.п. как и если бы я разрабатывал приложение под обычной ОС?
Докер нужен для того, чтобы легко перенести приложение например из разработки в продакшен, и при этом никаких зависимостей в саму ОС не устанавливать, поскольку все уже собрано внутри конкретного docker image.
Нет смысла разрабатывать приложение для работы в контейнере, а потом выдрать его из контейнера и запускать как обычно.
Нет смысла разрабатывать приложение для работы в контейнере, а потом выдрать его из контейнера и запускать как обычно.
Подскажите, а где хранить docker compose если две части приложения находятся в разных репозиториях, но должны взаимодействовать на продакшине?
Во всю эту красотишшу надо добавить пару камушков, ну чтобы юные падаваны не расшибли себе лоб.
1. Докер практически исключительно для кода, не для данных. Данные надо держать где-то снаружи, и потом пробрасывать внутрь контейнеров папки/диски/луны/чотамувас для тех данных, которые должны пережить рестарт контейнера. Не, ну если надо на локалхосте поставить какого-нибудь монстра, два часа потыкать в него и снести — можно и внутри данные хранить. В тестовых контейнерах опять же можно. Но на проде так делать не надо.
2. Вводя докер, вы переходите на коммуникации через tcp/ip. Монолитный nginx + php-fpm + mysql на сокетах может работать раза в два быстрее, чем то же самое, но в отдельных контейнерах по локальному tcp/ip. Потому что сокет он в разделяемой общей памяти и без копирования, а по сети данные минимум трижды копируются при упаковке/распаковке пакетов.
3. Вводя докер, вы вводите серьёзные зависимости непонятно от кого. Ну, точнее, следите, чьи именно репы вы используете. Они могут что-нибудь сломать в очередном апдейте (бывало и много раз), или вообще запихать какую-нибудь гадость (не слышал, но...).
1. Докер практически исключительно для кода, не для данных. Данные надо держать где-то снаружи, и потом пробрасывать внутрь контейнеров папки/диски/луны/чотамувас для тех данных, которые должны пережить рестарт контейнера. Не, ну если надо на локалхосте поставить какого-нибудь монстра, два часа потыкать в него и снести — можно и внутри данные хранить. В тестовых контейнерах опять же можно. Но на проде так делать не надо.
2. Вводя докер, вы переходите на коммуникации через tcp/ip. Монолитный nginx + php-fpm + mysql на сокетах может работать раза в два быстрее, чем то же самое, но в отдельных контейнерах по локальному tcp/ip. Потому что сокет он в разделяемой общей памяти и без копирования, а по сети данные минимум трижды копируются при упаковке/распаковке пакетов.
3. Вводя докер, вы вводите серьёзные зависимости непонятно от кого. Ну, точнее, следите, чьи именно репы вы используете. Они могут что-нибудь сломать в очередном апдейте (бывало и много раз), или вообще запихать какую-нибудь гадость (не слышал, но...).
Мы работаем с Docker Swarm + Ceph. Все работает неплохо. Мы планируем перенести в Swarm больше как наших собственных, так и сторонних приложений. Но есть проблемка:
Допустим, я развернул 10 сторонних приложений в виде docker swarm stack'ов. Я делаю это с помощью команды Docker stack deploy. Отдаю ему файл docker-compose (часто, в свою очередь, составленный из нескольких файлов docker-compose-*.yml, скомпилированных через docker-compose config). Но, если я хочу что-то изменить в стеке, мне часто нужны мои исходные файлы compose. Существует ли какой-либо реестр для дескрипторов развертывания docker-compose? Как реестр образов Docker, но для дескрипторов docker-compose?
Одна из идей, которые приходят на ум, состоит в том, чтобы завести Git или Mercurial репозиторий с некоторой структурой каталогов для версионирования дескрипторов развёртывания. Эта идея выглядит интересной, но работает (полу)хорошо только для сторонних приложений. С нашими собственными приложениями это добавляет проблем, так как мы часто используем CI/CD (тот самый пресловутый дженкинс и развёртывание на стейджинг после того, как тесты пройдут успешно). И это будет означать, что нам нужно извлечь еще один репозиторий во время развертывания, заменить deployment-дескрипторы для наших приложений и закоммитить их. Это может быть проблематично, так как это может привести к merge конфликтам и т. д. Да и вытягивать целый репозиторий ради коммита одного файла…
Видел забавное решение, когда docker-compose.yml запаковывается в docker image FROM docker/compose (https://hub.docker.com/r/docker/compose/) и пушится в локальный докер регистри. Но это решение тоже не супер, т.к., по сути, никакого версионирования между docker-compose-файлами нет.
Чтобы не кормить троллей: речь не идёт о Dockerfile, имейджах, билд-дкриптах и т.д. Это всё хранится в нормальных git/HG вместе с исходниками самих приложений и спользуется во время CI. Чтобы нагляднее представить себе проблему: представьте, что у вас несколько десятков stack'ов запущено в swarm'e. И вот вам понадобилось, скажем, заменить volume-driver. Для этого нужно взять тот докер-композ файл, из которого каждый стэк разворачивался и поправить в нём конфигурацию томов. А где взять все эти десятки композов? Они деплоились разными людьми в разное время с разных хостов.
В идеале, решение, которое я ищу, должно обеспечить простой способ получить последние версии дескрипторов развертывания определенного (развернутого) стека и одновременно содержать их предыдущие версии. Кроме того, чтобы я мог легко обновлять дескрипторы развертывания — без вытягивания всего git/hg репозитория
Как вы, ребята, управляете своими файлами для создания докеров, если их слишком много?
Допустим, я развернул 10 сторонних приложений в виде docker swarm stack'ов. Я делаю это с помощью команды Docker stack deploy. Отдаю ему файл docker-compose (часто, в свою очередь, составленный из нескольких файлов docker-compose-*.yml, скомпилированных через docker-compose config). Но, если я хочу что-то изменить в стеке, мне часто нужны мои исходные файлы compose. Существует ли какой-либо реестр для дескрипторов развертывания docker-compose? Как реестр образов Docker, но для дескрипторов docker-compose?
Одна из идей, которые приходят на ум, состоит в том, чтобы завести Git или Mercurial репозиторий с некоторой структурой каталогов для версионирования дескрипторов развёртывания. Эта идея выглядит интересной, но работает (полу)хорошо только для сторонних приложений. С нашими собственными приложениями это добавляет проблем, так как мы часто используем CI/CD (тот самый пресловутый дженкинс и развёртывание на стейджинг после того, как тесты пройдут успешно). И это будет означать, что нам нужно извлечь еще один репозиторий во время развертывания, заменить deployment-дескрипторы для наших приложений и закоммитить их. Это может быть проблематично, так как это может привести к merge конфликтам и т. д. Да и вытягивать целый репозиторий ради коммита одного файла…
Видел забавное решение, когда docker-compose.yml запаковывается в docker image FROM docker/compose (https://hub.docker.com/r/docker/compose/) и пушится в локальный докер регистри. Но это решение тоже не супер, т.к., по сути, никакого версионирования между docker-compose-файлами нет.
Чтобы не кормить троллей: речь не идёт о Dockerfile, имейджах, билд-дкриптах и т.д. Это всё хранится в нормальных git/HG вместе с исходниками самих приложений и спользуется во время CI. Чтобы нагляднее представить себе проблему: представьте, что у вас несколько десятков stack'ов запущено в swarm'e. И вот вам понадобилось, скажем, заменить volume-driver. Для этого нужно взять тот докер-композ файл, из которого каждый стэк разворачивался и поправить в нём конфигурацию томов. А где взять все эти десятки композов? Они деплоились разными людьми в разное время с разных хостов.
В идеале, решение, которое я ищу, должно обеспечить простой способ получить последние версии дескрипторов развертывания определенного (развернутого) стека и одновременно содержать их предыдущие версии. Кроме того, чтобы я мог легко обновлять дескрипторы развертывания — без вытягивания всего git/hg репозитория
Как вы, ребята, управляете своими файлами для создания докеров, если их слишком много?
В конце статьи не хватает ссылки на следующую часть. Приходится в начало крутить, где ссылки на все части.
Sign up to leave a comment.
Изучаем Docker, часть 2: термины и концепции