Size: a a a

DevOps — русскоговорящее сообщество

2021 February 17

ДС

Дмитрий Стародубцев... in DevOps — русскоговорящее сообщество
источник

L

Leliya in DevOps — русскоговорящее сообщество
Скажите пожалуйста, а как сделать вот такое : есть сайт. Работает на хосте. И нужно сделать 2 копии, одна для тестов, вторая с дополнительными  новыми сервисами. Сделать эти копии нужно на 2 разных доменах. В контейнерах докера развернуть. Нужно чтобы эти 2 сайта использовали одну и ьу же бд ,редис и другие сервисы

Я создала 2 рабочие папки для двух разных копий. Положила в одну проект+файлы докера одной копии( изменила внешние порты отличные от оригинала) и имена контейнеров тоже отличные от оригинала. Во вторую рабочую папку положила аналогично. Все контейнеры копий имеют свои внешние порты и имена. Чтобы не конфликтовали с контейнерами оригинального сайта.

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

Но когда я настраиваю и запускю компос, каждого копии  проекта, все контейнеры UP, но проверив curl -i copy1_domain.domain.com, то и первый и второй говорят timed out.
НА хосте с докером настроен прокси...
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Leliya
Скажите пожалуйста, а как сделать вот такое : есть сайт. Работает на хосте. И нужно сделать 2 копии, одна для тестов, вторая с дополнительными  новыми сервисами. Сделать эти копии нужно на 2 разных доменах. В контейнерах докера развернуть. Нужно чтобы эти 2 сайта использовали одну и ьу же бд ,редис и другие сервисы

Я создала 2 рабочие папки для двух разных копий. Положила в одну проект+файлы докера одной копии( изменила внешние порты отличные от оригинала) и имена контейнеров тоже отличные от оригинала. Во вторую рабочую папку положила аналогично. Все контейнеры копий имеют свои внешние порты и имена. Чтобы не конфликтовали с контейнерами оригинального сайта.

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

Но когда я настраиваю и запускю компос, каждого копии  проекта, все контейнеры UP, но проверив curl -i copy1_domain.domain.com, то и первый и второй говорят timed out.
НА хосте с докером настроен прокси...
Собирай оба образа из разных веток,  запускай в одном композе,  разрули доступ через nginx. Если нужно будет код на живую править замонтируй исходники внутрь контейнера по верх исходников что в образе.
источник

L

Leliya in DevOps — русскоговорящее сообщество
ну у меня 2 разных компоса, потому что 2 копии отличаются некоторыми сервисами
источник

L

Leliya in DevOps — русскоговорящее сообщество
я же не могу 2 контейнера nginx для 2 копий сайтов в одном компосе собирать...
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Leliya
ну у меня 2 разных компоса, потому что 2 копии отличаются некоторыми сервисами
Для этого не нужно городить несколько кампозов. 1 nginx справится хоть с 10 одинаковыми контейнерами на базе одного кода с небольшими изменениями, на то докер и удобен.
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Кампоуз у Вас будет содержать

nginx
appv1
appv2
appvN
redis
some_service1
some_service2
источник

AM

Alex Movergan in DevOps — русскоговорящее сообщество
Привет, вопрос архитектурного плана. Есть гибридная инфраструктура, часть в гугле часть в датацентре. Стоит вопрос управления секретами, хотим поставить хэшикорп волт. Вопрос, делать его отдельно одним большим инстансом или развернуть по инстансу в каждой локации, т.е. в гугле один и в датацентре один.

Какие есть плюсы и минусы централизованного и распределённого подхода. Интересует реальный практический опыт.
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Alex Movergan
Привет, вопрос архитектурного плана. Есть гибридная инфраструктура, часть в гугле часть в датацентре. Стоит вопрос управления секретами, хотим поставить хэшикорп волт. Вопрос, делать его отдельно одним большим инстансом или развернуть по инстансу в каждой локации, т.е. в гугле один и в датацентре один.

Какие есть плюсы и минусы централизованного и распределённого подхода. Интересует реальный практический опыт.
Если секреты для каждой точки одни и те же то имеет смысл кластер из консулов поднять и волт секреты хранить в консуле.
источник

C

Crysalis in DevOps — русскоговорящее сообщество
ну как минимум какой-то впн между двумя этими инфраструктурными штуками нужен
ну и HA надо тоже настроить)
а так, да, лучше консул в качестве бэкенда и вот это всё
источник

L

Leliya in DevOps — русскоговорящее сообщество
т.е. мне нужно в одной папке сделать 1 компос и 2 папки с двумя рабочими файлами для 2х копий проекта и просто указать в компосе 2 контейнера  nginx  для разных доменов/проектов  и для них указать разные   volumes  для монтирования конфигов?
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Leliya
т.е. мне нужно в одной папке сделать 1 компос и 2 папки с двумя рабочими файлами для 2х копий проекта и просто указать в компосе 2 контейнера  nginx  для разных доменов/проектов  и для них указать разные   volumes  для монтирования конфигов?
Да верно. Но если не планируется код править для отладки то лучше упаковать его в образы разных версий.
источник

L

Leliya in DevOps — русскоговорящее сообщество
не, планируется
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Образ должен быть иммутабельным.
источник

L

Leliya in DevOps — русскоговорящее сообщество
каким?)
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Создайте в репозитории две ветки
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
и состряпайте на базе отдельных веток разные образы.
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Ненадо городить огород по старинке с копипастой одного и того же кода в 2 дирректории.
источник

L

Leliya in DevOps — русскоговорящее сообщество
я хотела сначала сделать правильно а потом закинуть каждый в свою ветку
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
так делайте сразу разработку в feature branch и образ стройте на базе этого branch
источник