Ingress-nginx уходит на покой

На днях в блоге Kubernetes появилась запись Ingress NGINX Retirement: What You Need to Know в которой сообщается что поддержка Ingress Nginx будет осуществляться до марта 2026 и далее не стоит ожидать каких-либо новых выпусков или исправлений.

To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX. Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available.

Другими словами, самое время начинать двигаться дальше и искать альтернативу. Жаль конечно, на мой взгляд это был один из самых популярных ингресс контроллеров, но отсутствие ресурсов на поддержку и "излишняя гибкость" сделали своё дело.

Грабли при обновлении ingress-nginx до 1.12.1

Вчера срочно обновлял ingress-nginx до 1.12.1 (версия чарта 4.12.1) после новости о критической уязвимости CVE-2025-1974 и наступил на грабли - релиз обновился, но все существующие ingress'ы потеряли привязку к IP адресу балансировщика.

Полез смотреть events в кластере, но там ничего криминального не нашлось. В логах ingress-nginx контроллера присутствовали ошибки вида

E0325 12:26:36.275715       7 store.go:938] annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

но сходу у меня не сложилась связь этих ошибок с отсутствием привязки к IP адресу. А вот когда попробовал пересоздать один из ingress'ов всё стало на свои места

Error: INSTALLATION FAILED: admission webhook "validate.nginx.ingress.kubernetes.io" denied the request: annotation group ConfigurationSnippet contains risky annotation based on ingress configuration

Во всех ингресах присутствовала аннотация nginx.ingress.kubernetes.io/configuration-snippet через которую делается тонкий тюнинг приложений и нет простого способа отказаться от использования этой опции.

Чтобы не путаться в сортах Nginx ingress

Нужно помнить что в мире Kubernetes есть два варианта nginx ingress, которые можно спутать:

• ingress-nginx (аннотации)
  
• nginx-ingress (аннотации)

В самом кластере их можно опознать по контроллеру в ingressclass:

• k8s.io/ingress-nginx - это ingress-nginx
• nginx.org/ingress-controller - это nginx-ingress
  

Назначение префикса URI для веб сервисов

Эта история из разряда "как не нужно делать". Изначально не планировал ее писать, но потратил некоторое количество времеми и хочется предостеречь других от хождения по граблям.

Имеется набор веб сервисов в которых не реализована настройка префикса URI, т.е. все ссылки строятся относительно "корня" (например: hostname:port/login, hostname:port/public/script.js, и т.д.).

И есть желание проверить сможет ли Nginx прозрачно проксировать запросы добавляя префикс каждому сервису чтобы не пришлось менять внутренности самих сервисов.

Сразу скажу что существует более надежное и простое решение - дать каждому сервису собственный поддомен, но это бывает сложно с точки зрения процессов: одобрение доменных имён, новые записи в DNS, SSL сертификаты и т.д.

Nginx запрашивает / вместо /.well-known/openid-configuration

Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой

$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')

Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида

$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Нужно разобраться откуда у меня берется этот редирект.

Будьте внимательны при апгрейде Nginx + PHP-fpm в Debian Jessie

При обновлении хоста с Debian Jessie столкнулся с полностью нерабочими PHP сайтами после завершения апгрейда сервера. На любой запрос php скрипта веб-сервер просто отвечает HTTP 200 и отдает пустую страницу. Никаких ошибок в логе Nginx не было.

Сайты содержали следующий кусок конфига:

location ~ \.php$ {

  # skipped lines

  fastcgi_pass unix:/var/run/php5-fpm.sock;
  fastcgi_index index.php;
  include fastcgi_params;
}

