Вступление
Вы много слышали о Докере в последнее время и задавались вопросом, из-за чего весь этот шум? В этом уроке я расскажу вам о Докере, о том , что такое шумиха, какие преимущества он может вам дать и как вы можете начать использовать его для своих проектов разработки. В этом уроке я предполагаю знакомство с такими понятиями, как процессы и операционные системы.
Этот учебник представляет собой запись рабочего времени Codementor, которое я недавно провел. Вы можете посмотреть видео в конце этого урока.
содержание
Что такое Докер? Что такое Контейнер? Словарь Вам Нужно Знать, Как Выглядит Экосистема Docker? Начало работы: Установка Как мы можем использовать Docker для разработки? Пример Рабочего процесса приложения Python и Flask для работы с Docker Как мы можем это опубликовать? Смотрите видео Заключение в Рабочее время
Что такое Докер?
Официальный сайт для Docker государств:
Docker предоставляет способ запуска приложений, надежно изолированных в контейнере, упакованном со всеми его зависимостями и библиотеками. Поскольку ваше приложение всегда может быть запущено с той средой, которую оно ожидает прямо в образе сборки, тестирование и развертывание проще, чем когда-либо, поскольку ваша сборка будет полностью переносимой и готовой к запуску в соответствии с проектом в любой среде.
Что это значит с точки зрения непрофессионала? Если вы думаете о своем приложении или, более конкретно, о любом процессе операционной системы , то этот процесс имеет зависимости. Например, приложению может потребоваться открыть файлы конфигурации, записать данные в папку или открыть сетевые сокеты. Это все то, что, как предполагает ваш код, будет доступно операционной системе. Docker предоставляет способ упаковки вашего кода и всех этих зависимостей в единый блок, называемый контейнером.
Docker предоставляет среду инструментов для создания, запуска и остановки контейнеров. По сути, мы хотим рассматривать контейнеры как “строительный блок” программного обеспечения.
Некоторые из вас, читая это, могут задаться вопросом, связано ли это с виртуальными машинами. Давайте взглянем на изображение ниже.
Источник изображения
Самая большая разница заключается в том, какой слой стека виртуализируется. Для виртуальных машин они представляют собой отдельные операционные системы, работающие параллельно на одной хост-операционной системе. В мире Docker каждый контейнер-это просто процесс, и его зависимости сгруппированы вместе. В некотором смысле это виртуализация на уровне процессов, а не операционных систем.
Что такое Контейнер?
С официального сайта Docker :
Контейнеры Docker упаковывают часть программного обеспечения в полную файловую систему, которая содержит все необходимое для запуска: код, среду выполнения, системные инструменты, системные библиотеки — все, что может быть установлено на сервере. Это гарантирует, что программное обеспечение всегда будет работать одинаково, независимо от его среды.
Это может показаться немного запутанным, так что, надеюсь, картинка из RightScale немного прояснит ситуацию.
Запущенный контейнер – это просто стандартный процесс операционной системы, а также зависимости файловой системы и сетевые подключения. На рисунке выше крайняя левая диаграмма показывает абстрактную модель процесса, где зеленый PGM показывает основной программный код, а MEM-память, используемую запущенным процессом. Два других блока немного продвинуты, но в основном это текущее состояние регистров процессора и таблица процессов, используемая ОС.
Следующая диаграмма показывает это немного более конкретно в более реалистичном сценарии, где код , работающий в памяти, должен считывать данные с жесткого диска, такие как конфигурационные файлы в /etc , общие библиотеки в /lib и двоичный файл процесса в /bin .
На последней диаграмме показан контейнер — обратите внимание, что теперь граница окружает файловую систему с новым полем под названием “net”. Все, что находится в оранжевом ящике, – это контейнер, единая распределяемая единица, представляющая собой запущенный процесс и то, что ему нужно для запуска.
Отлично! Но зачем вообще беспокоиться об этом?
Основные причины, по которым мне нравится заставлять Docker работать в моем рабочем процессе, заключаются в следующем:
- Позволяет разбивать большие приложения на составные части, что помогает поддерживать низкую когнитивную нагрузку и обеспечивает более легкую отладку и большую прозрачность.
- Завершите сложные инструкции по применению таким образом, чтобы помочь документировать, как создавать и настраивать программное обеспечение.
- Если вы используете Docker как для разработки, так и для производства, то у вас есть идентичные стеки. Это уменьшает когнитивную нагрузку от знания того, как использовать несколько установок. Это также предотвращает оправдания “это работает для меня”, когда что-то ломается.
- Не нужно беспокоиться о сумасшедших шагах компиляции для установки программного обеспечения и обслуживания вашей машины.
- Помогает сохранить вашу работу по разработке независимой от вашей ОС (так что обновление Ubuntu не начинает касаться ваших библиотек разработки и т. Д.)
Словарь, Который Вам Нужно Знать
Всякий раз, когда я изучаю что-то новое, это всегда помогает наметить новый словарный запас. Вот некоторые из них, которые вам нужно будет знать, чтобы полностью погрузиться в экосистему Docker:
Container : Запускаемый процесс и его зависимости от ресурсов, сгруппированные в один блок (см. выше)
Изображение : Схема создания контейнеров. Очень похоже на сравнение класса с объектом или образа виртуальной машины с виртуальной машиной. Например, образ Redis Docker Image позволяет создать один или несколько реальных контейнеров Redis, которые могут/будут запускать процесс Redis и любые его зависимости.
Dockerfile : Текстовый файл, содержащий инструкции по созданию образа docker. Все изображения имеют связанный Dockerfile.
Registry : Внешняя служба для хранения/ссылки на изображения, которые вы можете назвать и версию. Docker hub – это реестр, предоставленный вам Docker, но при необходимости вы можете создать частный.
Том : Как и традиционный Linux
mount, том-это папка в хост-системе docker, которая сопоставляется с работающим контейнером
Как выглядит экосистема Docker?
Экосистема инструментов Docker всегда находится в постоянном движении. Существует постоянное развитие, поэтому многое из этого может измениться, но вот основные компоненты мира Докеров:
Docker Engine : Это ядро Docker. Этот демон представляет собой REST API и отвечает за фактический запуск контейнеров. Вы будете выполнять команды через клип, который напрямую разговаривает с этим демоном.
Docker Machine : Этот инструмент позволяет подготовить виртуальную машину на многих различных облачных провайдерах или локально через VirtualBox для запуска движка Docker. По сути, его единственная цель – обеспечить двигатели.
Docker Swarm: Распределенная контейнерная платформа Docker для объединения многих экземпляров машин Docker вместе. Мы не будем рассматривать это в этом уроке, но будем рассматривать в будущих.
Docker Compose: Координирует создание контейнеров, описывая, как контейнеры сочетаются друг с другом, чтобы обеспечить функциональность всего приложения.
Я большой поклонник визуального обучения, поэтому вот диаграмма , показывающая большую часть экосистемы Docker:
Слева у нас есть команды, которые вы будете запускать из командной строки, которая взаимодействует с демоном Docker (то есть движком). Движок находится на хосте Docker (то есть машине), и именно этот демон размещает образы и создает запущенные контейнеры из этих образов. Образы могут быть встроены локально в демон или загружены из реестра полностью справа.
Начало работы: Установка
В оставшейся части этого урока я буду использовать Docker engine, machine и compose. Я также буду использовать Virtualbox для локальной машины Docker и Digital Ocean в последней части. Чтобы сделать этот учебник короче, я свяжусь с примечаниями по установке всех этих инструментов:
Docker Примечания по установке
- Virtualbox Примечания по установке
Для Docker машины на Linux:
$ curl -L https://github.com/docker/machine/releases/download/v0.8.2/docker-machine-`uname -s`-`uname -m` > /usr/local/bin/docker-machine && chmod +x /usr/local/bin/docker-machine
Для Docker Compose в Linux:
$ curl -L "https://github.com/docker/compose/releases/download/1.9.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose
Как мы можем использовать Docker для разработки?
Теперь, когда мы знаем все это о Docker, как мы можем использовать Docker для локальной среды разработки? Давайте приведем мотивирующий пример: нас наняли для создания небольшого сервера REST. Для этого приложения я выбрал Python и Flask в качестве своих инструментов, но вы можете использовать и другие стеки. Этот разговор самоуверен в том, какие инструменты я предпочитаю использовать, но должен быть в целом применим к другим языкам.
Мы вызовем приложение Flask-Tester, чтобы увидеть готовые репозитории, пожалуйста, проверьте:
- git clone https://github.com/jquacinella/flask-tester-backend
- git clone https://github.com/jquacinella/flask-tester-docker
Пример приложения Python и Flask
Когда я разрабатываю программное обеспечение, мне нравится хранить несколько репозиториев:
- Один для самого кода приложения, в данном случае кода Python и Flask
- Один для оркестровки docker приложения
Для начала выполните следующие команды (в Linux; используйте эквивалент для Windows/MacOSX):
mkdir code; cd code git clone https://github.com/jquacinella/flask-tester-backend cd ../; git clone https://github.com/jquacinella/flask-tester-docker
Это создает две папки, по одной для каждого репо, которые мы начнем создавать прямо сейчас. Что касается самого приложения, то хотя это и не учебник по Python и Flask, мы быстро его рассмотрим. Вот ссылка на главную wsgi.py файл в Github для этого приложения. Это начальная версия, то есть неполная и без редиса. Версия на master имеет обновленный код с redis.
Когда дело доходит до приложений в Docker, вот несколько советов:
- Совет №1 : Заставьте ваше приложение реагировать на переменные env для загрузки конфигурации. Мы не будем делать этого здесь, но будем делать в будущем.
- Совет №2 : Убедитесь, что ваша установка перезагрузит приложение при изменении исходного кода, чтобы разрешить живое кодирование с вашего локального компьютера.
Рабочий процесс для работы с Docker
Теперь, когда мы покончили с этим, я расскажу о том, как я подхожу к разработке с помощью Docker. Когда я начинаю новый проект, мой мыслительный процесс идет примерно так:
- Создайте машину docker для размещения вашего движка docker. Примечание: Поскольку я использую Linux в качестве основной ОС, я мог бы использовать движок Docker, установленный локально на моем ноутбуке. Однако AFAIK, используя Docker на Windows или Mac OS X, требует виртуальной машины, поэтому я делаю это таким образом, чтобы быть как можно более общим.
- Создайте образ для контейнера, который может содержать и запускать наше приложение Python.
- Наметьте тома, необходимые для исходного кода и конфигурационных файлов.
- Напишите файл compose, чтобы мы могли автоматизировать создание и удаление контейнера приложения с соответствующими томами.
- Напишите несколько сценариев, чтобы обернуть Docker compose.
Давайте начнем!
Шаг 1: Создайте локальную машину Docker с общими томами
Во-первых, создайте виртуальную машину virtualbox под названием flask-tester-engine:
$ docker-machine create --driver virtualbox flask-tester-engine
Чтобы узнать, какие машины у вас есть в наличии, запустите:
$ docker-machine ls
Однако теперь нам нужно сказать клиенту docker, чтобы он использовал эту машину в качестве вашего движка docker. Мы делаем это с помощью команды env:
$ docker-machine env flask-tester-engine $ eval $(docker-machine env flask-tester-engine)
Теперь мы можем запустить команду docker, чтобы увидеть все контейнеры, которые вы не должны видеть правильно:
$ docker ps --all
Вот как выглядит мой вывод до сих пор:
$ docker-machine create --driver virtualbox flask-tester-engine Running pre-create checks... (flask-tester-engine) You are using version 4.3.36_Ubuntur105129 of VirtualBox. If you encounter issues, you might want to upgrade to version 5 at https://www.virtualbox.org Creating machine... (flask-tester-engine) Copying /home/james/.docker/machine/cache/boot2docker.iso to /home/james/.docker/machine/machines/flask-tester-engine/boot2docker.iso... (flask-tester-engine) Creating VirtualBox VM... (flask-tester-engine) Creating SSH key... (flask-tester-engine) Starting the VM... (flask-tester-engine) Check network to re-create if needed... (flask-tester-engine) Waiting for an IP... Waiting for machine to be running, this may take a few minutes... Detecting operating system of created instance... Waiting for SSH to be available... Detecting the provisioner... Provisioning with boot2docker... Copying certs to the local machine directory... Copying certs to the remote machine... Setting Docker configuration on the remote daemon... Checking connection to Docker... Docker is up and running! To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env flask-tester-engine $ docker-machine env flask-tester-engine export DOCKER_TLS_VERIFY="1" export DOCKER_HOST="tcp://192.168.99.101:2376" export DOCKER_CERT_PATH="/home/james/.docker/machine/machines/flask-tester-engine" export DOCKER_MACHINE_NAME="flask-tester-engine" # Run this command to configure your shell: # eval $(docker-machine env flask-tester-engine) $ eval $(docker-machine env flask-tester-engine) $ docker ps -all CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Теперь, когда мы создали машину, как именно эта виртуальная машина знает о файлах на моем жестком диске? Как вы можете разрабатывать программное обеспечение в интерактивном режиме? Следующая часть здесь может быть немного запутанной, поэтому не забудьте замедлиться и понять этот момент. Давайте посмотрим, что мы имеем сейчас:
Как вы можете видеть, машина никак не может коснуться вашей локальной файловой системы. Технически Docker machine настраивает Virtualbox с суммой из вашего локального или домашнего каталога на виртуальную машину. Однако мне не нравится эта автоматическая настройка, и я предпочитаю обновлять монтирование вручную. Видишь https://github.com/docker/machine/issues/1814 для получения более подробной информации.
Следующие команды позволят нам настроить “Общий том” Virtualbox (обратите внимание, что это не том docker):
$ VBoxManage sharedfolder add flask-tester-engine --automount --name "code" --hostpath /path/to/code $ docker-machine ssh flask-tester-engine 'sudo mkdir --parents /mnt/code' $ docker-machine ssh flask-tester-engine 'sudo mount -t vboxsf code /mnt/code' $ docker-machine ssh flask-tester-engine 'ls -l /mnt/code' drwxrwxr-x 1 root root 4096 Nov 29 19:53 flask-tester-backend drwxrwxr-x 1 root root 4096 Nov 29 19:53 flask-tester-docker
Вот что мы имеем сейчас:
Шаг 2: Создайте образ Docker Для Вашего Приложения
Теперь нам нужно создать контейнер для размещения приложения. Я всегда думаю в терминах “Каковы зависимости?” Это хороший вопрос, который нужно задать, думая о том, что должно быть в контейнере. Всегда есть две вещи, о которых нужно думать: процесс, который упаковывает контейнер, и какие файлы нужны этому процессу. Философия докера состоит в том, чтобы иметь один процесс на контейнер, но об этом много говорят. Проверьте Phusion BaseImage для альтернативного представления.
В нашем случае каким будет наш центральный процесс? Наше приложение будет представлять собой процесс uWSGI. Этот процесс запустит потоки, запускающие наше приложение Python Flask. Теперь нам нужно спросить: “Какие зависимости файлов у нас есть?”
Нам нужно:
- Исходные файлы Python
- Файлы, связанные с uWSGI, включая двоичные файлы и файлы conf
- Доступ к открытому порту 80 для клиентских подключений
Docker позволяет легко создать свой собственный образ, основывая его на другом образе. В нашем случае проще всего использовать стандартный образ Ubuntu. Это означает, что образ начинается с файловой системы, которая является копией дистрибутива Ubuntu Linux. Учитывая этот базовый образ, что нам нужно сделать, чтобы он работал в нашем приложении:
- Установите uWSGI в файловую систему контейнера.
- Настройте контейнер для запуска uWSGI в качестве основного процесса.
- Получите наш исходный код в контейнере.
Если вы помните из раздела лексики, нам нужно написать Dockerfile для выполнения задач, описанных выше. Этот Dockerfile будет определением изображения. Вот как будет выглядеть Dockerfile:
# Inspired by https://github.com/atupal/dockerfile.flask-uwsgi-nginx/blob/master/Dockerfile # Base our image off the ubuntu docker container from Dockerhub from ubuntu:14.04 # Update ubuntu filesystem with updates run apt-get update # Install python and easy_install from Ubuntu repos run apt-get install -y build-essential python python-dev python-setuptools # Install pip, and then use pip to install flask and uwsgi run easy_install pip run pip install uwsgi flask # We are exposing a network port expose 80 # uWSGI command that this container is running cmd ["/usr/local/bin/uwsgi", "--http", ":80", "--wsgi-file", "/src/wsgi.py", "--py-autoreload", "1"]
Для получения полной справки о синтаксисе Dockerfile обратитесь к documentation . Каждая строка файла Dockerfile начинается с ключевого слова, например run или expose. Главное, что нужно знать, – это run, который запускает команду точно так же, как вы были в командной строке Linux. Ключевое слово exposed сообщает Docker, что этому контейнеру потребуется доступ к сетевому порту. Затем из ключевого слова он сообщает Докеру, на каком образе должен основываться этот контейнер. Все эти команды, по сути, настраивают файловую систему контейнера.
Последний, cmd, сообщает Docker, что основным процессом этого контейнера будет uWSGI с параметрами CLI, разделенными в список. Обратите внимание на параметр --py-autoreload , который перезагрузит процесс uWSGI при изменении исходного кода.
Еще одна вещь, которую следует заметить, заключается в том, что этот контейнер предполагает, что исходный код Python будет расположен по адресу /src/wsgi.py
Когда это сделано, как мы строим образ?
# In flask-tester-docker repo: $ mkdir -p images/flask_tester $ vim images/flask_tester/Dockerfile # content from before $ docker build -t flask_tester:0.1 images/flask_tester # Build an image from the dockerfile ... a lot of output ... $ docker images # We can see our image and the ubuntu image it is based on REPOSITORY TAG IMAGE ID CREATED SIZE flask_tester 0.1 5cb4ef863e80 2 minutes ago 439.7 MB ubuntu 14.04 aae2b63c4946 About an hour ago 188 MB
Обратите внимание, что каждое изображение идентифицируется именем и тегом; тег полезен для отслеживания версий, поэтому, когда мы обновим Dockerfile позже в этом уроке, мы обновим тег с 0.1 до 0.2.
Шаг 3: Подумайте о томах для кода и конфигурации
Теперь нам нужно подумать об объемах. Что еще нужно нашему контейнеру? Как правило, нам также нужно получить конфигурационные файлы и данные или исходный код в контейнер. Мы создадим том для исходного кода и будем использовать монтирование виртуальной машины, чтобы указать контейнеру сопоставить каталог в виртуальной машине с папкой src/| в контейнере.
Обычно у нас был бы том для конфигурационных файлов для uWSGI. Чтобы все было просто, как в нашем случае, я запускаю uWSGI только с аргументами CLI.
Зачем мы возимся с объемами? Разве мы не можем скопировать все в контейнер во время сборки? Мы могли бы, но это сделало бы ситуацию менее динамичной. Вам придется перестраиваться при каждом изменении исходного кода или конфигурации. Это позволяет нам обновлять конфигурации и не перестраивать образ. Это значительно упрощает отладку и позволяет конфигурационным и исходным файлам находиться в Git.
Интерлюдия: Протестируйте приложение
На этом этапе мы можем запустить наше приложение! Имея все, что у нас есть , мы должны иметь возможность протестировать наше приложение с помощью docker run , которая является командой для создания и запуска контейнерного процесса:
$ docker run -d --name flask_tester_container -p 80:80 -v /mnt/code/flask-tester-backend:/src flask_tester:0.1 $ docker ps --all CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0fc5c1909584 flask_tester:0.1 "supervisord -n" 7 seconds ago Up 7 seconds 0.0.0.0:80->80/tcp flask_tester_container
Помните, что все относится к виртуальной машине, поэтому монтирование тома относится к /mnt , который сопоставляется с каталогом верхнего уровня на вашей машине. Вы должны быть в состоянии перейти к http://localhost/ и смотри Здравствуй, мир!
Вот что мы имеем сейчас:
Шаг 4: Docker Compose для автоматизации запуска Docker
Отлично, теперь, когда мы можем запустить приложение, мы можем написать сценарий Docker Compose, чтобы имитировать команду run, так что нам не нужно постоянно помнить параметры. Чтобы увидеть сценарий compose в его нынешнем виде прямо сейчас , проверьте его здесь:
version: '2'
services:
flask_tester_app:
container_name: flask_tester
hostname: flask_tester
image: flask_tester:0.1
volumes:
- /mnt/code/flask-tester-backend:/src
ports:
- "80:80"
Обратите внимание, что большинство строк имеют аналог команды run, включая container_name , image , volumes и ports . Строка версии вверху просто говорит использовать синтаксис версии 2. Оставьте все как есть, на данный момент нет никакой необходимости использовать версию 1. Подробнее о синтаксисе Docker Compose читайте здесь . Сначала мы останавливаем и убиваем старый контейнер из команды run, а затем используем команду docker compose для запуска этого файла:
$ docker stop flask_tester; docker rm flask_tester
$ /usr/local/bin/docker-compose -f compose/flask_tester.yml -p local up -d
Creating network "local_default" with the default driver
Creating flask_tester
$ /usr/local/bin/docker-compose -f compose/flask_tester.yml -p local ps
Name Command State Ports
--------------------------------------------------------------------------
flask_tester /usr/local/bin/uwsgi --htt ... Up 0.0.0.0:80->80/tcp
$ docker ps --all
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9098751a9976 flask_tester:0.1 "/usr/local/bin/uwsgi" 7 seconds ago Up 7 seconds 0.0.0.0:80->80/tcp flask_tester
Шаг 5: Сценарии-обертки
Поскольку в файле docker compose есть все необходимое для запуска нашего приложения, мы можем создать несколько сценариев bash, чтобы облегчить нашу жизнь. Это всего лишь один лайнер, который вы можете проверить на странице github .
Дополнительный кредит: Добавление Redis в микс
Э-э-э, клиент, на которого мы работаем, хочет новую функцию (помимо простой печати hello world, кто это видел?). Redis-это база данных NoSQL, которая может хранить различные типы данных. Они хотят добавить Redis в микс и использовать его для хранения количества посещений веб-страниц. С докером это не проблема. Нам придется:
Добавьте библиотеку Python
redisв файл Dockerfile контейнера flask-tester.Создайте новый контейнер для размещения процесса
redisи его зависимостей.- Мы будем использовать контейнер redis из Docker hub.
Обновите наш файл compose, чтобы связать их вместе
Вы можете ссылаться на другой контейнер, используя его имя и DNS, предоставленные Docker.
$ … update dockerfile for app … $ docker build -t flask_tester:0.2 images/flask_tester # Build image flask_tester:0.2 $ … update compose file … $ ./scripts/stop_app.sh # Stop all containers for this app $ mkdir data/redis # Create folder for persistent redis data $ ./scripts/start_app.sh # Re-create all the containers $ curl $(docker-machine ip flask-tester-engine) # cURL access to our app Counter: 27
Здесь много чего происходит, так что давайте разберемся. Что мы добавили в Dockerfile? Мы добавили строку 12:
run pip install uwsgi flask redis
Все, что мы сделали, это добавили redis в строку, так что библиотека Python redis теперь установлена в файловой системе нового образа.
Что нам нужно изменить в исходном коде? Мы обновляем код для подключения к Redis и увеличиваем счетчик каждый раз, когда выполняется вызов API. Это здорово, но как код в строке 7 знает, что нужно подключиться к Redis? Посмотрим ниже.
Что нам нужно изменить в файле Docker Compose? В основном все, начиная со строки 13, которая создает новый контейнер из образа Redis, предоставленного теми, кто создал Redis. Из документации по образу Redis он сохранит данные в папку /data . Мы можем смонтировать там локальный каталог, чтобы данные сохранялись в контейнерах. Мы создаем эту папку с помощью приведенных выше команд. Как только мы восстановим новый образ, compose позаботится о воспитании обоих контейнеров.
Вернемся к тому, как эти два контейнера будут взаимодействовать. Теперь мы можем перейти в пространство процесса контейнера с помощью команды docker exec , чтобы увидеть, что контейнеры могут пинговать друг друга, используя свои имена контейнеров в качестве DNS-имен:
$ docker exec -it flask_tester /bin/bash root@flask_tester:/# ping redis PING redis (172.18.0.2) 56(84) bytes of data. 64 bytes from flask_tester_redis.local_default (172.18.0.2): icmp_seq=1 ttl=64 time=0.142 ms 64 bytes from flask_tester_redis.local_default (172.18.0.2): icmp_seq=2 ttl=64 time=0.176 ms ^C --- redis ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.142/0.159/0.176/0.017 ms
Поэтому контейнер, представляющий наше приложение, может просто подключиться к нему с помощью DNS-имени
Как Мы Можем Это Опубликовать?
Фу, это было много. Надеюсь, вы узнали много нового о том, как делать вещи с Docker локально и как использовать его для разработки. Однако, если бы вы хотели протолкнуть это в Сеть, не могли бы вы? Да.
Сначала нам нужно будет создать новую машину на DigitalOcean, а затем переключиться на использование этой машины. Затем мы обновим наш Dockerfile, чтобы скопировать исходный код приложения непосредственно в процессе сборки (что все еще позволяет нам перезаписать его через том (чтобы мы могли получить лучшее из обоих миров). Как только мы это сделаем, мы снова запустим наш сценарий создания, и все должно сработать.
Вам нужно будет зарегистрироваться в DO и получить ключ API. После этого вы можете выполнить следующие команды:
$ docker-machine create --driver digitalocean --digitalocean-access-token XXXXXXXXXX flask-tester-do $ eval $(docker-machine env flask-tester-do)
Через несколько минут у вас будет новая машина Docker на вашей учетной записи DO. Команда eval теперь означает, что все ваши команды docker относятся к этой машине, включая compose scripts.
Затем мы обновим Dockerfile, чтобы скопировать исходный код в контейнер. Здесь кроется странная оговорка — Docker отказывается разрешить вам ссылаться на файлы из-за пределов каталога Dockerfile. Для этого есть несколько причин, но чтобы обойти их, мы можем использовать небольшой взлом и сказать Linux смонтировать каталог в другом каталоге с помощью стандартной команды mount:
$ sudo mount --bind/code/flask-tester-backend images/flask_tester/src
Для Windows вам может потребоваться символическая ссылка или не иметь двух репозиториев, но иметь свой Dockerfile ближе к источнику. Для Mac OS X должна работать команда mount. Посмотрите на строки 18 и 19, где мы запускаем файл mkdir/src и копируем наши исходные файлы в новый каталог, созданный в контейнере.
Все, что нам нужно сделать сейчас, это создать приложение и сказать compose, чтобы запустить его:
$ docker build -t flask_tester:0.2 images/flask_tester # Build image flask_tester:0.2 $ … update compose file … $ ./scripts/stop_app.sh # Stop all containers for this app $ mkdir data/redis # Create folder for persistent redis data $ ./scripts/start_app.sh # Re-create all the containers
Теперь вы должны иметь доступ к приложению на своей новой машине!
Смотрите видео в рабочее время
Вывод
Я надеюсь, что вам понравился этот учебник и вы увидите всю мощь использования Docker для разработки. Если вам это понравилось, следите за новыми учебниками о том, как использовать Docker Swarm для легкого масштабирования ваших машин в производстве.