Ответ 1

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

1. Изолировать услуги

Аннотация

Принцип разделения интересов

Зачем? Для повторного использования и масштабируемости (отладка и обслуживание тоже кстати).
Например, чтобы иметь среду разработки для веб-сайта PHP Laravel, я бы запустил пару контейнеров:

• Mysql
• Apache-PHP
• Redis
• ..

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

Apache <== Mysql (3306 port).

Контейнер Apache теперь может открывать TCP-соединение с контейнером Mysql через открытый порт 3306.

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

Управление исходным кодом

Я никогда не помещал исходный код непосредственно в контейнер. Я предпочитаю монтировать его по объему (опция docker run -v) в контейнер.

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

Запуск контейнеров

Следуя приведенному выше примеру, я буду запускать контейнеры myapp и mysql.

$ cd myapp
$ docker run -d \    # run as daemon (detached)
 -p 82:80 \          # bind container port 80 to host 82
 -p 22001:22 \       # bind container port 22 to host 22001
 --expose 3306       # exposed to other container linked with it
 --name mysql
 author/mysqlimage  
$ docker run -d \    # run as daemon (detached)
 -p 81:80 \          # bind container port 80 to host 81
 -p 22001:22 \       # bind container port 22 to host 22001
 -v $(pwd):/var/www  # mount current host directory to container /var/www
 --link mysql:db     # give access to mysql container (ports) as db alias
 --name myapp
 author/apacheimage

Контейнер myapp сможет общаться с контейнером mysql. Чтобы проверить это: $ telnet db 3306 будет работать.

Запуск контейнеров с помощью рис

Как я уже сказал, Docker cmd для меня - кошмар, поэтому я нашел еще один замечательный инструмент, Fig, который заставил меня получить этот чистый файл yaml, расположенный в корне моего проекта:

web:
    image: lighta971/laravel-apache
    links:
        - db
    ports: 
        - "81:80"
        - "22001:22"
    volumes:
        - .:/app
db:
    image: lighta971/phpmyadmin-apache
    ports:
        - "82:80"
        - "22002:22"
    expose:
        - "3306"

И тогда $ cd myapp && fig up дает тот же результат, что и команды ниже :)

2. Контейнерные сложные среды

Я также использую Docker для разработки под Android. Базовая настройка Android/Cordova большая, как и Gigs of downloads, и требует времени для настройки среды.
Вот почему я поместил все компоненты в один контейнер "Швейцарский армейский нож":

• Android SDK
• Android NDK
• Apache Ant
• Инструменты Android
• Джава
• ...

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

$ docker run -i 
 --privileged                  # special permission for usb
 -v /dev/bus/usb:/dev/bus/usb  # mount usb volume
 -v $(pwd):/app                # mount current folder
 -p 8001:8000
 lighta971/cordova-env

Который я псевдоним в cvd:

$ alias cdv='docker run -i --privileged -v /dev/bus/usb:/dev/bus/usb -v $(pwd):/app -p 8001:8000 lighta971/cordova-env'

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

$ cdv adb devices            # List usb devices
$ cdv cordova build android  # Build an app
$ cdv cordova run android    # Run an app on a device
$ cdv npm update             # Update an app dependencies

Все эти команды будут работать в текущем каталоге из-за опции монтирования тома $(pwd): /app.

Dockerfile

Все, что сказал, есть другие вещи, которые нужно знать, такие как:

• понимание процесса сборки для создания эффективных изображений
• иметь дело с потребностями постоянных данных
• обновлять пакеты изображений
• и т.п.

Надеюсь, что это было понятно для вас :)

Ответ 2

Я пробовал множество разных настроек среды для работы в докере.

Одна моя команда, застрявшая с ней, была предопределенным каталогом, где бы сидел код, а затем отображался в контейнер докера в качестве каталога. Необходимые переменные окружения были помещены в файл Docker, и было написано несколько сценариев bash, чтобы запустить контейнеры с отображенными необходимыми путями. Мы будем хранить файл Docker в Git, и каждый раз, когда добавлялась новая зависимость, мы должен был обновить файл Docker и, возможно, перестроить образ (это было главным образом из-за того, как мы обрабатывали управление зависимостями, это было не идеально, и я не думаю, что это необходимо, но будет зависеть от стека технологий)

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

