Добрый. Подскажите пожалуйста как накатить миграции для базы данных Postgresql

в контейнере Docker? Собрал в вижле свое ASP.Net приложение через файл docker-compose.
Кстати вот он:

version: '3.4'

services:
naladimbot:
image: ${DOCKER_REGISTRY-}naladimbot
build:
context: .
dockerfile: NaladimBot/Dockerfile
ports:
- "80:80"
depends_on:
- db
networks:
- mynetwork
db:
image: postgres:latest
ports:
- "5432:5432"
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: 23r2323ffsedsEGDS#%23EAF
POSTGRES_DB: NaladimBot.Database
volumes:
- db:/var/lib/postgresql/
networks:
- mynetwork

volumes:
db:

networks:
mynetwork:
driver: bridge

А вот строка подключения:


"ConnectionStrings": {
"DefaultConnection": "Server=db;Port=5432;Username=postgres;Password=23r2323ffsedsEGDS#%23EAF;Database=NaladimBot.Database;"
}


Все контейнеры появились в Docker Desktop. Но вот пытаюсь через Package Manager Console накатить миграции командой update-database, сталкиваюсь с ошибкой "Этот хост не найден".
В строке подключения пробывал менять server на Server=localhost, миграции наказываются успешно, но к базе данных не подключается в дальнейшем при работе приложения через докер. Что я делаю не так, где затык?

так db это не uri и не имя хоста в целом

Тогда получается затык в строке подключения?

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

Вообще накатка миграций на старте не самая лучшая идея, хотя иногда так и делают

А обоснование будет?

Да, можно погуглить 12 factor app, если устроит. А если нет, то, например, если приложение на старте не сможет накатить миграции, то упадёт вместе с контейнером и даже логи нельзя будет посмотреть нормально без танцев. +замедляется старт приложения

Ещё к причинам относят то, что может быть несколько инстансов таких сервисов, в которых происходят автомиграции и может случиться грязь) Но нам похер, мы накатываем)

> 12 factor app Это вообще не про миграции. А если нет, то, например, если приложение на старте не сможет накатить миграции, то упадёт вместе с контейнером А кто его падать обязывает?

В мультиинстансах вообще нельзя миграции применять )

Не вижу смысла спорить, если вы не понимаете о чём речь, честно.

Применяю и чувствую себя прекрасно 😁 прилепили ретрай на эту логику и ни разу проблем не возникло)

И как вам ретрай помогает, если провели миграцию, а половина инстансов со старой схемой?

А, мультиинстансы БДшек?) Я то про сервисы говорю, БД одна) у нас не шибко высокая нагрузка :)

Ну даже в этом случае сами инстансы отвалятся при обращении к одной БД, если схема не соответствует...

Кто-то же из них накатит миграцию при старте Что тут отвалится?

А кто будет гарантировать что они все одной версии? И как будет определяться кто из них будет накатывать... Как бы в паралель срать не начали... ну такое...

Ни разу в параллель не ушли) может когда-то обосремся, но не сегодня) Если инстанс не смог накатить, потому что другой накатывает - уходит в ретрай, на следующей итерации он смотрит, а схема уже соответствует и ничего не накатывает) На нашем проекте вполне достаточно такой логики

Не суть, я так то про монолит говорил )) Микросервисы сами по себе другая тема.

package manager не работает с компоузом