postgres первые шаги

pg_hba.conf в студию

Если тебе чисто потыкать, то забей.

docker run --name=postgres \
  --env=POSTGRES_USER=default \
  --env=POSTGRES_PASSWORD=default \
  --env=POSTGRES_DB=default \
  --detach=true \
  --publish=5433:5432 \
  --restart=unless-stopped \
  postgres:11-alpine

psql -h 127.1 -p 5433 -U default -d default

Мне конечно потыкать, но сделать по уму. В перспективе возможно нужно будет в работе использовать.

В том числе по-быстрому локально развернуть СУБД на 10-15 тачках для обучения студентов.

Поэтому хочется разобраться.

В том числе по-быстрому локально развернуть СУБД на 10-15 тачках для обучения студентов

Тем более докер в помощь.

Помогите с правами постгреса
docker run

Поколение докера ^^

Ну да, дефолт. Должен бы пускать. Какая-то мелочь, наверное. На всякий случай, попробуй пароль попроще(ибо «If the presented password string is already in MD5-encrypted or SCRAM-encrypted format, then it is stored as-is», мало ли) и проверь \echo :AUTOCOMMIT(что оно окажется не 'on' - ещё менее вероятно)

sudo -u postgres psql Так не делай. Делай так: psql -U postgres

Создал юзера create user with password ‘’ Так не делай. Делай так: create user with encrypted password ‘’

sudo -u postgres psql Так не делай.

Так не делай. Делай так: psql -U postgres

Создал юзера create user with password …

Так не делай. Делай так: create user with encrypted password …

Хахахахаха :-) Может быть, Kubernetes ещё развернуть посоветуешь человеку?

Поколение докера ^^

Еще есть поколение пубертатуса. С пубертатным периодом.

postgres=# \echo :AUTOCOMMIT
on

Дичь какая-то

Интересные фишки postgres подкидывает (не ожидал, что все объекты БД по дефолту будет неявно приводится к lowercase, но при этом во время коннекта будет регистрозависимая авторизация).

Скинул пароль до 1 символа, имя пользователя перевел в lowercase и тоже 1 символ. Перестало ругаться на неверный пароль, но стал говорить что БД указанная не существует. Посмотрел список созданных БД, а ее имя сохранено в lowercase, хотя создавал в lowerCamelCase. Написал строку подключения в lowercase - подцепился.

Чувствую мне «понравится»=))))

Всем спасибо)

Вычитал на просторах интернета, что encrypted нынче вроде не актуален. Но спасибо, почитаю зачем он нужен.

psql -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"

Чувствую надо править pg_hba.conf.

Пока не разобрался, что за поддержка 2х стилей команд с переключением в настройках и почему все с ними бьются то туда, то сюда. Все говорят делай так, но не объясняют почему, если не помогает по первому варианту, пробуй по второму и наоборот)))

В данном случае он прав. Докер как раз предназначен для «потестить и выкинуть», это его единственная полезная функция — зачем ее отрицать?

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

Незачем вам было писать эту чушь про Docker, которая к тому же не имеет отношениямк теме

Кроме кидания говном аргументация будет? Докер действительно позволяет быстро и просто поставить софт в контейнере с гарантированными свойствами. А поскольку докер сам по себе выкидывает все результаты работы постгреса, каждый раз начиная с чистого листа, то, очевидно, кроме как для «поиграться и выкинуть» он не подходит.

Для БД нужно использовать snake_case.

https://www.postgresql.org/docs/12/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

Мне 30, какое,блин, поколение докера?

К чему ты это? Если нужно что-то быстро запустить, то докер самое быстрое средство это сделать.

Чувствую мне «понравится»=))))

Просто потыкать немного, привыкнуть и всё будет норм )

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

