Это процесс настройки, который я использую для конфигурирования Gitlab и I2P, при этом Docker используется для управления самим сервисом. В таком виде Gitlab очень просто размещать в сети I2P; его без особых трудностей может администрировать один человек. Эти инструкции должны работать на любой системе на базе Debian и их можно легко адаптировать к любой системе, где доступны Docker и I2P router (маршрутизатор I2P).
Зависимости и Docker
Поскольку Gitlab работает в контейнере, нам нужно установить на нашей основной системе только зависимости, необходимые для контейнера. Удобно, что всё необходимое можно установить с помощью:
sudo apt install docker.io
Получение контейнеров Docker
После установки Docker вы можете загрузить контейнеры Docker, необходимые для GitLab. Пока их не запускайте.
docker pull gitlab/gitlab-ce
Настройка I2P HTTP-прокси для Gitlab (Важная информация, необязательные шаги)
Серверы Gitlab внутри I2P могут работать с возможностью взаимодействовать с серверами в интернете вне I2P или без такой возможности. В случае, если серверу Gitlab не разрешено взаимодействовать с серверами вне I2P, его нельзя деанонимизировать путем клонирования репозитория Git с сервера Git в интернете вне I2P.
В случае, когда сервер Gitlab разрешено взаимодействовать с серверами вне I2P, он может выступать “мостом” для пользователей, которые могут использовать его для зеркалирования контента, находящегося вне I2P, в ресурс, доступный через I2P, однако в этом случае он не является анонимным.
Если вы хотите иметь bridged (мостовой), неанонимный экземпляр Gitlab с доступом к веб-репозиториям, дальнейшие изменения не требуются.
Если вы хотите иметь экземпляр Gitlab только для I2P без доступа к репозиториям, доступным только через веб, вам нужно настроить Gitlab на использование I2P HTTP‑прокси. Поскольку I2P HTTP‑прокси по умолчанию прослушивает только на 127.0.0.1, вам нужно настроить новый для Docker, который будет слушать на адресе хоста/шлюза сети Docker, обычно это 172.17.0.1. Я настраиваю свой на порту 4446.
Локальный запуск контейнера
Как только вы это настроите, вы можете запустить контейнер и опубликовать локально ваш экземпляр Gitlab:
docker run --detach \
--env HTTP_PROXY=http://172.17.0.1:4446 \
--publish 127.0.0.1:8443:443 --publish 127.0.0.1:8080:80 --publish 127.0.0.1:8022:22 \
--name gitlab \
--restart always \
--volume /srv/gitlab/config:/etc/gitlab:Z \
--volume /srv/gitlab/logs:/var/log/gitlab:Z \
--volume /srv/gitlab/data:/var/opt/gitlab:Z \
gitlab/gitlab-ce:latest
Перейдите на свой локальный экземпляр GitLab и настройте учетную запись администратора. Выберите надежный пароль и установите ограничения для учетных записей пользователей в соответствии с доступными ресурсами.
Настройте свои сервисные tunnels и зарегистрируйте имя хоста
После локальной настройки Gitlab перейдите в консоль I2P Router. Вам нужно будет настроить два серверных tunnel: один, ведущий к веб(HTTP) интерфейсу Gitlab на TCP-порту 8080, и один — к SSH-интерфейсу Gitlab на TCP-порту 8022.
Gitlab Web(HTTP) Interface
Для веб-интерфейса используйте серверный tunnel “HTTP”. На http://127.0.0.1:7657/i2ptunnelmgr запустите “New Tunnel Wizard” и введите следующие значения:
- Select “Server Tunnel”
- Select “HTTP Server”
- Fill in “Gitlab Web Service” or otherwise describe the tunnel
- Fill in
127.0.0.1for the host and8080for the port - Select “Automatically start tunnel when Router Starts”
- Confirm your selections
Gitlab SSH Interface
Для интерфейса SSH используйте “Standard” серверный tunnel. С http://127.0.0.1:7657/i2ptunnelmgr запустите “New Tunnel Wizard” и введите следующие значения:
- Select “Server Tunnel”
- Select “Standard Server”
- Fill in “Gitlab SSH Service” or otherwise describe the tunnel
- Fill in
127.0.0.1for the host and8022for the port - Select “Automatically start tunnel when Router Starts”
- Confirm your selections
Re-start the Gitlab Service with the new Hostname
Наконец, если вы изменили gitlab.rb или зарегистрировали имя хоста, вам потребуется перезапустить службу GitLab, чтобы настройки вступили в силу.