Comments 26
Я так понял что всё запускалось на одном сервере. Как насчёт сценария с тремя серверами — на одном nginx-proxy, на двух других — контейнер с веб-сервисом. Как это сконфигурировать? Как сделать так, чтобы nginx видел что один контейнер с веб-сервисом умер, и на него не надо перенаправлять веб-запросы?
Думаю, что вам нужно посмотреть в сторону Docker Swarm или Kubernetes.
Для мониторинга бекендов в Nginx вроде был health check. Но я думаю, что в облаке он вам не понадобится.
Для мониторинга бекендов в Nginx вроде был health check. Но я думаю, что в облаке он вам не понадобится.
имхо, Kubernetes поудобнее, если не хочется отдельную сущность ковырять в виде консула
Во-первых, он медленнее. Во-вторых, мне лично не нравится, что у него свой API и свои абстракции. В итоге, когда вы работаете с Kubernetes, вам нужно знать и о нем, и о докере. В случае с Docker Swarm вы вообще можете не заметить разницы, потому что он полностью эмулирует Docker Remote API.
Т.е. меньше документации читать? «Соррян», я об этом не подумал.
Прошу прощения за оффтоп. А ежели рассматривать в разрезе API, сие удобство рассматривается в каком ключе? интеграция с CI и CD?
Прошу прощения за оффтоп. А ежели рассматривать в разрезе API, сие удобство рассматривается в каком ключе? интеграция с CI и CD?
В плане API. Вы можете использовать любое приложение, которое было изначально написано для локального докера, с Docker Swarm. Например, есть у вас какой-нибудь красивый GUI, который выводит табличкой список контейнеров. После того, как вы перейдете на Docker Swarm, вы можете продолжить пользоваться своим любимым софтом так, что последний может даже не знать ни о каких «облаках». В случае с примером выше, программа будет показывать вам список всех запущенных контейнеров облака, как будто они все запущены локально. Для Kubernetes вам бы пришлось искать альтернативу, или патчить имеющийся софт (если есть такая возможность).
просто у Kubernetes всё в одном (веб, сервис дисковери, HA)
а у Docker Swarm всё надо руками собирать и выбирать компоненты. Хотя с HA я может и не прав и он мультимастер научился.
Я вас понял, в плане однообразности всё-таки лучше Swarm. Пойду почитаю, что там за год изменилось.
а у Docker Swarm всё надо руками собирать и выбирать компоненты. Хотя с HA я может и не прав и он мультимастер научился.
Я вас понял, в плане однообразности всё-таки лучше Swarm. Пойду почитаю, что там за год изменилось.
Рад, что мы друг друга поняли. Возможно, Kubernetes и может в чем-то выиграть на гигантском количестве нод (при том, что Docker Swarm достаточно масштабируется). Но изначально вопрос был о трех серверах, один из которых load-balancer. И тут нельзя забывать о том, что Docker Swarm можно… банально запустить как контейнер в докере! ;-)
Таки изменилось, коллеги. Swarm чуть менее года как является частью самого Docker. Так что руками ничего поднимать более не надо.
kafeman, и к сожалению «какой-нибудь красивый GUI», предназначенный для контейнеров, не будет без доработки работать с новым Swarm, увы.
kafeman, и к сожалению «какой-нибудь красивый GUI», предназначенный для контейнеров, не будет без доработки работать с новым Swarm, увы.
Конечно, никакого «красивого GUI» у меня нет, но я не вижу причин, почему абстрактный сторонний клиент не сможет работать в swarm mode. Документация по API говорит, что просто добавились новые ресурсы для работы с сервисами, нодами и т.д. Но приложению, выводящему список контейнеров, о них знать и не нужно.
Я правильно понимаю то, что NGINX Reverse Proxy позволяет имея один белый IP адрес, который привязан к домену domain.ru, перенаправлять трафик на разные контейнеры в зависимости от вызова субдомена вроде forum.domain.ru в один контейнер, а faq.domain.ru в другой?
Да, если я правильно вас понял, то вы правильно поняли =)
А почему у двух других контейнеров одинаковый хост прописан: VIRTUAL_HOST=yourdomain.com?
Как NGINX Reverse Proxy понимает в какой контейнер переправлять трафик?
Как NGINX Reverse Proxy понимает в какой контейнер переправлять трафик?
Это только примеры ) Ясное дело, что, если вы запустите оба контейнера из этой статьи (например, с LAMP и с LEMP стеком), то в одном придется прописать один VIRTUAL_HOST, в другом — другой.
Т.е. это настраивается только в контейнерах с LAMP или с LEMP или другим вариантом, но не в контейнере NGINX Reverse Proxy, т.е. NGINX Reverse Proxy вообще трогать не надо?
Именно так. Он просто запускается и все. Главное, чтобы в нем был правильно задан volume (вот этот: -v /full/path/to/ssl-keys:/etc/nginx/certs).
Далее он автоматически подхватывает все контейнеры, запущенные после него с определенными VIRTUAL_HOST)
Далее он автоматически подхватывает все контейнеры, запущенные после него с определенными VIRTUAL_HOST)
Теперь всё понятно. А сертификаты достаточ получить только для основного домена domain.ru или надо для каждого forum.domain.ru и faq.domain.ru?
Желательно для каждого. Потому что nginx-proxy будет искать файлы .crt и .key в соответствии с заданным virtual_host.
Хотя в теории, можно сгенерировать 1 сертификат сразу под несколько доменов (например, для домена и его поддоменов) — а далее, если файл forum.domain.ru.crt, например, будет отсуствовать, то nginx-proxy вероятнее всего выберет единственный существующий (например, domain.ru.crt). И если окажется, что этот один сертификат подписан сразу на несколько доменов — в том числе на необходимый forum.domain.ru, то ошибки не должно быть…
Но все таки, лучше для каждого виртуального хоста генерировать по сертификату )) Тогда просто все будет четко и не будет сомнений в поведении реверс прокси контейнера ) Это стабильный на 100% вариант.
Хотя в теории, можно сгенерировать 1 сертификат сразу под несколько доменов (например, для домена и его поддоменов) — а далее, если файл forum.domain.ru.crt, например, будет отсуствовать, то nginx-proxy вероятнее всего выберет единственный существующий (например, domain.ru.crt). И если окажется, что этот один сертификат подписан сразу на несколько доменов — в том числе на необходимый forum.domain.ru, то ошибки не должно быть…
Но все таки, лучше для каждого виртуального хоста генерировать по сертификату )) Тогда просто все будет четко и не будет сомнений в поведении реверс прокси контейнера ) Это стабильный на 100% вариант.
Два контейнера с одинаковым VIRTUAL_HOST не имеют абсолютно никакого смысла ))
Точнее: в таком случае один из них (последний запущенный, вероятнее всего) будет исполняться по конкретному хосту, а второй не будет исполняться вообще, так как последний его по сути перекрыл.
В общем получилась бы ошибочная ситуация заведомо.
Точнее: в таком случае один из них (последний запущенный, вероятнее всего) будет исполняться по конкретному хосту, а второй не будет исполняться вообще, так как последний его по сути перекрыл.
В общем получилась бы ошибочная ситуация заведомо.
И кстати, виртуальные хосты на nginx и прочих веб-серверах совсем не обязательно выделять в рамках 1 домена.
Если средствами DNS привязать yourdomain.com -> 1.2.3.4 и mydomain.com -> 1.2.3.4, то nginx спокойно разрулит запросы на разные домены к разным бэкендам.
Все будет зависеть от заголовка 'Host', который будет слать ваш браузер на адрес 1.2.3.4
1. Зачем такой бАаальшой docker run для gitlab мы же решили использовать docker-compose )
2. Образ gitlab/gitlab-ce:latest конечно официальный, но по мне удобнее sameersbn/docker-gitlab.
Вообще у товарища sameersbn на github много интересных образов.
3.
Это не совсем правда!
Лучше это объяснить так:
опция docker run --volume «связывает» (линкует) папку хоста и образа. При использовании этой опции можно хранить данные контейнера хранятся на хосте и поэтому не исчезнут при удалении обновлении и вообще смене образ
4 Опять про volume:
во всех настройках данные расшарины абы как. Где-то пути относительные "./api:/src/app", где-то относительные. Когда контейнеров много можно и заплутать, если надо что-то исправить.
Предлагаю небольшой хак чтобы не все было прозрачно.
хранить все данные в одном формате:
/srv/docker/someImage/…
А еще лучше в домашней папке пользователя
~/docker/someImage/…
5. Все docker-compose в git
6. Все установки на сервере загонять в ansible (или любой другой инструмент для оркестрации) и тоже все в гит
7. Как решен вопрос с запуском всего этого после перезагрузки сервера?
8. На самом деле не понятно какая цель работы? gitlab + LAMP (MEAN)? приватные репозитории + хостинг проекта?
Тогда бы надо осветить wworkflow код -> gitlab -> ci -> LAMP
2. Образ gitlab/gitlab-ce:latest конечно официальный, но по мне удобнее sameersbn/docker-gitlab.
Вообще у товарища sameersbn на github много интересных образов.
3.
Важный момент: удаление контейнера не означает удаление данных, которые были созданы в процесе использования системы. Поэтому вы можете выполнять эту команду без каких-либо опасений.
Это не совсем правда!
Лучше это объяснить так:
опция docker run --volume «связывает» (линкует) папку хоста и образа. При использовании этой опции можно хранить данные контейнера хранятся на хосте и поэтому не исчезнут при удалении обновлении и вообще смене образ
4 Опять про volume:
во всех настройках данные расшарины абы как. Где-то пути относительные "./api:/src/app", где-то относительные. Когда контейнеров много можно и заплутать, если надо что-то исправить.
Предлагаю небольшой хак чтобы не все было прозрачно.
хранить все данные в одном формате:
/srv/docker/someImage/…
А еще лучше в домашней папке пользователя
~/docker/someImage/…
5. Все docker-compose в git
6. Все установки на сервере загонять в ansible (или любой другой инструмент для оркестрации) и тоже все в гит
7. Как решен вопрос с запуском всего этого после перезагрузки сервера?
8. На самом деле не понятно какая цель работы? gitlab + LAMP (MEAN)? приватные репозитории + хостинг проекта?
Тогда бы надо осветить wworkflow код -> gitlab -> ci -> LAMP
К сожалению, Docker под CentOS 6/7 по умолчанию использует device mapper как storage driver и это ужас-ужас — сборка больших контейнеров, работа с образами и реестром (registry) отнимает кучу времени и нервов. После перехода на OverlayFS всё начинает прямо-таки летать. При этом желательно использовать более свежее ядро например от ELRepo Project, т.к. в 3.10 от RH у overlayfs всё ещё есть некоторые ограничения.
Благодарю. Не знал раньше ничего о OverlayFS. Так что даете мне одно из направлений для развития в этом )
Думаю, со временем дойдут руки и до этого…
В любом случае я давно привык работать с Centos7 (олсо, с RHEL-подобными дистрами, не думаю, что в ближайшее время буду изменять это в своих проектах), так что стоящее замечание.
Думаю, со временем дойдут руки и до этого…
В любом случае я давно привык работать с Centos7 (олсо, с RHEL-подобными дистрами, не думаю, что в ближайшее время буду изменять это в своих проектах), так что стоящее замечание.
Sign up to leave a comment.
Docker, GitLab, бесплатные SSL-сертификаты и другие плюшки современной веб-разработки