Cloud-Init: Bootstrapping Cloud Instances
Cloud-init is the script that runs on a generic VM's first boot to turn it into *your* server. It's used by cloud providers to apply your `user-data` (like SSH keys and startup scripts) at launch. The biggest footgun: it only runs once on first boot.
WHY IT EXISTS: Cloud providers need a standard way to configure customer instances from generic, pre-built virtual machine images. Without it, they'd need to maintain thousands of image variations for every OS and configuration permutation. Cloud-init solves this by deferring customization to the instance's first boot.
THE MENTAL MODEL: Think of cloud-init as the automated setup wizard for a new server. You hand a cloud provider a generic OS image and a configuration file (user-data). When the new virtual machine boots for the first time, cloud-init runs, reads your configuration, and transforms the generic machine into a fully configured server with your specified users, packages, and network settings.
HOW IT WORKS: On first boot, cloud-init runs through several stages. First, it uses a "datasource" module to detect which cloud it's on (e.g., AWS, Azure, OpenStack). It then fetches metadata from that cloud, primarily the "user-data" you provided at launch. This user-data can be a shell script or a YAML file called cloud-config. Cloud-init parses this data and executes modules to configure the system: setting the hostname, adding SSH keys, and installing packages. After its first successful run, it creates a semaphore file to prevent it from running again on subsequent reboots.
WHEN TO USE IT: Use cloud-init whenever you launch a new cloud instance. It's the standard mechanism for initial server bootstrapping, ideal for tasks like installing essential software, adding your team's public SSH keys, or setting a hostname. It's built into most official Linux cloud images.
WHEN NOT TO USE IT: Cloud-init is not a full configuration management tool like Ansible or Puppet. It's designed for initial, one-time setup, not for ongoing state enforcement. For managing a server's state after its first boot, use a dedicated configuration management tool. Trying to manage complex application logic through user-data scripts becomes brittle.
ONE CANONICAL EXAMPLE: When launching an AWS EC2 instance, you can provide a shell script in the "User data" field to install a web server: #!/bin/bash\nyum update -y\nyum install -y httpd\nsystemctl start httpd\nsystemctl enable httpd. When the instance boots, cloud-init executes this script, and your web server is running without manual intervention.
Read the original → docs.cloud-init.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.