Справедливости ради я должен заметить, что у меня никогда не возникало проблемы с быстрым запуском постгреса при помощи штатного пакетного менеджера - это так же несколько команд в консоли, как и в докере. Другое дело - когда нужно поставить что-то требующее специфические версии либ. И уж вообще другое дело - оракл, который у меня в последний раз не получилось запустить даже после нескольких часов ковыряния.

Когда ты хочешь три разных постгреса на одной девелоперской машине, не каждый пакетный менеджер даст тебе лучший user experience чем докер.

Если все версии разные - таки даст

Зачем докер когда есть nix

Чтобы кэмэл кейс использовать, глянь 1С патченый постгрес.

Можно запускать множество одноразовых инстансов и тут же их грохать по ненадобности, можно вообще не заморачиваться настройкой. Для разработки самое то. А если тесты гонять, то вообще желательно свежую бд поднять и фикстурами набить, тут твой никс уже капитально сосёт.

Для тестов есть даже временные таблицы в постгресе. Докер - инструмент для решения определенных задач. Просто я не вижу в своей жизни подобных задач. В большинстве случаев мне хватает sudo make install. Ну а если начинаю беспокоится за стабильность системы - есть никс.

Всмысле блин временные таблицы?

Есть у тебя сервис, ты запушил, CI идёт на хост, поднимает бд, накатывает миграции, набивает фикстуры, запускает тесты, тесты проходят, бд исчезает, и даже никакие ублюдочные моки не были нужны, красота. То же самое ты можешь сделать на любой x86 железке с линуксом, докером и гитом по условному make test. А в идеале ещё и на своих часах, чайнике и умном пылесосе. Вместо этого ты «временные таблицы» предлагаешь?

Можно запускать множество одноразовых инстансов и тут же их грохать по ненадобности, можно вообще не заморачиваться настройкой

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

rm -rf /var/db/randomdirname
/usr/local/bin/pg_ctl initdb /var/db/randomdirname
/usr/local/bin/pg_ctl start -o "-p 12345"

Показательно, что все докероушибленные, которых я до сих пор встречал, преимущество докера мотивировали собственным невежеством - то есть, пытались утверждать о преимуществах докера в форме «докер позволяет удобно решать задачу X», при этом не зная, что задача X может быть решена другими средствами не менее просто и удобно.

Это угрожающая тенденция, потому что через какие-то 5-10 лет у нас 19 из 20 профессиональных энтерпрайз биг дата админов не будут уметь работать с никсами при том, что у большинства из них сервера таки на никсах.

Ты очень туп, если не видишь разницы. Во-первых, тебе по-прежнему нужно как-то запустить тесты, во вторых в окружении может быть множество сервисов, которые так просто не разворачиваются. И докер здесь — универсальное средство решения всех этих проблем, причём ещё и без привязки к конкретной тачке.

Ну и, да, если опустить твоё невежество и вернуться к моему. Почему ты вменяешь мне мне обязательство знать всё про постгрес? Это работа админа, которым я не являюсь, и уж тем более dba.

Вместо того, чтобы заниматься хернёй, я просто напишу конфиг для docker-compose и настрою таск в тимсити. Работы на полчаса в худшем случае.

во вторых в окружении может быть множество сервисов, которые так просто не разворачиваются

Да, это классическое оправдание докерушибленных «но у нас же много сервисов - как мы будем без докера ими управлять?». Ответ очень простой: нужно не дробить без необходимости систему, потому что разделенную систему ВСЕГДА сложнее разрабатывать, чем цельную. И тогда внезапно выясняется, что нет никакого множества сервисов, что систему очень просто администрировать и все задачи администрирования влазят в простенький скрипт на баше/питоне, вроде «остановить, скопировать новые версии, инициализировать, запустить».

тебе по-прежнему нужно как-то запустить тесты

Запускай.

докер здесь — универсальное средство решения всех этих проблем, причём ещё и без привязки к конкретной тачке

