Comments 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)
Там была поправочка один из ста способов:)
Kubernetes — это следующий шаг, немного не пойму зачем использовать разные порты и nginx ставить непосредственно на хосте? Ну а по сетям разделять — это уже тоже дополнительный шаг изоляции.
Kubernetes — это следующий шаг, немного не пойму зачем использовать разные порты и nginx ставить непосредственно на хосте? Ну а по сетям разделять — это уже тоже дополнительный шаг изоляции.
Потому что nginx работает как reverse proxy, и отправлять его на ip адреса внутренней сети докера грешно. Во-первых могут быть разные подсетки. Во вторых после ребута или ребилда докер контейнер может сменить IP адрес docker сети и вы получите нерабочий хост. Придётся лезть в nginx править конфиг.
Поэтому и линкуют контейнеры через имена, потому что IP может быть любым и в теории может сменится, так как там свой аналог dhcp
Поэтому и линкуют контейнеры через имена, потому что IP может быть любым и в теории может сменится, так как там свой аналог dhcp
По поводу прокси-пас в конфигах я искал более-менее полное и «без танце с бубном» решение такое чтобы поддердивало например и сокеты, и переписывало правильные 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;
Use docker-compose Luke
Ждём CRM для управления логикой.
Приятно. В воскресенье вечером)
Прошу прощения. Еще пару дней и залью на git
Почти готово. Сегодня-завтра (До вечера среды) и выкладываю.
Ничего не вышло с crm, простите, на деле система все больше и больше хочет разрастись и превратиться в в gui для управления докер, которых сейчас уже есть. Простите.
С бекэндами nginx там все понятно, вы лучше напишите про распределенную базу данных.
Нужно обеспечить 99,99% доступность системы. При выходе из строя одного сервера Nginx переключит на другой бекэнд, а база?
Хотелось бы, что бы каждый из бекэндов был полностью независимый, чтобы при возвращении онлайн он собирал с других серверов изменения в свою базу и продолжал работать, распределяя нагрузку в системе. Как это хоть примерно реализовать?
Нужно обеспечить 99,99% доступность системы. При выходе из строя одного сервера Nginx переключит на другой бекэнд, а база?
Хотелось бы, что бы каждый из бекэндов был полностью независимый, чтобы при возвращении онлайн он собирал с других серверов изменения в свою базу и продолжал работать, распределяя нагрузку в системе. Как это хоть примерно реализовать?
Ну в статье я заложил зернышко highload, зернышко — контейнеры которые мы сначала можем вынести на отдельный сервер а потом и масштабировать.
Если я вас правильно понял, Вы говорите про распределенные системы
Если я вас правильно понял, Вы говорите про распределенные системы
severalnines.com/blog/how-deploy-postgresql-high-availability
Базы можно расположить в docker, но есть нюанс, если грохнуть все контейнеры, или грохнуть до окончания синхронизации, то все данные упадут вместе с контейнером.
Так что как вариант — проброс данных в хостовую систему. Для кворума лучше использовать 3 сервера с базами. Чтобы если грохнулась одна, оставалось ещё две и если грохнется ещё одна база до восстановления первой, приложение жило.
Базы можно расположить в docker, но есть нюанс, если грохнуть все контейнеры, или грохнуть до окончания синхронизации, то все данные упадут вместе с контейнером.
Так что как вариант — проброс данных в хостовую систему. Для кворума лучше использовать 3 сервера с базами. Чтобы если грохнулась одна, оставалось ещё две и если грохнется ещё одна база до восстановления первой, приложение жило.
Мы до того, как на 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, а в остальных добавляете сеть и лайблы и всё.
Sign up to leave a comment.
Один из сотни способов публикации нескольких production проектов на одном сервере