VK Cloud Server Automation: Terraform, cloud-init, and High-IOPS

Configuring VK Cloud Servers: Where Manual Work Breaks Down

Setting up servers in the cloud through the web console seems fast while there is only one environment.

By the third environment, discrepancies appear: a port is open on the test machine that is not open in production, the system library version differs, and a firewall rule exists only in someone’s browser tab.

Reproducing such an environment from scratch is no longer possible — you can only “roughly recall” what was done manually.

The cost shows up at the most inconvenient moment.

When a node fails or a second site is being prepared, an engineer brings up the environment from memory and gets a different result: the service fails to start due to mismatched dependencies, the disk is attached with a different size, and mount points differ from production.

Diagnosing such a discrepancy consumes hours, and all that time it is not the environment that is unavailable, but the product.

Manual server configuration is also bad because of accumulation.

Every urgent fix “on a live machine” does not make it into the description, the next fix relies on the previous one — and after a few months, no one can say for sure how the production environment differs from the standby one.

Automating VK Cloud servers removes this class of failures: node parameters are described declaratively, and initial configuration is performed by a script on first boot rather than manually in the console.

Infrastructure as Code provides environment reproducibility — the same environment can be brought up again from the description and at another site, down to network rules and disk type. Below, we break down how this is covered.

Measurable Effect: Build Speed, Recovery, Failures

Before automation, bringing up a test environment consumed half a workday: an engineer manually deployed nodes, installed dependencies, and adjusted configurations for a specific task.

Now the environment is described as code and comes up entirely in 8–12 minutes — together with the network, disks, load balancer, and initial configuration. The same set is applied to the development branch, acceptance environment, and load test runs.

Recovery after a node failure used to mean rebuilding manually: find the image, recall non-standard changes, check dependencies — from forty minutes to several hours of downtime.

Now a failed node is recreated from the infrastructure description in 5–7 minutes, data state is pulled from snapshots, and the previous configuration remains in history and is available for rollback with one command.

Separately, a whole class of failures goes away that is not cured by fast recovery — configuration drift between environments.

Manual fixes “only in prod,” forgotten dependencies, and diverged service parameters no longer accumulate: any change goes through the same description and review as code.

Infrastructure in VK Cloud becomes reproducible — an environment built from scratch a month later matches the current one.

Environment stability stops depending on who exactly made the changes.

Identical disk parameters and I/O operation limits across all environments remove the scenario “fast in acceptance, slow in production,” and configuration drift is caught at the validation stage rather than at the moment of an incident.

Ways to Describe Infrastructure: Comparing Approaches

All four approaches solve one task — bring a server to the desired state — but they handle changes differently.

The choice depends on how often the environment changes, how many machines are in the environment, and how important repeatability of the result is during the next deployment — including when configuring VK Cloud servers.

In practice, the approaches are combined: a declarative description defines machines, network, and disks; cloud-init brings them to a working state; and a prebuilt image reduces launch to a minimum.

Together, this provides configuration through code and environment templates that can be transferred between projects without manual changes. Manual assembly remains appropriate only where reproduction is not required.

Implementation Stages: From Audit to Handover to Support

Engineering work proceeds in sequential steps: each next step relies on the result of the previous one, and skipping any of them comes back as an outage in the production environment. Below is how this looks in practice.

1. Infrastructure audit. Inventory: which servers actually run, which volumes and networks are attached to them, who has access and with which keys, and where the actual configuration diverges from the documentation. Without this step, describing resources simply transfers errors into code.
2. Environment topology design. We determine the number of environments, network isolation, which workloads require High-IOPS class disks, and which can get by with standard ones. The topology is fixed before writing manifests.
3. Resource description. Servers, networks, load balancers, and volumes are described declaratively in Terraform; initial system configuration is done via cloud-init. State is stored in access-restricted storage, and modules are reused across environments.
4. Role and access configuration. Separate accounts for automation and for people, permissions based on least privilege, and keys issued for a specific role. We close off manual changes in the console — otherwise the next apply will roll them back.
5. Configuration validation. A copy of the environment is deployed from scratch, deleted, and rebuilt; the change plan is compared against the current infrastructure. This validates reproducibility and the absence of hidden dependencies.
6. Handover to support. The team receives documentation, a change procedure, and a clear rollback scheme; scaling, key rotation, and updates are performed according to instructions without the involvement of the topology authors.

What We Hand Over: Configurations, Topologies, Procedures

For us, a project ends not with deployment, but at the moment when your team can bring up the environment, make a change, and restore the service without us.

Therefore, along with the working infrastructure, you receive artifacts in the repository — they are read, reviewed, and versioned on par with application code.

