- Техподдержка
- Мы в соц. сетях
- Проект перестал открываться в Конструкторе
- проблема с открытием готовых проектов
- Петр Ульянов
- Docker: как развернуть фуллстек-приложение и не поседеть
- Как работает Docker?
- 0. Устанавливаем Docker
- 1. Пишем приложения
- Backend на Spring Boot
- Фронтенд на ReactJS
- 2. Собираем образы и запускаем контейнеры
- Сборка front-end
- Сборка back-end.
- 3. Собираем образы и запускаем контейнеры на удалённом сервере
- Создание аккаунта на хабе Docker
- Коммит образов на Docker Hub
- Запускаем образы на удалённом сервере
- 4. Решаем проблемы с сетью
- Заключение
Техподдержка
Телефоны
+7(903) 005 03 02
+7(967) 005 08 80
Мы в соц. сетях
Проект перестал открываться в Конструкторе
- проект,
- Конструктор,
- или настройки компьютера.
Для этого пройдите, пожалуйста, в папку Конструктора
C:\Program Files (x86)\e-publish
и попытайтесь запустить файл constructor.exe (или просто constructor , если на Вашем компьютере не настроено отображение расширения файлов).
Если в какой-то момент проект перестал открываться в Констуркторе, то сначала необходимо узнать что служит причиной проблемы:
- проект,
- Конструктор,
- или настройки компьютера.
Для этого пройдите, пожалуйста, в папку Конструктора
C:\Program Files (x86)\e-publish
и попытайтесь запустить файл constructor.exe (или просто constructor , если на Вашем компьютере не настроено отображение расширения файлов).
а) Если данного файла в папке Конструктора Вы не найдете , значит его удалил излишне щепетильный антивирус, посчитав приложение, собирающее информацию и отправляющее её в Интернет, вирусом.
В силу специфики работы Конструктора (сбор информации и отправка её в сеть Internet) антивирусы могут принимать Конструктор за вирус и ощутимо тормозить работу Конструктора, закрывать программу, а то и вовсе удалять рабочие файлы программы.
Мы же в свою очередь можем гарантировать, что в (скачанном из виртуального кабинета) Конструкторе нет вирусов, так как Конструктор целиком и полностью разработан нами.
В таком случае переустановите, пожалуйста, Конструктор.
Отключите, пожалуйста, антивирус на время скачивания и установки.
С подробным руководством по скачиванию установочного файла Конструктора Вы можете ознакомиться на странице «Скачиваем дистрибутив (установочный файл)»
С подробным руководством по установке Конструктора Вы можете ознакомиться на странице «Устанавливаем Конструктор»
После установки внесите, пожалуйста, папку с Конструктором (C:\Program Files (x86)\e-publish) в доверенную зону антивируса.
Как это сделать в самых распространенных антивирусах Вы можете узнать на странице «Антивирус блокирует программу»
Важно:
Убедитесь, пожалуйста, перед установкой, что папка с Вашим проектом не размещена в папке Конструктора —
C:\Program Files (x86)\e-publish
во избежание потери данных проекта при установке Конструктора.
Если папка с проектом находится у Вас в папке Конструктора, перенесите её, пожалуйста, перед установкой в другую директорию.
б) Если файл constructor.exe есть в папке и нормально запустился , закройте, пожалуйста, это окно.
Значит проблема с проектом.
1. Если Ваш проект находится на съемном носителе, перенесите, пожалуйста, его на компьютер.
Важно:
Мы настоятельно рекомендуем не хранить проект на съемном носителе.
Это не самый надежный вид хранения проекта,
так как мы получали множество сообщений о потере проекта из-за повреждения съемного носителя (как частичного, так и полного),
или нехватки свободного места на носителе.
Либо просто повреждения соединения со съемным носителем.
Если Вам необходимо работать с сайтом на разных компьютерах, рекомендуем разместить папку с проектом в какое-нибудь облачное хранилище, к примеру:
Тогда и проект не нужно будет носить с компьютера на компьютер;
и доступ к проекту будет всегда (при наличии интернет-подключения, конечно);
и исчезает опасность потери проекта из-за поломки флешки.
Более детально о работе с проектом на двух (и более) компьютерах Вы можете ознакомиться на странице «Работа с сайтом на двух и более компьютерах»
2. Перенеся папку с проектом на компьютер;
либо, если папка изначально была на компьютере и переносить не понадобилось,
попытайтесь, пожалуйста, восстановить прежнюю (рабочую) версию проекта.
Вы можете восстановить проект из папки backup , находящейся в основной папке Вашего проекта.
Это папка резервного сохранения при конвертации.
С подробным руководством по восстановлению проекта из папки резервного копирования Вы можете ознакомиться на странице «Восстановление проекта»
Если восстановить из проект из папки резервного копирования не получится,
для устранения проблемы пришлите нам, пожалуйста, на наш электронный адрес info@edusite.ru с электронного адерса, указанного в Вашем виртуальном кабинете,
заархивированную основную папку Вашего проекта
( всю папку ,
внутри которой лежат папки: backup, DswMedia, images, project и прочие,
а также файлы: project.esc, menus.js, st.css, и прочие).
Если архив получится слишком большим, воспользуйтесь, пожалуйста, любым из следующих файлохранилищ:
И укажите нам ссылку на Ваш архив в облачном хранилище.
Также укажите, пожалуйста:
- Адрес Вашего сайта;
- В случае, если Ваш сайт находится не на нашем сервере, укажите тогда еще и «имя пользователя» (логин от виртуального кабинета на http://cp.edusite.ru/ , он же — номер договора). Только логин, пароль не нужно указывать
1. Запустить от имени администратора, кликнув правой кнопкой мыши по файлу и выбрав пункт «Запуск от имени администратора».
в) Если файл constructor.exe не запустится, или программа без проекта зависнет , то попробуйте, пожалуйста, следующие варианты:
1. Запустить от имени администратора, кликнув правой кнопкой мыши по файлу и выбрав пункт «Запуск от имени администратора».
- constructor.exe ,
FTPclient.exe и
ZipIt.exe ,
находящихся в папке ( C:\Program Files (x86)\e-publish ); - Editor.exe ,
находящегося в папке ( Pasport ); - zipit.exe ,
находящегося в папке ( zipit ).
Для того, чтобы установить уровень прав — запуск от имени администратора,
кликните правой кнопкой мыши по файлу и выберите пункт » Свойства «.
В появившемся окне перейдите во вкладку » Совместимость »
и установите отметку на пункте » Выполнять эту программу от имени администратора «
Если от имени администратора программа откроется нормально, то установите, пожалуйста, уровень прав — запуск от имени администратора для файлов:
- constructor.exe ,
FTPclient.exe и
ZipIt.exe ,
находящихся в папке ( C:\Program Files (x86)\e-publish ); - Editor.exe ,
находящегося в папке ( Pasport ); - zipit.exe ,
находящегося в папке ( zipit ).
Для того, чтобы установить уровень прав — запуск от имени администратора,
кликните правой кнопкой мыши по файлу и выберите пункт » Свойства «.
В появившемся окне перейдите во вкладку » Совместимость »
и установите отметку на пункте » Выполнять эту программу от имени администратора «
2. Запустите при выключенном антивирусе.
Если откроется при выключенном антивирусе, то, опять же, внесите, пожалуйста, папку с Конструктором (C:\Program Files (x86)\e-publish) в доверенную зону антивируса.
Как это сделать в самых распространенных антивирусах Вы можете узнать на странице «Антивирус блокирует программу»
3. Последуйте инструкциям, размещенным на странице «Проблемы с установкой или обновлением»
4. Если файл не запускается и такими способами, то обновите версию установленной на Вашем компьютере программной платформы Microsoft Framework
Для нормальной работы Конструктора требуются установленные версии платформы Microsoft Framework с 2.0 по 4.7.
То есть должны быть установлены все версии:
Как посмотреть и доставить, в случае необходимости, версии Framework на Вашем компьютере Вы можете узнать на странице «Системные требования»
Важно:
Если у Вас на компьютере установлена Windows 7 и уже установлена версия Framework 4.7 ,
то удалите её, пожалуйста, и установите 4.6
В Windows 7 достаточно чтоб были установлены/активированы версии Framework:
3.5 (обязательно со вторым сервиспаком) и
4.0 (либо любая другая версия, выше 4.0,
но ниже 4.7 (так как версии 4.7 и выше не всегда корректно работают с Windows 7)
Если у Вас на компьютере установлена Windows XP , то возможно придется обновить и Windows, если Framework не будет устанавливаться.
Дело в том, что Microsoft уже не поддерживает Windows XP, в связи с чем крайне проблематично решать возникающие проблемы, связанные с этой версией Windows.
Или же, если есть возможность, перенесите работу с Конструктором на другой компьютер, с более новой версией Windows и установленными версиями Framework с 2.0 по 4.7
5. Если же до сих пор не запускается, проверьте, пожалуйста, системные файлы.
Источник
проблема с открытием готовых проектов
Петр Ульянов
Пользователь сайта
Уважаемые пользователи, профи и спецы АЕ, всем привет! Ай нид ХЕЛП))
Столкнулся вот с такой проблемой: АЕ не открывает готовые проекты, которые скачал из сети, хотя другие скачавшие на такой баг не жаловались.
Теперь подробно.
Скачал себе кучу готовых проектов в АЕ, которые были созданы в cs3, cs4 , а у меня стоит cs5 макинтош снежный леопард, 64 битная версия. Может быть из-за этого? или все же я что-то не так делаю? АЕ не открывает ваще ни одного проекта, но сам при этом запускается, выскакивает вот такое окно (смотри фотку)
и вообще как может быть такое, что АЕ не может открыть свои же проекты, пусть и созданные старыми версиями, хотя они не такие уж и старые))
Название модели: Mac Pro
Идентификатор модели: MacPro4,1
Имя процессора: Intel Core i7
Скорость процессора: 3.24 ГГц
Количество процессоров: 1
Общее количество ядер: 4
Кэш 2-го уровня (в каждом ядре): 256 КБ
Кэш L3: 8 МБ
Память: 10 ГБ
Скорость внутреннего соединения процессора : 133 MT/с
Версия Boot ROM: MP41.00C1.B00
Модель набора микросхем: GeForce 9800 GT
Тип: GPU
Шина: PCIe
Ширина полосы PCIe: x16
VRAM-память (всего): 1024 МБ
Производитель: NVIDIA (0x10de)
Размер: 2 ГБ
Тип: DDR3
Скорость: 1066 МГц
Статус: ОК
Размер: 2 ГБ
Тип: DDR3
Скорость: 1066 МГц
Статус: ОК
Размер: 2 ГБ
Тип: DDR3
Скорость: 1066 МГц
Статус: ОК
Размер: 2 ГБ
Тип: DDR3
Скорость: 1066 МГц
Статус: ОК
Размер: 2 ГБ
Тип: DDR3
Скорость: 1066 МГц
Статус: ОК
Источник
Docker: как развернуть фуллстек-приложение и не поседеть
«Нам нужен DevOps!»
(самая популярная фраза в конце любого хакатона)
Сначала немного лирики.
Когда разработчик является отличным девопсом, умеющим развернуть своё детище на любой машине под любой OC, это плюс. Однако, если он вообще ничего не смыслит дальше своей IDE, это не минус — в конце концов, деньги ему платят за код, а не за умение его разворачивать. Узкий глубокий специалист на рынке ценится выше, чем средней квалификации «мастер на все руки». Для таких, как мы, «пользователей IDE», хорошие люди придумали Docker.
Принцип Docker следующий: «работает у меня — работает везде». Единственная программа, необходимая для деплоя копии Вашего приложения где угодно — это Docker. Если Вы запустили своё приложение в докере у себя на машине, оно гарантированно с тем же успехом запустится в любом другом докере. И ничего, кроме докера, устанавливать не нужно. У меня, к примеру, на виртуальном сервере даже Java не стоит.
Как работает Docker?
Docker создаёт образ виртуальной машины с установленными в ней приложениями. Дальше этот образ разворачивается как абсолютно автономная виртуальная машина. Запущенная копия образа называется «контейнер». Вы можете запустить на сервере любое количество образов, и каждый из них будет отдельной виртуальной машиной со своим окружением.
Что такое виртуальная машина? Это инкапсулированное место на сервере с операционкой, в которой установлены приложения. В любой операционке обычно крутится большое количество приложений, в нашей же находится одно.
Схему развёртывания контейнеров можно представить так:
Для каждого приложения мы создаём свой образ, а потом разворачиваем каждый контейнер отдельно. Также, можно положить все приложения в один образ и развернуть как один контейнер. Причём, чтобы не разворачивать каждый контейнер отдельно, мы можем использовать отдельную утилиту docker-compose, которая конфигурирует контейнеры и взаимосвязь между ними через отдельный файл. Тогда структура всего приложения может выглядеть так:
Я намеренно не стал вносить базу данных в общую сборку Docker, по нескольким причинам. Во-первых, база данных полностью независима от приложений, которые с ней работают. Это может быть далеко не одно приложение, это могут быть ручные запросы из консоли. Лично я не вижу смысла ставить базу данных в зависимость от сборки Docker, в которой она находится. Поэтому я её и вынес. Впрочем, очень часто практикуется подход, при котором база данных помещается в отдельный образ и запускается отдельным контейнером. Во-вторых, хочется показать, как Docker-контейнер взаимодействует с системами вне контейнера.
Впрочем, довольно лирики, давайте писать код. Мы напишем простейшее приложение на спринге и реакте, которое будет записывать наши обращения к фронту в базу данных, и поднимем всё это через Docker. Структура нашего приложения будет выглядеть так:
Реализовать такую структуру можно разными путями. Мы реализуем один из них. Мы создадим два образа, запустим из них два контейнера, причём, бэкенд будет подключаться к базе данных, которая установлена на конкретном сервере где-то в интернете (да, такие запросы к базе будут ходить не быстро, но нами движет не жажда оптимизации, а научный интерес).
Пост будет разбит на части:
0. Устанавливаем Docker.
1. Пишем приложения.
2. Собираем образы и запускаем контейнеры.
3. Собираем образы и запускаем контейнеры на удалённом сервере.
4. Решаем проблемы с сетью.
0. Устанавливаем Docker
Для того, чтобы установить Docker, нужно зайти на сайт и следовать тому, что там написано. При установка Docker на удалённом сервере будьте готовы к тому, что с серверами на OpenVZ Docker может не работать. Равно как могут быть проблемы, если у Вас не включён iptables. Желательно заводить сервер на KVM с iptables. Но это мои рекомендации. Если у Вас всё заработает и так, я буду рад, что Вы не потратили кучу времени на выяснение, почему не работает, как это пришлось сделать мне.
1. Пишем приложения
Напишем простое приложение с самым примитивным бэкендом на Spring Boot, очень простым фронтендом на ReactJS и базой данных MySQL. Приложение будет иметь Single-Page с одной-единственной кнопкой, которая будет записывать время нажатия по ней в базу данных.
Я рассчитываю на то, что Вы уже умеете писать приложения на буте, но если нет, Вы можете клонировать готовый проект. Все ссылки в конце статьи.
Backend на Spring Boot
LogController, который будет работать по упрощённой логике и сразу писать в базу данных. Сервис мы опускаем.
Всё, как мы видим, очень просто. По GET-запросу мы делаем запись в базу и возвращаем результат.
Файл настроек приложения обсудим отдельно. Их два.
Как это работает, Вы, наверняка, знаете, сначала Spring сканирует файл application.properties или application.yml — какой найдёт. В нём мы указываем одну-единственную настройку — какой профиль будем использовать. Обычно во время разработки у меня накапливается несколько профилей, и очень удобно их переключать при помощи дефолтного профиля. Далее Spring находит application.yml с нужным суффиксом и пользует его.
Мы указали датасорс, настройки JPA и, что важно, внешний порт нашего бэкенда.
Фронтенд на ReactJS
Фронтенд тоже можно посмотреть в проекте на git, а можно даже не смотреть, а клонировать и запустить.
Отдельную работу фронтенда можно проверить, скачав проект, перейдя в терминале в корневую папку проекта (туда, где лежит файл package.json) и выполнив последовательно две команды:
Конечно, для этого Вам нужен установленный Node Package Manager (npm), и это тот самый трудный путь, которого мы избегаем при помощи Docker. Если Вы всё-таки запустили проект, Вы увидите следующее окошко:
Ну да ладно, настало время посмотреть код. Укажу лишь часть, которая обращается к бэкенду.
Фронтенд работает предсказуемо. Переходим по ссылке, дожидаемся ответа и выводим его на экран.
Стоит акцентировать внимание на следующих пунктах:
- Фронт открыт внешнему миру через порт 3000. Это порт по умолчанию для React.
- Бэк открыт по порту 8099. Мы его задали в настройках приложения.
- Бэк стучится к БД через внешний интернет.
Приложение готово.
2. Собираем образы и запускаем контейнеры
Структура нашей сборки будет следующая. Мы создадим два образа — фронтенд и бэкенд, которые будут общаться друг с другом через внешние порты. Для базы мы не будем создавать образ, мы установим её отдельно. Почему так? Почему для базы мы не создаём образ? У нас есть два приложения, которые постоянно изменяются и не хранят в себе данные. База данных хранит в себе данные, и это может быть результат нескольких месяцев работы приложения. Более того, к данной базе данных может обращаться не только наше бэкенд-приложение, но и многие другие — на то она и база данных, и мы не будем её постоянно пересобирать. Опять же, это возможность поработать с внешним API, чем, безусловно, является подключение к нашей БД.
Сборка front-end
Для запуска каждого приложения (будь то фронт или бэк) потребуется определённая последовательность действий. Для запуска приложения на React нам потребуется сделать следующее (при условии, что у нас уже есть Linux):
- Установить NodeJS.
- Скопировать приложение в определённую папку.
- Проинсталлировать необходимые пакеты (команда npm install).
- Запустить приложение командой npm start.
Именно эту последовательность действий нам и предстоит выполнить в докере. Для этого в корне проекта (там же, где находится package.json) мы должны разместить файл Dockerfile со следующим содержанием:
Разберём, что означает каждая строчка.
Этой строчкой мы даём понять докеру, что при запуске контейнера первым делом нужно будет скачать из репозитория Docker и установить NodeJS, причём, самую лёгкую (все самые лёгкие версии популярных фреймворков и библиотек в докере принято называть alpine).
В линуксе контейнера будут созданы те же стандартные папки, что и в других линуксах — /opt, /home, /etc, /usr и проч. Мы задаём рабочую директорию, с которой будем работать — /usr/app/front.
Открываем порт 3000. Дальнейшая связь с приложением, запущенным в контейнере, будет происходить через этот порт.
Копируем содержимое исходного проекта в рабочую папку контейнера.
Устанавливаем все пакеты, необходимые для запуска приложения.
Запускаем приложение командой npm start.
Именно этот сценарий будет выполнен в нашем приложении при запуске контейнера.
Давайте сразу соберём фронт. Для этого нужно в терминале, находясь в корневой папке проекта (там, где находится Dockerfile), выполнить команду:
docker — вызов приложения docker, ну, это вы знаете.
build — сборка образа из целевых материалов.
-t — в дальнейшем, приложение будет доступно по тегу, указанному здесь. Можно не указывать, тогда Docker сгенерирует собственный тег, но отличить его от других будет невозможно.
. — указывает, что собирать проект нужно именно из текущей папки.
В результате, сборка должна закончиться текстом:
Если мы видим, что последний шаг выполнен и всё Successfull, значит, образ у нас есть. Мы можем проверить это, запустив его:
Смысл этой команды, я думаю, в целом понятен, за исключением записи -p 8080:3000.
docker run rebounder-chain-frontend — означает, что мы запускаем такой-то докер-образ, который мы обозвали rebounder-chain-frontend. Но такой контейнер не будет иметь выхода наружу, ему нужно задать порт. Именно команда ниже его задаёт. Мы помним, что наше React-приложение запускается на порте 3000. Команда -p 8080:3000 указывает докеру, что нужно взять порт 3000 и пробросить его на порт 8080 (который будет открыт). Таким образом, приложение, которое работает по порту 3000, будет открыто по порту 8080, и на локальной машине будет доступно именно по этому порту.
Пусть вас не смущает запись
Так думает React. Он действительно доступен в пределах контейнера по порту 3000, но мы пробросили этот порт на порт 8080, и из контейнера приложение работает по порту 8080. Можете запустить приложение локально и проверить это.
Итак, у нас есть готовый контейнер с фронтенд-приложением, теперь давайте соберём бэкенд.
Сборка back-end.
Сценарий запуска приложения на Java существенно отличается от предыдущей сборки. Он состоит из следующих пунктов:
- Устанавливаем JVM.
- Собираем jar-архив.
- Запускаем его.
В Dockerfile этот процесс выглядит так:
Процесс сборки образа с включением джарника по некоторым пунктам напоминает таковой для нашего фронта.
Процесс сборки и запуска второго образа принципиально ничем не отличается от сборки и запуска первого.
Теперь, если у Вас запущены оба контейнера, а бэкенд подключён к БД, всё заработает. Напоминаю, что подключение к БД из бэкенда Вы должны прописать сами, и оно должно работать через внешнюю сеть.
3. Собираем образы и запускаем контейнеры на удалённом сервере
Для того, чтобы всё заработало на удалённом сервере, нам необходимо, чтобы на нём был уже установлен Docker, после чего, достаточно запустить образы. Мы пойдём правильным путём и закоммитим наши образы в свой аккаунт в облаке Docker, после чего, они станут доступны из любой точки мира. Конечно, альтернатив данному подходу, как и всему, что описано в посте, предостаточно, но давайте ещё немного поднажмём и сделаем свою работу хорошо. Плохо, как говорил Андрей Миронов, мы всегда успеем сделать.
Создание аккаунта на хабе Docker
Первое, что Вам предстоит сделать — это обзавестись аккаунтом на хабе Docker. Для этого надо перейти на хаб и зарегаться. Это несложно.
Далее, нам нужно зайти в терминал и авторизоваться в Docker.
Вас попросят ввести логин и пароль. Если всё ок, в терминале появится уведомление, что Login Succeeded.
Коммит образов на Docker Hub
Далее, мы должны пометить наши образы тэгами и закоммитить их в хаб. Делается это командой по следующей схеме:
Таким образом, нам нужно указать имя нашего образа, логин/репозиторий и тэг, под которым наш образ будет закоммичен в хаб.
В моём случае, это выглядело так:
Мы можем проверить наличие данного образа в локальном репозитории при помощи команды:
Наш образ готов к коммиту. Коммитим:
Должна появиться запись об успешном коммите.
Делаем то же самое с фронтендом:
Теперь, если мы зайдём на hub.docker.com, мы увидим два закоммиченных образа. Которые доступны откуда угодно.
Поздравляю. Нам осталось перейди к заключительной части нашей работы — запустить образы на удалённом сервере.
Запускаем образы на удалённом сервере
Теперь мы можем запустить наш образ на любой машине с Docker, выполнив всего одну строчку в терминале (в нашем случае, нам надо последовательно выполнить две строчки в разных терминалах — по одной на каждый образ).
У такого запуска есть, правда, один минус. При закрытии терминала процесс завершится и приложение прекратит работу. Чтобы этого избежать, мы можем запустить приложение в «откреплённом» режиме:
Теперь приложение не будет выдавать лог в терминал (это можно, опять же, настроить отдельно), но и при закрытии терминала оно не прекратит свою работу.
4. Решаем проблемы с сетью
Если Вы всё сделали правильно, Вас, возможно, ожидает самое большое разочарование на всём пути следования этому посту — вполне может так получиться, что ничего не работает. Например, у Вас всё великолепно собралось и заработало на локальной машине (как, например, у меня на маке), но при развёртывании на удалённом сервере контейнеры перестали друг друга видеть (как, например, у меня на удалённом сервере на Linux). В чём проблема? А проблема вот в чём, и я в начале о ней намекал. Как уже было сказано раньше, при запуске контейнера Docker создаёт отдельную виртуальную машину, накатывает туда Linux, и потом в этот Linux устанавливает приложение. Это значит, что условный localhost для запущенного контейнера ограничивается самим контейнером, и о существовании других сетей приложение не подозревает. Но нам нужно, чтобы:
а) контейнеры видели друг друга.
б) бэкенд видел базу данных.
Решения проблемы два.
1. Создание внутренней сети.
2. Вывод контейнеров на уровень хоста.
1. На уровне Docker можно создавать сети, причём, три из них в нём есть по умолчанию — bridge, none и host.
Bridge — это внутренняя сеть Docker, изолированная от сети хоста. Вы можете иметь доступ к контейнерам только через те порты, которые открываете при запуске контейнера командой -p. Можно создавать любое количество сетей типа bridge.
None — это отдельная сеть для конкретного контейнера.
Host — это сеть хоста. При выборе этой сети, Ваш контейнер полностью доступен через хост — здесь попросту не работает команда -p, и если Вы развернули контейнер в этой сети, то Вам незачем задавать внешний порт — контейнер доступен по своему внутреннему порту. Например, если в Dockerfile EXPOSE задан как 8090, именно через этот порт будет доступно приложение.
Поскольку нам нужно иметь доступ к базе данных сервера, мы воспользуемся последним способом и выложим контейнеры в сеть удалённого сервера.
Делается это очень просто, мы убираем из команды запуска контейнера упоминание о портах и и указываем сеть host:
Подключение к базе я указал
Подключение фронта к бэку пришлось указать целиком, внешнее:
Если вы пробрасываете внутренний порт на внешний, что часто бывает для удалённых серверов, то для базы нужно указывать внутренний порт, а для контейнера — внешний порт.
Если Вы хотите поэкспериментировать с подключениями, вы можете скачать и собрать проект, который я специально написал для тестирования соединения между контейнерами. Просто вводите необходимый адрес, жмёте Send и в режиме отладки смотрите, что прилетело обратно.
Заключение
Есть масса способов собрать и запустить образ Docker. Интересующимся советую изучить docker-compose. Здесь мы разобрали лишь один из способов работы с докером. Конечно, такой подход поначалу кажется не таким уж и простым. Но вот пример — в ходе написания поста у меня возникли с исходящими подключениями на удалённом сервере. И в процессе дебага мне пришлось несколько раз менять настройки подключения к БД. Вся сборка и деплой умещались у меня в набор 4 строчек, после ввода которых я видел результат на удалённом сервере. В режиме экстремального программирования Docker окажется незаменим.
Как и обещал, выкладываю исходники приложений:
Источник