а как ты обращаясь к переменной в скупе плучаешь доступ к верхней переменной? она же переопределена через := или нет?

да легко, она же выше объявлена

но я копипастил и не заметил := вместо =

Господа, прошу помощи и совета. Запускаю приложение на го с базой через docker-compose, приложение не может зарезолвить адрес контейнера по его имени, хотя если зайти в контейнер и сделать пинг по имени - все нормально резолвится. Пробовал переменные окружения ENV GODEBUG=netdns=go и ENV GODEBUG=netdns=cgo - все равно не хочет резолвить имя контейнера с базой. Как быть?

а как ты обращаясь к переменной в скупе плучаешь доступ к верхней переменной? она же переопределена через := или нет?

err := lib.Func() if 1 == 1 { err := lib2.Func() } return err

Господа, прошу помощи и совета. Запускаю приложение на го с базой через docker-compose, приложение не может зарезолвить адрес контейнера по его имени, хотя если зайти в контейнер и сделать пинг по имени - все нормально резолвится. Пробовал переменные окружения ENV GODEBUG=netdns=go и ENV GODEBUG=netdns=cgo - все равно не хочет резолвить имя контейнера с базой. Как быть?

docker-compose в студию

как вы можете заметить, мы нихрена не обработали err и возращаем его

docker-compose в студию

version: '3' services: database: container_name: am-log-user-service-db image: percona:5.7 environment: MYSQL_ROOT_PASSWORD: "qazxsw" MYSQL_DATABASE: am_log_user_service volumes: - /opt/DB/am-log-user-service/:/var/lib/mysql/ restart: always depends_on: - web web: container_name: am-log-user-service-http image: am-log-user-service volumes: - ./log/:/app/log/ ports: - 8091:8091 restart: on-failure

случайно написал := и мы получим чертичто

version: '3' services: database: container_name: am-log-user-service-db image: percona:5.7 environment: MYSQL_ROOT_PASSWORD: "qazxsw" MYSQL_DATABASE: am_log_user_service volumes: - /opt/DB/am-log-user-service/:/var/lib/mysql/ restart: always depends_on: - web web: container_name: am-log-user-service-http image: am-log-user-service volumes: - ./log/:/app/log/ ports: - 8091:8091 restart: on-failure

depends_on: - web почему если наоборот?

какой хост используешь?

depends_on: - web почему если наоборот?

Верно, косяк, спасибо, сейчас поправлю. Коннекчусь к хосту database

Верно, косяк, спасибо, сейчас поправлю. Коннекчусь к хосту database

а если так: am-log-user-service-db?

Так внутри контейнера нормально резолвится database

Ща попробую сначала композ поправить

Так внутри контейнера нормально резолвится database

я не это спросил)

Тогда я не понял вопроса

Тогда я не понял вопроса

пробовал ли так: am-log-user-service-db?

Нет, сейчас попробую

ошибку пишет какую-нибудь?

dial tcp 172.18.0.2:3306: getsockopt: connection refused

так может база не стартовала?

Сам контейнер стартовал, базу не проверял

Ну так это не неможет разрезолвить ...

Сам контейнер стартовал, базу не проверял

у тебя ввыскакивает ошибка и сразу падает приложение?

Это значит я туда сходила, там на 3306 никто не слушает

Да, именно

причём сам ip существует

Да, именно

приложение поднмиается сразу,Э а база через пару секунд. щас код дам

тоесть контейнер поднят.

Да, именно

db, err := sql.Open("postgres", fmt.Sprintf("postgres://postgres:%s@%s/postgres?sslmode=disable", os.Getenv("POSTGRES_PASSWORD"), os.Getenv("POSTGRES_HOST"))) if err != nil { log.Fatal(err) } for i := 0; i < 10; i++ { err = db.Ping() if err == nil { break } log.Print(err) time.Sleep(2 * time.Second) } if err != nil { log.Fatal(err) }

типа такого

смысл понятен - пингует, пока база не поднимется

Эмм

А docker-compose при указании depends_on разве не гарантирует, что контейнер с базой поднимется до того как начнет подниматься контейнер с приложением?

смысл понятен - пингует, пока база не поднимется

а это точно лучший способ?

А docker-compose при указании depends_on разве не гарантирует, что контейнер с базой поднимется до того как начнет подниматься контейнер с приложением?

контейнер поднимется, а база в нем еще нет (в доке указано)

а это точно лучший способ?

хороший

контейнер поднимется, а база в нем еще нет (в доке указано)

я думаю лучше в коде не пытаться ничего исправить, пусть админы ставят задержки там сами, но не в коде ?

хороший

Просто ты откладываешь свой старт... докер сам не умеет зависить от живости сервиса?