Это вообще сработало.

Однако создание локальной среды разработки было собственной проблемой. Я начал с Windows-машины, которая вытащила бы из git. У меня было то, что было отображено в VM Ubuntu, в которой работала докер.

В виртуальной машине ubuntu у меня были скрипты bash, которые запустили бы все необходимые контейнеры докеров.

./start-apache.sh
./start-mysql.sh
./start-mongodb.sh ... and so on

В конечном итоге он перестает работать, когда я узнал из-за использования Windows в качестве хоста, у меня были проблемы с созданием символических ссылок, от которых зависел наш проект. SO я переключился на использование git в Ubuntu VM, а затем запустил все в Ubuntu, используя те же bash скрипты.

Недостатком этого я был в основном кодированием в виртуальной машине и не мог использовать мою среду IDE в Windows. Это было не страшно, но работа в VM не идеальна, imo.

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

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

Ответ 3

Это, наконец, рабочий процесс, с которым я согласился.

Ключевые моменты в настройке среды dev:

• Код записи должен происходить за пределами докера
• VCS должен находиться вне докеров
• Вся компиляция и выполнение должны быть внутри докеры
• Контейнеры-докеры должны быть неактивными, поэтому для изменения и создания нового контейнера докеров требуется только перекомпилировать, выполнить

Как предложено lighta, есть два варианта:

• У каждой службы есть докер
• Все сервисы внутри одной докеры

Я предпочел последний подход, потому что я работаю над несколькими проектами и у m x n dockers чувствует себя хуже, чем с m dockers.

Настройка среды:

• Началось с phusion_baseimage
• Установленные mysql, phpmyadmin, nodejs, grunt и его друзья, apache, django
• Настройте сервисы init и ведение журнала (легкий ветерок с runit и svlogd, который поставляется вместе с базовым изображением), чтобы запустить apache, mysql и т.д. при запуске. Таким образом, запуск докеров перезапустит эти службы.
• Вывести необходимые порты (80 и, как правило, 8000 для запуска тестового сервера).
• Теперь я определяю точки монтирования следующим образом
  • ~/host/projectDocker/src > /root/project
  • ~/host/projectDocker/dbData/mysql_data > /var/lib/mysql
  • ~/host/projectDocker/apache_conf > /etc/apache/sites-enabled/

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

Все докеры града.

Ответ 4

Вот как я это делаю для своего приложения nodejs.

Во-первых, файл Dockerfile как часть источника выглядит так:

FROM node:0.10-onbuild
EXPOSE 8080
COPY . /src

Это используется для создания изображения:

sudo docker build -t myapp .

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

sudo docker run --rm -it -p 8080:8080 --name="myapp" -v '/path/to/app/src:/usr/src/app' myapp:latest

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

Кодом управляет github, поэтому поток разработки одинаков. Сделайте ветку, работайте локально, после того, как вы снова сходите к мастеру.

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

Надеюсь, что это будет полезно

Ответ 5

Я создал образ для использования Cordova в Docker-контейнере с Java, JDK, SDK-менеджером, Gradle и Maven, угловым интерфейсом командной строки, лицензиями для Android и т.д.... https://hub.docker.com/r/walterwhites/docker-cordova/builds/

построить образ

sudo docker build . -t walterwhites/cordova

запустить контейнер:

docker run -ti --rm --name=cordova -v /Users/username/workspace/gusto-coffee-mobile-app:/workspace walterwhites/cordova

опция -t - запуск контейнера с терминалом. опция -i - запуск в интерактивном режиме. опция -rm - остановка контейнера при выходе из него. опция -v - создание тома для совместного использования между вашим хостом (локальным компьютером). и контейнер

Примечание для настройки Android-приложения на Cordova:

добавить платформу Android:

cordova platform add android

построить:

cordova build android