DEV Community: AndersonPEM

Setting Up Multi-Architecture Docker Builds with QEMU

AndersonPEM — Wed, 04 Dec 2024 16:14:27 +0000

Why Multi-Architecture Builds?

With the rise of ARM-based systems like Apple Silicon Macs and AWS Graviton instances, building container images for multiple architectures has become essential. This guide explains how to set up your Ubuntu system for multi-architecture Docker builds.

System Requirements

I'm assuming you're using a Debian or Debian derivate (Ubuntu, PopOS, Tuxedo OS, etc)

First, install the necessary virtualization packages:

sudo apt update && sudo apt install qemu-kvm qemu-system qemu-utils libvirt-daemon \
  libvirt-clients bridge-utils ovmf cpu-checker

sudo usermod -aG kvm $USER

These packages provide:

QEMU: Hardware virtualization
libvirt: API for virtualization
bridge-utils: Network bridging tools
OVMF: UEFI firmware for virtual machines
cpu-checker: Verifies virtualization support

Setting Up Multi-Architecture Support

Docker needs QEMU to emulate different CPU architectures. Configure this with:

docker run --privileged --rm tonistiigi/binfmt --install arm64

This command installs the necessary binary format handlers for ARM64 architecture.

Creating a Multi-Architecture Builder

BuildKit, Docker's build system, needs a dedicated builder for multi-arch builds:

docker buildx create --name multiarch --driver docker-container --bootstrap
docker buildx use multiarch

Building Multi-Architecture Images

Build images for both AMD64 and ARM64 with:

docker buildx build --platform linux/amd64,linux/arm64 .

Best Practices

Test images on actual hardware when possible
Use multi-stage builds to optimize image size
Consider CI/CD pipeline integration for automated builds
Tag architecture-specific images alongside multi-arch manifests

Verification

Verify your setup with:

docker buildx ls

This should show your new builder with both platforms available.

Symfony: The way of the bundle

AndersonPEM — Wed, 28 Feb 2024 10:57:41 +0000

In the realm of Symfony, where the architecture is as vast as the landscapes of code it governs, there exists a path for the wise: the way of the bundle. As a master guiding you, my apprentice, through the intricacies of Symfony, I shall unveil the secrets to abstracting your code into bundles, transforming your applications into a tapestry of reusable components, each a testament to the art of software craftsmanship.

The Genesis of a Bundle
Imagine, young apprentice, a world where each feature of your application is not a tangled web of dependencies but a serene island of functionality. This is the essence of a bundle in Symfony. The journey begins with the identification of reusable features. Look closely at your codebase; what do you see? Perhaps a user management system, a payment processing library, or an API client whispering the tales of external services. These are your candidates for abstraction.

Carving Out the Boundaries
With the features identified, the next step is to define the boundaries of each bundle. A bundle, much like the ancient temples, should be dedicated to a single deity, or in this case, a single feature. It should encompass all that is necessary for its function and nothing more. This is the principle of cohesion—a bundle should be self-contained, a microcosm of functionality.

The Structure of Sanctity
As you craft your bundle, adhere to the sacred structure recommended by Symfony:

Entities: The heart of your bundle, where the essence of your feature is modeled. Repositories: The oracles, through which the knowledge of your entities is queried.
Services: The priests, interpreting the divine logic of your domain.
Controllers: The messengers, conveying requests and responses to and from the mortal realm. Configuration: The scriptures, allowing the mortals to customize the divine will.
Tests: The trials, ensuring the deity's will is pure and uncorrupted.
Flexibility and Configurability

A bundle must be as the willow, flexible in the wind. Provide means for the mortals to configure it, to bend its functionality to their will without breaking it. Use configuration files and expose extension points. Let others extend the reach of your bundle through events and dependency injection.

The Chronicles of Documentation
Documentation is the map to the treasure, the guide through the labyrinth. Without it, the mortals are lost. Detail the installation, provide examples of usage, enumerate configuration options, and describe how to extend the bundle. Your words will light the path for others to follow.

The Art of Decoupling
A bundle should stand alone, a citadel on a hill. It should not depend on the villages below for its survival. Use interfaces and dependency injection to manage dependencies, ensuring that your bundle can be lifted and placed into another project without upheaval.

The Ritual of Distribution
When your bundle is ready, release it into the wild. Use version control and consider publishing it on Packagist. Embrace semantic versioning to communicate your changes to the world. Let the continuous integration spirits test your bundle, ensuring its purity remains untainted.

An Example for the Ages
Let us consider some examples:

Example 1: Logging Bundle

Purpose: A bundle dedicated to logging activities across your Symfony projects. It can offer configurable log formats, handlers, and processors.

Components:

Entity: Log entries that can be stored in a database.
Services: A logging service that abstracts the logic of writing logs, potentially supporting different levels of logging (info, warning, error) and different storage mechanisms (file, database).
Configuration: Options for setting the log level, log format, and the choice of handler (e.g., Monolog).
Tests: Unit and integration tests to ensure the logging mechanism works as expected under various conditions.

Flexibility: Through extension points, allow other bundles or applications to define custom log processors or handlers.

Example 2: E-commerce Bundle

Purpose: A bundle to add e-commerce capabilities, including product management, cart operations, and order processing.

Components:

