Setting up autoscaling in the cloud for 1C-Bitrix

Configuring Cloud Auto-Scaling for 1C-Bitrix

Auto-scaling differs from horizontal scaling in that the number of nodes changes automatically — it grows under load and shrinks during idle periods. For 1C-Bitrix, this is relevant for projects with uneven load patterns: e-commerce stores during sale seasons, event portals, B2B platforms with daily peaks. Maintaining 10 servers for a 3-hour afternoon spike is irrational — auto-scaling lets you pay only for the resources actually in use.

Cloud Platforms: Yandex Cloud and VK Cloud

In the Russian-language market, the primary platforms are Yandex Cloud (Instance Groups) and VK Cloud (Auto Scaling Groups). The architecture is identical to AWS Auto Scaling: virtual machine groups with scaling policies based on metrics (CPU, RPS, memory).

How it works:

Metric Alert (CPU > 70% for 5 minutes)
  → Scale-out trigger
    → New VM created from golden image
      → Cloud-init: install nginx + php-fpm, mount NFS
        → Health check: VM added to load balancer
          → Traffic distributed to new node

Golden Image Requirements

Auto-scaling only works if a new VM is ready to accept traffic without manual intervention. The image must contain:

• nginx, php-fpm of the required version with Bitrix extensions
• Application PHP code (or a mechanism for rapid delivery)
• Shared storage mount script (/upload/, cache)
• Redis connection script for sessions
• Bitrix configuration with correct database and Redis parameters

Creating a golden image in Yandex Cloud:

# Launch a base VM, configure it manually
# After configuration, create a disk snapshot
yc compute disk create --snapshot-id <snapshot-id> --name bitrix-golden

# Create an image from the snapshot
yc compute image create \
    --name bitrix-app-v1-20240315 \
    --source-disk bitrix-golden \
    --description "1C-Bitrix app node, PHP 8.1, March 2024"

Cloud-init: Automatic VM Configuration on Boot

Cloud-init runs on first boot. Everything that depends on the specific environment is placed here:

# /etc/cloud/cloud.d/bitrix-init.yaml
#cloud-config
runcmd:
  # Mount the shared NFS volume
  - echo "nfs-server:/srv/bitrix-shared /var/www/html/upload nfs rw,sync,hard,intr 0 0" >> /etc/fstab
  - mount -a

  # Register the node in consul for service discovery
  - |
    curl -X PUT http://consul:8500/v1/agent/service/register \
      -d '{"name":"bitrix-web","address":"'$(hostname -I | awk '{print $1}')'"}'

  # Warm up PHP OPcache
  - php /var/www/html/bitrix/cli/health.php --warmup

  # Start services
  - systemctl start nginx php8.1-fpm
  - systemctl enable nginx php8.1-fpm

Bitrix configuration via environment variables (not hardcoded in the image):

// /bitrix/.settings.php — reads from environment
return [
    'connections' => [
        'value' => [
            'default' => [
                'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
                'host'      => getenv('DB_HOST') ?: 'mysql-master',
                'database'  => getenv('DB_NAME') ?: 'bitrix',
                'login'     => getenv('DB_USER') ?: 'bitrix',
                'password'  => getenv('DB_PASS') ?: '',
            ],
        ],
    ],
    'cache' => [
        'value' => [
            'type'  => 'redis',
            'redis' => [
                'host' => getenv('REDIS_HOST') ?: 'redis-master',
                'port' => (int)(getenv('REDIS_PORT') ?: 6379),
            ],
        ],
    ],
];

Configuring a VM Instance Group in Yandex Cloud (Terraform)

resource "yandex_compute_instance_group" "bitrix_web" {
  name               = "bitrix-web-asg"
  service_account_id = var.service_account_id

  instance_template {
    platform_id = "standard-v3"

    resources {
      cores  = 4
      memory = 8
    }

    boot_disk {
      initialize_params {
        image_id = var.bitrix_golden_image_id
        size     = 50
      }
    }

    network_interface {
      subnet_ids = var.subnet_ids
    }

    metadata = {
      user-data = file("cloud-init.yaml")
    }
  }

  scale_policy {
    auto_scale {
      initial_size    = 2
      min_zone_size   = 1
      max_size        = 10
      measurement_duration = 60   # seconds
      warmup_duration      = 120  # new VM warm-up

      cpu_utilization_rule {
        utilization_target = 70 # %
      }
    }
  }

  deploy_policy {
    max_unavailable = 1
    max_expansion   = 2
  }

  load_balancer {
    target_group_name = "bitrix-target-group"
  }
}

Code Deployment Without Rebuilding the Image

Rebuilding the golden image on every deployment is impractical. Two approaches:

Approach 1: Code on NFS — application code resides on NFS as well. Deployment = updating files on the NFS server. All nodes see the changes automatically. Downside: NFS is a single point of failure for code.

Approach 2: Pull on start — add a code retrieval step to cloud-init:

# In cloud-init: fetch the required tag from S3
aws s3 cp s3://bitrix-deploys/release-$(cat /etc/bitrix-release).tar.gz /tmp/
tar -xzf /tmp/release-*.tar.gz -C /var/www/html/

The RELEASE_TAG environment variable is passed in the VM metadata at instance group creation; cloud-init reads it and downloads the appropriate artifact.

Bitrix Auto-Scaling Readiness Checklist

• Sessions → Redis (not files)
• Cache → Redis or NFS (not local disk)
• /upload/ files → NFS or S3
• Temporary files, queues → Redis or database, not /tmp/
• Cron jobs → run only on one designated node (not all)
• Bitrix agents → switch to cron mode (BX_CRONTAB=Y) and run from the designated node
• REMOTE_ADDR → properly forwarded via X-Forwarded-For from the load balancer

Critical cron note: if Bitrix agents run on all nodes simultaneously, duplicates will occur. Use the bx_crontab_nodes parameter in bitrix/.settings.php or restrict via iptables on the cron node.

Monitoring and Alerts

Auto-scaling policy metrics:

Scope of Work

• Architecture audit, preparing Bitrix for stateless operation
• Redis HA setup (Sentinel or Cluster) for sessions and cache
• NFS/GlusterFS or S3 setup for files
• Golden image build, cloud-init scripts
• Terraform/Pulumi Instance Group configuration with scaling policies
• Application Load Balancer and health check configuration
• Solving the cron/agent problem in a cluster
• Load testing: scale-out/scale-in scenario validation

Timeline: basic auto-scaling with two nodes — 3–4 weeks. Production-ready setup with IaC, monitoring, and runbook — 6–10 weeks.