Полное раскрытие: я работаю в Atlassian Premier Support, тесно сотрудничаю с нашей командой Bitbucket Server и в течение последних нескольких лет являюсь основным разработчиком образа Docker atlassian/bitbucket-server.
Короткая версия
Во-первых: используйте наше официальное изображение , есть множество проблем, которые мы решали на протяжении многих лет, поэтому вместо того, чтобы пытаться начать с нуля, используйте нашу в качестве базы.
Второе: вы действительно можете запустить кластер ЦОД в Docker. Моя личная среда тестирования состоит из 3 узлов кластера и пары Smart Mirror, все из которых используют официальный образ, с HAProxy, выступающим в роли балансировщика нагрузки, и внешним экземпляром Elasticsearch, управляющим поиском. Проверьте README выше для списка общих опций конфигурации - те, которые вам, вероятно, понадобятся, могут быть установлены путем передачи переменных окружения
Длинная версия
AKA "Как я могу раскрутить полный кластер постоянного тока в тестовой среде?"
Вот простое руководство, которое я собрал для наших собственных групп внутренней поддержки давным-давно. Он использует настраиваемый контейнер HAProxy Docker, чтобы предоставить вам готовый балансировщик нагрузки. Он предназначен для тестирования на одном хосте, поэтому, если вы хотите сделать что-то другое или приблизиться к производственному развертыванию, это не будет охватывать это.
Здесь есть что рассказать, поэтому давайте начнем с основ.
Сеть
Существует несколько способов подключения отдельных контейнеров Docker, чтобы они могли находить друг друга и обмениваться данными (например, параметр --link), но сеть Docker на сегодняшний день является наиболее гибкой. С выделенной сетью мы получаем следующее:
- Межконтейнерная связь: контейнеры в одной сети могут взаимодействовать друг с другом и получать доступ к сервисам из других контейнеров без необходимости публиковать определенные порты для хоста.
- Автоматический DNS: контейнеры могут находить друг друга по имени контейнера (определяется параметром
--name). В отличие от реального DNS, однако, когда контейнер не работает, его разрешение DNS перестает существовать. Это может вызвать некоторые проблемы для сервисов, таких как HAProxy, но мы вернемся к этому позже. Также стоит отметить, что при этом не задается имя хоста машины, которое необходимо установить отдельно, если требуется.
- Назначение статического IP-адреса. В некоторых случаях полезно назначать контейнерам Docker статические IP-адреса в своей сети
- Multicast: сети Docker по умолчанию поддерживают многоадресную передачу, что идеально подходит для узлов центра обработки данных, обменивающихся данными через Hazelcast
Единственное, чего не делает сеть Docker, - это присоединяет хост к своей сети, поэтому вы, пользователь, не можете подключаться к контейнерам по имени контейнера, и вам все равно нужно публиковать порты на локальном компьютере. Однако существуют ситуации, когда это полезно и необходимо. Самый простой обходной путь - добавить в файл hosts записи, которые указывают имя каждого контейнера, к которому вы хотите получить доступ, по адресу обратной связи, 127.0.0.1
Чтобы создать сеть Docker, выполните следующую команду. В моем примере мы назовем нашу сеть atlasNetwork. Если вы хотите использовать другое имя, не забудьте изменить имя сети во всех последующих командах Docker.
docker network create --driver bridge \
--subnet=10.255.0.0/16 \
atlasNetwork
Здесь мы создаем сеть, используя драйвер моста - это самый простой тип сети. Более сложные типы сетей позволяют сети охватывать несколько хостов. Мы также вручную указываем подсеть - если мы ее опускаем, Docker выберет одну из них случайным образом, и она может конфликтовать с существующей сетевой подсетью, поэтому безопаснее выбрать нашу собственную. Мы также указываем маску / 16, чтобы мы могли использовать диапазоны IP-адресов в последних двух октетах - это будет позже!
Хранение
Постоянные данные, такие как $BITBUCKET_HOME или файлы базы данных, должны храниться где-то за пределами самого контейнера. Для нашей тестовой среды мы можем просто хранить их непосредственно на хосте, нашей локальной ОС. Это означает, что мы можем редактировать конфигурационные файлы, используя наш любимый текстовый редактор, что очень удобно!
В приведенных ниже примерах мы будем хранить наши файлы данных в папке ~/dockerdata. Нет необходимости создавать эту папку или любые подпапки, так как Docker сделает это автоматически. Если вы хотите использовать другую папку, обновите приведенные ниже примеры.
Вы можете удивиться, почему мы не используем именованные тома Docker вместо монтирования папок на хосте. Именованные тома проще в управлении абстракцией и обычно рекомендуются; однако для целей тестовой среды (особенно в Docker для Mac, где у вас нет прямого доступа к виртуализированной файловой системе), существует огромная практическая выгода в том, что вы можете напрямую проверять постоянные данные каждого контейнера. Возможно, вы захотите отредактировать несколько файлов конфигурации в Bitbucket, Postgres или HAProxy, и это может быть сложно при использовании именованного тома, так как для этого требуется открыть оболочку в контейнере - а многие контейнеры не содержат базовых утилиты текстового редактора (даже не vi!). Однако, если вы предпочитаете использовать тома, вы можете сделать это, просто заменив папку хоста именованным томом во всех приведенных ниже примерах.
База данных
Первый сервис, который нам нужен в нашей сети, - это база данных. Давайте создадим экземпляр Postgres:
docker run -d \
--name postgres \
--restart=unless-stopped \
-e POSTGRES_PASSWORD=mysecretpassword \
-e PGDATA=/var/lib/postgresql/data/pgdata \
-v ~/dockerdata/postgres:/var/lib/postgresql/data/pgdata \
--network=atlasNetwork \
-p 5432:5432 \
postgres:latest
Давайте рассмотрим, что мы здесь делаем:
-d
- Запустите контейнер и отсоединитесь от него (вернитесь к приглашению). Без этой опции при запуске контейнера мы будем прикреплены непосредственно к его стандартному выводу, а отмена остановит контейнер.
--name postgres
- Установите имя контейнера на postgres, который также действует как его DNS-запись в нашей сети.
--restart=unless-stopped
- Устанавливает автоматический запуск контейнера при запуске Docker, если вы явно не остановили контейнер. Таким образом, при перезагрузке компьютера Postgres автоматически возвращается
-e POSTGRES_PASSWORD=mysecretpassword
- Устанавливает пароль для пользователя postgres по умолчанию mysecretpassword
-e PGDATA=/var/lib/postgresql/data/pgdata
- Официальный образ докера Postgres рекомендует указывать это пользовательское расположение при монтировании папки данных на внешний том
-v ~/dockerdata/postgres:/var/lib/postgresql/data/pgdata
- Монтирует папку
/var/lib/postgresql/data/pgdata внутри контейнера на внешний том, расположенный на хосте в ~/dockerdata/postgres. Эта папка будет создана автоматически
--network=atlasNetwork
- Присоединяет контейнер к нашей пользовательской сети Docker
-p 5432:5432
- Публикует порт Postgres на хост-компьютере, поэтому мы можем получить доступ к Postgres на
localhost:5432. Это не обязательно для других контейнеров, чтобы получить доступ к сервису, но это необходимо для нас, чтобы добраться до него
postgres:latest
- Последняя версия официального образа докера Postgres
Запустите команду, и вы можете получить доступ к полностью работающему экземпляру Postgres. Для согласованности, вы можете добавить свою самую первую запись хостов здесь:
127.0.0.1 postgres
Теперь вы и все работающие контейнеры можете получить доступ к экземпляру в postgres:5432
Прежде чем двигаться дальше, вам следует подключиться к базе данных, используя выбранный вами инструмент администратора БД. Подключитесь к имени хоста postgres с помощью имени пользователя postgres, базы данных postgres по умолчанию и пароля mysecretpassword и создайте базу данных Bitbucket, готовую к работе:
CREATE USER bitbucket WITH PASSWORD 'bitbucket';
CREATE DATABASE bitbucket WITH OWNER bitbucket ENCODING 'UTF8';
Если у вас нет удобного инструмента администратора БД, вы можете создать БД, используя docker exec для запуска psql непосредственно в контейнере:
# We need to run two commands because psql won't let
# you run CREATE DATABASE from a multi-command string
docker exec -it postgres psql -U postgres -c \
"CREATE USER bitbucket WITH PASSWORD 'bitbucket';"
docker exec -it postgres psql -U postgres -c \
"CREATE DATABASE bitbucket WITH OWNER bitbucket ENCODING 'UTF8';"
* +1135 * Elasticsearch
Следующая служба, которую мы настроим, - Elasticsearch.Нам нужен выделенный экземпляр, к которому могут получить доступ все наши узлы ЦОД.У нас есть отличный набор инструкций о том, как установить совместимую версию, настроить ее для использования с Bitbucket и установить подключаемый модуль безопасности Atlassian для баклеров: установить и настроить удаленный экземпляр Elasticsearch. Итак, как нам настроить это в Docker?Что ж, это просто:
docker pull dchevell/bitbucket-elasticsearch:latest
docker run -d \
--name elasticsearch \
-e AUTH_BASIC_USERNAME=bitbucket \
-e AUTH_BASIC_PASSWORD=mysecretpassword \
-v ~/dockerdata/elastic:/usr/share/elasticsearch/data \
--network=atlasNetwork \
-p 9200:9200 \
dchevell/bitbucket-elasticsearch:latest
Проще говоря, dchevell/bitbucket-elasticsearch - это предварительно настроенный образ Docker, настроенный в соответствии с инструкциями для Atlassian * Установка и настройка удаленного экземпляра Elasticsearch Статья кб.Плагин безопасности Atlassian Buckler установлен для вас, и вы можете настроить имя пользователя и пароль с помощью переменных среды, показанных выше.Опять же, мы подключаем том данных к нашей хост-машине, подключаем его к нашей сети Docker и публикуем порт, чтобы мы могли получить к нему прямой доступ.Это сделано исключительно для устранения неполадок, поэтому, если вы хотите покопаться в локальном экземпляре Elasticsearch без прохождения через Bitbucket, вы можете.
Теперь все готово, вы можете добавить вторую запись хостов:
127.0.0.1 elasticsearch
HAProxy
Далее мы настроим HAProxy.Установка Bitbucket Data Center предоставляет пример конфигурации, и снова у нас есть предварительно настроенный образ Docker, который выполняет всю тяжелую работу за нас.Но сначала, есть несколько вещей, которые мы должны выяснить в первую очередь.HAProxy плохо работает с DNS-системой сети Docker.В реальном мире, если система не работает, запись DNS все еще существует, и время соединения просто истекает.HAProxy отлично справляется с этим сценарием.Но в сети Docker, когда контейнер останавливается, его DNS-запись перестает существовать, и соединения с ним завершаются с ошибкой «Неизвестный хост».HAProxy не запустится, когда это произойдет, что означает, что мы не можем настроить его для прокси-соединений с нашими узлами по имени контейнера.Вместо этого нам нужно будет дать каждому узлу статический IP-адрес и настроить HAProxy для использования вместо этого IP-адреса.
Несмотря на то, что нам еще предстоит создать наши узлы, мы можем сейчас выбрать для них IP-адреса.,Подсеть нашей сети Docker 10.255.0.0/16, и Docker будет динамически назначать адреса контейнеров в последнем октете (например, 10.255.0.1, 10.255.0.2 и т. Д.).Так как мы знаем это, мы можем безопасно назначать нашим узлам Bitbucket статические IP-адреса, используя второй-последний октет:
10.255.1.1
10.255.1.2
10.255.1.3
С этим из пути есть еще одна вещь.HAProxy будет лицом нашего экземпляра, поэтому его имя контейнера будет представлять URL, который мы используем для доступа к экземпляру.В этом примере мы назовем это bitbucketdc.Мы также собираемся установить одинаковое имя хоста машины.
docker run -d \
--name bitbucketdc \
--hostname bitbucketdc \
-v ~/dockerdata/haproxy:/usr/local/etc/haproxy \
--network=atlasNetwork \
-e HTTP_NODES="10.255.1.1:7990,10.255.1.2:7990,10.255.1.3:7990" \
-e SSH_NODES="10.255.1.1:7999,10.255.1.2:7999,10.255.1.3:7999" \
-p 80:80 \
-p 443:443 \
-p 7999:7999 \
-p 8001:8001 \
dchevell/bitbucket-haproxy:latest
В приведенном выше примере мы указываем конечные точки HTTP наших будущих узлов Bitbucket, а также конечные точки SSH в виде списка через запятую.Контейнер превратит это в правильную конфигурацию HAProxy.Прокси-сервисы будут доступны через порт 80 и порт 443, поэтому мы публикуем их оба.Этот контейнер настроен на автоматическую генерацию самозаверяющего SSL-сертификата на основе имени хоста компьютера, поэтому у нас есть доступ к HTTPS из коробки.
Поскольку мы также используем прокси-сервер SSH, мытакже публикует порт 7999, стандартный SSH-порт Bitbucket Server.Вы также заметите, что мы также публикуем порт 8001. Это необходимо для доступа к интерфейсу администратора HAProxy, чтобы мы могли отслеживать, какие узлы обнаруживаются как работающие или отключенные в любой момент времени.
Наконец, мы монтируем папку конфигурации HAProxy на том данных.На самом деле в этом нет необходимости, но он позволит вам получить прямой доступ к haproxy.cfg , чтобы вы могли почувствовать параметры конфигурации.
Теперь пришло время для нашей третьей записи хоста.Это, поскольку он влияет на такие вещи, как доступ к базовому URL, абсолютно необходим
127.0.0.1 bitbucketdc
узлы Bitbucket
Наконец-то мы готовы создать наши узлы Bitbucket.Поскольку все они будут доступны через балансировщик нагрузки, нам не нужно публиковать какие-либо порты.Однако в целях устранения неполадок и тестирования могут возникнуть ситуации, когда вы захотите напрямую подключиться к определенному узлу, поэтому мы собираемся опубликовать каждый узел на отдельном локальном порту, чтобы мы могли обращаться к нему напрямую при необходимости.
docker run -d \
--name=bitbucket_1 \
-e ELASTICSEARCH_ENABLED=false \
-e HAZELCAST_NETWORK_MULTICAST=true \
-e HAZELCAST_GROUP_NAME=bitbucket-docker \
-e HAZELCAST_GROUP_PASSWORD=bitbucket-docker \
-e SERVER_PROXY_NAME=bitbucketdc \
-e SERVER_PROXY_PORT=443 \
-e SERVER_SCHEME=https \
-e SERVER_SECURE=true \
-v ~/dockerdata/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \
--network=atlasNetwork \
--ip=10.255.1.1 \
-p 7001:7990 \
-p 7991:7999 \
atlassian/bitbucket-server:latest
docker run -d \
--name=bitbucket_2 \
-e ELASTICSEARCH_ENABLED=false \
-e HAZELCAST_NETWORK_MULTICAST=true \
-e HAZELCAST_GROUP_NAME=bitbucket-docker \
-e HAZELCAST_GROUP_PASSWORD=bitbucket-docker \
-e SERVER_PROXY_NAME=bitbucketdc \
-e SERVER_PROXY_PORT=443 \
-e SERVER_SCHEME=https \
-e SERVER_SECURE=true \
-v ~/dockerdata/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \
--network=atlasNetwork \
--ip=10.255.1.2 \
-p 7002:7990 \
-p 7992:7999 \
atlassian/bitbucket-server:latest
docker run -d \
--name=bitbucket_3 \
-e ELASTICSEARCH_ENABLED=false \
-e HAZELCAST_NETWORK_MULTICAST=true \
-e HAZELCAST_GROUP_NAME=bitbucket-docker \
-e HAZELCAST_GROUP_PASSWORD=bitbucket-docker \
-e SERVER_PROXY_NAME=bitbucketdc \
-e SERVER_PROXY_PORT=443 \
-e SERVER_SCHEME=https \
-e SERVER_SECURE=true \
-v ~/dockerdata/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \
--network=atlasNetwork \
--ip=10.255.1.3 \
-p 7003:7990 \
-p 7993:7999 \
atlassian/bitbucket-server:latest
Вы можете видеть, что мы указываем статические IP-адреса, которые мы определили при настройке HAProxy.Вам решать, будете ли вы добавлять записи узлов для этих узлов или просто получать доступ к их портам через localhost.Поскольку никаким другим контейнерам не требуется доступ к нашим узлам через имя хоста, это на самом деле не является необходимым, и я лично не беспокоился.
Официальный образ Docker добавляет возможность устанавливать переменную только для Docker, ELASTICSEARCH_ENABLED=falseдля предотвращения запуска Elasticsearch в контейнере.Остальные свойства Hazelcast изначально поддерживаются в официальном образе докера, поскольку Bitbucket 5 основан на Springboot и может автоматически преобразовывать переменные окружения в их эквивалентные свойства точек для нас.
Включите все это
Теперь мы готовы к работе!
Доступ к вашему экземпляру на https://bitbucketdc (или любом другом имени, которое вы выбрали).Добавьте пробную лицензию на Центр обработки данных (Вы можете создать 30-дневную лицензию на https://my.atlassian.com) и подключить ее к базе данных Postgres. Войдите в систему, затем перейдите к Admin администратора и подключите свой экземпляр Elasticsearch (помните, он работает на порту 9200).поэтому установите для URL-адреса Elasticsearch значение http://elasticsearch:9200 и используйте имя пользователя и пароль, которые мы настроили при создании контейнера Elasticsearch.
Посетите раздел «Кластеризация» в Server Admin, и вы увидите все узлы, демонстрирующиечто Multicast работает, и узлы нашли друг друга.
Вот и все! Ваш экземпляр ЦОД полностью готов к работе. Вы можете использовать его как свой ежедневный экземпляр, выключив все узлы, кроме одного, и просто используйте его кактестовый экземпляр с одним узлом - затем, когда вам нужно, включите дополнительные узлы.