Все новости проекта теперь доступны в telegram-канале – подписывайтесь! А ниже по темам сгруппированы все статьи, которые вы можете найти на сайте.
Стандарт взаимодействия между клиентом и сервером. Альтернатива restful-сервисам.
Базовые алгоритмы, которые могут быть реализованы на любом языке программирования.
Прикладные задачи, которые можно решить с помощью сторонних библиотек.
Kotlin, Java, Spring, Spring Boot, Spring Data, Spring AI, SQL, PostgreSQL, Oracle, H2, Linux, Hibernate, Collections, Stream API, многопоточность, чат-боты, нейросети, файлы, devops, Docker, Nginx, Apache, maven, gradle, JUnit, YouTube, новости, руководство, ООП, алгоритмы, головоломки, rest, GraphQL, Excel, XML, json, yaml.
Если я правильно понял вопрос, на клиенте (мы говорим про спринговые RestClient/WebClient) специальным образом никак "поддерживать" сертификат не требуется. Просто указываем эндпоинт с https.
А как на клиенте поддержать сертификат, выпущенный доменом в Dockhost?
Ага, собирать лучше из main (master), а сертификат dockhost автоматом настроит.
Да, r-service можно не указывать в связке домен-сервис маршрута, удалил его.
Вся проблема была в том, что пайплайн собирался не из того коммита на гитхабе и каждый раз поднимался tomcat по https.
Внутри dockhost в маршруте используется http и поэтому был Bad Request. Нужно просто отключить в веб-сервисе SSL, использовать сертификат домена и поддержать его на клиенте. На хосте всё и так автоматически защищено.
Ну и авторизацию на веб-сервисе написать, чтобы чужие не гуляли.
service или app - тут не имеет значения, это просто название. важно что домен мы привязываем к определённому порту, который должен быть открыт у контейнера. и конечное приложение должно слушать именно этот порт. Если на карте сети появились лишние элементы - попробуйте их удалить вручную.
Ну и ещё можно обратиться в техподдержку dockhost - там очень хорошие специалисты работают.
Так я сначала в проекте настраиваю переменные среды, подключаю репозиторий Git и получаю контейнер r-app.
Затем у этого контейнера r-app я открываю порт 8761.
После этого создаю динамический контейнер r-domain.
Затем создаю сетевой сервис r-service, в котором указываю контейнер r-app и порт 8761.
Далее создаю маршрут r-web, в котором указываю домен r-domain и сервис r-service (кстати, у вас в статье подключается не devmark-service,а devmark-app).
Потом в браузере открываю домен и мне в ответ:
Bad Request
This combination of host and port requires TLS.
Я пробовал поиграться и в маршруте указывал и r-service, и r-app - одинаковый результат.
По статье получается 5 элементов и какой-то один будет сбоку (смотря что выбрать в маршруте).
В карте сети там должно быть 4 элемента в одну линию: домен -> путь -> app -> реплика. Кажется, сервис у вас тут лишний - удалите его.
У меня получилась такая карта сети для моего API:
r-service (111.111.111.111) -|
v
Домен (333.333.333.333) -> r-web (путь: \) -> r-app (222.222.222.222) -> r (реплика: 1)
Так и должно быть? service как-то отдельно от всего и в него не входит ничего. И service, и app в настройках имеют 8888 порт. Ради интереса открыл в браузере ip домена без указания порта (его же не надо указывать?) и получил:
Bad Request
This combination of host and port requires TLS
В клиентском приложении пока не получается коннект с API, использую самоподписанные сертификаты. В логкате:
E Network error: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
Если запускать в эмуляторе и подключаться из одной локальной сети с телефона к сервису, то всё ок. В чём мой косяк?
приятно удивлен, спасибо. Ничего лишнего, все понятно...
Спасибо и респект!
очень удобно
В общем случае можно либо использовать базу данных по модели saas (когда хостинг сам берёт на себя все вопросы администрирования), либо поднять докер с нужным postgres, а данные хранить в примонтированном диске.
Что касается конкретно dockhost, там в админке есть раздел "Приложения", где можно быстро развернуть движок любой базы данных (и не только).
А как быть, если веб-сервис работает с базой данных? Не совсем понимаю этот момент.
Считайте, что каждая такая вставка как отдельная транзакция. То есть тот, кто вставит позже, перезатрёт данные того, кто вставил первым. Обычно такие конфликты разруливают например через таблицу синхронизации, как и для шедулеров.
А если с этой таблицей будут работать два воркера. То есть будет вероятность одновременной батч вставки практически одинаковых данных (но у одного из воркеров чуть более свежие данные). Как разрулить конфликт, кто должен первым вставить.
not bad
Лучший онлайн генератор uuid в моей жизни
Имба
Спасибо, админу здоровья!
devmark, не 5.3 * 10^36, а 16^32 или 3.4 * 10^38