DEV Community: UBA-code

Cloud-1: How I Automated a Full Cloud Deployment with Ansible and Docker

UBA-code — Wed, 01 Apr 2026 15:41:28 +0000

Zero manual SSH sessions. Zero hand-typed commands. One ansible-playbook call and the whole stack is live.

A Little Context

As part of my job, spinning up cloud VMs and deploying web applications is routine. But the mandate for my latest project, Cloud-1, was to take this a step further and automate absolutely everything. No clicking around in a dashboard, no executing commands by hand on the server. The entire deployment pipeline had to be flawlessly scripted and repeatable.

The result is a clean DevOps project that touches Ansible, Docker Compose, Nginx, Certbot (Let's Encrypt), DuckDNS, and automated certificate renewal. In this post I'll walk through the design and the most interesting implementation details.

The Architecture at a Glance

Local Machine (control node)
  │
  │  ansible-playbook
  │  ──────────────────────►  Cloud VM (Ubuntu)
  │                              │
  │                              ├─ Docker
  │                              │   ├─ WordPress
  │                              │   ├─ Nginx (reverse-proxy + SSL termination)
  │                              │   ├─ MariaDB
  │                              │   └─ Certbot (one-shot certificate issuer)
  │                              │
  │                              └─ anacron (monthly cert renewal)

Everything lives in two Ansible playbooks:

Playbook	Responsibility
`docker_playbook.yaml`	Install Docker & add the ubuntu user to the docker group
`deploy_playbook.yaml`	Clone the app repo, inject secrets, start containers, configure DNS & SSL

Step 1 — Inventory: Targeting the Servers

The inventory.ini is deliberately minimal:

[myhosts]
15.237.214.130
15.236.239.28

Two IP addresses, one group. Ansible will run every play against both hosts in parallel. Swapping servers is a one-line change.

Step 2 — Bootstrapping Docker (the `docker_playbook`)

Before we can run any containers, the host needs Docker. Rather than baking a custom AMI, the playbook installs it idempotently every time:

- name: Install Docker
  hosts: myhosts
  remote_user: ubuntu
  become: true
  tasks:
    - name: Install required system packages
      ansible.builtin.apt:
        pkg:
          - apt-transport-https
          - ca-certificates
          - curl
          - software-properties-common
          - git
          - anacron   # needed later for cert renewal
        state: latest

    - name: Add Docker GPG apt Key
      ansible.builtin.apt_key:
        url: https://download.docker.com/linux/ubuntu/gpg
        state: present

    - name: Add docker repository
      ansible.builtin.apt_repository:
        repo: "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"
        state: present

    - name: Install docker
      ansible.builtin.apt:
        name: docker-ce
        state: latest

    - name: Start & enable docker service
      ansible.builtin.service:
        name: docker
        state: started
        enabled: true

    - name: Add the current user to docker group
      ansible.builtin.user:
        name: ubuntu
        groups: docker
        append: yes

The key design choice here is idempotency — running this playbook twice won't break anything. state: latest and state: present ensure Ansible only acts when necessary.

Step 3 — Deploying the Application (the `deploy_playbook`)

This is where the magic happens. The playbook has eight logically ordered stages.

3a. Clone the App Repository

- name: Clone the repository of source files
  ansible.builtin.git:
    repo: "https://github.com/UBA-code/cloud-1-blog.git"
    dest: $HOME/site
    force: true

force: true ensures any local changes on the server are wiped and replaced with the canonical version from GitHub. The server is always in sync with the repo — no config drift.

3b. Inject Secrets Securely

- name: Copy the .env into wordpress directory
  ansible.builtin.copy:
    src: ../secrets/.env
    dest: $HOME/site

The .env file lives in a secrets/ directory on the control node (local machine) and is explicitly listed in .gitignore. It is never committed to version control. Ansible copies it to the server at deploy time — so secrets travel over SSH but never touch a git remote.

3c. Start the Containers

- name: Build and run the containers
  ansible.builtin.command:
    cmd: docker compose up --build -d
    chdir: /home/ubuntu/site
  become: yes

--build ensures any image changes are picked up. -d puts containers in detached (daemon) mode. One command brings up WordPress, MariaDB, Nginx, and Certbot simultaneously.

3d. Dynamic DNS with DuckDNS

Cloud VMs get a new IP on every boot. Hardcoding IPs in DNS is a maintenance nightmare. The solution: DuckDNS, a free dynamic DNS provider with a dead-simple API.

- name: Update DuckDNS with the new machine IP
  ansible.builtin.command: >
    curl "https://www.duckdns.org/update?domains=cloud-2&token=<token>&ip=&verbose=true"
  register: duckdns_response

- name: Print the DuckDNS response
  ansible.builtin.debug:
    msg: "{{ duckdns_response.stdout }}"

Leaving ip= empty tells DuckDNS to auto-detect the caller's public IP — perfect for ephemeral cloud instances.

To ensure the DNS stays updated across reboots, the same curl command is appended to .bashrc:

- name: Ensure DuckDNS update is added to .bashrc
  ansible.builtin.lineinfile:
    path: "$HOME/.bashrc"
    line: 'curl "https://www.duckdns.org/update?domains=cloud-2&token=<token>&ip=&verbose=true"'
    state: present
    create: yes

3e. Generating Let's Encrypt Certificates

HTTPS is non-negotiable. Certbot runs as a Docker container in one-shot mode using the webroot challenge:

- name: Generate Let's Encrypt certificates
  ansible.builtin.command:
    cmd: >
      docker compose run --rm certbot certonly
      --webroot --webroot-path=/var/www/certbot
      --email you@example.com
      --agree-tos --no-eff-email
      -d cloud-2.duckdns.org
      --non-interactive
    chdir: /home/ubuntu/site
  register: certbot_output
  become: yes
  failed_when: 'certbot_output.rc != 0 and "unauthorized" not in certbot_output.stdout'

The failed_when condition is a nice touch: if Certbot exits non-zero because the domain already has a valid certificate ("unauthorized" in Certbot parlance), Ansible doesn't fail the entire play. Idempotency again.

3f. Switching Nginx to HTTPS Mode

The deployment uses a two-phase Nginx config:

Initial config (nginx.conf) — HTTP only, serves the Let's Encrypt challenge at /.well-known/acme-challenge/.
Final config (nginx.conf.final) — Full HTTPS with SSL certs mounted as Docker volumes.

Once the certificate is issued, the playbook swaps them:

- name: Switch Nginx config to final SSL version
  ansible.builtin.shell:
    cmd: "mv nginx.conf nginx.conf.initial && mv nginx.conf.final nginx.conf"
    chdir: $HOME/site/nginx-conf/

- name: Reload Nginx
  ansible.builtin.command:
    cmd: docker compose exec nginx nginx -s reload
    chdir: /home/ubuntu/site
  when: 'certbot_output.rc == 0 and "unauthorized" not in certbot_output.stdout'

A graceful reload (nginx -s reload) applies the new config with zero downtime.

Step 4 — Automatic Certificate Renewal

Let's Encrypt certificates expire every 90 days. Forgetting to renew means a hard HTTPS outage. The solution is a tiny shell script deployed to the server and wired into anacron:

#!/bin/sh

docker compose -f /home/ubuntu/site/docker-compose.yaml \
  run --rm certbot renew > /var/log/renew_cert_log.log

Anacron (unlike cron) is designed for machines that aren't always on — it catches up on missed jobs. The playbook registers a weekly renewal task:

- name: Add certbot renew task to anacron
  ansible.builtin.lineinfile:
    path: /etc/anacrontab
    line: "7  1 cron.renew_task /home/ubuntu/renew_certificate.sh"
    state: present
  become: true

The 7 means the job runs if it hasn't run in the last 7 days. The logfile at /var/log/renew_cert_log.log captures every renewal attempt for easy debugging.

Project Structure

cloud-1/
├── .gitignore               # Excludes secrets/.env
├── inventory.ini            # Target hosts
├── playbooks/
│   ├── docker_playbook.yaml # Bootstrap Docker on hosts
│   └── deploy_playbook.yaml # Full application deployment
├── scripts/
│   └── renew_certificate.sh # SSL cert auto-renewal
└── secrets/
    └── .env.example         # Template — copy to .env and fill in values

Running It

# 1. Configure your servers
vi inventory.ini

# 2. Set up your secrets
cp secrets/.env.example secrets/.env
vi secrets/.env

# 3. Bootstrap Docker on the servers (only needed once)
ansible-playbook -i inventory.ini playbooks/docker_playbook.yaml

# 4. Deploy the full application
ansible-playbook -i inventory.ini playbooks/deploy_playbook.yaml

That's it. A few minutes later, WordPress is live at https://cloud-2.duckdns.org with a valid Let's Encrypt certificate and automatic renewal configured.

Key Takeaways

Infrastructure as Code pays off immediately. When a server was wiped and re-provisioned, bringing it back up was a single command instead of an hour of manual work.

Idempotency is not optional. Every task was written so re-running the playbook is safe. state: present, state: latest, lineinfile with duplicate detection — these aren't conveniences, they're correctness requirements.

Secrets management is simple but effective. No Vault, no KMS at this scale. The pattern of keeping secrets local and copying them over SSH is good enough for most small projects and dramatically reduces the attack surface compared to committing .env files.

Two-phase Nginx config solves the chicken-and-egg SSL problem. You need HTTP available to issue the certificate, but you want HTTPS everywhere after. The swap trick elegantly handles this without a complex conditional setup.

What's Next

A few natural extensions for anyone picking up this project:

CI/CD integration — Trigger deploy_playbook.yaml from a GitHub Actions workflow on every push to main
Monitoring — Add a Prometheus + Grafana stack as additional Docker Compose services
Load balancing — Add more hosts to inventory.ini and put Nginx (or an AWS ALB) in front of them
Backup automation — Dump the MariaDB database and upload it to S3 on a schedule

Cloud-1 is a 42 School project. The full source is on GitHub.

🍿 Hypertube: Building a Netflix-Inspired Streaming App Powered by BitTorrent

UBA-code — Sun, 29 Mar 2026 21:22:10 +0000

What if you could build your own Netflix — without any licensing deals, content budgets, or monthly subscription fees? That was the challenge behind **Hypertube.

The Idea

Streaming platforms have conditioned us to expect instant, high-quality video — but that experience is expensive to build and expensive to maintain. What if the same seamless experience could be delivered using peer-to-peer technology that's been around for decades?

Hypertube is a full-stack web application that does exactly that. It's a modern, dark-mode streaming platform — aesthetically inspired by Netflix — that uses BitTorrent to source and stream movies directly inside your browser. No subscriptions. No ads. No waiting for downloads to finish.

What Hypertube Can Do

The application brings together a full cinematic experience:

🔍 Advanced Search — Filter thousands of movies by quality, genre, and rating across multiple torrent sources
▶️ Instant Streaming — Start watching in seconds with smart buffering. The video plays while it downloads in the background
🌐 Multi-language Subtitles — Dozens of subtitle languages, auto-synced to the video
💬 Community Features — Comment on films, discuss your favorites, and connect with other cinephiles
🔐 Flexible Authentication — Log in with GitHub, Google, GitLab, Discord, or 42 — or just use email

Authentication: Five OAuth Providers and Email

The sign-in flow was built with real-world security in mind. Users can authenticate via five different OAuth2 providers or a classic email/password flow — all handled through Passport.js strategies on the NestJS backend.

Access tokens are short-lived and JWTs are revoked on logout through a dedicated revoked-tokens module, preventing token replay attacks.

Browsing: A Cinematic Movie Grid

The main browsing experience presents movies in a rich poster grid — sorted by popularity, rating, or genre. Each card shows the movie's quality badge, IMDb rating, and release year at a glance. The interface feels instantly familiar thanks to its dark-mode Netflix-like design, built with React, TypeScript, and Tailwind CSS.

Filtering and searching happen in real time, with query results pulled from multiple torrent sources and enriched with metadata from public movie APIs.

Movie Details: Everything at a Glance

Every movie gets its own dedicated page with:

Full synopsis, cast, and director info
Available quality options (720p, 1080p, etc.)
Subtitle language selector
A one-click Stream Now button

The detail page fetches metadata and torrent magnet links simultaneously, so by the time you hit play, everything is ready.

The Magic: BitTorrent Meets HLS Streaming

This is where Hypertube gets genuinely interesting from an engineering perspective.

Traditional streaming services encode videos into HLS segments and serve them from CDNs. Hypertube does something different: it downloads the torrent file on-demand on the server, pipes the video data through FFmpeg for real-time transcoding, and serves it as an HLS stream to the browser.

Here's the flow:

User clicks "Play"
       ↓
Backend resolves torrent → starts downloading in-memory
       ↓
FFmpeg transcodes incoming bytes → .m3u8 + .ts segments
       ↓
Browser loads HLS playlist → video plays instantly
       ↓
Download continues in background while you watch

The result is a zero-wait streaming experience backed by the BitTorrent network — no file storage required, no CDN bill.

Community: Comments & Discussions

Hypertube isn't just a player — it's a community. Each movie has a threaded comment section where users can discuss the film, share thoughts, and leave ratings. Comments are tied to authenticated accounts, keeping discussions meaningful.

Watch History: Never Lose Your Place

Every movie you stream is automatically logged to your watch history. You can resume from where you left off, revisit favorites, and track your watching habits — all without any manual bookmarking.

Tech Stack Deep Dive

Hypertube is a modern full-stack application split cleanly into two services:

🖥️ Frontend

Technology	Purpose
React + TypeScript	UI components and type safety
Tailwind CSS	Utility-first styling
Vite	Lightning-fast dev server and bundler
React Router	Client-side routing
React Icons	Icon library

⚙️ Backend

Technology	Purpose
NestJS (TypeScript)	Modular REST API framework
Passport.js	OAuth2 + JWT authentication strategies
FFmpeg	Real-time video transcoding
HLS	Adaptive HTTP video streaming
Swagger	Auto-generated API documentation

🐳 Infrastructure

Both the frontend and backend are fully Dockerized, with separate docker-compose configurations for development and production. This makes the entire stack reproducible with a single command:

docker-compose up --build

Architecture Overview

┌─────────────────────────────────────────┐
│              React Frontend              │
│     (Vite + TypeScript + Tailwind)      │
└──────────────────┬──────────────────────┘
                   │ REST API / HLS
┌──────────────────▼──────────────────────┐
│             NestJS Backend               │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ │
│  │  Auth   │ │  Movies  │ │ Comments │ │
│  │ Module  │ │  Module  │ │  Module  │ │
│  └─────────┘ └────┬─────┘ └──────────┘ │
│              ┌────▼─────┐               │
│              │ Torrent  │               │
│              │  Module  │               │
│              └────┬─────┘               │
│              ┌────▼─────┐               │
│              │  FFmpeg  │               │
│              │ (HLS out)│               │
│              └──────────┘               │
└─────────────────────────────────────────┘

The backend is cleanly separated into NestJS modules: auth, movies, comments, torrent, users, and mails — making the codebase easy to navigate and extend.

Lessons Learned

Building Hypertube touched on some genuinely tricky engineering problems:

Streaming before the download completes — The hardest part was piping torrent data through FFmpeg fast enough that the HLS playlist stays ahead of the playback position.
OAuth across five providers — Each OAuth provider has subtle differences. Passport.js strategies abstract most of it, but edge cases (like handling missing email fields from some providers) required custom logic.
Token revocation with JWTs — JWTs are stateless by nature. Implementing a revoked-tokens store means the backend must check every request against it — a trade-off between security and performance.
Responsive dark-mode UI — Getting the poster grid, player, and detail pages to feel premium across all screen sizes required careful Tailwind component design.

Try It Yourself

Hypertube is open source. If you want to run it locally:

# Clone the repository
git clone https://github.com/UBA-code/hypertube

# Fill in your OAuth credentials
cp .env.preview .env.dev

# Start everything with Docker
docker-compose up --build

The frontend runs at http://localhost:5173 and the API at http://localhost:3000/api (with Swagger docs included).

Final Thoughts

Hypertube is a proof of concept that modern streaming UX doesn't require a billion-dollar infrastructure budget. By combining BitTorrent's decentralized network with server-side HLS transcoding via FFmpeg, the app delivers a genuinely responsive streaming experience built entirely on open-source technology.

It was a challenging project — touching OAuth, real-time video processing, peer-to-peer networking, and modern frontend design all at once — but the end result is something that actually works and looks great doing it.

If you found this interesting, feel free to ⭐ the repo and share your thoughts in the comments below.

Built with ❤️ using React, NestJS, FFmpeg, and BitTorrent.

Building Taskmaster: A Go-Powered Process Supervisor from Scratch

UBA-code — Tue, 24 Mar 2026 20:46:54 +0000

How two 42 School students reimagined process management with Go's concurrency model

If you've ever managed a production server, you know the pain: a critical process crashes at 3 AM, no one notices until morning, and your users are left with a broken experience. Tools like Supervisor were built to solve this — but they come with Python overhead, complex configurations, and aging architectures.

We decided to build our own. Taskmaster is a lightweight, production-ready process supervisor written in Go — and building it taught us more about operating systems, concurrency, and daemon design than any textbook could.

What Is Taskmaster?

Taskmaster is a process control daemon. It manages the full lifecycle of your processes — starting, stopping, restarting, and monitoring them — all through a simple interactive shell. Think of it as a modern, Go-native alternative to Supervisor or systemd service management, without the complexity.

$ ./bin/taskmaster config.yaml
Taskmaster> status
Task          Status    PID    Uptime       Restarts  Command
nginx         RUNNING   1234   2m15s        0         /usr/local/bin/nginx
worker_1      RUNNING   1235   2m15s        1         python3 worker.py
worker_2      STOPPED   -      -            0         python3 worker.py

Taskmaster> start worker_2
Process 'worker_2' started with PID 1240

Taskmaster> logs worker_1 5
[2026-02-02 10:15:25] Processing task #1
[2026-02-02 10:15:26] Task completed
[2026-02-02 10:15:27] Waiting for tasks...

A single YAML file to configure everything. A single binary to run it.

Why Go?

The choice of Go wasn't arbitrary. Process supervision is inherently concurrent — you need to monitor dozens of processes simultaneously without blocking. Traditionally, this is solved with threads and shared memory, which leads to complex locking, race conditions, and hard-to-debug crashes.

Go offers a better model: goroutines and channels.

Goroutines are lightweight (a few KB of stack vs. MB for threads) and can be spawned in the thousands without issue.
Channels provide safe, structured communication between concurrent components — no mutexes, no shared state hell.

This aligned perfectly with our architecture: one goroutine per managed process, communicating via channels. Elegant, efficient, and easy to reason about.

Architecture Deep Dive

The High-Level Picture

┌─────────────────────────────────────────────────────────────┐
│                        Main Process                          │
│  ┌──────────────┐  ┌─────────────┐  ┌──────────────────┐   │
│  │   CLI Loop   │  │   Config    │  │  Signal Handler  │   │
│  │  (readline)  │  │   Parser    │  │    (SIGHUP)      │   │
│  └──────────────┘  └─────────────┘  └──────────────────┘   │
└─────────────────────────────────────────────────────────────┘
                            │
                ┌───────────┴───────────┐
                │    Task Manager       │
                └───────────┬───────────┘
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
   ┌────▼────┐         ┌────▼────┐        ┌────▼────┐
   │ Process │         │ Process │        │ Process │
   │ Monitor │   ...   │ Monitor │        │ Monitor │
   │(gorout.)│         │(gorout.)│        │(gorout.)│
   └────┬────┘         └────┬────┘        └────┬────┘
        │                   │                   │
   ┌────▼────┐         ┌────▼────┐        ┌────▼────┐
   │  Child  │         │  Child  │        │  Child  │
   │ Process │         │ Process │        │ Process │
   └─────────┘         └─────────┘        └─────────┘

The main process runs the interactive CLI (using the readline library for history and completion) and listens for system signals. It owns a Task Manager which holds the state of all configured processes. Each managed process gets its own goroutine — a StartTaskManager — that is entirely responsible for that process's lifecycle.

Goroutine per Process

Each StartTaskManager goroutine does three things independently:

Listens for control commands over a buffered channel (CmdChan)
Monitors the child process for exits and unexpected crashes
Handles restarts based on the configured policy

Because each process is isolated in its own goroutine, a crash or slowdown in one process monitor cannot affect others. The system stays responsive even when managing hundreds of processes.

Channel-Based Communication

The CLI never directly kills or starts a process. Instead, it sends a message over a channel:

CLI ──── "stop nginx" ───► nginx's CmdChan ──► goroutine acts on it

This decoupling means the CLI remains non-blocking regardless of how long a process takes to shut down. The goroutine handles timeouts, fallback signals, and cleanup entirely on its own.

Three channel types power the system:

Command Channels — carry control messages (start, stop, restart)
Done Channels — signal that a child process has exited
Timeout Channels — implement deadlines for startup grace periods and graceful shutdowns

Process State Machine

Every process moves through a well-defined set of states:

[STOPPED] → start → [STARTED] → (after successfulStartTimeout) → [RUNNING]
                        │
                        └─ unexpected exit ──► [FATAL]
                                                   │
                                         restart policy applies

STOPPED: Not running (intentionally or not yet started)
STARTED: Running but in the startup grace period
RUNNING: Confirmed healthy and past the startup timeout
FATAL: Crashed and restart attempts exhausted

The successfulStartTimeout parameter is a key reliability feature. A process that starts and immediately crashes is different from one that runs for 30 seconds before failing — Taskmaster treats them differently.

Configuration: Simple and Expressive

Taskmaster tasks are defined in a single YAML file. Here's a real-world example managing a web server and a pool of background workers:

tasks:
  web_server:
    command: "/usr/local/bin/nginx -g 'daemon off;'"
    instances: 1
    autoLaunch: true
    restart: on-failure
    expectedExitCodes: [0]
    successfulStartTimeout: 3
    restartsAttempts: 3
    stopingSignal: SIGTERM
    gracefulStopTimeout: 10
    stdout: /var/log/taskmaster/nginx.out.log
    stderr: /var/log/taskmaster/nginx.err.log
    environment:
      PORT: "8080"
      ENV: "production"
    workingDirectory: /var/www

  worker:
    command: "python3 worker.py"
    instances: 5
    autoLaunch: true
    restart: always
    restartsAttempts: 5
    gracefulStopTimeout: 15
    stdout: /var/log/taskmaster/worker.out.log
    stderr: /var/log/taskmaster/worker.err.log

A few things worth highlighting:

instances: 5 — Taskmaster automatically spawns 5 copies of worker.py and names them worker_1 through worker_5. You manage them individually or all at once with restart all.

restart: on-failure vs restart: always — The distinction matters in production. on-failure only restarts if the exit code isn't in expectedExitCodes. An intentional exit(0) won't trigger a restart. always is for long-running daemons that should never stop.

gracefulStopTimeout: 15 — When you issue a stop, Taskmaster sends the configured signal and waits up to 15 seconds for a clean exit. If the process hasn't stopped, it gets SIGKILL. No zombie processes.

Hot Reload: Zero-Downtime Config Changes

One of the features we're most proud of: you can change your configuration file and apply it without restarting the daemon or killing your processes.

Taskmaster> reload
Configuration reloaded.

Under the hood, this sends a SIGHUP signal (or you can do it from outside with kill -HUP <pid>). The config parser re-reads the YAML, diffs it against the current state, and applies changes incrementally. New tasks get started; removed tasks get stopped; modified tasks get restarted. Running tasks that haven't changed? They keep running, untouched.

Signal Propagation and Graceful Shutdown

Getting shutdown right is tricky. We had to handle:

The daemon receiving SIGTERM (e.g., from the OS on shutdown)
Propagating the right signal to each child process
Waiting for all children to exit before the daemon itself exits

We used Go's sync.WaitGroup for this. Every goroutine registers itself with a global WaitGroup before starting, and signals done when it exits. The main process waits on this group before terminating — guaranteeing that no child processes are left orphaned.

// Simplified version of the shutdown flow
tasks.WaitGroup.Wait() // Block until all process monitors are done
os.Exit(0)

Key Takeaways

Building Taskmaster from scratch gave us a deep appreciation for:

1. Go's concurrency model is genuinely different. Not just syntactically different from threads — conceptually different. "Don't communicate by sharing memory; share memory by communicating" isn't just a motto. It's a design philosophy that produces cleaner, more correct code.

2. UNIX process management is a deep topic. Process groups, session leaders, signal inheritance, file descriptor leaks, zombie processes — every one of these is a footgun waiting to go off. We hit most of them.

3. Small surface area wins. Taskmaster has one config file, one binary, and one shell. No agents, no web UIs, no databases. This simplicity makes it auditable, embeddable, and easy to debug.

Try It Yourself

Taskmaster is open source and available on GitHub:

git clone https://github.com/UBA-code/taskmaster.git
cd taskmaster
make build
./bin/taskmaster  # Generates an example config and starts the shell

If you're building something in Go that needs process management, or if you're curious about how supervisors work under the hood, we hope Taskmaster serves as a useful reference.

Built with ❤️ by Yassine Bel Hachmi and Hassan Idhmmououhya as part of the 42 School curriculum.

⭐ Star the repo if you find it useful!

DEV Community: UBA-code

Cloud-1: How I Automated a Full Cloud Deployment with Ansible and Docker

A Little Context

The Architecture at a Glance

Step 1 — Inventory: Targeting the Servers

Step 2 — Bootstrapping Docker (the docker_playbook)

Step 3 — Deploying the Application (the deploy_playbook)

3a. Clone the App Repository

3b. Inject Secrets Securely

3c. Start the Containers

3d. Dynamic DNS with DuckDNS

3e. Generating Let's Encrypt Certificates

3f. Switching Nginx to HTTPS Mode

Step 4 — Automatic Certificate Renewal

Project Structure

Running It

Key Takeaways

What's Next

🍿 Hypertube: Building a Netflix-Inspired Streaming App Powered by BitTorrent

The Idea

What Hypertube Can Do

Authentication: Five OAuth Providers and Email

Browsing: A Cinematic Movie Grid

Movie Details: Everything at a Glance

The Magic: BitTorrent Meets HLS Streaming

Community: Comments & Discussions

Watch History: Never Lose Your Place

Tech Stack Deep Dive

🖥️ Frontend

⚙️ Backend

🐳 Infrastructure

Architecture Overview

Lessons Learned

Try It Yourself

Final Thoughts

Building Taskmaster: A Go-Powered Process Supervisor from Scratch

What Is Taskmaster?

Why Go?

Architecture Deep Dive

The High-Level Picture

Goroutine per Process

Channel-Based Communication

Process State Machine

Configuration: Simple and Expressive

Hot Reload: Zero-Downtime Config Changes

Signal Propagation and Graceful Shutdown

Key Takeaways

Try It Yourself

Step 2 — Bootstrapping Docker (the `docker_playbook`)

Step 3 — Deploying the Application (the `deploy_playbook`)