Комментарии 20
Для дочитавших статью до конца - бонусная ссылка: https://github.com/Lakr233/GitLab-License-Generator
Вы явно знаете, что с этим делать)
Никогда не выставляйте крупные веб-морды наружу. Они все дырявы насквозь, и взлом - вопрос времени. Причем хорошо, если взломает хулиган, а не распространитель политоты или цопе... Науржу только ssh + ipsec (или другой впн), остальное внутри. В крайнем случае накрывайте реверс-прокси с клиентским сертом.
Для почты есть отличное решение mailcow, набор преднастроеных контейнеров. Если донастроить по инструкции - почта ходит прекрасно, ничего не режет. Пользуюсь довольно давно.
Для "бытового" DNS/DHCP лучше всего TechnitiumDNS - при полной бесплатности там шикарная веб-морда для конфигурации. И тоже распространяется как контейнер в том числе.
а как вы направляете трафик с cloudflare в домашнюю серверную с серым ИП адресом?
А тут всё просто - я ставлю А запись на ip в домашней сети. ну к примеру 192.168.1.10 . И оно работает, но правда только внутри домашней сети. Можно заморочиться и выкинуть наружу, но я не хочу.
тогда зачем морочиться с сертами? можно обычный http использовать. ну и платное доменное имя для домашней сети? можно поднять внутри домашней сети свой днс сервер и сделать зону local например
ну я писал и про Duckdns, он бесплатный и работает в локальной сети.
Сертификаты нужны, чтобы на runner и в docker не получать ошибку x509 при запросе на этот гитлаб. В общем, я тут просто описал свою методику.
А можно сгенерировать локальный сертификат хоть на 20 лет и забыть об обновлении. Только распихать CA-шку по клиентским компам.
вот поэтому я и беру летсэнкрипт, потому что его CA уже раскидан на все компы) А так, сертбот сам потом обновляет и рестартит сервис, так что в целом это "бессрочный" сертификат)
Конечные серты, сгенеренные более чем на 3 месяца очень скоро будут недействительны везде. Вопрос времени, когда это правило заедет в openssl. На макоси уже сейчас конечные серты сроком более чем на год не работают - яблоко первым начало применять эту инициативу...
А еще сейчас каждая контора разработчиков считает за хороший тон не использовать системные серты, а класть их максимально неудобно и нестандартно. Гитлаб раннер в одном месте СА хранит, докер в другом, жава в третьем, ... попробуй собери их всех! А еще прокинь кастомные CA в контейнеры, которых мешок и они все разные... Испытай настоящие боль и унижение.
Так что LE сейчас очень выручает, если домены на реальном tld, а не на своем типа *.lan
Это странно, что у вас были проблемы с gitlab на NPM. Может недонастроили какие-то доп параметры в gitlab? Помню, что делал такое при установке за NPM.
у меня проблема была на вкладке с раннерами при работе через npm. То есть нажимаешь создать раннера, а в итоге получаешь ошибку и редирект на локалхост. Поэтому в итоге решил делать через certbot. По факту пока что гитлаб единственный сервис, который работает таким способом, остальные сервисы закинуты в кубер и там уже certmanager автоматически запрашивает сертификат при деплое ingress-а
У меня в локальной сети работает сервер гитлаб и на другой машине раннер запущен, зарегался без проблем по локальному адресу без серта, джобы идут, все норм. Странно
Скажу вам по секрету, у regru есть api, и даже можно dns челлендж пройти(у меня уже как года два работает все, никаких проблем не было)
Тоже самое только в контейнере
docker-compose.yml
networks:
gitlab_net:
name: gitlab
driver: bridge
ipam:
driver: default
config:
- subnet: '172.28.3.0/24'
gateway: '172.28.3.254'
ip_range: '172.28.3.0/28'
driver_opts:
com.docker.network.bridge.name: gitlab-bridge
services:
gitlab:
container_name: gitlab
hostname: gitlab.example.com
image: gitlab/gitlab-ee:17.11.2-ee.0
shm_size: '512mb'
environment:
SENSELESS: variable
GITLAB_OMNIBUS_CONFIG: |
### Postgresql settings
###! Docs: https://docs.gitlab.com/omnibus/settings/database.html
postgresql['enable'] = true
postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432
postgresql['md5_auth_cidr_addresses'] = ['127.0.0.1/24', '172.28.3.0/24', '197.15.22.0/24']
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/24)
# force ssl on all connections defined in trust_auth_cidr_addresses and md5_auth_cidr_addresses
postgresql['hostssl'] = true
postgresql['db_sslmode'] = 'require'
# Disable monitoring
prometheus_monitoring['enable'] = false
prometheus['enable'] = false
postgres_exporter['enable'] = false
redis_exporter['enable'] = false
node_exporter['enable'] = false
alertmanager['enable'] = false
# Custom settings
postgresql['max_connections'] = 512
postgresql['shared_buffers'] = '4096MB'
external_url 'https://gitlab.example.com'
# gitlab_rails['gitlab_ssh_host'] = 'ssh.host_example.com'
gitlab_rails['time_zone'] = 'Europe/Moscow'
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_display_name'] = 'My GitLab'
gitlab_rails['webhook_timeout'] = 40
### GitLab email server settings
###! Docs: https://docs.gitlab.com/omnibus/settings/smtp.html
###! **Use smtp instead of sendmail/postfix.**
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.yandex.ru"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "gitlab@example.com"
# user password
#gitlab_rails['smtp_password'] = "xxxxxxxxxxxxxxxxxxx"
# application password
gitlab_rails['smtp_password'] = "xxxxxxxxxxxxxxxxxxx"
gitlab_rails['smtp_domain'] = "example.com"
gitlab_rails['gitlab_email_from'] = "gitlab@example.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = false
gitlab_rails['smtp_tls'] = true
gitlab_rails['smtp_openssl_verify_mode'] = "peer"
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['admin@example.com']
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"
nginx['redirect_http_to_https'] = true
nginx['hsts_max_age'] = 63072000
nginx['hsts_include_subdomains'] = true
nginx['http2_enabled'] = true
nginx['proxy_set_headers'] = {
'X-Forwarded-Proto' => 'https',
'X-Forwarded-Ssl' => 'on'
}
registry['enable'] = false
### Backup Settings
###! Docs: https://docs.gitlab.com/omnibus/settings/backups.html
gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
## Limit backup lifetime to 2 days - 172800 seconds
gitlab_rails['backup_keep_time'] = 86400
# In the event of an disaster,
# the container must be stopped manually
# and must not start automatically.
restart: unless-stopped
ports:
- "197.15.22.27:22:22"
- "80:80"
- "443:443"
volumes:
- './gitlab.example.com/config:/etc/gitlab'
- './gitlab.example.com/logs:/var/log/gitlab'
- './gitlab.example.com/data:/var/opt/gitlab'
- './gitlab.example.com/hooks:/opt/gitlab/embedded/service/gitlab-shell/hooks'
- './gitlab.example.com/backups:/var/opt/gitlab/backups'
networks:
gitlab_net:
ipv4_address: 172.28.3.1DNS-01 challenge в GitLab не реализован, поэтому придётся использовать HTTP-01 challenge, либо получать сертификат с помощью certbot
А почему gitlab, а не gitea или firgejo? Ресурсов в разы меньше нужно и функционал тот же
гитлаб распространён как ci/cd тулза в компаниях. Про gitea ни разу не видел в вакансиях)
Ну в gitea используется GitHub actions для cicd). Если по ставится не для изучения чисто cicd gitlab, то в чем ещё его преимущество?) Я сам поставил на домашнем сервере firgejo (форк gitea) и выбирал между ним и gitlab. Вот пытаюсь понять в чем причина популярности gitlab
Домашняя серверная для DevOps: установка GitLab + Let's Encrypt