The Basics of Operating Alpine Linux

Light as a blade, controlling with precision

In the previous article (“The Basics of Operating Alpine Linux (2): Installing a ‘Toy'”), we completed the installation of Alpine Linux, creating a minimal experimental environment. Today, we will delve deeper into this “small yet beautiful” world and explore its significant differences from the traditional RHEL series.

If RHEL is a comprehensive “enterprise-level guardian,” then Alpine is a capable “special forces soldier.” It eliminates redundancy and focuses on core tasks, a design philosophy that permeates every operational detail.

Exploring the ‘Small’ Secrets of Alpine

The Philosophical Difference in Shutdown Commands

In the RHEL series, we are accustomed to using shutdown now to shut down the system, although there is also the poweroff command, the former is more common.

In Alpine, however, the situation is quite the opposite—poweroff is the preferred choice.

This seemingly minor difference actually reflects Alpine’s core philosophy: it does not pursue comprehensive functional symmetry but rather strives for extreme simplicity and directness.poweroff is shorter and aligns with a system that seeks efficiency through minimization.

Exploring the Roots of ‘Small’: BusyBox

We often say Alpine is small, but where does its ‘smallness’ come from? Let’s reveal the answer through a simple experiment.

Execute the following in your Alpine environment:

ls -l /bin | head -10

You will see something like this:

lrwxrwxrwx    1 root     root            12 Oct 18 16:51 arch -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Oct 18 16:51 ash -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Oct 18 16:51 base64 -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Oct 18 16:51 cat -> /bin/busybox

Astonishing discovery: Most commonly used commands are symbolic links pointing to busybox!

To see more clearly, run:

busybox --list | wc -l

The output shows that BusyBox integrates 305 commands. This means that a binary file of less than 1MB provides most of the tools we need daily.

Core Understanding: Alpine’s ‘smallness’ is not due to functional deficiencies but stems from high integration and optimization. It uses musl libc instead of the glibc used by RHEL, and integrates most commonly used commands through BusyBox, achieving extremely low resource usage.

Revolution in Software Management: APK Package Manager

Starting from Practical Problems

Let’s simulate a real scenario: querying the public IP of the machine. The common command is:

curl ifconfig.me

But on a newly installed Alpine, you will see:

ash: curl: command not found

This leads to Alpine’s core operational principle: the system only provides the core skeleton, and all additional tools need to be installed on demand through its package manager apk.

Deep Dive into APK

For those of us coming from the RHEL world, we can quickly get started with APK by comparison:

Operation	RHEL (yum/dnf)	Alpine (apk)	Core Differences
Update Software Sources	`<span>yum makecache</span>`	`<span>apk update</span>`	Alpine syntax is more concise
Install Software	`<span>yum install nginx</span>`	`<span>apk add nginx</span>`	Direct and without redundancy
Search Software	`<span>yum search curl</span>`	`<span>apk search curl</span>`	Logically consistent
Remove Software	`<span>yum remove nginx</span>`	`<span>apk del nginx</span>`
List Installed	`<span>yum list installed</span>`	`<span>apk info -v</span>`	View packages and versions
System Upgrade	`<span>yum update</span>`	`<span>apk upgrade</span>`	Upgrade all packages

Now, let’s solve the earlier curl issue:

apk update
apk add curl

After installation, execute curl ifconfig.me again, successfully retrieving the public IP!

Core APK Operation Process can be distilled to:apk update → apk add package_name. This simplicity is a reflection of Alpine’s philosophy.

Service Management and Firewall Configuration

Service Management: OpenRC vs Systemd

This is another significant difference between Alpine and RHEL. Starting from RHEL 7, the system uniformly uses systemd, while Alpine defaults to using OpenRC.

Let’s feel the difference through a practical case: installing and starting the Nginx web server.

Install Nginx:

apk add nginx

Start Service (compared to systemd):

RHEL: systemctl start nginx
Alpine: rc-service nginx start

Set to Start on Boot:

RHEL: systemctl enable nginx
Alpine: rc-update add nginx default

Check Service Status:

rc-service nginx status

Command Interpretation:

rc-service is the core command for managing the lifecycle of individual services in OpenRC
rc-update is the command for managing service run levels

Summary: Alpine’s service management is not unified through a large systemd but through a clearly defined combination of tools, reflecting its modular design philosophy.

Web Service Configuration Practice

After installing Nginx, accessing localhost shows a 404 page. This is because Alpine’s Nginx configuration is in “safe mode,” requiring us to manually define the web root directory.

Configuration Steps:

Edit Virtual Host Configuration

vi /etc/nginx/http.d/default.conf

Replace with Valid Configuration

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.html index.htm;
    server_name localhost;

    location / {
        try_files $uri $uri/ =404;
    }
}

Create Web Directory and Test Page

mkdir -p /var/www/html
cat > /var/www/html/index.html << 'EOF'




    <title>Alpine Nginx Test</title>


    <h1>Web Service Configuration Successful!</h1>


EOF

Validate and Restart Service:

nginx -t  # Check configuration syntax
rc-service nginx restart
curl localhost  # Test access

This “default no configuration” design reflects Alpine’s security philosophy—making no assumptions about any needs, requiring users to configure explicitly as needed.

Firewall Configuration: Returning to Basics

RHEL defaults to using the complex firewalld, while the Alpine community prefers to use iptables directly. Note that a minimal installation does not include firewall tools by default and requires manual installation.

Basic Configuration:

Install iptables

apk add iptables

Add Rules (example to open port 80):

iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

Save Rules (a major difference from RHEL!):

/etc/init.d/iptables save

This command saves the rules to /etc/iptables/rules.v4, otherwise the rules will be lost after a reboot.

Important Reminder: This configuration method is not an “out-of-the-box” enterprise-level solution but provides the most direct and transparent manual control. For production environments, it is recommended to write scripts or use configuration management tools to maintain firewall rules.

Mindset Shift: From RHEL to Alpine

Through the above practices, we have crossed several key thresholds from RHEL to Alpine:

Cognitive Design Philosophy shifts from “large and comprehensive” to “small and beautiful”
Mastering Core Tools shifts from yum to apk, from systemctl to rc-service
Understanding Configuration Differences especially in service definitions and firewall persistence

Suggestions for Further Learning:

Official Wiki First This is the most authoritative source of information and should be your first stop
Practice Makes Perfect Try installing and configuring various services to experience the differences firsthand
Utilize the Community Alpine has an active community, and you can seek help when encountering difficulties

Key Mindset Shift: Forget those “automatic” assumptions from RHEL, embrace the minimalism and control of “everything needs explicit configuration.” This not only allows you to manage Alpine well but also helps you deeply understand the underlying mechanisms of Linux systems.

In this era of containerization and cloud-native applications, understanding minimalist systems like Alpine is a key skill for building efficient and secure application infrastructures.