• Infrastructure description — declarative VK Cloud Servers files: network, subnets, disks, security groups, load balancer. State is stored remotely with locking so that two simultaneous applies do not diverge.
• Environment topologies — what differs between environments, where parameters are overridden, and how to bring up a copy of the production environment to validate changes.
• Access policies — roles for engineers and service accounts, the least privilege principle, and the procedure for issuing and revoking keys and console access.
• Backup procedure — disk snapshot schedule, retention depth, recovery testing in a separate environment, and the procedure for rolling back to a previous point.
• Initial configuration templates — cloud-init scripts: accounts, disk mounting, agent installation, so that a new machine is brought into service without manual steps.
• Support documentation — instructions for the on-call shift: what a monitoring signal means, how to expand a disk, how to roll back a release, and where to look first.

We record the list of artifacts in the handover act: for each item, it is clear where it is stored and who owns it.

Case Study: Moving Manual Environments to a Reproducible Topology

The team assembled test environments manually: machines were brought up through the web panel, disks were attached according to instructions, and access was configured after the first launch.

Each environment came out slightly different, discrepancies surfaced during acceptance, and investigation took days — environment descriptions lived in the heads of two engineers.

We moved the infrastructure description into declarative configurations: the network, High-IOPS class disks for databases, and initial node configuration became part of the code.

VK Cloud provided a programmatic interface that the configurations access directly — a manual click in the panel stopped being a deployment step.

Separately, the most frequently recurring failures went away: the wrong disk class for a database, missed access rules, and nodes brought up in the wrong network segment.

Now this is caught by validating the description before apply — the error does not reach the environment, and rollback is done by switching to the previous revision.

What To Do If Part of the Infrastructure Is Already Built Manually?

Yes, this is almost always the case: some machines in VK Cloud are brought up manually, some by scripts, and no one is ready to rewrite everything at once.

Stopping a running service for the sake of a clean description is pointless, so we start with a hybrid mode: described and manual resources coexist until the former replace the latter.

Existing machines are pulled into the description via state import. The configuration is compared against the actual one, and the change plan must show no changes — if it proposes recreating a disk or network interface, then the description has diverged from reality.

In that case, we fix the description, not the machine: this way the resource comes under management without a reboot and without downtime.

New resources are described immediately and completely: networks, disks, access rules, and initial configuration via cloud-init.

Existing ones are connected as data sources — they read parameters but do not claim ownership, so an accidental apply will not destroy what we are not yet ready to take over.

We keep environments backward compatible: the same modules with different variable sets, so that a change is first tested in the test environment and only then goes to production.

The migration proceeds in parts, by group of machines, while preserving the ability to return to the previous state.

From iteration to iteration, the share of described resources grows, and manual changes become fewer.

Eventually the entire environment is described, changes are validated before apply, and recovery after a failure does not depend on whether someone remembers which command brought up a particular machine.

Common Technical Questions Before Starting Work

Before starting work, engineering teams usually have the same doubts: how access is arranged, what happens to data during a failure, and who is responsible for the infrastructure after handover. Below are short answers to each point.

How is backup arranged, and is recovery tested?

Copies are taken on a schedule and stored separately from the working environment, with a limited lifetime — the registry does not grow indefinitely. We test recovery in the test environment: otherwise, we cannot claim that the copy actually comes up.

Can custom images and non-standard disk volumes be migrated?

Yes. The initial boot configuration is described declaratively, so custom images, volume layouts, and requirements for high-throughput disks are set by parameters rather than edited manually. The description is stored in the repository and is reproduced when the machine is recreated.

What happens if the provider changes management interfaces?

Such changes are inevitable. We isolate them in a separate layer of the infrastructure description, so the fix affects one module rather than the entire configuration.

Change control is through review and edit history: deviation from the described state is visible and can be rolled back.

What is included in infrastructure support after implementation?

We hand over the description, topologies, policies, and instructions for typical operations, and we train the team. After that — post-implementation support in an agreed mode: updates, incident response, and scheduled fault tolerance checks.

Let’s Discuss Your Task: We’ll Come Back with an Estimate and Plan

Discussion of a task begins with a description of what exists now: how many servers and environments there are, and how they are created — manually through the control panel or already partly declaratively.

This is enough to estimate the automation project and propose a sequence of steps without prying for unnecessary details.

What is useful to include in the request:

• how many servers, environments, and teams currently use the infrastructure;
• which areas we automate first: network, disks, application deployment, access;
• requirements for disks and the nature of the workload — this determines the volume class;
• whether there is a procedure for access, secrets, and change logging;
• whether existing machines need to be migrated or only new ones are brought up;
• what infrastructure support mode is expected after launch.

In response, we send a work plan with stages, team composition, and effort estimates for each block, rather than a general list of services.

The first step is almost always a pilot environment: one service is fully described declaratively, from the network and volumes to initial configuration via cloud-init, to validate the approach under a real workload.

Next, we expand the environment to the remaining environments, move state to remote storage, and connect change validation into the overall build process.

Describe the task in whatever way is convenient for your team — we will come back with an estimate and a plan for the first steps.