gitlab-org/gitlab-environment-toolkit 3.11.0

on GitLab

[!important]

The GitLab Environment Toolkit automates deploying and managing scaled GitLab environments following the Reference Architectures. It's recommended that users review the Before You Start section before use. Users are expected to have a good working knowledge of Terraform, Ansible, GitLab administration, and infrastructure management, as environments ultimately remain the responsibility of the user. As such, it's strongly recommended that you independently review the Toolkit in full before any use to ensure it meets your requirements, especially around security or data integrity.

If upgrading, it's always recommended to review the release notes in full as well as the relevant documentation and to upgrade the Toolkit first before the environment.

[[TOC]]

New Key Features

Container Registry Metadata Database GA

• Merge Request(s): !1866, !1867 (thanks @nwestbury!), !1869, !1884
  
• Documentation: Container Registry Metadata Database
  

The Container Registry Metadata Database support has graduated from Beta to GA.

Support is available where the registry has its own dedicated PostgreSQL instance: a single GitLab managed Postgres node, an externally managed database, or a separate externally managed database via container_registry_database_host. Refer to the documentation for full setup support and limitations.

Further Updates and Improvements

• Bumped HAProxy to 3.4 (latest LTS). !1881
  
• Bumped Node Exporter to 1.12.1. !1881
  
• Exposed disk IOPS and throughput variables consistently across all AWS node types, not just Gitaly. !1859. See Upgrade Notes for more information.
  
• Restricted NFS exports to per-node inventory entries instead of a broad /16 CIDR. !1860. See Upgrade Notes for more information.
  
• Disabled EPEL setup by default on RHEL-family hosts, now opt-in via epel_setup. !1861. See Upgrade Notes for more information.
  
• Switched Python packages (psycopg2/pexpect/requests) from pip to system packages, scoped only to nodes that need them. !1863
  
• Added s3:GetObjectTagging/s3:PutObjectTagging to S3 IAM policies to fix intermittent AccessDenied errors from external taggers (for example, GuardDuty Malware Protection). !1858
  
• Added aws_profile passthrough for Geo kubeconfig configuration, enabling cross-account primary/secondary Geo on AWS. !1873
  
• Documented the GKE/EKS extra node pool extension pattern (for example, AI Gateway). !1864
  
• Added Envoy Gateway controller support for the GitLab Operator install path, previously only installed for the Helm chart path. !1883
  
• Fixed ZDU post-deployment migrations failing with external Postgres. !1868
  
• Fixed HAProxy configuration folder permissions to match the HAProxy Docker container's user ID. !1874 (thanks @fdonval!)
  
• Ensured target directories exist for GitLab deb and rpm packages. !1876 (thanks @fdonval!)
  
• Lowered CI docker:dind MTU from 1400 to 1360 to fix dropped TLS packets during docker build steps. !1862
  
• Added an AI-assisted contributions policy and clarified support routing in CONTRIBUTING/README. !1875
  
• Documented RDS major version upgrades with Geo cross-region replication. !1877
  
• Clarified AWS and Azure provisioning permissions. !1878 (thanks @vivekyarra567!)
  

Upgrade Notes

EPEL now opt-in on RHEL-family hosts

EPEL repository setup is now disabled by default (epel_setup: false), since no package installed by the Toolkit requires it. If you rely on EPEL being configured for your own custom config/tasks, set epel_setup: true explicitly.

NFS export restrictions

NFS exports are now restricted to per-node entries derived from the gitlab_rails and sidekiq inventory groups, rather than a broad /16 CIDR range. This is a tightening of access, not an expansion, so no action should be required, but review your NFS host's firewall/export config if you have custom rules layered on top of the Toolkit's defaults.

Praefect RDS iops fix (AWS)

!1859 fixes a bug where the Praefect RDS instance's iops incorrectly fell back to rds_postgres_iops instead of rds_praefect_postgres_iops. If your environment sets these two variables to different values, upgrading will apply a real iops change to the Praefect RDS instance on the next terraform apply. Review your plan output before applying if you use a custom rds_praefect_postgres_iops value.

Feedback

Got any feedback or found an issue? Please feel free to create an issue on our tracker: https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/issues