Comments 19
Название звучит как «Знакомство в Docker для самых маленьких»
Также удобно сделать сервер доступным снаружи контейнера, для этого мы запускаем его на 0.0.0.0 IP
0.0.0.0 указывает на то, что созданный сервер будет доступен на всех интерфейсах контейнера
Как вариант — некоторое время использовался Vagrant, но это всё-таки ovrerhead и наши поиски оптимального способа привели, на данный момент, к Docker.
OSX и MS Windows пользователи могут использовать VirtualBox, на котором установлена Linux система для того, чтобы запустить Docker.
То есть просто Virtualbox это overhead, а Docker из под VirtualBox это норм. О-ок.
Уже который месяц присматриваюсь к докеру, читаю статьи и хаутушки и все они почему-то оказываются очень поверхностными:( В итоге тратишь время на статью, а потом все равно идешь копать доки и разбираться самостоятельно. В данной статье грубо говоря вообще ничего нет, ни толком плюсы/минусы не описаны, не описано хранение файлов проекта и базы при перезапуске образов, как и сохранение изменений в самом образе(обновления/добавление софта). Плюс везде предлагается вынесение каждого сервиса в отдельный контейнер(вебсервер отдельно, база отдельно, приложение отдельно), но это ведь бесполезное усложнение на этапе разработки, хотя и деплой тоже усложняется. Для мелких проектов это бессмысленно, а для крупных в чем смысл использования именно докера, почему не использовать сразу отдельные впски/сервера под базу/сервер/приложение?
Я тоже попробовал, и без понимания того, что Вы описали — не совсем понятно, что это и чем оно лучше openvz/lxc контейнера, вот если бы кто эту часть нормально обьяснил…
Docker — это обёртка над lxc.
Есть и ещё одна функция, слои. Слой — это как commit в git.
Т.е. пишите вы свой Dockerfile
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
И при каждом изменении nginx.conf будет создаваться новый коммит.
Хранить эту историю изменений можно публично hub.docker.com/, либо приватно github.com/docker/docker-registry.
Удобно, если новая версия перестала работать, можно откатить до работающей.
И скоро они сделают своё средство для оркестрации, и тогда можно будет без проблем работать с зоопарком контейнеров.
Вроде, всё
Есть и ещё одна функция, слои. Слой — это как commit в git.
Т.е. пишите вы свой Dockerfile
FROM nginx
COPY nginx.conf /etc/nginx/nginx.conf
И при каждом изменении nginx.conf будет создаваться новый коммит.
Хранить эту историю изменений можно публично hub.docker.com/, либо приватно github.com/docker/docker-registry.
Удобно, если новая версия перестала работать, можно откатить до работающей.
И скоро они сделают своё средство для оркестрации, и тогда можно будет без проблем работать с зоопарком контейнеров.
Вроде, всё
немного уточню
Да, слои — это подобие коммитов в `git`, но только вот слой создается не при каждом изменении nginx.conf, а в двух случаях:
1. вы пишете свой Dockerfile, по которому билдите свой образ и при этом каждая запись в `Dockerfile` (`ADD`, `COPY`, `RUN`) будет генерировать новый слой. имейте в виду, что если вы пишете
то будет сгенерировано 4 слоя — каждый слой увеличивает размер результируючего образа в результате записи новых мета-данных. я специально привел в пример команды, которые в принципе (за исключением записи в `~/.bash_history`, но я не уверен, что он пишется во время билда образа) не должны ничего писать в файловую систему. потому все, что Вы будете делать через команду RUN лучше записывать в виде одной большой команды:
этом случае будет создано один слой
2. если Вы идете другим путем: можно запустить контейнер с интерактивной консолью `docker run -it imagename /bin/bash` (по сути Вы будете находиться в комендной оболочке контейнера), что-то там устанавливать, настраивать и писать. когда вы произведете некоторые нужные Вам действия (установите тот же `nginx` и настроите его), то Вы можете сделать коммит этих изменений в следуюющий слой (аналог коммита в `git`). при этом у Вас в дереве слоев образа добавится новый слой с изменениями. каждый слой можно тегировать — это и есть названия образов. можно смотрить изменения, которые были произведены (`diff`).
но я не советую использовать второй вариант поскольку если нужно будет поделиться этим образои или перенести или забекапить, то вам придется передавать его полностью. в случае же когда Вы пишете `Dockerfile`, вы все Ваши дейсвтия, производимые непосредственно в консоли, записываете командой `RUN` и дополнительно, если требуется, добавление файлов (готовых конфигов, к примеру). потом по этму файлу (наборов файлов если требуется `Dockerfile` + файлы конфигов, которые вы прописали в `Dockerfile` с помощью команд `ADD`, `COPY`) можно сбилдить образ, этими файлами проще поделиться — они намного меньше, чем результируючий образ — и другой человек тоже сбилдит образ на основе этих файлов
Да, слои — это подобие коммитов в `git`, но только вот слой создается не при каждом изменении nginx.conf, а в двух случаях:
1. вы пишете свой Dockerfile, по которому билдите свой образ и при этом каждая запись в `Dockerfile` (`ADD`, `COPY`, `RUN`) будет генерировать новый слой. имейте в виду, что если вы пишете
RUN echo "Hello"
RUN echo "World"
RUN echo "My name is Vasya!"
RUN echo "Bye!"
то будет сгенерировано 4 слоя — каждый слой увеличивает размер результируючего образа в результате записи новых мета-данных. я специально привел в пример команды, которые в принципе (за исключением записи в `~/.bash_history`, но я не уверен, что он пишется во время билда образа) не должны ничего писать в файловую систему. потому все, что Вы будете делать через команду RUN лучше записывать в виде одной большой команды:
RUN apt-get update && apt-get install nginx -y && apt-get clean
этом случае будет создано один слой
2. если Вы идете другим путем: можно запустить контейнер с интерактивной консолью `docker run -it imagename /bin/bash` (по сути Вы будете находиться в комендной оболочке контейнера), что-то там устанавливать, настраивать и писать. когда вы произведете некоторые нужные Вам действия (установите тот же `nginx` и настроите его), то Вы можете сделать коммит этих изменений в следуюющий слой (аналог коммита в `git`). при этом у Вас в дереве слоев образа добавится новый слой с изменениями. каждый слой можно тегировать — это и есть названия образов. можно смотрить изменения, которые были произведены (`diff`).
но я не советую использовать второй вариант поскольку если нужно будет поделиться этим образои или перенести или забекапить, то вам придется передавать его полностью. в случае же когда Вы пишете `Dockerfile`, вы все Ваши дейсвтия, производимые непосредственно в консоли, записываете командой `RUN` и дополнительно, если требуется, добавление файлов (готовых конфигов, к примеру). потом по этму файлу (наборов файлов если требуется `Dockerfile` + файлы конфигов, которые вы прописали в `Dockerfile` с помощью команд `ADD`, `COPY`) можно сбилдить образ, этими файлами проще поделиться — они намного меньше, чем результируючий образ — и другой человек тоже сбилдит образ на основе этих файлов
Ну вот я и хотел сказать что это должно быть также описано в статье, а мой вопрос был о другом. Что такое докер и какие у него возможности я давно уже изучил, но до сих пор я не вижу «места» где действительно есть смысл его использовать, вместо тех же контейнеров/виртуальных машин/отдельных серверов. При первом знакомстве с докером я подумал вот оно счастье: упакую сейчас каждый сайт в свой контейнер со своим софтом/базой и буду запросто переносить его куда мне нужно и просто бекапить — красота. Но разбираясь дальше я пришел к выводу что цели у докера другие и использовать его так как я хочу хоть и можно, но не так уж удобно. С тех пор пытаюсь понять где же его ниша и в какой ситуации он будет полезен.
докер — это инструмент, который работает с lxc-контейнерами и предоставляет расширенній API для работы. на сколько мне известно, то lxc зависим от конфигурации системы и его не так уж просто перенести на другой хост. докер же делает возможным в несколько команд развернуть контейнер, который крутился на одном хосте, развернуть на другом. идея докера состоит в том, чтобы именно упаковать некое приложение или приложения и запустить его в изолированном контейнере.
для примера, можно без особых проблем на одном хосте в контейнерах запустить несколько версий серверов БД и иметь доступ к ним через разные порты
лично для себя докер мне удобен тем, что я могу экспериментировать с софтом, вести веб-разработку и при этом держать хост-машину в чистоте
для примера, можно без особых проблем на одном хосте в контейнерах запустить несколько версий серверов БД и иметь доступ к ним через разные порты
лично для себя докер мне удобен тем, что я могу экспериментировать с софтом, вести веб-разработку и при этом держать хост-машину в чистоте
для начала посоветую познакомиться с коротким русскоязычным гайдом
Как вариант — некоторое время использовался Vagrant, но это всё-таки ovrerhead и наши поиски оптимального способа привели, на данный момент, к Docker.
Vagrant не исключает Docker, более того, Vagrant поддерживает его уже не первый день.
> Когда наш контейнер будет запущен, внутри него запустится команда “ls”, которая покажет все файлы и фильтры в главной директории.
О чем речь, что за фильтры?
О чем речь, что за фильтры?
Мне кажется, что всю статью надо было свести к последнему абзацу и ссылкой на fig.sh. На мойвзгляд fig может смело покрыть все нужды как локальной разработки, так и тестирования на удаленном сервере.
вот вы вспомнили о тестировании на удаленном сервере. сейчас я придумываю как сделать приемочное тестирование на хост-машине из-под контейнера. но пока ничего толкового не приходит в голову ибо, скорее всего, это невозможно. тоесть, невозможно из-под докера запустить firefox на хост-машине. а поднимать в докере xserver как-не нерезонно
а что Вы скажете о приемочном тестировании в докере? понимаю, что юнит-тесты раскрутить не проблема и можно проводить приемочные тесты в фантоме, но вопрос именно о firefox
а что Вы скажете о приемочном тестировании в докере? понимаю, что юнит-тесты раскрутить не проблема и можно проводить приемочные тесты в фантоме, но вопрос именно о firefox
Sign up to leave a comment.
Быстрое знакомство с Docker-контейнерами для Django-разработчика