SlavikF

Можно настроить, чтобы все заходили на Gitlab через внешний Nginx. Тогда и не надо будет париться с разными настройками.

у меня Gitlab настроен работать только по HTTP, а SSL добавляется на Traefik (а не через Nginx, как у вас)

конфиг Gitlab:

services:
  gitlab-web:
    image: 'gitlab/gitlab-ce:14.8.2-ce.0'
    hostname: 'dev.slavikf.com'
    ports:
      - '22:22'
    labels:
      - traefik.enable=true
      - traefik.http.routers.gitlab-web.tls.certresolver=myresolver
      - traefik.http.routers.gitlab-web.tls=true
      - traefik.http.routers.gitlab-web.rule=Host(`dev.slavikf.com`)
      - traefik.http.services.gitlab-web.loadbalancer.server.port=80
    environment:
      GITLAB_OMNIBUS_CONFIG: |
          external_url 'https://dev.slavikf.com'
          registry_external_url 'https://dev.slavikf.com'
          nginx['real_ip_header'] = 'X-Forwarded-For'
          nginx['real_ip_recursive'] = 'on'
          nginx['listen_port'] = 80
          nginx['listen_https'] = false
          nginx['redirect_http_to_https'] = false
...

Многое зависит от сценария.

1. Например можно просто сделать вторую копию Nextcloud, куда регулярно скриптами будут копироваться файлы с основной копии. И в случае, если первая копия пропадает, то данные доступны на второй копии.
Минусы:
- Синхронизация может иметь задержку
- Вторая копия должна быть READ ONLY, потому что синхронизировать данные в обе стороны - сложно
- У второй копии адрес будет отличаться, поэтому его надо будет менять вручную. Наверное можно на коленке слепить свой Load Balancer, но он явно будет ограничен в функциональности.

2. Можно сделать полноценный high availability, но для этого надо:
- DB cluster
- File system cluster
- Load Balancer
Вот тут описан пример такой конфигурации:
https://severalnines.com/database-blog/deploying-h...
Но сюда не подходит "на очень слабом ПК".
И такую конфигурацию достаточно сложно настраивать, поддерживать и обновлять.

Не очень понятно - зачем в вашем приложении Nextcloud работающий через WebDAV?

Какая реализация в сервисах yandex, google, как они работают со своими файловыми хранилищами, доступом?

Современные приложения типично используют object storage (S3 compatible).

Использовать внешние облачные решения нет возможности.

Если хотите хостить сами - то можно MinIO. Можно поставить на тот же самый хост, что и приложение, а можно и развернуть систему из нескольких хостов.

Если же оставаться с Nextcloud, то другой вариант - настроить Nextcloud чтобы он мог отдавать файлы напрямую, без WebDAV, по ссылке, но здесь могут быть вопросы по аутефикации.

как реализовать проверку доступа к файлам?

Не очень понятно - что такое "проверка доступа"?

У Эластика как раз под эта дело есть утилиты для сбора информации:
- https://www.elastic.co/beats/metricbeat
- https://www.elastic.co/beats/winlogbeat
- есть и другие.

LogStash не нужен.

Grafana вроде бы работает с Elastic, но это не очень стандарнтная конфигурация. Обычно используют Kibana.

У меня как раз такая конфигурация стоит для нескольких небольших серверов.
В общем - работает, много метрик и логов собирает.

Events с Windows собираются без проблем.
Сетевую статистику тоже можно смотреть.
Но слабым местом мне показалось, что у Elastic'a как-то недоработан набор дэшбордов. То есть что-то можно увидеть сразу на стандартных дэшбордах, а что-то приходится вытягивать из метриков и логов самому. Не знаю, если у других инструментов дэшбоарды лучше...

Во первых, в платном тарифе у вас будет больше минут для раннера, но памяти больше не будет.

Во вторых, ошибка с нехваткой памяти - это не ошибка раннера. Это ошибка PHP.

Я не знаю, какой контейнер вы используете, но думаю, что решение проблемы - это увеличить memory_limit в конфиге PHP:

memory_limit = 512M

Вот именно для этой задачи написан nginx-proxy контейнер:
https://github.com/nginx-proxy/nginx-proxy

Этот "nginx-proxy" мониторит, какие контейнеры запущены на системе, и при появлении новых контейнеров - автоматические добавляет их в свой прокси.