Tag: MariaDB

Deploying a web application on AWS Elastic Compute Cloud (EC2) usually means setting up a server with the right software, configurations, and optimizations. But let’s be honest—doing this manually over and over again gets old fast. Instead of setting up everything from scratch each time, Amazon Machine Images (AMIs) let us create a pre-configured system that we can reuse whenever we need to spin up a new EC2 instance.

And instead of doing this manually every time that we need to change something in the AMI, we’ll use Packer to automate the entire process. But before we get into that, let’s break down what an AMI actually is and why you might want to build your own.

What is an AMI?

Think of it like making a pizza at home. You could start from scratch every time—making the dough, preparing the sauce, chopping toppings—but why bother when you can just freeze a fully prepared pizza and bake it whenever you’re hungry? An AMI is that prepped pizza, ready to go. But unlike frozen food, an AMI doesn’t mean sacrificing quality or control. You still get a fresh, optimized setup—just without the hassle of doing it all over again.

For those who want to skip ahead, the complete solution with all scripts and configurations is available on my GitHub repository: aws-ols-mariadb-ami.

Why Build a Custom AMI?

When launching an EC2 instance, you have three main options:

1. Start from scratch – Use a bare Linux AMI, launch an instance, SSH in, and manually install and configure everything. This gives you full control but is tedious and time-consuming.
2. Use a prebuilt AMI from AWS Marketplace – These come with software pre-installed, saving setup time, but many require a paid subscription and often include extra software you don’t need.
3. Build your own custom AMI – The best of both worlds! You get a pre-configured, lightweight setup, tailored to your needs, with only the software you actually use—no unnecessary bloat or extra costs.

In my previous posts, I explained how to use the OpenLiteSpeed AMI from the AWS Marketplace. It’s a convenient option, but it costs $5 per month. The funny thing? Everything inside that AMI is open-source and free. So instead of paying for it, we can build our own version. This saves money, allows full customization, and lets us configure it once and reuse it as many times as we need. Plus, we can skip unnecessary packages, keeping our AMI lightweight.

In this post, I’ll walk through how to build a custom AMI based on Ubuntu 24.04, with these software and packages preinstalled and configured:

• OpenLiteSpeed (with LiteSpeed Cache)
• PHP (LSPHP)
• MariaDB (Server & Client)
• phpMyAdmin
• WordPress

And instead of doing this manually every time that we need to change something in the AMI, we’ll use Packer to automate the entire process.

What is Packer?

Packer, created by HashiCorp, is a tool that automates machine image creation. Instead of manually setting up an instance and then taking a snapshot, Packer does everything for you. You define a template (in JSON or HCL), and Packer spins up a temporary server, installs and configures everything, then saves the final golden image as an AMI.

Why does this matter? Manually setting up AMIs is repetitive, time-consuming, and error-prone. With Packer, you define everything once, and it builds AMIs on autopilot. Need an update? Just tweak the template and rebuild—no clicking around AWS wondering what you forgot.

In short: Packer Automate AMI creation instead of doing it manually. Ensure consistency across deployments. Save time and avoid configuration headaches.

Before we get into Ansible, let’s break down how Packer actually works. Packer doesn’t just magically create an AMI—it follows a process with two key components: builders and provisioners.

• Builders are responsible for creating the machine image. In our case, the Amazon EC2 builder launches a temporary EC2 instance, installs everything needed, and then snapshots it into an AMI.
• Provisioners handle installing software and configuring the system. Once the instance is up, provisioners take over to set up services, install dependencies, and customize the system before the image is finalized.

While Packer supports different provisioners, including raw shell scripts, a more structured approach makes things easier to maintain—which brings us to Ansible. If Packer is the robot that builds your AMI, then Ansible is the smart assistant making sure everything inside is set up exactly the way you want.

What is Ansible?

Ansible is an automation tool for configuring servers, installing software, and managing infrastructure—without manually SSH-ing into each machine. Instead of writing long, brittle shell scripts, you define what needs to be done in simple YAML playbooks, and Ansible handles the rest.

What makes Ansible special?

Why Use Ansible with Packer Instead of a Shell Script?

Packer has a Shell provisioner, so why not just use bash scripts? Well, while shell scripts work, they have drawbacks:

• Harder to maintain – Bash scripts can quickly turn into a tangled mess of commands and conditionals. Ansible uses structured, declarative YAML playbooks that are easier to read and modify.
• Idempotency – As mentioned above, Ansible won’t re-run commands but shell scripts happily reinstall everything, every time.
• Better error handling – If something fails in Ansible, it fails gracefully, showing exactly where and why. A shell script might just stop mid-way, leaving your setup half-broken.
• More flexibility – Ansible modules allow for cleaner and more portable provisioning logic compared to writing a bunch of apt-get or yum commands.

How It Works with Packer

Once Packer spins up a temporary EC2 instance, Ansible takes over as the provisioner, installing software, configuring services, and making sure everything is properly set up before the AMI is saved.

Now that we know why AMIs make life easier, how Packer automates the heavy lifting, and why Ansible keeps everything neat and organized, it’s time to roll up our sleeves and build our own custom AMI!

(more…)