Докеру нужны конкретные ABI линукса. Подчеркиваю, что даже не API, которое более стабильно. Точно так же можно запускать собранные standalone-версии приложений на каком-нибудь питоне, архив в чруте, или виртуалку. Ты не запустишь контейнер на лине, который имеет сильно отличающуюся версию ядра, ты не запустишь докер в бсдяхе, тебе нужна будет виртуалка на маке, и кривость WSL в итоге требует той же виртуалки в винде. В итоге ты можешь запустить докер-контейнер на любой системе, если эта система - x86 линукс определеного диапазона версий. По этой причине докер на самом деле довольно сильно привязан к «конкретной тачке». И зачем было выделываться, если все равно пришли к единственному линуксу и виртуалкам с ним? Чтобы просто устранить различия инструментов администрирования убунты и федоры? Чтобы на новой машине быстрее заново инициализировать окружение? А если у меня меньше 10 машин в работе и я не меняю их раз в полгода?

Ладно, ты сам, наверное, не знаешь - так и быть, подскажу: докер нужен для того, чтобы запускать написанный рукожопами софт в окружении с безупречным соблюдением версий всех библиотек, поскольку рукожоп методом тыка добился работы своего куска дерьма на единственном наборе версий библиотек, и теперь админы вынуждены ставить на каждую машину именно те версии, которые он использовал при разработке. В частности, это очень актуально по отношению к версии интерпретатора питона, поскольку бездарные питонисты, которых большинство, умудряются делать зависимость, например, от 3.6.2+, причем, на 3.6.0 и на 3.7.0 их софт уже не работает. Именно такой подход не совместим с классической организацией никсов, который заключался в сборке софт из сорцов, спецфичных для разных версий системы, где у последней могут быть разные версии ядра и более высокоуровневых интерфейсов программирования, вплоть до упомянутого мной интерпретатора.

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

Что значит «всё?». Ты ведешь разработку для постгреса, но не можешь его запустить? Вот тебе метла - мети двор. Толчки еще нужно почистить. В понедельник новую мебель принесут для третьего этажа - поможешь поднять.

я просто напишу конфиг для docker-compose и настрою таск в тимсити. Работы на полчаса в худшем случае

Ага, то есть, пару команд для постгреса тебе знать не нужно, а конфиги для докера и тимсити - нужно. Интересная позиция.

а что мускуля не хватит?

нужно не дробить без необходимости систему

В мелкой конторе однозначно. А в крупной возможны варианты. Так что применение у докера наверно есть. Просто оно далеко лично от меня, а пихать докер везде, где и без него норм не хочется. Вместо него я пихаю никс туда где и без него хорошо, просто потому что более менее разобрался как там конфигурить и создавать пакеты в то время как не горю желанием разбираться в доисторических dpkg и прочих ебилдах.

В мелкой конторе однозначно. А в крупной возможны варианты

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

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

Никс является хорошей альтернативой там, где нужно заморачиваться с многочисленными версиями софта. Традиционная никсовая организация (FHS) в виде мусорок /etc, /bin, /lib, /include, /share устарела уже в девяностых, потому что кол-во софтин давно перевалило за два десятка.

В шинде уже в конце девяностых MS реализовало систему https://en.wikipedia.org/wiki/Side-by-side_assembly , благодаря которой родившиеся в девяностых люди так и не узнали, что такое dll-hell. Надо сказать, что я тоже не узнал о нем, но скорее потому, что первый компьютер у меня появился довольно поздно. А в мейнстримовых никсах и вовсе нет никаких способов решения проблем конфликтующего софта. Именно это создало почву для докера, который тоже не решает проблему, а лишь подпирает ее костылем, позволяя держать параллельно разные версии виртуальной системы. Почему я настаиваю именно на том, что проблема докером не решена - потому что докер обрезает функциональность софта (сеть, логи, да и в целом ФС и прочие устройства), давая в результате кастрированную систему, в которой нужно делать много дополнительных действий просто для того, чтобы сделать ее похожей на полноценную.