Entities: Products, Carts, Orders, and related models.
Repositories: To manage data retrieval and manipulation for the e-commerce entities.
Services: Business logic for cart operations, order processing, payment integration, and inventory management.
Controllers: Endpoints for product listing, cart management, checkout process, and order tracking.
Configuration: Customizable settings for payment gateways, tax calculation, shipping options, and currency formats.
Tests: Comprehensive tests to ensure reliability and security of the e-commerce transactions and data integrity.

Flexibility: Offer hooks and events for integration with payment gateways, shipping services, and external inventory systems.

Example 3: API Bundle

Purpose: A bundle to facilitate the creation and management of RESTful APIs, providing tools for request validation, response formatting, and API versioning.

Components:

Services: API response builder, request validator, and version management.
Controllers: Base controller with common functionalities like response formatting and error handling.
Configuration: Settings for API versioning, default response formats, and security policies (e.g., API keys, OAuth).
Tests: Tests to ensure API endpoints adhere to the specified request and response formats and handle errors gracefully.

Flexibility: Configuration options for enabling CORS, defining API rate limits, and selecting serialization groups for different API versions.

Example 4: Notification Bundle

Purpose: A bundle to handle notifications across various channels (email, SMS, push notifications) with a unified interface.

Components:

Services: Notification sender service that abstracts the complexity of sending notifications through different channels.
Configuration: Options to configure different notification channels, templates, and default settings for each type of notification.
Tests: Ensure that notifications are sent correctly and fallback mechanisms work in case of failures with any channel.

Flexibility: Allow developers to extend the bundle by adding custom notification channels and integrating with third-party services.

Conclusion
The way of the bundle is a path of wisdom, of foresight. It is the understanding that what we create today should stand the test of time, should be a beacon for those who come after us. In the vast landscapes of Symfony, let your code be a testament to the art of reuse, a series of bundles, each a masterpiece of functionality. This is the way of the bundle, the path to enlightenment in the realm of Symfony. Walk it with pride, young apprentice, and let your code illuminate the darkness.

Laravel Sail & XDebug

AndersonPEM — Wed, 26 Apr 2023 11:01:44 +0000

Sailing on turbulent waters

Laravel Sail is a project focused on giving developers a dockerized environment without hassling with the internals of Docker.

I've been in contact with this project for some days and found it incredibly frustrating making XDebug work properly on PHPStorm.

Me being the Docker nerd I am, I started to mess with Sail's Docker image to make it work.

Why?

There are 2 kinds of developers:

The ones who use dd or console.log() to debug and
The ones who use debugging tools.

In my years of experience, the latter usually makes debugging faster and comprehensible. You can walk through the code line by line, inspect memory, check if conditionals are working, it has saved me days of headaches.

Okay, what's wrong with my Sail?

It seems like Sail's default config does not ship (pun intended) proper XDebug configuration for some environments (in my case, the env variables did not work at all). So, if you're not able to make it work the default way, come with me. Let's dew it.

Getting your hands dirty

Create a file called 20-xdebug.ini somewhere in your project. You can create a folder called docker, for example and add it to your .gitignore, so you don't commit config to your repository.

We are going to add a path mapping to the application container in docker-compose.yml

Considering you have added the file 20-xdebug.ini to a folder called Docker, add the following volume to your container:

- './docker/20-xdebug.ini:/etc/php/8.1/cli/conf.d/20-xdebug.ini'

(I assumed you're using PHP 8.1. If not, change the path version accordingly)

This command will map the file on your computer to PHP's XDebug config.

The file contents is as follows:

zend_extension=xdebug.so
[xdebug]
xdebug.start_with_request=yes
xdebug.discover_client_host=true
xdebug.max_nesting_level=256
xdebug.remote_handler=dbgp
xdebug.client_port=9003
xdebug.idekey=Docker
xdebug.mode=develop,debug
xdebug.client_host=host.docker.internal

This file sets the PHP to some default debug behaviors, like:

Set the port of XDebug to 9003 (9000 might be busy with PHP-FPM or Node applications)
Starts debugging with request
Sets an IDE key, which is useful for PHPStorm's debug configuration
Sets the client host to the gateway (your computer)

Among others :)

Now let's configure PHPStorm.

In the upper right corner, click on the debug options. Then on 'Edit configurations'

You'll be presented with a dialog. Click on add new configuration.

Choose the option PHP Remote debug

Give your debug config a name

Now click on 'Filter debug connection by IDE key' and click on the triple dot button of the servers option to add a new server.

Name your server Docker. To the host, add either 0.0.0.0 or localhost

Make sure to map your project's root directory to the container's /var/www/html.

Click OK. Then, on the previous dialog select the Docker server. Also, add the Docker IDE session key.

Click OK and you're likely set to go.

Select your Docker configuration for debug, and mind this icon:

When it's all green, it's listening to debug connections. If it's red, it's not listening. In this case, no breakpoints will be triggered.

Click on it to make it green.

You should be able to breakpoint through the project when you go sail up.

Some caveats

There's a default config of PHPStorm that really bothers me. For example, when you start a container, the routines executed firstly trigger the debugger without me asking for it.

To avoid this, go to PHPStorm's settings, then go in PHP>Debug.

Set it as following:

This will avoid accidental triggering of the debugger, for example, when the PHP server is starting. If it's not allowed to start, the process will hang, and you won't be able to run pages.

If you suspect there might be path mapping issues, tick back the 'Force break at first line if no path mapping is specified' option to check if you need to map something else. Then, untick it, because it can get pretty annoying.

That's it for today, kids.