В процессе дебага выяснилось, что из файла /etc/nginx/fastcgi_params выкинули объявление параметра SCRIPT_FILENAME и из-за этого интерпретатору срывает крышу. Случилось это в районе версии 1.6.1-2:

  * debian/conf/fastcgi_params:
    + Sync with upstream and remove `SCRIPT_FILENAME` parameter.
      This change might break fastcgi sites. (Closes: #718639)
  + debian/conf/fastcgi.conf:
    + Ship upstream file.

Теперь в Nginx включен пример конфигурации для PHP-fpm (/etc/nginx/snippets/fastcgi-php.conf)

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

P.S. Особая благодарность создателям socat - он мой новый лучший друг в вопросах отладки. Достаточно запустить

socat -v UNIX-LISTEN:/tmp/php5-debug.sock UNIX-CONNECT:/var/run/php5-fpm.sock

и перенастроить Nginx на подключение к /tmp/php5-debug.sock, как становится виден процесс общения Nginx и PHP-fpm, а соответственно и суть проблемы.

Nginx: запаролить доступ к директории с PHP скриптами

Очень удивился когда Nginx дал выполнить скрипт из запароленной директории. При этом на саму директорию пароль спрашивает.

Этот ответ прояснил ситуацию. Полное описание логики блока location.

Nginx: client intended to send too large body

Если в логи nginx падает ошибка вида

2014/03/11 11:54:28 [error] 8699#0: *4615315 client intended to send too large body: 1569729 bytes, client: xx.xx.xx.xx, server: example.com, request: "POST /upload/index.php HTTP/1.1", host: "example.com", referrer: "http://example.com/upload/"

То причина в превышении лимита размера тела запроса в Nginx, за этот лимит отвечает параметр client_max_body_size (по-умолчанию лимит равен 1m).

Чтобы увеличить этот лимит хотя бы до 50m добавьте в конфигурацию nginx (в Debian это можно сделать через файл /etc/nginx/conf.d/local.conf)

# echo 'client_max_body_size 50m;' > /etc/nginx/conf.d/local.conf
# nginx -t
the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful
# service nginx reload

P.S. Ответ нашелся тут.

Включение maintenance режима в Nginx без помощи системного администратора

Вчера реализовал новую, более удобную для разработчиков, возможность перевести сайт в maintenance режим для всех посетителей, кроме тех, кто заходит с определенных ip (сайт всегда доступен самим разработчикам).

Имеем два ip адреса, с которых нужно пускать клиентов независимо от текущего режима сайта (для примера 67.81.43.124 и 67.23.44.5). Чтобы для включения maintenance режима не нужно было дергать администратора, будем считать наличие файла maintenance.flag в корне сайта, признаком включения maintenance режима.

Я использую nginx из Debian Squeeze и примеры будут ориентированы на него.

Для поддержки нового режима я добавил несколько секций в /etc/nginx/sites-enabled/www.example.com

geo $show_maintenance_page {
    default yes;
    67.81.43.124 no;
    67.23.44.5 no;
}

server {
    listen 80;
    server_name www.example.com example.com;

    if ( -f /var/www/www.example.com/maintenance.flag ) {
        set $maintenance y;
    }

    if ( $show_maintenance_page = yes ) {
        set $maintenance y$maintenance;
    }

    if ( $maintenance = yy ) {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        root /var/www/maintenance;
        rewrite ^(.*)$ /maintenance.html break;
    }

    # All other config

}

Содержимое /var/www/maintenance у меня существует еще с прежнего варианта, который я описывал ранее. Теперь чтобы перевести сайт в режим maintenance нужно создать файл maintenance.flag в корне сайта (/var/www/www.example.com). После этого всем посетителям будет выдавать maintenance страницу, а для тех, кто заходит с адресов 67.81.43.124 или 67.23.44.5 будет доступен сайт. Чтобы выключить maintenance достаточно удалить файл maintenance.flag.

Maintenance page для сайтов, которые обслуживаются Nginx

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

<html>
<head>
<title>Server Maintenance</title>
</head>
<body>
<center>
<h1>Server maintenance</h1>
Our apologies for the temporary inconvenience. The page is temporarily unavailable as server is down for scheduled maintenance. We will be back soon.
</center>
</body>
</html>

/var/www/maintenance/maintenance.html

<IfModule mod_rewrite.c>
    RewriteEngine on

    RewriteCond %{REQUEST_URI} !^/maintenance.html$
    RewriteRule .* /maintenance.html [R=302,L]
</IfModule>

/var/www/maintenance/.htaccess

Это позволяет отключать сайты вот так:

$ mv /path/to/siteroot /path/to/siteroot~disabled && \
cp -a /path/to/maintenance /path/to/siteroot

Этот способ хорош для apache, который обрабатывает .htaccess. Для Nginx поступил иначе:

• Поместил директорию maintenance в /var/www
• Создал конфиг /etc/nginx/maintenance-page
  

  location / {
      return 503;
  }
  
  error_page 503 /maintenance.html;
  
  location /maintenance.html {
      internal;
      root /var/www/maintenance;
  }

  /etc/nginx/maintenance-page
  
• Теперь чтобы отключить сайт /etc/nginx/sites-enabled/example.com (symlink на /etc/nginx/sites-available/example.com), нужно:
  

  # rm -f /etc/nginx/sites-enabled/example.com
  # cat > /etc/nginx/sites-available/example.com~maintenance <<EOF
  server {
      listen 80;
      server_name example.com;
      include /etc/nginx/maintenance-page;
  }
  EOF
  
  # ln -s /etc/nginx/sites-{available,enabled}/example.com~maintenance

• Остается перечитать конфиг в Nginx
  

  nginx -t && nginx -s reload

UPDATE: В комментариях подсказали более простой (и скорее всего более быстрый) способ для maintenance страницы. Поправил код в посте. Директива internal в секции location не даст напрямую обращаться к /maintenance.html.