в то время как не горю желанием разбираться в доисторических dpkg и прочих ебилдах

Ими очень просто пользоваться, если ты не создаешь в них пакеты и не ставишь софт извращенных комбинаций версий.

Ну смысл именно в том чтоб создавать, впрочем восновном обновлять, патчить и собирать с кастомными конфигфлагами. На счет зоопарка версий зависимостей одного пакета предлагаю обновлять все зависимости на самый топ. Впрочем редко когда получается, особенно если речь идет о хаскеле например. Да и сишные либы часто так ломают апи, что за голову хватайся. А если речь идёт о независимых пакетах, то тут как раз спасает никс.

нужно не дробить без необходимости систему

Я имел ввиду сторонние вещи, например реббит или memcached. Но вообще лол, когда вырастешь из лягушатника и начнёшь писать что-то серьёзное, приходи, расскажешь как прекрасно масштабируется твой монолит.

Остальную часть твоего высера читать лень.

Запускаю в докере, всё в порядке.

Вот тебе метла

Оставь свой инструмент себе.

а конфиги для докера и тимсити - нужно

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

Ну смысл именно в том чтоб создавать, впрочем восновном обновлять, патчить и собирать с кастомными конфигфлагами. На счет зоопарка версий зависимостей одного пакета предлагаю обновлять все зависимости на самый топ

Обновлять все софтины, использующие эту библиотеку, что ли? Да, это единственный надежный вариант. Хотя, иногда хочется сказать «жри что дают», но здесь хотелось бы какой-то вариант «пересборки» пакетов без пересборки, то есть создание новой версии старых пакетов, при этом новые версии пакетов просто зависят от новой версии либы.

Я имел ввиду сторонние вещи, например реббит или memcached

Есть проблема в запуске кролика/memcached? Ты опять придумал проблему, которой нет. Есть проблема криворуких разрабов, которым нужно строго конкретная версия сервера/клиентских либ на целевой машине, причем, таких разрабов несколько и каждому из них нужна свое сочетание версий софта.

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

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

Остальную часть твоего высера читать лень

То есть, ты даже не намерен там претендовать на свою правоту. Спасибо, похвалил.

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

/bin/bash

Поменяй peer и md5 на trust везде, еще 127.0.0.1/32 на 0.0.0.0/0

Ты с той же машины коннектишься, где у тебя постгрес поднят?

Похоже проблема в методе peer – он требует, чтобы user в бд был такой же как и текущий user операционки.

Ты душевнобольной или что?

Один единственный конфиг написать или привязываться для тестов к конкретным тачкам и ставить туда софт? У нормаьного человека такой дилеммы даже не встанет, очевидный выбор в пользу докера.

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

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

Поставить софт на машину и забыть, багфиксы автоматически по крону встанут - никай докер по удобству рядом не валялся. Если тебе нужно тестить на одной машине, то и тестируй на одно машине. Если тебе нужно тестировать в разных окружениях, то ты будешь писать конфиги и собирать каждое окружение, с докером или без.

компов будет много и можно раскидать их по разным компам

Так тут ведь и мякотка. Минимальное требование для железки — наличие containerd. Т.е. вообще почти без подготовки хоста бери да запускай сервисы.

Если тебе нужно тестить на одной машине, то и тестируй на одно машине. Если тебе нужно тестировать в разных окружениях, то ты будешь писать конфиги и собирать каждое окружение, с докером или без

Ты либо бредишь, либо разработки и не нюхал ещё. Есть уменя, допустим, пара стоек в конторе, чтобы внутренние сервисы и тесты гонять. Ты предлагаешь каждый сервер настраивать под конкретные задачи, лол?

У нормальных людей есть набор хостов, куда ходит CI и запускает всё, что ему вздумается. Сборки, тесты, что угодно, и ничто из этого настраивать не нужно, докер, да агент для CI, если требуется.