а так норм да

кто-нить сталкивался zero downtime deployments для бд? у меня бек node и фронт сборкой вебпака и с ними проблем нету, т.к. можно "на лету" обновить код. и есть один бек на джаве, которая прямо зависит от бд и бд постгрес

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

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

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

в качестве триггера для скрипта можно даже попробовать написать элементарный web-server который при посылке секретного токена запускал бы скрипт.

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

По хорошему, если у вас обратно совместимые миграции, то можно сначала делать миграции

А потом переключать

Если нет

То это все равно адовый головняк, как не крути

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

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

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

Есть еще упоротый третий вариант: Это поднимать blue-green деплой для постгреса и сливать данные

есть у кого docker-compose для php проекта со стоковыми образами?

невыходит php-fpm завезти постоянно primary script unknown показывает, все статьи такую конфигурацию nginx показывают, и не работает

https://github.com/hanovruslan/sf-demo-security/blob/master/docker/docker-compose.yml

а уже день сижу - прям стыжно поеэтому и прошу )

https://github.com/hanovruslan/sf-demo-security/blob/master/docker/docker-compose.yml

это не стоковый

проект заведен под демку на фрейме symfony

он билдит php-fpm нафига надо если fpm просто есть )

ай вижу прости

ок спс

) я уж грешным делом подумал, что надо совсем без Dockerfile-ов )

можно и так если честно ))

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

я привык )

если только из CMD кашу не делать

Powershell

Powershell

ненужен, есть баш)

ну да

если в винде то он глючит

особенно с некоторыми символами в названиях папок или уровня вложенности папок

вывод о нуджности винды тоже нппрашивается))

так и не подружился

ну да

все равно file not found что за уродство

все равно file not found что за уродство

Данные мапятся/подключаются в одну папку? У nginx и пыхи

вот и разрулил уже сам.. это было ужасно )

Кто нибудь сталкивался с тем что когда делаешь docker-compose up - в логах у одного из сервисов сжираются првые 8 байт? Выглядит это прмерно так: web_1 | -03-12T06:17:28.645742 #1] INFO — : Loading pingmonitor[production] ... web_1 | Migration complete

кто-нить сталкивался zero downtime deployments для бд? у меня бек node и фронт сборкой вебпака и с ними проблем нету, т.к. можно "на лету" обновить код. и есть один бек на джаве, которая прямо зависит от бд и бд постгрес

Могу поделиться как делать zero uptime 😄

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

тогда уж лучше взять CI систему, и научить ее делать так, как нужно вам.

Вот вам мой пропэр-вэй ту ду тхингс

https://github.com/holms/docker-compose-php

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

на втором контейнере будет nginx, раздающий файлы из папки, которая находится в первом контейнере

Положить nginx в первый контайнер и избежать костылей

Сделать дата сервис

И оба других через вольюмес фром прописать

data: image: tianon/true volumes: - .:/shared nginx: volumes_from: - data

И оба других через вольюмес фром прописать

хорошее решение.

Добрый день! Может ли кто-нибудь подсказать, как заставить containerd создавать при запуске pid-файл, который располагается в /run/docker/libcontainerd/docker-containerd.pid

Добрый день! Может ли кто-нибудь подсказать, как заставить containerd создавать при запуске pid-файл, который располагается в /run/docker/libcontainerd/docker-containerd.pid

Ответа не знаю, но интересно, для чего?

Ответа не знаю, но интересно, для чего?

Kubernetes требует этот pid-файл, при этом считает ошибкой.

Ответа не знаю, но интересно, для чего?

Облазил код взятый с гитхаба, но так и не понял убрали этот функционал из последней версии docker/containerd или нет.

всем добра когда стартует контейнер с постгрес из официального образа, то он смотрит в специальную папку со скриптами, эти скрипты (файлы .sql или скрипты .sh) можно добавить перед билдом образа и постгра их выполнит сразу после init_db, причем выполнять их будет в алфавитном порядке по именам. Вопрос такой: если существующая схема БД большая, содержит кучу таблиц/функций и триггеров, то имеет ли смысл разбивать все это добро по отдельным файлам скриптов (например, функции отдельно, индесы отдельно и тд) или лучше держать одну портянку?

разбивать всегда имеет смысл, безотносительно докера

если этого хозяйства много, не будет ли проблем с тем, что где-то что-то забыл/недописал при различных дальнейших апдейтах схемы?

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

со своими коллегами

зачем разбивать если это 1) было сдамплено 2) никто не будет это читать 3) только загрузка будет в новую базу

просто докерфайл кинуть надо коллегам

?

зачем разбивать если это 1) было сдамплено 2) никто не будет это читать 3) только загрузка будет в новую базу

Идея в том, чтобы контейнер всегда стартовал с актуальной схемой БД. Коммитим скрипт в мастер-ветку -> CI-сервак пересобирает образ -> Compose стягивает новый образ и перезапускает контейнер. Таким образом, для добавления каких-нибудь элементов схемы не нужно подключаться клиентом напрямую к базе. У себя на компе развернул/дополнил/проверил и пушнул в прод. Это вроде как соответствует идеологии докера Естественно все последующие изменения на уже работающей базе будут через ALTER и т.д. И сами данные, которые есть в базе будут в порядке. Такой вот Continuous Migration получается Или я перемудрил?

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

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

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

Посмотрите в сторону миграций БДшных

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

эт типа либу юзать?

orm?

Наша практика показала что лучше ничего не пилить, а просто делать грамотные миграции

Единственно важный момент миграции должны быть атомарны

Не все вещи можно засунуть в транзакции

orm?

Да

я ждал эту шутку)

,kz

уже было))

пошучено

#синийкит #хочувигру