я думаю лучше в коде не пытаться ничего исправить, пусть админы ставят задержки там сами, но не в коде ?

там - это где?

при старте аппки например

если они поднимают базу, потом аппку

не правильно ждать в аппке пока база поднимается

Просто ты откладываешь свой старт... докер сам не умеет зависить от живости сервиса?

старт не умеет. если контейнер стартовал, то он success. Но это не значит что база внутри уже готова принимать коннекты

Ну что-то юзкейс слишком частый, я почти на 100% уверен что в композе это по-другому решается

а это не забота аппки ?

Вот да

не правильно ждать в аппке пока база поднимается

не жди.

аппка стартанула не на готовой базе? падаем!

Ну что-то юзкейс слишком частый, я почти на 100% уверен что в композе это по-другому решается

да. в доку залезь и прочитай, как это решается

аппка стартанула не на готовой базе? падаем!

вот он и пришел - у него падает.

Ну что-то юзкейс слишком частый, я почти на 100% уверен что в композе это по-другому решается

https://docs.docker.com/compose/compose-file/#depends_on

depends_on will not wait for db and redis to be “ready” before starting web - only until they have been started. If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.

depends_on will not wait for db and redis to be “ready” before starting web - only until they have been started. If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.

https://docs.docker.com/compose/startup-order/

Если компоуз версии 2 то твое спасение это healthcheck

В ином случае добавляй маленький энтрипоинт который пингует 3 раза (условно) коннекшн и падает если не получилось

Ну у меня энтрипоинт это запуск самого приложения, буду проверять, если нет - падать

https://docs.docker.com/compose/startup-order/

Спасибо огромное, пошаманил с порядком запуска - все заработало.

https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on в частности depends_on: db: condition: service_healthy redis: condition: service_started в свою очередь service_healthy базируется на этом https://docs.docker.com/compose/compose-file/compose-file-v2/#healthcheck

db, err := sql.Open("postgres", fmt.Sprintf("postgres://postgres:%s@%s/postgres?sslmode=disable", os.Getenv("POSTGRES_PASSWORD"), os.Getenv("POSTGRES_HOST"))) if err != nil { log.Fatal(err) } for i := 0; i < 10; i++ { err = db.Ping() if err == nil { break } log.Print(err) time.Sleep(2 * time.Second) } if err != nil { log.Fatal(err) }

А если база отвалится?

https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on в частности depends_on: db: condition: service_healthy redis: condition: service_started в свою очередь service_healthy базируется на этом https://docs.docker.com/compose/compose-file/compose-file-v2/#healthcheck

У меня v3

А если база отвалится?

что значит отвалится? мой код выполняет\ся только при запуске

при работе твой апп должен упасть и докер его должен поднять

Упадет демон базы\контейнер

Упадет демон базы\контейнер

это в общем-то другой кейс

Т.е. апп тоже должен падать? У меня оно юзает в основном локальный кеш и поэтому продолжает жить даже без базы

ERROR: S client not available

это в общем-то другой кейс

Да, я понимаю

Его же тоже по идее надо обрабатывать, так?

Т.е. апп тоже должен падать? У меня оно юзает в основном локальный кеш и поэтому продолжает жить даже без базы

не, ну это твоя логика. у меня нет кэша

да, с третьим компоузом грустненько(

не, ну это твоя логика. у меня нет кэша

Ну т.е. ты в этом случае просто падаешь, да?

Ну т.е. ты в этом случае просто падаешь, да?

я нет. я обрабатываю ошибку и в лог

падаю только если при запуске аппа нету базы через дцать секунд

Посмотрел сервисы других чуваков у себя на работе, нашел такой код: func (a *Layer) GetDb() *sql.DB { if a.db != nil { a.db.Ping() return a.db } db, err := sql.Open("mysql", a.dbCredential.GetConnectionString()) if err != nil { panic(err) } a.db = db return db }

И в хттп-хендлерах дергается getDb() а потом через полученный объект делается запрос

Вроде выглядит как хорошая практика

Юзает кто-нибудь такое?

И, если нет предварительной загрузки чего-либо из базы - то и несколько попыток коннекта на старте сервиса можно не делать

Т.к. все по запросу

пинговать на каждый getDB - не очень как по мне, а учитывая что там паника дальше, то это то же самое что и у тебя

Всем привет! Можете подсказать, создаю структуру с fluent api, которая на каждый вызов возвращает саму себя. Внутри каждый шаг записывается в очередь, которая будет исопльзоваться в последнем вызове. То есть, вот структура: type FluentStruct struct { queue []func(string) string } У нее есть статический метод создания func NewFluentStruct() FluentStruct { return FluentStruct{} } Интерфейс должен быть: result := NewFluentStruct().Step1().Step2().GetResult() Проблема в реализации самих степов, хочется, чтобы они расширяли массив изначального экземпляра в виде: func (f *FluentStruct) Step1() FluentStruct { f.queue := append(f.queue, smth) return *f } Но в таком случае указанный выше интерфейс не работает и возвращает ошибку cannot call pointer method on packet.NewFluentStrtuct() так как этот вызов не создает ссылку, а в методе Step1 я хочу работать именно с ссылкой, чтобы изменять значение поля структуры. Выхода здесь 2: 1) Создавать ссылку отдельно, а затем прикручивать сами стэпы (Он не подходит, так как нужен именно inline синтаксис): fluentStruct := NewFluentStruct() result := fluentStruct.Step1().Step2().GetResult() 2) Переработать метод Step1, чтобы он не модифицировал предыдущий объект, а возвращал новый, то есть получается иммутабельная версия - вариант приемлимый, но я боюсь не будет ли он более затратный по памяти: func (f FluentStruct) Step1() FluentStruct { return FluentStruct{append(f.queue, smth)} } Заранее спасибо за помощь!

