Deploying machine learning models is more than just training — it’s about tracking, versioning, serving, and monitoring. In this post, I’ll walk you through how I built a production-ready ML pipeline using:

• MLflow for experiment tracking and model registry
• FastAPI for serving models via REST API
• MinIO for artifact storage (S3-compatible)
• Docker Compose for orchestration

👉 Full source code:
🔗 github.com/liviaerxin/mlops-fastapi-mlflow-minio

What's workflow in Celery?

In Celery, workflow is composed of multiple tasks, and a task is deemed to be a universal unit of the workflow, as a function in the program. In Celery, it's recommended to divide a long-running task into multiple short-running tasks. workflow comes out to help ease the orchestrations of the work, such as chain() three tasks.

A demo workflow

For small projects or self-hosted apps, using a full-fledged CI/CD tool like GitHub Actions or Jenkins can be overkill. What if you could have automated deployments without any third-party service, and all you need is Git and SSH?

In this post, we’ll walk through setting up a lightweight, no-cost CI/CD pipeline using Git hooks and Docker Compose, with deployments triggered by a simple git push to your production server.

Capturing HTTPS traffic from an Android device can be a crucial aspect of testing and debugging applications. Additionally, gaining insight into decrypted HTTPS messages can offer valuable information for troubleshooting or security analysis, albeit with ethical considerations in mind. Here, we explore two methods to achieve this: via an HTTPs proxy or a VPN.

In real life, when we build our website and make it public, some paid or free Certificate Authority (CA) will help us sign a certificate for our website domain (IP address is not acceptable!) and enable SSL/TLS connections from user browser to our server.

Given the secure reasons, the browser will only admit those servers's certificates signed from the authorized CA, and the CA certificate is kept in our host system trust store. In Linux, you can view the CA certificate file like /etc/ssl/certs/ca-certificates.crt.

However, in many internal networks and development environments, we often need self-signed certificate more frequently.

Here is an example, we will generate a local server certificate that is signed by a local CA. Finally, let Chrome can visit our local website without security warning.

In brief, these steps we need to sign local sever certificate actually simulate how those CA sign certificates for public servers, as following:

1. Create a local Root CA.
2. Create a CSR(Certificate Signing Request) file for local server 127.0.0.1.
3. The local Root CA use the local server 127.0.0.1 CSR to generate a certificate.
4. Install the local Root CA into our system(Windows, Ubuntu or macOS) trust store.
5. Run a simple https server to test local server certificate.

For those official CA, they have to validate the domain is owned by the server before the step 3, and we can ignore step 4 as they are already installed into the system or the browser trust store.

And there is nice picture from How to create your own self-signed root Certificate Authority(CA) to show the relationship between CA, server and browser.

For viewing the content of the ISO image file like *.iso, we can mount it to filesystem and loop up its contained files.

Mounting the ISO image file in linux is much easier than doing in macOS. Because ISO use ISO9660 file system while the hdiutil in macOS does not support it originally. That will require more steps to implement in comparison with one command like mount in Linux.

How to mount iso image in Linux

osx - Can a Mac mount a Debian install CD? - Unix & Linux Stack Exchange

Concepts:

• Show shared libraries dependencies(detect what shared libraries an executable or a another shared libraries depend on)
• Check/Test dependent shared libraries loaded successfully

Here, I will employ QEMU to emulate a minimal Linux x86_64 platform with a minimal root filesystem from scratch, as well as debugging with GDB:

• Build Linux x86_64 kernel
• Build Linux x86_64 rootfs(root filesystem)
• Run QEMU
• Debug with GDB

Why do I use QEMU to boot Linux kernel directly with skipping BIOS/UEFI boot procedures?

Use QEMU to launch a Linux kernel directly without having to make a fully bootable disk image. This is very useful for:

• Linux kernel testing
• root filesystem testing
• arm system emulation

In this blog, QEMU is employed to emulate Raspberry Pi 3/4 in mac M1 host(it's also supposed to work in Windows/Linux with a little tweak). I will demonstrate two different ways to emulate Raspberry Pi 3 and Raspberry Pi 4 in respect. These two ways are different by using different QEMU machines as you would like to use:

1. -machine raspi3b: raspberry pi 3b machine to emulate Raspberry Pi 3.
2. -machine virt: general arm machine to emulate Raspberry Pi 4.

For both of these two, we still need prepare some common steps before running QEMU:

• Extract the appropriate kernel, device tree or root filesystem

Cross Compilation Anatomy​

Cross-Compilation ecosystem involves the following components:

• host system
  • cross-Compilation toolchain
    • cross compiler
    • cross linker
    • cross debugger
    • sysroot
      • target system library files
      • target system header files
      • target system other files
• target system