Комментарии 17
Я бы сказал что это не очень хорошее решение.
Есть три более правильных подхода
1) Minikube со всеми вытекающими
2) Поставить на хостовую машину nginx и использовать его как proxy, сертификаты для SSL можно хранить в нём же. Достаточно поднять пул контейнеров для каждого приложения на разных портах и проксировать запросы на них. (Чтобы доступа извне не было достаточно написать 127.0.0.1:%port%:80)
3) Если и использовать nginx в контейнере, тогда использовать docker external network и разделить приложения по подсетям докера (очень геморойный путь, проще использовать пункт 2)
Есть три более правильных подхода
1) Minikube со всеми вытекающими
2) Поставить на хостовую машину nginx и использовать его как proxy, сертификаты для SSL можно хранить в нём же. Достаточно поднять пул контейнеров для каждого приложения на разных портах и проксировать запросы на них. (Чтобы доступа извне не было достаточно написать 127.0.0.1:%port%:80)
3) Если и использовать nginx в контейнере, тогда использовать docker external network и разделить приложения по подсетям докера (очень геморойный путь, проще использовать пункт 2)
0
Там была поправочка один из ста способов:)
Kubernetes — это следующий шаг, немного не пойму зачем использовать разные порты и nginx ставить непосредственно на хосте? Ну а по сетям разделять — это уже тоже дополнительный шаг изоляции.
Kubernetes — это следующий шаг, немного не пойму зачем использовать разные порты и nginx ставить непосредственно на хосте? Ну а по сетям разделять — это уже тоже дополнительный шаг изоляции.
0
Потому что nginx работает как reverse proxy, и отправлять его на ip адреса внутренней сети докера грешно. Во-первых могут быть разные подсетки. Во вторых после ребута или ребилда докер контейнер может сменить IP адрес docker сети и вы получите нерабочий хост. Придётся лезть в nginx править конфиг.
Поэтому и линкуют контейнеры через имена, потому что IP может быть любым и в теории может сменится, так как там свой аналог dhcp
Поэтому и линкуют контейнеры через имена, потому что IP может быть любым и в теории может сменится, так как там свой аналог dhcp
0
По поводу прокси-пас в конфигах я искал более-менее полное и «без танце с бубном» решение такое чтобы поддердивало например и сокеты, и переписывало правильные ip-адреса. Пока что склоняюсь к такому решению:
proxy_pass http://уууу:хххх;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-NginX-Proxy true;
0
Use docker-compose Luke
0
Ждём CRM для управления логикой.
0
Приятно. В воскресенье вечером)
0
Прошу прощения. Еще пару дней и залью на git
0
Почти готово. Сегодня-завтра (До вечера среды) и выкладываю.
0
Ничего не вышло с crm, простите, на деле система все больше и больше хочет разрастись и превратиться в в gui для управления докер, которых сейчас уже есть. Простите.
0
С бекэндами nginx там все понятно, вы лучше напишите про распределенную базу данных.
Нужно обеспечить 99,99% доступность системы. При выходе из строя одного сервера Nginx переключит на другой бекэнд, а база?
Хотелось бы, что бы каждый из бекэндов был полностью независимый, чтобы при возвращении онлайн он собирал с других серверов изменения в свою базу и продолжал работать, распределяя нагрузку в системе. Как это хоть примерно реализовать?
Нужно обеспечить 99,99% доступность системы. При выходе из строя одного сервера Nginx переключит на другой бекэнд, а база?
Хотелось бы, что бы каждый из бекэндов был полностью независимый, чтобы при возвращении онлайн он собирал с других серверов изменения в свою базу и продолжал работать, распределяя нагрузку в системе. Как это хоть примерно реализовать?
0
Ну в статье я заложил зернышко highload, зернышко — контейнеры которые мы сначала можем вынести на отдельный сервер а потом и масштабировать.
Если я вас правильно понял, Вы говорите про распределенные системы
Если я вас правильно понял, Вы говорите про распределенные системы
0
severalnines.com/blog/how-deploy-postgresql-high-availability
Базы можно расположить в docker, но есть нюанс, если грохнуть все контейнеры, или грохнуть до окончания синхронизации, то все данные упадут вместе с контейнером.
Так что как вариант — проброс данных в хостовую систему. Для кворума лучше использовать 3 сервера с базами. Чтобы если грохнулась одна, оставалось ещё две и если грохнется ещё одна база до восстановления первой, приложение жило.
Базы можно расположить в docker, но есть нюанс, если грохнуть все контейнеры, или грохнуть до окончания синхронизации, то все данные упадут вместе с контейнером.
Так что как вариант — проброс данных в хостовую систему. Для кворума лучше использовать 3 сервера с базами. Чтобы если грохнулась одна, оставалось ещё две и если грохнется ещё одна база до восстановления первой, приложение жило.
0
Мы до того, как на kubernetes пересели, использовали traefik. Ещё на нескольких докер серверах крутиться. Он может всё, что вы написали, только автоматически и ещё Let's encrypt сертификаты.
Выглядит это как-то так.
docker-compose.yaml для traefik
config.toml
И часть docker-compose.yaml из контейнера, где это используется:
Это вариант конфигурации, при которой создаются сертификаты от Let's encrypt.
Делается всё просто. Стартуете контейнер с traefik, а в остальных добавляете сеть и лайблы и всё.
Выглядит это как-то так.
docker-compose.yaml для traefik
Заголовок спойлера
networks:
traefik:
external: true
services:
traefik:
image: traefik:alpine
networks:
traefik: null
ports:
- 80:80/tcp
- 443:443/tcp
restart: unless-stopped
volumes:
- ./config/traefik.toml:/traefik.toml:rw
- /a/data/traefik/acme.json:/acme.json:rw
- /var/run/docker.sock:/var/run/docker.sock:rw
version: '3.0'
config.toml
Заголовок спойлера
debug = false
checkNewVersion = false
logLevel = "ERROR"
defaultEntryPoints = ["https","http"]
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
[retry]
[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "docker.localhost"
watch = true
exposedbydefault = false
[acme]
email = "administrator@example.com"
storage = "acme.json"
entryPoint = "https"
OnHostRule = true
[acme.httpChallenge]
entryPoint = "http"
И часть docker-compose.yaml из контейнера, где это используется:
Заголовок спойлера
networks:
traefik:
external: true
services:
postfix:
image: marooou/postfix-roundcube
environment:
ADMIN_USERNAME: root
ADMIN_PASSWD: pass
DOMAIN_NAME: example.com
labels:
traefik.backend: example-demo-mailhog
traefik.docker.network: traefik
traefik.enable: "true"
traefik.frontend.rule: Host:example.com;PathPrefixStrip:/postfix/
traefik.port: '80'
ports:
- 10110:110/tcp #POP3 not SSL
- 10143:143/tcp #IMAP not SSL
- 10025:25/tcp #SMTP not SSL
- 10465:465/tcp #SMTPS
- 10993:993/tcp #IMAPS
- 10995:995/tcp #POP3S
networks:
default: null
traefik: null
volumes:
- /a/data/example.com/mail/mysql:/var/lib/mysql
- /a/data/example.com/mail/vmail:/var/vmail
- /a/data/example.com/mail/log:/var/log
restart: unless-stopped
version: '3.0'
Это вариант конфигурации, при которой создаются сертификаты от Let's encrypt.
Делается всё просто. Стартуете контейнер с traefik, а в остальных добавляете сеть и лайблы и всё.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Один из сотни способов публикации нескольких production проектов на одном сервере