Using a launcher built docker image in docker-compose

Разработка
21

Привет, Майк. По сути, ты запускаешь ./launcher bootstrap, чтобы собрать образ, загружаешь его в репозиторий, а затем используешь ./launcher start-cmd, чтобы узнать, какие переменные окружения нужно передать Docker для запуска всего процесса.

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

22

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

23

Спасибо, Джей — я это уже понял. В конце концов мне удалось заставить это работать.

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

Кажется, часть проблемы в том, что это противоречит общепринятому подходу ко всем остальным Docker-образам. Это не совсем «подключи и работай». Здесь больше «покрути, подключи, а потом работай».

Как я уже сказал, лаунчер — прекрасная и надёжная вещь для своих задач.

Очень хорошая новость: сборка только для веба работает отлично, она очень быстрая на моём свёрке, и её можно обновлять, потому что у меня есть сервер сборки.

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

Вот что я пробовал, но это оставило много желать лучшего…

  • Docker-образ от Bitnami — работал как собака без лап.
  • Dockerfile от IndieHosts — даже не дошёл до этапа сборки; казалось, он упорно пытается собрать всё подряд, я думаю, он компилировал сам Linux. Опять же, должно быть более простое решение!

Ладно — спасибо.

Майк.

24

У нас есть «недостаток первого хода» :sunglasses:

Скрипт запуска был создан до появления docker-compose, docker-swarm, kubernetes и всего подобного, и… он всё ещё работает. У нас действительно нет веских причин переходить на что-то другое. «Преимущества» этих систем не являются таковыми для самого крупного пользователя самостоятельного размещения Discourse — это бюджетные установки на облачных VPS.

25

О! Я всегда об этом задумывался. И, насколько я помню, установка docker-compose на Ubuntu требовала дополнительных шагов. Словно они не хотят, чтобы люди его использовали, если только эти люди не используют Windows (или Mac?)

26

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

Что ж, к сожалению, не у всех из нас есть обширный опыт работы с DevOps.

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

27

Это сработает? А что насчет миграций базы данных?

28

В этом сценарии bootstrap выполнит миграции при создании нового образа контейнера.

29

Привет, @lucasbasquerotto

Да, вы можете загрузить образы Docker для Discourse в репозиторий и архивировать остальную часть /var/discourse, как обсуждалось ниже, но это неэффективный способ и он официально не поддерживается. Недавно я полностью протестировал это:

30

Однако в данном случае шаг bootstrap должен выполняться на продакшн-сервере. Это, по сути, сводит на нет цель выгрузки базового образа в реестр контейнеров, если я не ошибаюсь (поскольку это делается с целью избежать bootstrap-процесса на продакшене, за исключением, возможно, выполнения шага миграции базы данных или чего-то подобного).

Вот что я делаю на других хостингах, не связанных с Discourse: обычно я использую Flyway для выполнения миграций в базе данных, а также для других задач, таких как очистка кэша Redis, но без запуска других ресурсоемких процессов, особенно тех, которые зависят от внешних сервисов, например, обновления сертификатов https (это я бы делал через cron-задачу, кроме первого запуска, что вполне допустимо) или изменения кодовой базы (она должна быть статичной в образе, как пакеты, библиотеки и прочее). Похоже, что Discourse использует rake, что нормально, но он также выполняет другие задачи, такие как установка gems, генерация ассетов, обновление базы данных MaxMind и, возможно, другие сервисы (что может сломать шаг пересборки, если, например, сервис недоступен или если они изменят API, что случается редко, но возможно).

Я не утверждаю, что Discourse должен действовать именно так, конечно. Но создание образа в среде CI и выполнение только шага миграции базы данных на тестовых/продакшн-серверах с определением переменных окружения — это то, чего я ожидаю, и это легко реализуемо с помощью другого ПО, такого как WordPress, MediaWiki, Rocket.Chat и т. д. Discourse, на мой взгляд, лучшее программное обеспечение для форумов, и у них могут быть веские причины для такого подхода, но пока я бы использовал только стандартную установку (или установку с несколькими контейнерами), чтобы избежать проблем, и просто надеялся бы, что при пересборке ничего не пойдет не так.

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

31

Привет, Майк,

Ты в итоге задокументировал свой процесс? Было бы здорово посмотреть и видео.

С уважением,