как контейнеризировать java приложение
Docker — основы
В данной статье мы поговорим о таком инструменте как Docker. Сегодня мы не будем писать приложения, а попытаемся их запускать.
Если Вы пользовались виртуальной машиной — то поймете быстрее. Поскольку, Докер это приложение, которое позволяет отделить приложения от инфраструктуры. Например, есть у Вас Windows система и Вы хотите попробовать поработать с Ubuntu. Для этого совсем не обязательно удалять свою систему и устанавливать другую. Достаточно поднять виртуальную машину: приложение внутри которого будет полноценная операционная система. Вы сможете туда зайти и посмотреть как оно там устроено. Если интересен этот вопрос — советую погуглить VMware или просто виртуальная машина.
Теперь, что касается непосредственно Docker. Он позволяет создавать мини виртуальные машины и помещать в них все что нужно для выполнения Вашего приложения вместе с самим приложением, запаковать все это в контейнер и использовать сколько угодно раз.
Например: есть у нас простое java приложение. Допустим это веб приложение, которое имеет свою реляционную базу данных. Пусть будет PostgreSQL. И еще наше приложение использует не реляционную базу (NoSql) MongoDB. В принципе, стандартный набор. Вот мы запустили наше приложение локально и полны счастья и радости. Но что если нам нужно показать приложение товарищу? Не вопрос. Мы можем сбросить ему ссылку на гит или вообще перебросить код. Вот он пытается запустить наше приложение а ему нужна база данных. Наш товарищ устанавливает PostgreSQL, потом MongoDB. Приложение запустилось.
Потом мы сбрасываем приложение другому товарищу. У него уже есть PostgreSQL, но только не версии 9.2 как у нас, а 6.4. Он не может удалить старую версию потому что у него другое приложение использует его старую версию базы. Что делать в этом случае? А что если наши товарищи — это не люди, а разные сервера?
Написать приложение — это пол беды. Не менее сложно заставить его работать на сервере именно так как мы того хотим. Особенно сложно когда приложений несколько сотен и все они имеют определенные зависимости будь-то база данных или менеджер настроек. Еще сложнее, когда к существующим системам приходится добавлять новые приложения, которые могут например требовать новые версии баз данных.
Таким образом мы получаем ситуацию, когда было бы удобно использовать некую формальную оболочку, чтобы можно было запускать приложения только в ней. И чтобы можно было запускать сколько угодно таких оболочек на одном физическом сервере и чтобы они не пересекались по зависимостям. Чтобы была возможность на одной оболочке использовать базу данных версии 6.4, на другой версии 7.8, а на третьей версии 9.2.
Для вышеописанных решений и был придуман Докер. Только в контексте Docker, оболочка — это контейнер (container).
Это как аналогия с корабельным контейнером.
Когда нужно перевезти большое количество разного груза — его помещают в контейнер. Таким образом груз не смешивается и его очень удобно транспортировать. Это тоже самое только в разрезе запуска приложений.
С docker container (контейнером) теперь вопросов быть не должно. Это инкапсулированная среда в которой выполняются приложения.
К стати, контейнеры могут общаться как между собой так и с внешней средой.
Сам по себе пустой контейнер вещь бесполезная. Чтобы он стал полезным в него нужно положить наше приложение, а также все что нужно приложению для запуска. Основа для контейнера — образ (image).
Чтобы было понятно, образ — это набор команд которые будут выполняться для запуска контейнера. Docker images — это наполнения наших контейнеров, их содержимое. Чтобы было еще проще — это можно представить как аналогию с репозиторием кода. Например, есть определенный код на гитхаб который автор выложил для общего пользования. Например приложение на спринг бут. Это приложение может скачать и запустить любой желающий. Потому что я выложил его в общий доступ. Вы можете его скачать себе, изменить там любой участок кода и залить на свой гит аккаунт.
В контексте Docker существует Docker Hub, где также есть готовые образы, которые вы сможете себе закачать. Туда же вы сможете залить свои созданные образы. Советую там зарегистрироваться.
Именно с докер хаб будут скачаны базовые образы такие как оболочка операционной системы база данных mysql например. Ведь для того, чтобы запустить java приложение Вам как минимум нужна операционная система и установленная java.
На данном этапе все еще может быть не понятно. Все дело в том, что я не показал Вам ни единого примера.
Перед тем как показывать примеры, докер нужно установить. На этом моменте я останавливаться не буду. Здесь все предельно просто: качаем установщик с официального сайта, запускаем и следуем инструкциям.
Чтобы проверить что все работает можно запустить хело ворлд команду: docker run hello-world в командной строке.
результат работы docker run hello-world
Если Вы видите результат как на скрине выше — значит докер установлен и работает корректно.
Чтобы посмотреть активные контейнеры нужно выполнить комманду docker ps
CONTAINER ID — это уникальный идентификатор контейнера. По этому айди можно будет потом управлять контейнером (удалять, запускать, останавливать).
IMAGE — имя образа который запускался в этом контейнере. Для того чтобы посмотреть все образы нужно выполнить комманду docker images.
Теперь осталось контейнеризировать наше приложение чтобы увидеть результат работы докера. Предлагаю для примера использовать простое Spring Boot приложение. В данном случае, что именно мы будем отправлять в контейнер большого значения иметь не будет. Docker позволяет контейнеризировать любое приложение.
Я захожу на сайт https://start.spring.io/ выбираю зависимости веб и нажимаю сгенерировать:
генерация Spring Boot приложения
Дальше я добавил всего лишь один класс контроллера и метод, который будет возвращать приветствие:
простое REST приложение
Дальше, перед тем как помещать приложение в Docker, я его запустил и убедился что оно работает корректно:
результат работы приложения
Вот теперь мы готовы задеплоить наше приложение на Docker. У нас есть установленный и корректно работающий Докер и корректно работающее java приложение.
Для того, чтобы написать свой образ используется Dockerfile.
Это просто текстовый файл в который нужно прописать команды для Докера. Теперь о хорошем) Список команд не большой и учить много не нужно. Команды интуитивно понятны и состоят фактически из одного-двух слов.
Вот пример докер файла для помещения нашего приложения в Docker:
Синтаксис докер файла не чувствителен к регистру, но команды принято писать в верхнем регистре.
Команды выполняются по порядку сверху вниз. Сначала будет выполнена команда FROM. Она определяет базовый образ контейнера. В нашем примере, за базовый образ у нас openjdk:8-jdk-alpine. Ведь, для того чтобы запускать java приложения нам необходима установлена джава.
Знаком # объявляют комментарии. Это как аналогия // в java.
ARG — используется для объявления аргументов. Если брать аналогию с языком java: String file = «filename»;. В докере это будет ARG JAR_FILE=target/*.jar Где JAR_FILE — это имя переменной, а target/*.jar — ее значение. Именно в папке target находиться сгенерированный jar файл после билда мавеном.
Дальше, идет команда COPY. Она говорит докеру что нужно скопировать из папки target файл с расширением jar в контейнер и дать ему новое имя app.jar.
Чтобы сгенерировать образ нужно воспользоваться командой:
Запускать ее нужно находясь в одной директории с Dockerfile. Когда докер начнет выполнять ваш файл он скачает в контейнер либы джавы, скопирует jar-ник с папки target и збилдит контейнер.
Запустите команду docker images чтобы увидеть вновь созданный образ:
созданный образ
Мы не запушили наш образ в репозиторий поэтому в строке REPOSITORY пусто. Строка TAG тоже пуста поскольку мы не задавали тегов нашему образу. Нас сейчас больше всего интересует IMAGE ID. С помощью этого айди мы можем запустить контейнер.
Для запуска контейнера существует команда docker run айди_образа. Таким образом, чтобы запустить наш контейнер нужно выполнить команду docker run 6c8a153530ff
результат запуска команды docker run 6c8a153530ff
Теперь, когда Вы выполните команду docker ps, то увидите свой запущенный контейнер:
Чтобы остановить запущенный контейнер нужно воспользоваться командой: docker stop контейнер_айди.
Вот таким образом мы подняли наше java приложение в Docker. Тема докера очень обширна и многообразна. Уместить все в одну статью просто не получиться. Но, что касается основ докера — этого достаточно.
Java и Docker: это должен знать каждый
Постановка проблемы
В демонстрационных целях я создал демон docker в виртуальной машине с 1 Гб ОЗУ, используя такую команду:
Похожий результат получается даже в кластере Kubernetes / OpenShift. Я запустил группу контейнеров Kubernetes с ограничением памяти, используя такую команду:
При этом кластеру было назначено 15 Гб памяти. В итоге общий объём памяти, о котором сообщила система, составил 14 Гб.
Исследование кластера с 15 Гб памяти
Для того, чтобы понять причины происходящего, советую прочесть этот материал об особенностях работы с памятью в контейнерах Linux.
Для того, чтобы воспроизвести ситуацию, в которой система останавливает процесс после превышения заданного лимита памяти, можно запустить WildFly Application Server в контейнере с ограничением памяти в 50 Мб, воспользовавшись такой командой:
Теперь, в процессе работы контейнера, можно выполнить команду docker stats для того, чтобы проверить ограничения.
Данные о контейнере
Через несколько секунд исполнение контейнера WildFly будет прервано, появится сообщение:
Выполним такую команду:
Анализ причины остановки контейнера
Влияние неверной работы с памятью на Java-приложения
Попробуем это сделать:
Конечная точка ответит примерно следующим образом:
Всё это может навести нас, по меньшей мере, на два вопроса:
Увеличение объёма памяти как пример неверного решения проблемы
Разработчики, не понимающие сути происходящего, склонны полагать, что вышеописанная проблема заключается в том, что окружение не даёт достаточно памяти для исполнения JVM. В результате частое решение этой проблемы заключается в увеличении объёма доступной памяти, но такой подход, на самом деле, только ухудшает ситуацию.
Предположим, мы предоставили демону не 1 Гб памяти, а 8 Гб. Для его создания подойдёт такая команда:
Следуя той же идее, ослабим ограничение контейнера, дав ему не 150, а 800 Мб памяти:
Обратите внимание на то, что команда curl http://`docker-machine ip docker8192`:8080/api/memory в таких условиях даже не сможет выполниться, так как вычисленный параметр MaxHeapSize для JVM в окружении с 8 Гб памяти будет равен 2092957696 байт (примерно 2 Гб). Проверить это можно такой командой:
Проверка параметра MaxHeapSize
Приложение попытается выделить более 1.6 Гб памяти, что больше, чем лимит контейнера (800 Мб RAM и столько же в swap-файле), в результате процесс будет остановлен.
Верное решение проблемы
Небольшое изменение в Dockerfile позволяет нам задавать переменную окружения, которая определяет дополнительные параметры для JVM. Взгляните на следующую строку:
Теперь можно использовать переменную окружения JAVA_OPTIONS для того, чтобы сообщать системе о размере кучи JVM. Этому приложению, похоже, хватит 300 Мб. Позже можно взглянуть в логи и найти там значение 314572800 байт (300 МиБ).
В Kubernetes переменную среды можно задать, воспользовавшись ключом –env=как контейнеризировать java приложение :
Улучшаем верное решение проблемы
Что если размер кучи можно было бы рассчитать автоматически, основываясь на ограничениях контейнера?
Это вполне достижимо, если использовать базовый образ Docker, подготовленный сообществом Fabric8. Образ fabric8/java-jboss-openjdk8-jdk задействует скрипт, который выясняет ограничения контейнера и использует 50% доступной памяти как верхнюю границу. Обратите внимание на то, что вместо 50% можно использовать другое значение. Кроме того, этот образ позволяет включать и отключать отладку, диагностику, и многое другое. Взглянем на то, как выглядит Dockerfile для приложения Spring Boot:
Теперь всё будет работать так, как нужно. Независимо от ограничений памяти контейнера, наше Java-приложение всегда будет настраивать размер кучи в соответствии с параметрами контейнера, не основываясь на параметрах демона.
Использование разработок Fabric8
Итоги
JVM до сих пор не имеет средств, позволяющих определить, что она выполняется в контейнеризированной среде и учесть ограничения некоторых ресурсов, таких, как память и процессор. Поэтому нельзя позволять механизму JVM ergonomics самостоятельно задавать максимальный размер кучи.
Один из способов решения этой проблемы — использование образа Fabric8 Base, который позволяет системе, основываясь на параметрах контейнера, настраивать размер кучи автоматически. Этот параметр можно задать и самостоятельно, но автоматизированный подход удобнее.
В JDK9 включена экспериментальная поддержка JVM ограничений памяти cgroups в контейнерах (в Docker, например). Тут можно найти подробности.
Надо отметить, что здесь мы говорили о JVM и об особенностях использования памяти. Процессор — это отдельная тема, вполне возможно, мы ещё её обсудим.
Уважаемые читатели! Сталкивались ли вы с проблемами при работе с Java-приложениями в контейнерах Linux? Если сталкивались, расскажите пожалуйста о том, как вы с ними справлялись.
Упаковка jvm приложения в docker образ
Мы же решим практическую задачу по упаковке jvm приложения и получим контейнер с миниатюрным Linux, JDK и нашим приложением, который опубликуем на hub.docker.com и сможем запускать где угодно.
Исходное приложение
Если ваше приложение для jvm состоит из более чем одного файла и образ нужно генерировать регулярно/автоматически, то можно интегрировать процесс сборки в maven с помощью плагина com.spotify:docker-maven-plugin. Если же вы используете Gradle, то se.transmode.gradle:gradle-docker вам поможет сделать сборку docker образа. Пример для maven опубликовал на github.
В публикации используем jar из центрального maven репозитария. Это своя сборка груви, которая примечательна упакованным aether provide для разрешения зависимостей Grape и расширенной поддержкой протоколов для java.net.URL. Для пытливых умов:
Для меня это удобный инструмент, который часто использую. Как пример — загрузка jvm агента в запущенную JVM, инсталятор для crate.io, пример парсера сайта…
Теперь groovy-grape-aether доступен и в docker образе suhorukov/docker-groovy. В подобный образ вы может упаковать ваше приложение для jvm.
Dockerfile
Описывает на основе какого существующего образа и с помощью каких команд сформировать новый образ.
Воспользуемся образом frolvlad/alpine-oraclejdk8, с благодарностью frol за его труд! Этот образ на основе Alpine Linux image + glibc и Oracle JDK 8u102.14. Достаточно компактный, по сравнению с образами на основе на debian/ubuntu. Как альтернатива возможен популярный образ anapsix/alpine-java.
ENTRYPOINT определяет какая команда с параметрами будет запущена при старте контейнера. Для команды возможно указать с помощью CMD параметры по-умолчанию.
Собираем образ локально
Запускаем в той же директории, где находится наш Dockerfile команду
Публикация в hub.docker.com
Этот раздел можете пропустить, если у вас не opensource проект и вам не нужно делиться образом со всем миром.
Публикуем Dockerfile на github
В своей учетной записи на github выбираем New Repository и помещаем туда подготовленный Dockerfile. В этом примере используется репозитарий docker-groovy.
Настраиваем сборку в hub.docker.com
Создаем бесплатный аккаунт на главной странице hub.docker, заполнив форму и нажав «Sign Up». Обязательно активируем его с помощью письма в email.
В настройках аккаунта заходим во вкладку «Linked Accounts & Services» и настраиваем «Link Github» на ваш github аккаунт( другой вариант Bitbucket аккаунт).
В меню вверху страници выбираем Create->Create Automated Build, затем жмем«Create Auto-build Github», выбираем репозитарий и указываем где в репозитарии Dockerfile. При следующем push в репозитарий на github сборка автоматичеки запустится. Можно запустить и сборку вручную.
В результате всех вышеописанных действий получился такой проект на hub.docker.com.
Загрузка и использование контейнера
Перед использованием, получим образ из hub.docker.
И запустим контейнер с параметром-скриптом gitblit.groovy.
В случае, если для приложения нужен доступ к внешним для контейнера ресурсам в файловой системе (директории хост-машины, NFS, распределенной файловой системы) то нужно указать точки монтирования при создании образа в секции VOLUME в Dockerfile. Если же нужно распределенное выполнение и орекстрация контейнеров — Kubernetes / Mesos / Swarm / fabric8.io / Rancher более подходящие для этого технологии которые работают с docker.
Руководство по Kubernetes, часть 1: приложения, микросервисы и контейнеры
По нашей просьбе Хабр создал хаб Kubernetes и нам приятно разместить первую публикацию в нём. Подписывайтесь!
Kubernetes — это просто. Почему же банки платят мне за работу в этой сфере большие деньги, в то время как любой может освоить эту технологию буквально за несколько часов?
Если вы сомневаетесь в том, что Kubernetes можно изучить так быстро — предлагаю вам попытаться сделать это самим. А именно, освоив этот материал, вы сможете запустить приложение, основанное на микросервисах, в кластере Kubernetes. Я могу это гарантировать, так как именно по такой методике, которая использована здесь, я обучаю работе с Kubernetes наших клиентов. Что отличает это руководство от других? На самом деле — много всего. Так, большинство подобных материалов начинается с объяснения простых вещей — концепций Kubernetes и особенностей команды kubectl. Авторы этих материалов полагают, что их читатель знаком с разработкой приложений, с микросервисами и с контейнерами Docker. Мы же пойдём другим путём. Сначала расскажем о том, как запустить на компьютере приложение, основанное на микросервисах. Потом рассмотрим сборку образов контейнеров для каждого микросервиса. А уже после этого познакомимся с Kubernetes и разберём развёртывание приложения, основанного на микросервисах, в кластере, управляемом Kubernetes.
Такой подход, с постепенным приближением к Kubernetes, даст глубину понимания происходящего, необходимую обычному человеку для того, чтобы понять то, как просто всё устроено в Kubernetes. Kubernetes — это, безусловно, простая технология, при условии, что тому, кто хочет её освоить, известно, где и как она используется.
Теперь, без лишних слов, приступим к работе и поговорим о приложении, с которым мы будем работать.
Экспериментальное приложение
Наше приложение будет выполнять лишь одну функцию. Оно принимает, в качестве входных данных, одно предложение, после чего, используя средства анализа текстов, производит анализ тональности (sentiment analysis) этого предложения, получая оценку эмоционального отношения автора предложения к некоему объекту.
Вот как выглядит главное окно этого приложения.
Веб-приложение для анализа тональности текстов
С технической точки зрения приложение состоит из трёх микросервисов, каждый из которых решает определённый набор задач:
Потоки данных в приложении
На вышеприведённой схеме можно видеть пронумерованные этапы работы системы, иллюстрирующие потоки данных в приложении. Разберём их:
Запуск приложения, основанного на микросервисах, на локальном компьютере
Для того чтобы приложение заработало, нам нужно запустить все три микросервиса. Начнём с самого симпатичного из них — с фронтенд-приложения.
▍Настройка React для локальной разработки
Для того чтобы запустить React-приложение, вам нужно установить на своём компьютере платформу Node.js и NPM. После того, как вы всё это установите, перейдите, используя терминал, в папку проекта sa-frontend и выполните следующую команду:
▍Подготовка React-приложения к выводу в продакшн
Для целей реального использования React-приложения нам нужно преобразовать его в набор статических файлов и отдавать их клиентам, используя веб-сервер.
Для сборки React-приложения, снова, используя терминал, перейдите в папку sa-frontend и выполните следующую команду:
▍Обслуживание статических файлов средствами Nginx
React-приложение, обслуживаемое сервером Nginx
Если вы сейчас что-нибудь введёте в поле Type your sentence и нажмёте на кнопку Send — ничего не произойдёт. Но, если заглянуть в консоль, там можно увидеть сообщения об ошибках. Для того чтобы понять, где именно происходят эти ошибки, разберём код приложения.
▍Анализ кода фронтенд-приложения
1. URL, по которому выполняется POST-запрос. Подразумевается, что по этому адресу находится приложение, ожидающее подобные запросы.
2.Тело запроса, отправляемое приложению. Вот пример тела запроса:
Нам нужно Spring-приложение, способное принять POST-запрос
▍Настройка веб-приложения, основанного на Spring
Для того чтобы развернуть Spring-приложение, вам понадобится JDK8 и Maven и правильно настроенные переменные среды. После того, как вы всё это установите, вы можете продолжать работу над нашим проектом.
▍Упаковка приложения в jar-файл
Перейдите, с помощью терминала, в папку sa-webapp и введите следующую команду:
▍Запуск Java-приложения
Перейдите в папку target и запустите приложение следующей командой:
В ходе выполнения этой команды произойдёт ошибка. Для того чтобы приступить к её исправлению, мы можем проанализировать сведения об исключении в данных трассировки стека:
▍Анализ кода Java-приложения
Вот фрагмент кода, в котором происходит ошибка.
▍Задание значения свойства
Значение этого свойства должно указывать на адрес нашего Python-приложения.
Настраивая его, мы сообщаем веб-приложению Spring о том, куда ему нужно обращаться для выполнения запросов на анализ текста.
Для того чтобы не усложнять себе жизнь, решим, что Python-приложение будет доступно по адресу localhost:5000 и постараемся об этом не забыть. В результате команда для запуска Spring-приложения будет выглядеть так:
В нашей системе не хватает Python-приложения
Теперь нам осталось лишь запустить Python-приложение и система заработает так, как ожидается.
▍Настройка Python-приложения
Для того чтобы запустить Python-приложение, у вас должны быть установлены Python 3 и Pip, и нужно, чтобы были правильно настроены соответствующие переменные среды.
▍Установка зависимостей
Перейдите в папку проекта sa-logic/sa и выполните следующие команды:
▍Запуск приложения
После установки зависимостей мы готовы к тому, чтобы запустить приложение:
После выполнения этой команды нам сообщат следующее:
Это означает, что приложение запущено и ожидает запросы по адресу localhost:5000/
▍Исследование кода
Рассмотрим код Python-приложения для того, чтобы понять то, как оно реагирует на запросы:
Все микросервисы, из которых состоит приложение, приведены в работоспособное состояние
Теперь, прежде чем продолжать, откройте React-приложение в браузере и попытайтесь проанализировать с его помощью какое-нибудь предложение. Если всё сделано правильно — после нажатия на кнопку Send вы увидите под текстовым полем результаты анализа.
В следующем разделе мы поговорим о том, как запустить наши микросервисы в контейнерах Docker. Это нужно для того, чтобы подготовить приложение для запуска в кластере Kubernetes.
Контейнеры Docker
Kubernetes — это система для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями. Её ещё называют «оркестратором контейнеров» (container orchestrator). Если Kubernetes работает с контейнерами, то нам, прежде чем этой системой пользоваться, нужно сначала этими контейнерами обзавестись. Но сначала давайте поговорим о том, что такое контейнеры. Пожалуй, лучший ответ на вопрос о том, что это такое, можно найти в документации к Docker:
Образ контейнера — это легковесный, автономный, исполняемый пакет, содержащий некое приложение, который включает в себя всё необходимое для его запуска: код приложения, среду исполнения, системные средства и библиотеки, настройки. Контейнеризированными программами можно пользоваться в средах Linux и Windows, при этом они всегда будут работать одинаково независимо от инфраструктуры.
Это означает, что контейнеры можно запускать на любых компьютерах, в том числе, на продакшн-серверах, и в любых средах заключённые в них приложения будут работать одинаково.
Для того чтобы исследовать особенности контейнеров и сопоставить их с другими способами запуска приложений, рассмотрим пример обслуживания React-приложения с использованием виртуальной машины и контейнера.
▍Обслуживание статических файлов React-приложения средствами виртуальной машины
Пытаясь организовать обслуживание статических файлов средствами виртуальных машин, мы столкнёмся со следующими недостатками:
Веб-сервер Nginx, обслуживающий статические файлы, запущенный на виртуальной машине
Если же для решения аналогичной задачи применить контейнеры, то, в сравнении с виртуальными машинами, можно будет отметить следующие их сильные стороны:
Веб-сервер Nginx, обслуживающий статические файлы, запущенный в контейнере
Мы сопоставили виртуальные машины и контейнеры лишь по нескольким пунктам, но даже этого достаточно для того, чтобы ощутить сильные стороны контейнеров. Здесь можно найти подробности о контейнерах Docker.
▍Сборка образа контейнера для React-приложения
▍Подготовка файла Dockerfile для приложения SA-Frontend
▍Сборка образа и загрузка его в репозиторий
Прежде чем мы сможем работать с готовым образом, нам нужно отправить его в репозиторий образов. Для этого мы воспользуемся бесплатной облачной платформой для хостинга образов Docker Hub. На данном этапе работы вам нужно сделать следующее:
Теперь нужно, с помощью терминала, перейти в директорию sa-frontend и выполнить там команду следующего вида:
Для того чтобы отправить готовый образ в репозиторий нам понадобится такая команда:
После её выполнения проверьте список своих репозиториев на Docker Hub для того, чтобы понять, удачно ли прошла отправка образа в облачное хранилище.
▍Запуск контейнера
На данном этапе, после успешного запуска контейнера фронтенд-приложения, у вас должна быть возможность открыть его страницу в браузере.
Займёмся теперь образом для Java-приложения.
▍Сборка образа контейнера для Java-приложения
Знаете что, а ведь вы уже изучили всё необходимое для создания образов контейнеров. Именно поэтому данный раздел будет весьма коротким.
Ключевое слово ENV позволяет объявлять переменные окружения внутри контейнеров Docker. В частности, в нашем случае оно позволяет задать URL для доступа к API приложения, выполняющего анализ текста.
▍Сборка образа контейнера для Python-приложения
▍Тестирование контейнеризированных приложений
Можете ли вы доверять чему-то такому, что вы не протестировали? Я тоже не могу. Испытаем наши контейнеры.
Для того чтобы узнать о том, как выяснить IP-адрес контейнера или виртуальной машины Docker — обратитесь к файлу README.
Запустим контейнер приложения sa-frontend :
Теперь всё готово к тому, чтобы перейти в браузере по адресу localhost:80 и испытать приложение.
Вот как выглядит схема нашего приложения теперь.
Микросервисы выполняются в контейнерах