пинговать на каждый getDB - не очень как по мне, а учитывая что там паника дальше, то это то же самое что и у тебя

Не, эта штука дергается перед каждым запросом. А у меня если БД однажды поднялась - считается что с ней все ок и дальше просто выполняются запросы, если она упадет - просто будет обработана ошибка, после того как она поднимется снова реконнекта не произойдет. А в коде выше будет реконнект, поэтому выглядит лучше, чем у меня

Всем привет! Можете подсказать, создаю структуру с fluent api, которая на каждый вызов возвращает саму себя. Внутри каждый шаг записывается в очередь, которая будет исопльзоваться в последнем вызове. То есть, вот структура: type FluentStruct struct { queue []func(string) string } У нее есть статический метод создания func NewFluentStruct() FluentStruct { return FluentStruct{} } Интерфейс должен быть: result := NewFluentStruct().Step1().Step2().GetResult() Проблема в реализации самих степов, хочется, чтобы они расширяли массив изначального экземпляра в виде: func (f *FluentStruct) Step1() FluentStruct { f.queue := append(f.queue, smth) return *f } Но в таком случае указанный выше интерфейс не работает и возвращает ошибку cannot call pointer method on packet.NewFluentStrtuct() так как этот вызов не создает ссылку, а в методе Step1 я хочу работать именно с ссылкой, чтобы изменять значение поля структуры. Выхода здесь 2: 1) Создавать ссылку отдельно, а затем прикручивать сами стэпы (Он не подходит, так как нужен именно inline синтаксис): fluentStruct := NewFluentStruct() result := fluentStruct.Step1().Step2().GetResult() 2) Переработать метод Step1, чтобы он не модифицировал предыдущий объект, а возвращал новый, то есть получается иммутабельная версия - вариант приемлимый, но я боюсь не будет ли он более затратный по памяти: func (f FluentStruct) Step1() FluentStruct { return FluentStruct{append(f.queue, smth)} } Заранее спасибо за помощь!

func NewFluentStruct() *FluentStruct { return &FluentStruct{} }

Не, эта штука дергается перед каждым запросом. А у меня если БД однажды поднялась - считается что с ней все ок и дальше просто выполняются запросы, если она упадет - просто будет обработана ошибка, после того как она поднимется снова реконнекта не произойдет. А в коде выше будет реконнект, поэтому выглядит лучше, чем у меня

я и говорю - пинговать на каждый запрос. а если база легла, то паника.

func NewFluentStruct() *FluentStruct { return &FluentStruct{} }

Работает, спасибо! Чисто из любопытства, есть идеи насколько иммутабельная версия принесет оверхеда и как это можно проверить?

я и говорю - пинговать на каждый запрос. а если база легла, то паника.

Это по сути и делает приведенный мной код выше. Он используется примерно так: db := a.dbLayer.GetDb() stmtOut, err := db.Prepare("SELECT id, border FROM league") if err != nil { ...

Это по сути и делает приведенный мной код выше. Он используется примерно так: db := a.dbLayer.GetDb() stmtOut, err := db.Prepare("SELECT id, border FROM league") if err != nil { ...

так я этот код и описываю

А, ну т.е. я все правильно делаю

и мне не нравится идея пинговать на каждый запрос

я не утверждал этого

пинговать на каждый getDB - не очень как по мне, а учитывая что там паника дальше, то это то же самое что и у тебя

Тогда я тебя не понимаю)

Пинговать на каждый запрос - плохо, так?

Тогда как проверять, что БД не легла?

SELECT 42 (FROM DUAL)

с каких пор пинг гарантирует работоспособность базы? о_0

с каких пор пинг гарантирует работоспособность базы? о_0

а почему нет?

база упала, сервер нет