Вроде бы прошло уже прилично времени, но я только сейчас разгрузился от переноса рабочих проектов. Теперь буду переносить это сайт. Буду описывать все проблемы и особенности, с которыми столкнусь “по ходу пьесы”.

Замена переменных для GitLab CI

Здесь все относительно просто. При первоначально настройке деплоя сайта опирался на docker образ amazon/aws-cli. Так что пришлось только обновить переменные в настройках репозитория.

Переменные Gitlab CI

Тут все как у всех, но стоит обратить внимание на AWS_ACCESS_KEY_ID, он состоит из двух частей <tenant_id>:<key_id>. Ключи key_id получается как везде, через сервисный аккаунт. А вот tenant_id нужно найти в консоли сервиса. Найти его можно по пути “Хранение данных”, “Object Storage”, “Параметры работы с API”:

Где найти tenant_id

Тут же есть регион. В моем случае он отличался от Яндекса, в Яндексе регион был ru-central1, в Cloud.ru же он имеет значение ru-central-1. Так же указываем новый AWS_ENDPOINT_URL_S3 как https://s3.cloud.ru. Остальные настройка просто копируются из данных сервисного аккаунта и названия бекета.

Статический сайт

Тут есть как плюс, так и минус. Имя для статического сайта можно указать отличное от имени бакета. Но оно не может содержать ничего кроме латинских букв, цифр и знаки дефиса:

domain-name.png

Так же оно будет ТОЛЬКО в виде [доменное имя].s3.cloud.ru. Как задать ему свой домен, пока-что не понятно. А значит придется на уровне Cloudflare поправить обработку домена. Так же это создает проблему: сайт будет всегда доступен по этому домену, значит нужно настраивать доступ ТОЛЬКО с ip адресов Cloudflare.

Ограничение доступа для всех, кроме Cloudflare

Получить список адресов Cloudflare можно либо на странице https://www.cloudflare.com/ips/, либо по апи https://api.cloudflare.com/client/v4/ips. Оттуда мы берем весь список и обновляем правило доступа (ip адреса на 21 октября 2026 года):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Deny",
      "Principal": "*",
      "NotPrincipal": {},
      "Action": "s3:GetObject",
      "NotAction": [],
      "Resource": "arn:aws:s3:::[имя бакета]/*",
      "NotResource": [],
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "173.245.48.0/20",
            "103.21.244.0/22",
            "103.22.200.0/22",
            "103.31.4.0/22",
            "141.101.64.0/18",
            "108.162.192.0/18",
            "190.93.240.0/20",
            "188.114.96.0/20",
            "197.234.240.0/22",
            "198.41.128.0/17",
            "162.158.0.0/15",
            "104.16.0.0/13",
            "104.24.0.0/14",
            "172.64.0.0/13",
            "131.0.72.0/22",
            "2400:cb00::/32",
            "2606:4700::/32",
            "2803:f800::/32",
            "2405:b500::/32",
            "2405:8100::/32",
            "2a06:98c0::/29",
            "2c0f:f248::/32"
          ]
        }
      }
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": "*",
      "NotPrincipal": {},
      "Action": "s3:GetObject",
      "NotAction": [],
      "Resource": "arn:aws:s3:::[имя бакета]/*",
      "NotResource": [],
      "Condition": {}
    }
  ]
}

Вместо [имя бакета] нужно подставить свой бакет. В конце должно быть правило Allow. Потому что если запрос не попал вод первое правило (имел правильный ip адрес), то без второго он окажется не попавшим ни в одно правило и все равно будет заблокирован.

Настройки самого Cloudflare

После простого прописывания домена из Cloud.ru в виде CNAME мы получаем ошибку:

Ошибка с сертификатом

Это из-за того, что в настройках у нас до сих пор стоит строгая проверка сертификата домена. Но это уже не Yandex, и сертификат отдается для работы с сайтом на s3. Тут нужно первым делом подменить hostname при запросе от Cloudflare, что бы Cloud.ru хотя бы поняло, на какой статический сайт идет запрос. И тут случается затык, так как функции переписывания hostname и/или sni - работают ТОЛЬКО в Enterprise версии:

Нет возможности редактировать hostname или sni

Итог

На текущий момент решить это все можно только поставив свой собственный nginx (или другой прокси на любой вкус). Средствами же Cloud.ru и Cloudflare это сделать нельзя. В следующий раз попробуем использовать Cloudflare pages.