In een wereld vol DHCP-adressen is externe toegang tot je pc of server thuis een gedoe. Heb je een provider die je een dynamisch publiek IP-adres toewijst, dan heb je een probleem: je IP verandert regelmatig, en daarmee breekt de verbinding met je apparaat thuis via een statisch domein.

Dit gratis Dynamic DNS (DDNS) updater script voor TransIP lost dat op. Het actualiseert je DNS-records zodra je externe IP verandert, zodat je domein (bijv. vpn.example.com) altijd naar het juiste IP wijst. Dit script is een must voor iedereen die TransIP’s DNS-diensten gebruikt.

Belangrijkste features van het script

1. Geautomatiseerde DNS-updates:
   • Controleert automatisch je huidige externe IP en vergelijkt dat met het DNS A-record van je domein.
   • Maakt het A-record aan of werkt het bij zodat het overeenkomt met je nieuwste externe IP.
2. Dynamic DNS voor dynamische IP’s:
   • Ideaal voor situaties waarin je publieke IP regelmatig verandert, zoals een internetverbinding thuis met dynamische DHCP-toewijzing.
3. Veilige authenticatie:
   • Gebruikt TransIP’s API met een private key voor veilige communicatie.
   • Genereert kort geldige tokens voor extra veiligheid (maximaal 10 minuten per sessie).
4. Aanpasbare instellingen:
   • Configureer eenvoudig domein, subdomein, TTL (time-to-live) en logging.
   • Pas het script aan naar je eigen wensen.
5. Logging en foutafhandeling:
   • Uitgebreide logging houdt elke stap van het updateproces bij.
   • Ingebouwde foutafhandeling voor een soepelere uitvoering en makkelijker debuggen.

Hoe het werkt

1. Initiële setup:
   • Maak een TransIP-account aan en genereer een private key voor API-toegang op https://www.transip.nl/cp/account/api/
   • Configureer het script met je domeinnaam, subdomein en het pad naar je private key.
2. Extern IP ophalen:
   • Het script haalt je huidige externe IP op via een publieke API zoals ipinfo.io.
3. Token genereren:
   • Genereert een kort geldig access token via TransIP’s authenticatie-endpoint.
4. DNS-record controleren:
   • Controleert of het huidige DNS A-record overeenkomt met je externe IP.
   • Verschilt het, dan werkt het script het record bij; ontbreekt het, dan maakt het een nieuw aan.
5. DNS updaten:
   • Gebruikt TransIP’s beveiligde API om het DNS A-record bij te werken of aan te maken met je huidige externe IP.
6. Logging en meldingen:
   • Logt elke stap en geeft duidelijke meldingen als er iets misgaat.

Vereisten

Voordat je het script gebruikt, zorg dat je het volgende hebt:

1. Een TransIP-account met API-toegang ingeschakeld.
2. Een geregistreerd domein in je TransIP-account.
3. Een statische private key voor veilige API-authenticatie.
4. De benodigde dependencies op je systeem:
   • curl, openssl en jq.

sudo apt update
sudo apt install -y curl openssl jq

Waarom deze oplossing?

In tegenstelling tot betaalde externe DDNS-providers geeft dit script je gratis controle over je eigen DNS-beheer, met privacy en zonder vendor lock-in. Het is op maat gemaakt.

#!/bin/bash

# Configuration settings
LOGIN_NAME="your-login-name"  # Fill in your TransIP login name
PRIVATE_KEY_PATH="/path/transip_private_key.pem"  # Path to your private key file
AUTH_URL="https://api.transip.nl/v6/auth"
TOKEN_FILE="/var/tmp/transip_token.json"  # File to store token and expiration date
DOMAIN="example.com"  # Your main or test domain
SUBDOMAIN="vpn"  # The subdomain you want to update (e.g., test.example.com)
RECORD_TYPE="A"
TTL=60  # Time-to-live for DNS records
LOG_FILE="/var/log/transip_dyndns.log"

# Function to update a log file
log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" > $LOG_FILE
}

# Function to log an error and stop the script
handle_error() {
    log_message "ERROR: $1"
    echo "ERROR: $1" >&2
    exit 1
}

# Function to obtain a new access token with a short validity period (10 minutes)
generate_new_token() {
    log_message "Generating a new token with a validity period of 10 minutes."
    NONCE=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 16)
    TIMESTAMP=$(date +%s)
    LABEL="Set DNS to external DHCP $TIMESTAMP"
    REQUEST_BODY=$(printf '{"login":"%s","nonce":"%s","read_only":false,"expiration_time":"10 minutes","label":"%s","global_key":true}' "$LOGIN_NAME" "$NONCE" "$LABEL")
    log_message "Request Body: $REQUEST_BODY"
    SIGNATURE=$(echo -n "$REQUEST_BODY" | openssl dgst -sha512 -sign "$PRIVATE_KEY_PATH" | base64 | tr -d '\n')
    log_message "Generated signature: $SIGNATURE"
    RESPONSE=$(curl -s -X POST "$AUTH_URL" \
        -H "Signature: $SIGNATURE" \
        -H "Content-Type: application/json" \
        -d "$REQUEST_BODY") || handle_error "Failed to connect to TransIP API"
    log_message "API-response received: $RESPONSE"
    ACCESS_TOKEN=$(echo "$RESPONSE" | jq -r '.token // empty')
    if [ -z "$ACCESS_TOKEN" ]; then
        handle_error "The received access token is empty or invalid. Check the API-response: $RESPONSE"
    fi
    log_message "Received token: $ACCESS_TOKEN"
}

# Function to get the current DNS A-record from TransIP
get_dns_record() {
    # Get API response and store status code
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Check if response contains JSON and no errors
    if echo "$RESPONSE" | jq empty 2>/dev/null; then
        RECORD_CONTENT=$(echo $RESPONSE | jq -r '.dnsEntries[] | select(.name=="'$SUBDOMAIN'" and .type=="'$RECORD_TYPE'") | .content')
    else
        handle_error "API response does not contain valid JSON or contains an error: $RESPONSE"
    fi

    # Check if we found a valid record
    if [ -z "$RECORD_CONTENT" ]; then
        log_message "No valid DNS record found for $SUBDOMAIN.$DOMAIN. Record may need to be created."
        return 1
    fi

    echo "$RECORD_CONTENT"
    return 0
}

# Function to update or create DNS record
update_or_create_dns_record() {
    # Check if record exists
    CURRENT_DNS_IP=$(get_dns_record)

    if [ -z "$CURRENT_DNS_IP" ]; then
        log_message "No DNS A-record found for $SUBDOMAIN.$DOMAIN. Creating record."
        # Create request body for new record (TTL set to 60 seconds)
        DNS_ENTRY=$(jq -n \
        --arg name "$SUBDOMAIN" \
        --arg expire "60" \
        --arg type "$RECORD_TYPE" \
        --arg content "$CURRENT_IP" \
        '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

        log_message "DNS entry (create): $DNS_ENTRY"

        # Execute POST request to create new DNS entry with better status code handling
        RESPONSE=$(curl -s -w "%{http_code}" -X POST \
            -H "Authorization: Bearer $ACCESS_TOKEN" \
            -H "Content-Type: application/json" \
            -d "$DNS_ENTRY" \
            "https://api.transip.nl/v6/domains/$DOMAIN/dns")

        HTTP_STATUS_UPDATE=$(echo "$RESPONSE" | tail -n1)
        RESPONSE_BODY=$(echo "$RESPONSE" | head -n -1)

        log_message "API response for creating DNS entry: $RESPONSE_BODY"
        log_message "HTTP status code received for creation: $HTTP_STATUS_UPDATE"

        if [ "$HTTP_STATUS_UPDATE" -ne 201 ]; then
            handle_error "API call for creating DNS entry failed with status code $HTTP_STATUS_UPDATE."
        fi

        log_message "New DNS A-record successfully created."
    else
        log_message "Updating DNS A-record for $SUBDOMAIN.$DOMAIN to IP $CURRENT_IP"
        # Create request body for updating the record
        DNS_ENTRY=$(jq -n \
        --arg name "$SUBDOMAIN" \
        --arg expire "$TTL" \
        --arg type "$RECORD_TYPE" \
        --arg content "$CURRENT_IP" \
        '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

        log_message "DNS entry (update): $DNS_ENTRY"

        # Execute PATCH request to update the existing DNS record
        RESPONSE=$(curl -s -w "%{http_code}" -X PATCH \
            -H "Authorization: Bearer $ACCESS_TOKEN" \
            -H "Content-Type: application/json" \
            -d "$DNS_ENTRY" \
            "https://api.transip.nl/v6/domains/$DOMAIN/dns")

        HTTP_STATUS_UPDATE=$(echo "$RESPONSE" | tail -n1)
        RESPONSE_UPDATE_BODY=$(echo "$RESPONSE" | head -n -1)

        log_message "API update response received: $RESPONSE_UPDATE_BODY"
        log_message "HTTP status code received for update: $HTTP_STATUS_UPDATE"

        # Accept both 200 and 204 as successful updates
        if [ "$HTTP_STATUS_UPDATE" -ne 200 ] && [ "$HTTP_STATUS_UPDATE" -ne 204 ]; then
            handle_error "API call for DNS update failed with status code $HTTP_STATUS_UPDATE."
        else
            log_message "DNS A-record successfully updated to $CURRENT_IP"
        fi
    fi
}

# Get the current external IP
CURRENT_IP=$(curl -s http://ipinfo.io/ip) || handle_error "Failed to get external IP"

# Log the start
log_message "---- Start new run ----"
log_message "Current external IP: $CURRENT_IP"

# Always generate a short lived new token.
generate_new_token


# Try to update or create the DNS record
update_or_create_dns_record

log_message "---- End of run ----"

SSL-certificaten beheren voor domeinen die bij TransIP gehost worden, kan zonder automatisering een gedoe zijn. TransIP biedt gelukkig een degelijke API voor DNS-beheer, maar om die naadloos te integreren met Certbot voor dns-01-validatie is een eigen oplossing nodig. Omdat ik daar geen kant-en-klaar script voor kon vinden, heb ik er zelf één gemaakt dat veilig de authenticatie, DNS-updates en het aanmaken van certificaten regelt.

De volledige API-documentatie vind je hier:

TransIP API

Deze handleiding legt de complete setup met Docker uit, inclusief hoe je het API-keypair genereert in de webinterface van TransIP en gebruikt voor geautomatiseerd certificaatbeheer.

Hoe de authenticatie bij TransIP werkt

TransIP gebruikt een RSA-keypair voor API-authenticatie. Zo stel je dat in:

1. Genereer het keypair in TransIP:
   • Log in op je TransIP-controlepaneel.
   • Ga naar API-instellingen onder je account en schakel API-toegang in.
   • Genereer een nieuw API-keypair.
   • Download/sla de private key (transip_private_key.pem) veilig op en maak er een secret van voor gebruik in je Docker-setup.

docker secret create transip_private_key transip_private_key.pem

1. Houd de private key veilig:
   • Bewaar de private key op een veilige plek nadat je er een secret van hebt gemaakt.
   • Deze private key is nodig om requests naar de API van TransIP te signen.
2. Hoe het werkt:
   • Het script gebruikt de private key om een authenticatie-request te signen.
   • De API van TransIP antwoordt met een token met korte geldigheid (standaard 10 minuten), die vervolgens gebruikt wordt om de DNS-records te beheren.
   • Voor het gemak maakt het script bij elke run een nieuwe token aan. Dat maakte het robuuster dan controleren op een actieve token en die hergebruiken, wat het hele script minder betrouwbaar en omslachtiger maakte.

Wat deze setup gaat doen

1. Automatiseert SSL-certificaten:
   • Automatiseert het aanmaken en vernieuwen van wildcard- en domeinspecifieke certificaten.
2. Verwerkt DNS-challenges:
   • Beheert dns-01-challenges door DNS TXT-records aan te maken en te verwijderen via de TransIP API.
3. Naadloze integratie:
   • Alles zit in een Docker container voor draagbaarheid en eenvoud.
   • Je kunt in dit script domeinen verwijderen of toevoegen bij het -d-gedeelte. Ik heb de voorbeelden erin laten staan voor een betere uitleg.

We pipen een add- of clean-commando naar het bash-script om de acties uit te voeren die in het script staan. We gebruiken hier dus de –manual-auth-hook en de manual-cleanup-hook. Zo wordt bijvoorbeeld gegarandeerd dat een fout in het add-gedeelte alsnog netjes wordt opgeruimd.

Je kunt ook een –force aan dit script toevoegen, maar dan ben je snel door je pogingen bij Letsencrypt heen, want ze staan maar een paar calls per 24 uur toe. Wel zorgt dit ervoor dat de certificaten altijd vernieuwd worden als je iets wilt testen of verifiëren.

version: "3.8"

services:
  certbot:
    image: certbot/certbot:latest
    container_name: certbot-transip
    secrets:
      - transip_private_key  # Reference the secret you created earlier
    # adjust these volumes to point to the right .pem and script. right now this dockerfile expects the files to be in the same folder as the docker-certbot-transip.yml
    volumes:
      - "./certbot-transip.sh:/usr/local/bin/certbot-transip.sh:ro"
      - "./letsencrypt:/etc/letsencrypt"
    environment:
    #These Variables are going to be piped in our bash script.
      LOGIN_NAME: "your-transip-login"        # Replace with your TransIP login name
      PRIVATE_KEY_PATH: "/etc/transip_private_key.pem"
      DOMAIN: "example.com"                  # Replace with your domain
      TTL: "60"                              # Optional: Time-to-live for DNS challenge
      CERTBOT_EMAIL: "you@example.com"       # Replace with your valid email as requested by letsencrypt.
    entrypoint:
      - sh
      - -c
      - |
        apk update && apk add --no-cache bash curl jq bind-tools && \
        chmod +x /usr/local/bin/certbot-transip.sh && \
        certbot certonly --manual --preferred-challenges dns \
          --manual-auth-hook "/usr/local/bin/certbot-transip.sh add" \
          --manual-cleanup-hook "/usr/local/bin/certbot-transip.sh clean" \
          --cert-name "$DOMAIN" \
          -d "*.$DOMAIN" \
          -d "example2.$DOMAIN" \
          -d "example3.$DOMAIN" \
          --expand \
          --non-interactive --agree-tos \
          --email "$CERTBOT_EMAIL"

secrets:
  transip_private_key:
    external: true  # Secret must already exist in Docker

Het Bash-script

Dit is het “geavanceerde” deel dat zijn magie doet en alles met TransIP laat werken. Ik heb het ook een stuk robuuster gemaakt dan standaard. Dit zou dus hopelijk helpen om een stabiele en goed werkende omgeving op te zetten.

Je kunt dit TransIP-script ook lokaal draaien om certificaten aan te maken, of in een Kubectl- of Helm chart.

#!/bin/bash

# Configuration settings
LOGIN_NAME=${LOGIN_NAME}
TTL=${TTL:-60}  # Default value 60 if TTL is not set
PRIVATE_KEY_PATH=${PRIVATE_KEY_PATH}
DOMAIN=${DOMAIN}

AUTH_URL="https://api.transip.nl/v6/auth"
LOG_FILE="/var/log/transip_dyndns.log"

# Function to update a log file
#log_message() {
#    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> $LOG_FILE
#}

# Function to log messages to stdout
log_message() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1"
}

# Function to log an error and stop the script
handle_error() {
    log_message "ERROR: $1"
    echo "ERROR: $1" >&2
    exit 1
}

# Function to obtain a new access token with a short validity period (10 minutes)
generate_new_token() {
    log_message "Generating a new token with a validity period of 10 minutes."

    NONCE=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 16)
    TIMESTAMP=$(date +%s)
    LABEL="Certbot DNS update $TIMESTAMP"

    REQUEST_BODY=$(printf '{"login":"%s","nonce":"%s","read_only":false,"expiration_time":"10 minutes","label":"%s","global_key":true}' "$LOGIN_NAME" "$NONCE" "$LABEL")

    log_message "Request Body: $REQUEST_BODY"

    SIGNATURE=$(echo -n "$REQUEST_BODY" | openssl dgst -sha512 -sign "$PRIVATE_KEY_PATH" | base64 | tr -d '\n')

    log_message "Generated signature: $SIGNATURE"

    RESPONSE=$(curl -s -X POST "$AUTH_URL" \
        -H "Signature: $SIGNATURE" \
        -H "Content-Type: application/json" \
        -d "$REQUEST_BODY") || handle_error "Failed to connect to TransIP API"

    log_message "API-response received: $RESPONSE"

    ACCESS_TOKEN=$(echo "$RESPONSE" | jq -r '.token // empty')
    if [ -z "$ACCESS_TOKEN" ]; then
        handle_error "The received access token is empty or invalid. Check the API-response: $RESPONSE"
    fi

    log_message "Received token: $ACCESS_TOKEN"
}

# Function to add or update a TXT record
add_or_update_txt_record() {
    local full_domain="$1"
    local value="$2"

    # Extract the subdomain part from the full domain
    local name="_acme-challenge.${full_domain%%.*}"

    if [ -z "$name" ] || [ -z "$value" ]; then
        log_message "ERROR: Name or value for TXT record is missing."
        exit 1
    fi

    # Check if the DNS record already exists
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Search for all existing records with the same name and type TXT
    MATCHING_RECORDS=$(echo "$RESPONSE" | jq -r --arg name "$name" '[.dnsEntries[] | select(.name==$name and .type=="TXT")]')

    # Check if there are multiple or no matching records
    MATCHING_COUNT=$(echo "$MATCHING_RECORDS" | jq 'length')

    # Ensure MATCHING_COUNT is always an integer
    if ! [[ "$MATCHING_COUNT" =~ ^[0-9]+$ ]]; then
        MATCHING_COUNT=0
    fi

    if [ "$MATCHING_COUNT" -eq 0 ]; then
        log_message "No existing TXT record found for $name. Creating a new record."
    elif [ "$MATCHING_COUNT" -ge 1 ]; then
        log_message "Multiple or one existing TXT record found for $name. Removing all existing records."

        # Remove all existing records using the full details of each record
        echo "$MATCHING_RECORDS" | jq -c '.[]' | while read -r record; do
            existing_name=$(echo "$record" | jq -r '.name')
            existing_expire=$(echo "$record" | jq -r '.expire')
            existing_content=$(echo "$record" | jq -r '.content')

            # Log the details of the record to be removed
            log_message "Remove record: name=$existing_name, expire=$existing_expire, content=$existing_content"

            # Make the DELETE call using the full DNS-entry details
            DELETE_ENTRY=$(jq -n \
            --arg name "$existing_name" \
            --arg expire "$existing_expire" \
            --arg type "TXT" \
            --arg content "$existing_content" \
            '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

            DELETE_RESPONSE=$(curl -s -X DELETE \
                -H "Authorization: Bearer $ACCESS_TOKEN" \
                -H "Content-Type: application/json" \
                -d "$DELETE_ENTRY" \
                "https://api.transip.nl/v6/domains/$DOMAIN/dns")

            # Log the response of the DELETE call
            log_message "Response after removing $existing_name: $DELETE_RESPONSE"

            # Check if the removal was successful
            if [[ "$DELETE_RESPONSE" == *"error"* ]]; then
                log_message "ERROR: The record $existing_name could not be removed."
            else
                log_message "Record $existing_name successfully removed."
            fi
        done
    fi

    # Create a new record
    DNS_ENTRY=$(jq -n \
    --arg name "$name" \
    --arg expire "$TTL" \
    --arg type "TXT" \
    --arg content "$value" \
    '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

    RESPONSE=$(curl -s -X POST \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "Content-Type: application/json" \
        -d "$DNS_ENTRY" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    log_message "API-response for TXT record creation: $RESPONSE"

    if [[ "$RESPONSE" == *"error"* ]]; then
        handle_error "The TXT record could not be created. Check the API-response: $RESPONSE"
    else
        log_message "TXT record successfully added for $name with value $value"
    fi
}

# Function to update an existing TXT record
update_txt_record() {
    local name="$1"
    local value="$2"

    DNS_ENTRY=$(jq -n \
    --arg name "$name" \
    --arg expire "$TTL" \
    --arg type "TXT" \
    --arg content "$value" \
    '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

    RESPONSE=$(curl -s -X PATCH \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        -H "Content-Type: application/json" \
        -d "$DNS_ENTRY" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    log_message "API-response for TXT record update: $RESPONSE"

    if [[ "$RESPONSE" == *"error"* ]]; then
        handle_error "The TXT record could not be updated. Check the API-response: $RESPONSE"
    else
        log_message "TXT record successfully updated for $name with value $value"
    fi
}

# Function to remove a TXT record for `dns-01` validation
remove_txt_record() {
    local full_domain="$1"

    # Extract the subdomain part from the full domain
    local name="_acme-challenge.${full_domain%%.*}"

    # Check if the DNS record exists
    RESPONSE=$(curl -s -X GET \
        -H "Authorization: Bearer $ACCESS_TOKEN" \
        "https://api.transip.nl/v6/domains/$DOMAIN/dns")

    # Search for all records with the same name and type TXT
    MATCHING_RECORDS=$(echo "$RESPONSE" | jq -r --arg name "$name" '[.dnsEntries[] | select(.name==$name and .type=="TXT")]')

    # Check if there are existing records that need to be removed
    MATCHING_COUNT=$(echo "$MATCHING_RECORDS" | jq 'length')

    if [ "$MATCHING_COUNT" -eq 0 ]; then
        log_message "No existing TXT record found for $name to remove."
    else
        log_message "Removing all existing TXT records for $name."

        # Loop through all found records and remove them
        echo "$MATCHING_RECORDS" | jq -c '.[]' | while read -r record; do
            existing_name=$(echo "$record" | jq -r '.name')
            existing_expire=$(echo "$record" | jq -r '.expire')
            existing_content=$(echo "$record" | jq -r '.content')

            # Make the DELETE call using the full details
            DELETE_ENTRY=$(jq -n \
            --arg name "$existing_name" \
            --arg expire "$existing_expire" \
            --arg type "TXT" \
            --arg content "$existing_content" \
            '{"dnsEntry": {"name": $name, "expire": ($expire | tonumber), "type": $type, "content": $content}}')

            DELETE_RESPONSE=$(curl -s -X DELETE \
                -H "Authorization: Bearer $ACCESS_TOKEN" \
                -H "Content-Type: application/json" \
                -d "$DELETE_ENTRY" \
                "https://api.transip.nl/v6/domains/$DOMAIN/dns")

            # Check if the removal was successful
            if [[ "$DELETE_RESPONSE" == *"error"* ]]; then
                log_message "ERROR: The TXT record $existing_name could not be removed."
            else
                log_message "TXT record $existing_name successfully removed."
            fi
        done
    fi
}

# Always generate a new token for each run
generate_new_token

# Certbot passes these values when adding and removing the record
if [ "$1" == "add" ]; then
    add_or_update_txt_record "$CERTBOT_DOMAIN" "$CERTBOT_VALIDATION"
    sleep 25  # Wait for DNS update to propagate
elif [ "$1" == "clean" ]; then
    remove_txt_record "$CERTBOT_DOMAIN"
fi

Stappen om te draaien

1. Download de private key: Sla het bestand met de private key (transip_private_key.pem) uit de API-instellingen van TransIP op op het apparaat waar je dit gaat draaien.
2. Stel Docker Compose in: Zet de bestanden docker-compose.yml en certbot-transip.sh in dezelfde map. (of pas het script aan)
3. Start de container: Start de container (cd naar het pad waar je yml staat)

docker-compose up --build

Houd de logoutput in de gaten: de logoutput van de Docker container laat de voortgang van de DNS-challenges en het aanmaken van het certificaat zien.

Meer is het niet!

Binnenkort post ik ook een versie met een werkende Helm chart. Die was wat lastiger om alles correct te laten werken en alle certificaten te laten updaten via verschillende namespaces, waar ik de certificaten op verschillende domeinen beschikbaar moest hebben.

De API: https://api.protonvpn.ch/vpn/logicals is volgens Proton Support officieel stopgezet. Het enige wat hij nog teruggeeft is:

{"Code":0,"Error":"Invalid access token","Details":{}}

Dit artikel is daarmee helaas achterhaald. Iemand is een petitie begonnen om deze functionaliteit terug te krijgen.

De achterhaalde handleiding die niet meer werkt sinds 06/2025. Voor de historie bewaard.

Toen ProtonVPN zijn command-line interface (CLI)-tool stopzette, bleven gebruikers van headless systemen zoals de Raspberry Pi zonder een eenvoudige manier om VPN-verbindingen te beheren. Zonder grafische interface is het handmatig wisselen van VPN-servers een gedoe geworden. Ook het selecteren van de snelste VPN uit een pool van servers is onmogelijk geworden.

Om dit probleem op te lossen, heb ik een Python-script ontwikkeld dat automatisch de snelste ProtonVPN-server selecteert op basis van latency en load, en daarna je WireGuard-configuratie voor je bijwerkt. Deze handleiding neemt je mee door het instellen van WireGuard voor ProtonVPN, het installeren van het script en het automatiseren van je VPN-verbinding, zodat je Raspberry Pi altijd verbonden is met de beste server.

Waarom heb ik dit Protonss-script nodig?

Dit Python-script automatiseert het verbinden van je Raspberry Pi met de snelst beschikbare ProtonVPN-server, met WireGuard als VPN-protocol. Het controleert de latency en load van meerdere VPN-servers via de API van ProtonVPN, kiest de server met de beste prestaties, werkt je WireGuard-configuratie bij met de nieuwe servergegevens en maakt alleen opnieuw verbinding als er een duidelijk snellere server is gevonden (niemand zit eigenlijk te wachten op reconnects). Het script logt het hele proces, wat het debuggen een stuk makkelijker maakt.

1. Geen handmatig VPN-wisselen meer: Zonder de CLI van ProtonVPN zou het wisselen naar de snelste server handwerk betekenen. Dit script automatiseert dat proces door regelmatig de beschikbare servers te controleren en de verbinding bij te werken op basis van realtime prestaties.
2. Optimaliseert de verbindingssnelheid: Het script zorgt dat je altijd verbonden bent met de VPN-server met de laagste latency en load. Dit is vooral handig om snelle verbindingen te behouden in landen met snelle ProtonVPN-servers of servers met weinig verkeer.
3. Vermindert downtime: Door het herverbinden te automatiseren, minimaliseert het script mogelijke downtime door slechte serverprestaties of trage verbindingen.
4. Gemaakt voor de Raspberry Pi: Als je een headless Raspberry Pi draait (zonder monitor), is dit script ideaal om VPN-taken te automatiseren zonder constante supervisie.
5. Beveiliging & privacy: Door ervoor te zorgen dat je Raspberry Pi altijd via een VPN verbinding maakt, beschermt het je data en online activiteit, zeker als je de Pi gebruikt voor torrenting of als netwerkapparaat.

Dit script automatiseert dus het vinden van de optimale ProtonVPN-server, met hogere snelheden, meer betrouwbaarheid en gemak voor headless systemen zoals een Raspberry Pi.

Aan de slag!

Eerst moet je WireGuard installeren, een snel en lichtgewicht VPN-protocol dat we gebruiken om verbinding te maken met onze ProtonVPN-server.

# First, update your package list and install WireGuard:
sudo apt update
sudo apt install wireguard curl resolvconf

Genereer een WireGuard-configuratie via ProtonVPN

• Log in op je ProtonVPN-account op hun website.
• Ga naar het gedeelte “Downloads” in je dashboard.
• Genereer een nieuw configuratiebestand onder “WireGuard Configurations”.
• Gebruik je torrents, schakel dan NAT-PMP in.

Sla dit configuratiebestand op je Raspberry Pi op:

# Save the configuration file to your Raspberry Pi:
# Place it in the WireGuard directory and rename it for simplicity:
sudo nano /etc/wireguard/protonvpn.conf

Zodra je het configuratiebestand in de juiste map hebt geplaatst, controleer je de verbinding.

# Verify connection to ProtonVPN:
sudo wg-quick up protonvpn

# This should give an ip address different to the one frome your isp
curl ifconfig.me 

# Verify connection to ProtonVPN:
sudo wg-quick down protonvpn

curl ifconfig.me 

Als deze twee ip-adressen van ifconfig.me verschillen, ben je verbonden via een VPN. Ook als je je eigen ip-adres niet kent omdat het een DHCP-adres of iets dergelijks is.

Onze Python-omgeving installeren voor Protonss.

Bij het ontwikkelen en draaien van Python-scripts op je Raspberry Pi is het verstandig om een Python virtual environment te gebruiken. Zo’n virtuele omgeving laat je Python-packages geïsoleerd installeren en beheren, zodat de standaard Python-configuratie van je systeem onaangeroerd blijft.

Veranderingen in je omgeving beïnvloeden dan alleen het project waaraan je werkt — zoals het installeren van specifieke packages zoals requests — zonder conflicten te veroorzaken met andere Python-projecten of systeemafhankelijkheden.

Zo stel je een virtuele omgeving in voor ons script:

1. Installeer de virtuele omgeving: Installeer eerst het package python3-venv, waarmee je virtuele omgevingen kunt aanmaken en beheren.

sudo apt install -y python3-venv python3-full

2. Maak een virtuele omgeving: Na installatie kun je een virtuele omgeving aanmaken. Dit genereert een geïsoleerde omgeving in de door jou opgegeven map (in dit geval ~/protonss).

python3 -m venv ~/protonss

3. Activeer de virtuele omgeving: Na het aanmaken moet je de omgeving activeren. Dit zorgt dat je systeem de Python-versie en packages uit de virtuele omgeving gebruikt in plaats van de systeembrede Python-installatie.

source ~/protonss/bin/activate

• Nu de omgeving actief is, wordt elke Python-package die je installeert (zoals requests) in deze geïsoleerde omgeving geïnstalleerd.

pip install requests

Deze virtuele omgeving in de toekomst gebruiken: Elke keer dat je Python-scripts wilt draaien die van deze virtuele omgeving afhankelijk zijn, moet je hem opnieuw activeren met het commando source ~/venv/bin/activate. Eenmaal actief draaien alle Python-commando’s en packages in deze omgeving.

Ons ProtonSS-script installeren om automatisch met de snelste VPN te verbinden.

We maken een configuratiebestand aan met alle variabelen die het Python-script gebruikt. Daarin definieer je bijvoorbeeld het pad naar je WireGuard-configuratie, het logbestand en het aantal pings om latency te testen.

cd ~/protonss

Voorbeeld config.ini:

nano config.ini

[Settings]
# Path to your WireGuard configuration file
wg_config_path = /etc/wireguard/protonvpn.conf

# Path to your log file
log_file = /var/log/wireguard_updater.log

# Number of pings to measure latency
ping_count = 3

# Maximum score difference before reconnection 0 - 100
# Average score of servers is between 10-40 it seems. so setting this to high results in no switches from servers
score_threshold = 5.0

# Comma-separated list of preferred countries
preferred_countries = US

# Comma-separated list of preferred cities
# If specified, servers must be in these cities (unless they're in a country without any specified city)
# Preferred cities to connect to. If specified, servers must be in these cities
# (unless they're in a country without any specified city).
# Example: preferred_cities = Phoenix, Los Angeles, Seattle
# This allows you to target specific cities within your preferred countries.
# If left empty, any city within the preferred countries will be considered.
# Note: City names are case sensitive and must match ProtonVPN's naming exactly.
# Multiple cities should be comma-separated.
preferred_cities =Phoenix

# Weight for latency in the server score
# latency is subjective since this is probably measured through the vpn and only counts as server latency.
# Checking the latency without a vpn isnt recommended since the proton servers wont reply back without vpn.
# Value cant be higher then 1. 0.3 translates to 30% of the score_treshold.
latency_weight = 0.3

# Weight for server load in the server score
# Load is the best factor 0.7 translates to 70% of the weight of the score_threshold. this cant be higher then 1.
load_weight = 0.7

# Enable or disable pinging servers (True or False)
# Since ping might not be reliable enough for you to keep on switching servers this can be disabled here.
ping_enabled = True

# Specify the interface to use for ping tests. By setting this option you can ping to the fastest vpn server
# this will ensure the lowest latency VPN from your location.
ping_interface = eth0

[Features]
# Choose which type of servers you want to use
# Options: p2p, plus, secure_core, tor
# Default is p2p if not specified
feature_type = p2p

# Feature explanation:
# Each server has exactly ONE feature number:
# 1, 17 = Secure Core servers
# 2 = TOR servers
# 0, 8, 16, 24 = Plus-only servers
# 4, 12, 20, 28 = P2P servers (these are also Plus servers)

Je kunt de variabelen naar behoefte aanpassen. Laat je preferred_countries leeg, dan controleert het script een HELEBOEL! servers, waardoor het script erg lang gaat draaien!

Maak het Python-script aan

Nu gaan we het Python-script maken dat je VPN-verbinding automatiseert. Eerst moeten we een paar stappen voorbereiden.

De eerste regel van het script moet een shebang zijn, die er altijd voor zorgt dat het script in de juiste Python-omgeving draait:

source ~/protonss/bin/activate
which python

Dit geeft je het pad dat je op de eerste regel van het script moet zetten.

/home/pi/venv/bin/python

Pas het script aan door een shebang toe te voegen: zet de volgende regel helemaal bovenaan je Python-script. Vervang /home/{user}/venv/bin/python door het daadwerkelijke pad dat je kreeg toen je eerder het commando which python uitvoerde. Laat de #! aan het begin van de regel staan—daaruit maakt het systeem op welke interpreter het script moet draaien. We hebben het absolute pad nodig, dus ~/ werkt niet.

nano protonvpn_auto_connect.py

#!/home/{user}/protonss/bin/python

import requests
import subprocess
import os
import sys
import configparser
import logging
import re
from datetime import datetime
import math
import shutil

# Get the directory of the current script
script_dir = os.path.dirname(os.path.abspath(__file__))

# Load the config file from the same directory as the script
config = configparser.ConfigParser()
config.read(os.path.join(script_dir, 'config.ini'))

WG_CONFIG_PATH = config.get('Settings', 'wg_config_path')
LOG_FILE = config.get('Settings', 'log_file')
PING_COUNT = config.getint('Settings', 'ping_count')
SCORE_THRESHOLD = config.getfloat('Settings', 'score_threshold', fallback=5.0)
PREFERRED_COUNTRIES = config.get('Settings', 'preferred_countries', fallback='').split(',')
PREFERRED_CITIES = config.get('Settings', 'preferred_cities', fallback='').split(',')
PING_INTERFACE = config.get('Settings', 'ping_interface', fallback=None)

# Weighting factors for latency and load from the config
LATENCY_WEIGHT = config.getfloat('Settings', 'latency_weight', fallback=0.3)
LOAD_WEIGHT = config.getfloat('Settings', 'load_weight', fallback=0.7)

# Ping option from config
PING_ENABLED = config.getboolean('Settings', 'ping_enabled', fallback=True)

# Clean up country codes (remove spaces and convert to uppercase)
PREFERRED_COUNTRIES = [country.strip().upper() for country in PREFERRED_COUNTRIES if country.strip()]

# Clean up city names (remove spaces)
PREFERRED_CITIES = [city.strip() for city in PREFERRED_CITIES if city.strip()]

# Set up logging
logging.basicConfig(
    filename=LOG_FILE,
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] %(message)s',
    datefmt='%Y-%m-%d %H:%M:%S'
)

logging.info('--- ProtonVPN Auto Connect Script Start ---')

# Feature definitions
FEATURE_SECURE_CORE = [1, 17]  # Secure Core servers
FEATURE_TOR = [2]         # TOR servers
FEATURE_PLUS = [0, 8, 16, 24]  # Plus-only servers
FEATURE_P2P = [4, 12, 20, 28]    # P2P servers (these are also Plus servers)
# check https://api.protonmail.ch/vpn/logicals for more info. 
# be aware that the secure core and tor server are very limited so check if one is available for your country as stated in the config.ini file.
# FREE servers are not included in the api response. so they are already left out.

def get_feature_description(features):
    # If no feature type is specified in config.ini, default to P2P
    # Features is a number representing server capabilities
    if not features:  # If features is 0 or None
        return "P2P"  # Default to P2P
    elif features in FEATURE_SECURE_CORE:
        return "Secure Core"
    elif features in FEATURE_TOR:
        return "TOR" 
    elif features in FEATURE_P2P:
        return "P2P"
    elif features in FEATURE_PLUS:
        return "Plus"
    else:
        return "P2P"  # Default to P2P for any unrecognized feature

def get_wanted_features():
    """Get the wanted feature type based on config priorities"""
    feature_type = config.get('Features', 'feature_type', fallback='p2p').lower()
    
    if feature_type == 'secure_core':
        return FEATURE_SECURE_CORE
    elif feature_type == 'tor':
        return FEATURE_TOR
    elif feature_type == 'plus':
        return FEATURE_PLUS
    else:  # Default to P2P
        return FEATURE_P2P

# Function to fetch the list of servers from the ProtonVPN API
def get_servers(full_list=False):
    try:
        url = 'https://api.protonmail.ch/vpn/logicals'
        response = requests.get(url)
        response.raise_for_status()
        data = response.json()
        logging.info("API response data received.")
        return data['LogicalServers']
    except requests.RequestException as e:
        logging.error(f'Error fetching server list: {e}')
        sys.exit(1)
    except ValueError as e:
        logging.error(f'Error parsing JSON: {e}')
        sys.exit(1)

# Function to filter P2P servers and servers in preferred countries
def filter_servers(servers):
    filtered_servers = []
    
    # Get feature preferences from config (nu maar één type)
    wanted_features = get_wanted_features()
    
    logging.info(f"Filtering servers with preferences - Countries: {PREFERRED_COUNTRIES or 'Any'}, "
                f"Cities: {PREFERRED_CITIES or 'Any'}, Features: {[get_feature_description(f) for f in wanted_features]}")
    
    for server in servers:
        if not isinstance(server, dict):
            logging.error(f"Unexpected type for server: {type(server)} - Value: {server}")
            continue
            
        features = server.get('Features', 0)
        country = server['ExitCountry']
        city = server.get('City', '')

        # Check if server features match our wanted features
        if features in wanted_features:
            # Check country and city preferences
            if country in PREFERRED_COUNTRIES:
                if not PREFERRED_CITIES or city in PREFERRED_CITIES:
                    filtered_servers.append(server)
                    logging.info(f"Server matched - Country: {country}, City: {city}, "
                              f"Features: {get_feature_description(features)}")
            
    if not filtered_servers:
        logging.warning(f"No servers found matching filters. Countries: {PREFERRED_COUNTRIES}, "
                      f"Cities: {PREFERRED_CITIES}, Features: {[get_feature_description(f) for f in wanted_features]}")
    else:
        logging.info(f"Found {len(filtered_servers)} matching servers")
        
    return filtered_servers

# Function to measure latency by pinging the server (optional)
def get_latency(hostname):
    if not PING_ENABLED:
        logging.info(f"Ping disabled, skipping latency check for {hostname}.")
        return 0  # Return 0 latency if ping is disabled

    latencies = []
    for i in range(PING_COUNT):
        try:
            # Add the interface option if it's specified
            ping_command = ['ping', '-c', '1', '-W', '1', hostname]
            if PING_INTERFACE:
                ping_command.insert(1, '-I')
                ping_command.insert(2, PING_INTERFACE)

            result = subprocess.run(ping_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
            if result.returncode == 0:
                output = result.stdout.decode()
                latency_line = [line for line in output.split('\n') if 'time=' in line][0]
                latency = float(latency_line.split('time=')[1].split(' ms')[0])
                latencies.append(latency)
            else:
                latencies.append(float('inf'))
        except Exception as e:
            latencies.append(float('inf'))
            logging.error(f'Ping error for {hostname}: {e}')

    # Return the lowest (best) latency value
    best_latency = min(latencies)
    
    # Handle inf latency
    if math.isinf(best_latency):
        logging.warning(f"Latency for {hostname} is inf. Assigning high latency value.")
        best_latency = 1000  # Assign a high latency value

    return best_latency

# Function to select the best server based on a weighted combination of latency and load
def select_best_server(servers):
    best_server = None
    best_score = float('inf')
    
    for server in servers:
        server_load = server.get('Load')
        
        # Handle inf load
        if server_load is None or math.isinf(server_load):
            logging.warning(f"Server {server['Name']} has inf load. Assigning high load value.")
            server_load = 100  # Assign a high load value if it's inf or None
        else:
            server_load = int(server_load)
        
        for srv in server['Servers']:
            exit_ip = srv.get('ExitIP')
            hostname = exit_ip

            # Get latency, only if ping is enabled
            latency = get_latency(hostname)

            # Combine latency and load using the configured weights
            score = (latency * LATENCY_WEIGHT) + (server_load * LOAD_WEIGHT)
            
            logging.info(f"Server {server['Name']} - Latency: {latency:.2f} ms, Load: {server_load}%, Score: {score:.2f}")
            
            if score < best_score:
                best_score = score
                best_server = server
                best_server_instance = srv

    return best_server, best_server_instance, best_score

# Function to read the current server IP from the WireGuard configuration
def get_current_server_ip():
    try:
        with open(WG_CONFIG_PATH, 'r') as f:
            config_text = f.read()
        # Extract the current Endpoint IP
        match = re.search(r'Endpoint\s*=\s*([\d\.]+):\d+', config_text)
        if match:
            logging.info(f"Current server IP found in WireGuard configuration: {match.group(1)}")
            return match.group(1)
        else:
            logging.warning('No current Endpoint IP found in WireGuard configuration.')
            return None
    except Exception as e:
        logging.error(f'Error reading the WireGuard configuration: {e}')
        return None

# Function to find the current server's performance in the live server data
def get_current_server_performance(servers, current_ip):
    if current_ip is None:
        logging.warning('Current server IP is None, skipping performance check.')
        return None, None, float('inf')
    
    for server in servers:
        for srv in server['Servers']:
            if srv['ExitIP'] == current_ip:
                server_load = server.get('Load')
                if server_load is None or math.isinf(server_load):
                    logging.warning(f"Server {server['Name']} (IP: {current_ip}) has inf load. Assigning high load value.")
                    server_load = 100  # Assign a high load value
                else:
                    server_load = int(server_load)

                latency = get_latency(current_ip) if PING_ENABLED else 0
                score = (latency * LATENCY_WEIGHT) + (server_load * LOAD_WEIGHT)

                logging.info(f"Current server {server['Name']} - Latency: {latency:.2f} ms, Load: {server_load}%, Score: {score:.2f}")
                return server, srv, score
    logging.warning(f"Current server with IP {current_ip} not found in live data.")
    return None, None, float('inf')

# Function to find the current server in the full ProtonVPN list if not found in filtered data
def find_current_server_full_list(current_ip):
    servers = get_servers(full_list=True)
    return get_current_server_performance(servers, current_ip)

# Function to update the WireGuard configuration file
def update_wg_config(server, server_instance, best_score):
    try:
        endpoint_ip = server_instance['EntryIP']
        endpoint_port = 51820  # Default WireGuard port
        endpoint = f"{endpoint_ip}:{endpoint_port}"
        public_key = server_instance['X25519PublicKey']
        server_name = server['Name']

        # Read the current WireGuard configuration
        with open(WG_CONFIG_PATH, 'r') as f:
            config_text = f.read()

        # Strip comments that start with # under [Peer] before PublicKey
        config_text = re.sub(r'#.*\n', '', config_text, flags=re.M)

        # Update the Endpoint in the configuration
        config_text = re.sub(r'Endpoint\s*=.*', f'Endpoint = {endpoint}', config_text)

        # Update the PublicKey in the configuration
        config_text = re.sub(r'PublicKey\s*=.*', f'PublicKey = {public_key}', config_text)

        # Add the new comment indicating the chosen server and score
        config_text = re.sub(r'\[Peer\]\n', f'[Peer]\n# {server_name} - Auto-generated by ProtonVPN Auto Connect - Score: {best_score:.2f}\n', config_text)

        # Write the updated configuration back to the file
        with open(WG_CONFIG_PATH, 'w') as f:
            f.write(config_text)
        os.chmod(WG_CONFIG_PATH, 0o600)

        logging.info(f"WireGuard configuration updated with server: {server_name} ({server['ExitCountry']}), Endpoint: {endpoint}, PublicKey: {public_key}, Score: {best_score:.2f}")
    except Exception as e:
        logging.error(f'Error updating the WireGuard configuration: {e}')
        sys.exit(1)

# Function to restart the WireGuard interface
def is_resolvconf_available():
    """Check if resolvconf is available on the system."""
    return shutil.which("resolvconf") is not None

def is_wg_quick_available():
    """Check if wg-quick is available on the system."""
    return shutil.which("wg-quick") is not None

def restart_wg():
    interface_name = os.path.basename(WG_CONFIG_PATH).split('.')[0]
    
    # Check if wg-quick is available before proceeding
    if not is_wg_quick_available():
        logging.error("wg-quick not found. Ensure WireGuard is installed correctly.")
        sys.exit(1)

    try:
        # Check if resolvconf is available before proceeding
        if not is_resolvconf_available():
            logging.warning("resolvconf not found, DNS settings may not be updated correctly.")

        # Bring down the interface
        subprocess.run(['wg-quick', 'down', interface_name], stdout=subprocess.PIPE, stderr=subprocess.PIPE)

        # Bring up the interface
        subprocess.run(['wg-quick', 'up', interface_name], check=True)
        logging.info(f'WireGuard interface {interface_name} started.')

    except subprocess.CalledProcessError as e:
        logging.error(f'Error starting the WireGuard interface: {e}')
        sys.exit(1)

# Main function
def main():
    logging.info('--- Starting server selection process ---')
    
    # Fetch the list of servers
    servers = get_servers()
    if not isinstance(servers, list):
        logging.error(f'Unexpected type for servers: {type(servers)}')
        sys.exit(1)

    # Filter the servers
    filtered_servers = filter_servers(servers)
    if not filtered_servers:
        logging.error('No suitable servers available after filtering.')
        sys.exit(1)

    # Get the current server's IP address from the WireGuard configuration
    current_ip = get_current_server_ip()

    # Get the current server's performance if it exists
    current_server, current_server_instance, current_score = get_current_server_performance(filtered_servers, current_ip)

    # If the current server is not found, check the full list of servers
    if current_server is None:
        logging.info(f"Current server not found in filtered list, checking full server list...")
        current_server, current_server_instance, current_score = find_current_server_full_list(current_ip)

    # Select the best server based on weighted latency and load
    best_server, best_server_instance, best_score = select_best_server(filtered_servers)
    if not best_server:
        logging.error('No suitable server found.')
        sys.exit(1)

    if current_server:
        logging.info(f"Current server {current_server['Name']} (IP: {current_ip}) - Score: {current_score:.2f}")
    
    logging.info(f"Selected best server {best_server['Name']} - Score: {best_score:.2f}")
    
    if current_server and current_score <= best_score + SCORE_THRESHOLD:
        logging.info(f"Current server {current_server['Name']} is within threshold. No switch necessary.")
    else:
        logging.info(f"Switching to server {best_server['Name']} due to better performance.")
        update_wg_config(best_server, best_server_instance, best_score)
        restart_wg()

    logging.info('--- ProtonVPN Auto Connect Script End ---')

if __name__ == '__main__':
    main()

Het script testen

chmod +x protonvpn_auto_connect.py

Zodra het script is opgeslagen, geef je het uitvoerrechten en draai je het.

sudo ./protonvpn_auto_connect.py

cat /var/log/wireguard_updater.log
tail -f /var/log/wireguard_updater.log

Je kunt het logbestand tailen of catten om de output te controleren. Tail heeft de voorkeur, want dan kun je het blijven volgen terwijl je script draait. Open gewoon een tweede ssh-sessie met de tail om het in de gaten te houden.

2024-09-25 22:19:10 [INFO] --- ProtonVPN Auto Connect Script Start ---
2024-09-25 22:19:10 [INFO] --- Starting server selection process ---
2024-09-25 22:19:11 [INFO] API response data received.
2024-09-25 22:19:11 [INFO] Current server IP found in WireGuard configuration: 79.135.105.20
2024-09-25 22:19:11 [WARNING] Current server with IP 79.135.105.20 not found in filtered data.
2024-09-25 22:19:11 [INFO] Current server not found in filtered list, checking full server list...
2024-09-25 22:19:12 [INFO] API response data received.
2024-09-25 22:19:13 [INFO] Current server BH#1 - Latency: 26.90 ms, Load: 10%, Score: 15.07
2024-09-25 22:19:14 [INFO] Server AO#1 - Latency: 27.10 ms, Load: 7%, Score: 13.03
2024-09-25 22:19:15 [INFO] Server AO#2 - Latency: 26.60 ms, Load: 14%, Score: 17.78
2024-09-25 22:19:16 [INFO] Server AO#3 - Latency: 27.10 ms, Load: 9%, Score: 14.43
2024-09-25 22:19:17 [INFO] Server AO#4 - Latency: 26.60 ms, Load: 16%, Score: 19.18
2024-09-25 22:19:17 [INFO] Current server BH#1 (IP: 79.135.105.20) - Score: 15.07
2024-09-25 22:19:17 [INFO] Selected best server AO#1 - Score: 13.03
2024-09-25 22:19:17 [INFO] Current server BH#1 is within threshold. No switch necessary.
2024-09-25 22:19:17 [INFO] --- ProtonVPN Auto Connect Script End ---

sudo cat /etc/wireguard/protonvpn.conf

Je kunt ook controleren of alles werkt door het bestand protonvpn.conf te bekijken of door je externe ip-adres na te gaan.

[Peer]
# BH#3 - Auto-generated by ProtonVPN Auto Connect - Score: 7.74

Je ziet dan iets zoals hierboven. Deze comment wordt bijgewerkt zodra er verbinding wordt gemaakt met een andere VPN, en het ip-adres binnen de peer verandert dan uiteraard mee.

curl ifconfig.me #this wil give the external ip in the cli.

Als extra stap kun je ook je externe ip controleren. Die moet anders zijn dan het ip-adres dat je provider je geeft.

Dit script elk uur draaien

sudo crontab -e

0 * * * * cd /home/{user}/protonss && /home/{user}/protonss/protonvpn_auto_connect.py >> /home/{user}/protonss/protonvpn_cron.log 2>&1

Hier hebben we ingesteld dat het elk uur draait, maar je kunt het plannen zoals je wilt.

sudo crontab -l

Sla de crontab op en controleer dat cron is geïnstalleerd.

Optioneel: specifiek verkeer blokkeren als je VPN uitvalt

Als je er zeker van wilt zijn dat er geen verkeer je device verlaat als de VPN-verbinding uitvalt, kun je iptables gebruiken om verkeer te blokkeren wanneer de WireGuard-interface down is.

sudo apt-get install iptables

Controleer dat je iptables hebt geïnstalleerd, of installeer het met het bovenstaande commando.

ifconfig -a

protonvpn: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet 10.2.1.3  netmask 255.255.255.255  destination 10.2.1.3
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 612  bytes 101768 (99.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 765  bytes 101144 (98.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Bepaal eerst de naam van je netwerkinterface. Als je je bestand protonvpn.conf hebt genoemd, heet de interface protonvpn.

sudo iptables -A OUTPUT -p tcp --dport 51413 ! -o protonvpn -j REJECT --reject-with icmp-port-unreachable
sudo iptables -A OUTPUT -p udp --dport 51413 ! -o protonvpn -j REJECT --reject-with icmp-port-unreachable

Je kunt elke regel aan je iptables toevoegen. De 2 regels hieronder zorgen ervoor dat poort 51413 wordt geweigerd zodra de netwerkinterface met de naam protonvpn niet beschikbaar is. Er is een regel voor UDP- en voor TCP-verkeer.

sudo iptables -L OUTPUT -v -n

Nadat je alle benodigde regels hebt toegevoegd, kun je ze met dit commando controleren.

sudo apt-get install iptables-persistent

En maak de regels persistent, zodat je ze niet bij elke reboot opnieuw hoeft toe te voegen.

sudo netfilter-persistent save

Conclusie

Met dit Python-script is je Raspberry Pi altijd verbonden met de snelste beschikbare ProtonVPN-server, zodat je de best mogelijke VPN-prestaties hebt zonder handmatig ingrijpen. Of je je Pi nu gebruikt voor netwerken, torrenten of algemene online beveiliging: deze automatisering zorgt voor optimale prestaties en betrouwbare privacybescherming.

Update - 20-12-2024

Preferred_cities toegevoegd als optie om de selectie voor de VS te verkleinen. Dat land bevat anders ruim 2000 servers om te controleren. De performance-check kan zo in elk geval wat korter worden :-).

En ik heb uitgevonden wat de Feature-sectie van elke server in de API betekent. Hieronder leg ik het uit. Ik heb mijn code daarnaar aangepast om er correct mee te werken. Let op: de configuratie die je eerder hebt gemaakt moet overeenkomen met het type server waarmee je verbindt. Als je configuratie niet is ingesteld om met een Secure Core te verbinden, selecteer dan ook geen Secure Core in dit script. Sluit aan bij de ProtonVPN-configuratie die je hebt aangemaakt.

Uitleg van de features:

Elke server heeft precies één feature-nummer:

• 1, 17 = Secure Core-servers
• 2 = TOR-servers
• 0, 8, 16, 24 = Plus-only servers
• 4, 12, 20, 28 = P2P-servers (dat lijken ook Plus-servers te zijn)

        {
            "Name": "US-AZ#105",
            "EntryCountry": "US",
            "ExitCountry": "US",
            "Domain": "node-us-260.protonvpn.net",
            "Tier": 2,
            "Features": 12,

Na wat meer onderzoek naar vragen over de gratis servers van ProtonVPN blijkt dat ProtonVPN de publieke API-toegang tot hun free server-endpoints heeft verwijderd. Het /vpn/servers-endpoint dat eerder informatie over gratis servers had moeten leveren, geeft nu een 404-error:

{    "Code": 404,    "Error": "Path not found",    "Details": {}}

Op dit moment is alleen het Plus-server-endpoint via de publieke

API bereikbaar: url = ‘https://api.protonmail.ch/vpn/logicals’

Dit is waarschijnlijk een bewuste keuze van ProtonVPN. Helaas kan dit script daardoor de gratis servers niet ondersteunen.

Inleiding

In deze post wil ik databaseperformance binnen Azure belichten, met een directe vergelijking tussen MySQL, MariaDB en PostgreSQL. Er is veel literatuur over het onderwerp, maar praktische tests die de performance in de praktijk meten, zijn schaars.

Veel discussies draaien om de verschillen tussen deze databases in plaats van om hun daadwerkelijke performance. Toen ik dit onderzoek begon, stonden niet de verschillen voorop, maar de zoektocht naar een performante database die een goed Azure-alternatief kon zijn voor onze MariaDB-monolith. Aanvankelijk dachten we dat de overstap van MariaDB naar MySQL een simpele vervanging was, met nauwelijks impact op de performance. Daar hadden we het mis!

“There are many opinions about performance, But we needed facts”

We zagen een enorme performance-regressie bij elke query. Performance is cruciaal voor ons, en het was verwarrend om te zien dat MySQL zo ver achterbleef bij MariaDB. Toen we dit ontdekten, hebben we zelf een MariaDB-VM in Azure opgezet. Die was weer wel performant, maar bracht veel extra onderhoud en beheer met zich mee: uptime garanderen, hot standby, backups.

Daarom ging ik PostgreSQL onderzoeken, in de hoop op betere performance dan MySQL bood. Met deze introductie: de tests die we hebben gedaan, met een complexe query en een set kleine queries, om de performanceverschillen tussen de drie databases en hun implementaties binnen Azure te meten. We hebben ook Docker-tests toegevoegd om te kunnen vaststellen of de performanceverschillen aan de databases liggen of dat Azure de oorzaak is.

Onze complexe query testen

Om de databases te beoordelen draaiden we een complexe query die data uit meerdere tabellen aggregeerde, een realistische workload voor ons systeem. Om vertrouwelijkheidsredenen hebben we de tabel- en kolomnamen in deze beschrijving aangepast. Deze query moest laten zien hoe elke database omgaat met data-aggregatie en complexe joins.

WITH AggregatedSkateData AS (
SELECT
    e.id AS eventID,
    e.theme_cid AS themeCID,
    s.id AS skateID,
    p.firstName || ' ' || p.lastName AS participantName,
    l.label AS locationLabel,
    s.priceOffered,
    s.inspectionCompleted,
    s.registrationDate,
    s.eventStartDate,
    org.name AS organizerName,
    'https://skateeventimages.net/' || im.path AS organizerImageURL,
    s.registrationCode,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 0 OR pa_last.id IS NULL THEN sp.id END) AS partsPending,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 1 THEN sp.id END) AS partsRequested,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 2 THEN sp.id END) AS partsConfirmed,
    COUNT(DISTINCT CASE WHEN pa_last.status_cid = 8 THEN sp.id END) AS partsDenied,
    MAX(CASE WHEN ti_unscanned.id IS NOT NULL THEN 1 ELSE 0 END) AS hasUnscannedTickets,
    s.isPublic
FROM
    skateEvents s
    INNER JOIN events e ON s.eventID = e.id
    INNER JOIN participants p ON p.id = e.participantID
    LEFT JOIN organizers org ON org.id = e.organizerID
    LEFT JOIN images im ON im.id = org.profileImageID
    LEFT JOIN locations l ON l.id = s.locationID
    LEFT JOIN skateParts sp ON sp.eventID = s.id
    LEFT JOIN partApprovals pa ON pa.id = sp.partApprovalID
    LEFT JOIN ticketsUnscanned ti_unscanned ON ti_unscanned.id = sp.ticketID AND ti_unscanned.scannedAt IS NULL
    LEFT JOIN partApprovalActions pa_last ON pa_last.id = (
        SELECT pa2.id
        FROM partApprovalActions pa2
        WHERE pa2.partID = pa.id
        ORDER BY pa2.id DESC
        LIMIT 1
    )
WHERE
    s.registrationDate IS NOT NULL
    AND e.cancelledAt IS NULL
    AND e.deletedAt IS NULL
    AND s.isArchived = false
    AND s.deletedAt IS NULL
GROUP BY
    e.id, e.theme_cid, s.id, p.id, p.firstName, p.lastName, org.id, im.id, l.id, l.label, s.priceOffered, s.inspectionCompleted, s.registrationDate, s.eventStartDate, org.name, im.path, s.registrationCode, s.isPublic
)
SELECT * FROM AggregatedSkateData
WHERE
    TO_CHAR(s.registrationDate, 'YYYY-MM') = '2024-03'
    OR partsDenied + partsRequested + partsPending > 0
ORDER BY s.registrationDate DESC

Azure, complexe query

We hebben deze tests binnen dezelfde Azure-zone gedraaid voor containers en databases, om interzone-latency te vermijden. Hieronder de specificaties en resultaten, voor de transparantie. Opvallend: bij MariaDB en MySQL hadden de performancespecificaties nauwelijks invloed op de resultaten, mits we de eerste (burstable) tier vermeden. PostgreSQL was de uitzondering, met duidelijke verbeteringen bij de runtime van grote queries.

Met HeidiSQL via de Azure VPN hebben we onze beste resultaten van vijf runs bepaald.

MySQL Flexible, Zone 2 (Standard_E4ds_v5, 450 iops)
Found rows: 130
Duration for 1 query: 13,875 sec

MariaDB VM, Zone 2 (Standard B4s v2 (4 vcpus, 16 GiB memory))
Found rows: 130
Duration for 1 query: 10,625 sec
23,4% beter dan MySQL

Postgres Flexible, Zone 3 (Standard_E4ds_v50 p10, 500 iops)
Found rows: 130
Duration for 1 query: 3,953 sec
71,5% beter dan MySQL

Lokale Docker, complexe query

De hardware waarop we lokaal hebben getest:

12th Gen Intel(R) Core(TM) i9-12900H, 2900 Mhz, 14 Core(s), 20 Logical Processor(s)
Installed Physical Memory (RAM) 32,0 GB

MySQL 8.3 Docker
Found rows: 130
Duration for 1 query: 12,437 sec

MariaDB 11.4 Docker
Found rows: 130
Duration for 1 query: 9,484 sec

Postgres 16.2 Docker
Found rows: 130
Duration for 1 query: 3,969 sec

Daarmee zijn de tests met de complexe query afgerond. Geweldig om te zien dat Postgres hier zo goed presteert! Voor onze overstap naar Azure draaiden we op MariaDB. Het was behoorlijk vervelend om zo’n slechte performance in MySQL te zien zodra we met de nieuwe setup gingen testen.

Onze set kleine queries testen

De volgende test vuurt meer dan 20.000 transacties per seconde af op elke database, waarmee we een feed in JSON bouwen die een bepaalde tijd nodig heeft om af te ronden. Met veel queries belasten we de database beter, wat ons een gemiddelde runtime per database geeft. Er zit ook wat PHP-logica in, want dit is een PHP-script dat we draaien om de feed te genereren. Maar dat draait altijd op dezelfde hardware en hetzelfde docker-image, dus het verschil in runtime komt van de database. Hiervoor hebben we onze containers naar dezelfde zone verplaatst als waar de database draait, om ook mogelijke problemen met zone-latency uit te sluiten.

We draaien dit script binnen ons Laravel-framework. Onze PHP draait tegen Swoole voor de best mogelijke performance binnen PHP 8.

Azure, kleine queries

In deze test komen ook aspecten van containerperformance kijken. We draaien onze containers en database weer in dezelfde zone in Azure (West-Europa). Binnen Azure draaien we met een stuk minder performance dan we lokaal in onze docker-omgeving tot onze beschikking hebben.

Daarom kunnen we deze resultaten alleen gebruiken om de verschillen binnen docker en binnen Azure zelf te vergelijken, niet tussen die twee. Die met elkaar vergelijken zegt niets door dit hardwareverschil. We willen alleen het verschil in runtime tussen de databases zien, en Docker is de baseline om te checken of de verschillen overeenkomen met wat we in Azure zien.

Onze node size in Azure is een standard_b2s, 2 vCPU’s met 4 GiB RAM.

API, Zone 2 -> MariaDB VM, Zone 2
24,59s runtime (spot nodes)

API, Zone 2 -> MySQL Flexible, Zone 2
27,87s runtime (spot nodes)

API, Zone 3 -> Postgres Flexible, Zone 3
24,92s runtime (spot nodes)

Lokale Docker, kleine queries

Voor de kleine query-tests binnen lokale Docker gebruiken we een systeem met een 12th Gen Intel(R) Core(TM) i9-12900H CPU, draaiend op 2900 MHz met 14 cores en 20 logical processors, aangevuld met 32 GB RAM.

Deze Docker images zijn zo geconfigureerd dat ze memory-bound zijn, wat betekent dat de prestaties vooral afhankelijk waren van het beschikbare geheugen en niet beperkt werden door de CPU. De CPU-instellingen stonden op onbeperkte prestaties, zodat Docker zoveel CPU-bronnen kon gebruiken als nodig.

Voor elke testrun tegen een database herstartte ik de Docker container om de verbinding te verversen. Na de herstart hield ik een pauze van 30 seconden aan om er zeker van te zijn dat de container volledig gestabiliseerd en idle was. Die pauze is belangrijk voor consistentere testomstandigheden. Zodra de container klaar was, startte ik het feed generator script om de feed op te bouwen, om zo te beoordelen hoe goed onze verschillende database-setups kleine queries aankunnen onder deze gecontroleerde omstandigheden.

API -> MariaDB 11.4 Docker
22.88s runtime

API -> MySQL 8.3 Docker
23.74s runtime

API -> Postgres 16.2 Docker
20.77s runtime

MariaDB query cache

In ons eerdere gebruik van MariaDB binnen onze monolithische setup maakten we veelvuldig gebruik van de query cache. Deze functionaliteit speelde een cruciale rol bij het leveren van prestaties voor herhaalde queries. Die efficiëntie houdt stand totdat de cache herbouwd moet worden, meestal getriggerd door updates of inserts op de tabellen van de gecachte query. We doen een tweede run op onze complexe query met de query cache ingeschakeld.

Local MariaDB Docker
Found rows: 130
Duration for 1 query: 0,000 sec

De prestatiewinst van de query cache is echter niet overal even groot. Bij bijvoorbeeld gemiddeld 20.000 transacties per seconde met kleine queries zakte de runtime enigszins in. Deze variatie laat zien dat de query cache niet altijd hetzelfde niveau van optimalisatie oplevert, zeker onder hoge belasting. Maar daar later meer over.

API -> Local MariaDB Docker (query cache enabled)
17.30s runtime

API, Zone 2 -> MariaDB VM, Zone 2 (query cache enabled)
22.72s runtime (spot nodes)

De query cache in MariaDB werkt door de result set van SELECT queries op te slaan, samen met de querytekst. Wanneer een identieke query opnieuw wordt uitgevoerd (met dezelfde tekst en onder dezelfde database-userrechten), kan MariaDB de query-uitvoerfase overslaan en het resultaat direct uit de cache halen. Dit kan de uitvoertijd van vaak gedraaide queries die geen data wijzigen drastisch verlagen.

Wees voorzichtig met het gebruik van de query cache van MariaDB. Ondanks de voordelen is de query cache deprecated en standaard uitgezet in nieuwere versies van MariaDB 10.1.7 (en in MySQL vanaf versie 5.7.20), vanwege zorgen over de impact op prestaties in omgevingen met veel gelijktijdige transacties. Voor specifieke scenario’s, met name met een overwegend read-workload, kan de query cache nog steeds aanzienlijk betere prestaties opleveren. In MySQL 8 en hoger is hij volledig verwijderd.

Observatie over de Flexible Servers van Azure

Deze tests laten zien dat de prestaties van databases op de flexible servers van Azure aanzienlijk zijn verbeterd en dicht bij de prestaties van lokale Docker-omgevingen liggen. Dat is een flinke verbetering ten opzichte van de eerdere Azure database single servers, die doorgaans minder prestaties leverden door een vorm van overhead die voortkwam uit de manier waarop ze in de Azure-cloud draaiden.

Azure latency-anomalie

Als bonus hebben we nog wat extra tests gedaan om de interzone-latency te meten bij het verbinden van Zone 1 of 2 met een PostgreSQL-database in Zone 3 binnen Azure.

API, Zone 2 -> Azure PostgreSQL Flexible, Zone 3
De runtime was 44.23 seconden.

Interessant: de runtime verdubbelde opnieuw, een fenomeen dat we uitsluitend zien bij communicatie tussen Zone 1-2 en Zone 3, of andersom. Dit patroon suggereert dat elke container die een databaseverbinding nodig heeft onder deze omstandigheden aanzienlijke latency ondervindt, terwijl de latency vrijwel verwaarloosbaar is bij interactie tussen Zone 1 en Zone 2.

Voor wie het gemist heeft: ik heb eerder een latency-anomalie in Zone 3 besproken. De gangbare wijsheid is dat je de databaseverbinding binnen dezelfde zone houdt om latency te minimaliseren. Onze tests laten echter zien dat de latency-impact minimaal is tussen Zone 1 en 2, maar aanzienlijk wordt zodra je van Zone 1 of 2 naar Zone 3 gaat.

Deze tests bevestigen opnieuw dat het latency-probleem niet exclusief is voor MySQL Flexible services, maar ook PostgreSQL Flexible services binnen Azure raakt, wat wijst op een breder patroon in het database-aanbod van Azure.

Latency Anomaly: An attempt to untangle Azure Performance issues in Western EuropeUnveiling a significant Azure performance issue: Zone 3’s unexpected latency anomaly in the Western Europe region challenges cloud deployment strategies All Subjects MatterRemco Loup.

Conclusie

Vanuit prestatieoogpunt is het duidelijk dat de keuze voor de juiste database cruciaal is en moet aansluiten bij de specifieke snelheids- en efficiëntiebehoeften van je app. De resultaten laten zien dat MySQL vaak trager is. MariaDB presteert goed en heeft een handige query cache, maar Azure ondersteunt MariaDB niet meer. Daarmee is PostgreSQL de meest logische keuze voor prestatiegerichte gebruikers in Azure, want het blinkt uit in het verwerken van zowel complexe queries als grote aantallen simpele queries, zoals de tests hierboven laten zien.

Hopelijk helpt deze analyse bij het kiezen van de juiste databasetechnologie en onderstreept ze hoe belangrijk zorgvuldige planning is voor het verbeteren van je app-prestaties. Voor wie Azure gebruikt en topprestaties zoekt, is PostgreSQL in mijn testresultaten de beste optie.

Er zijn genoeg andere redenen om je database te kiezen. Maar in deze post wilde ik me alleen richten op performance. Dat was onze grootste zorg, want we zijn bezig met de overstap van een monolithische server naar Azure. Bij een database-switch komt nog meer kijken. Het voordeel hier is dat alle drie de databases zich redelijk makkelijk laten integreren, welke je ook kiest.

Postgres is hier het best compatibel dankzij zijn strikte routines. De gecompliceerde query hierboven is geschreven voor Postgres en draait in MariaDB zonder één wijziging. Voor MySQL hoef je alleen de TO_CHAR in de laatste regel te vervangen door DATE_FORMAT.

Introductie

We zijn begonnen aan een overstap van een traditionele VM-setup bij TransIP naar de schaalbare cloudinfrastructuur van Microsoft Azure. Die reis draait net zo goed om ontdekking als om prestaties. Met de expertise van Pionative als leidraad verhuizen we onze omgeving niet alleen; we proberen haar in Azure opnieuw op te bouwen, waarbij we elke stap zorgvuldig testen en analyseren. Ons doel? Optimale prestaties in deze nieuwe architectuur, en eventuele bottlenecks of verborgen problemen in onze nieuwe cloudarchitectuur zo vroeg mogelijk op het spoor komen.

Azure-regions en zones

De infrastructuur van Azure beslaat de hele wereld, georganiseerd in regions voor gelokaliseerde diensten, en verder onderverdeeld in zones voor hoge beschikbaarheid. Regions zijn specifieke geografische gebieden waar Azure-diensten draaien, terwijl zones fysieke locaties binnen die regions zijn, elk met eigen voorzieningen om storingen te isoleren.

De region Western Europe

De region Western Europe in Azure is opgebouwd uit drie aparte availability zones. Deze zones bieden een extra laag redundantie en fouttolerantie door datacenters binnen de region fysiek van elkaar te scheiden. Deze opzet moet garanderen dat zelfs bij een volledige uitval van één zone de diensten in de andere zones gewoon doordraaien — een stevige disaster recovery-oplossing voor bedrijven die in Europa actief zijn. Waar Zone 1, 2 en 3 geografisch precies liggen, is mij niet bekend.

Prestatie-anomalie in de region Western Europe

Ons testprogramma bracht ons bij een anomalie die het middelpunt van onze Azure-verkenning in deze post vormt: een duidelijk latency-probleem in Zone 3 van de region Western Europe. Deze ontdekking kwam niet meteen; ze kwam uit dagen prestatietesten en scherpe observatie van patronen die afweken van wat we verwachtten. Dat komt vooral doordat we Azure nog maar net aan het leren zijn, en door het prestatieverschil met onze huidige setup.

Eerst hebben we onze eigen pods, code en prestatie-instellingen binnen de node pool uitgesloten. Database-prestatie-instellingen en dat soort zaken.

Methodiek en bevindingen

Onze uiteindelijke aanpak was behoorlijk grondig om dit resultaat te verifiëren. We deployden twee node pools in elk van de drie zones van Microsoft Azure binnen de region Western Europe, om nodespecifieke verschillen uit te sluiten. Al die pools hadden exact dezelfde prestatie-instellingen.

Uit uitgebreide tests — waaronder een hele reeks database-aanroepen en de cron jobs die essentieel zijn voor de functionaliteit van onze applicatie — zagen we een consistent en verrassend patroon. Ongeacht de gerapporteerde capaciteit of drukte van de zone.

Interacties met de database waren aanzienlijk trager zodra de database óf de verbindende pods in Zone 3 stonden.

Prestatieresultaten

Hieronder onze situatie met een cronjob die lokaal in Docker tegen onze huidige setup zo’n 32 seconden nodig heeft. Die setup is niet vergelijkbaar met MS Azure, maar gaf ons wel een prestatiematrix en een doel. Het script (de cronjob) dat we draaiden vuurt zo’n 32.000 queries af om een feed te bouwen van alle producten op onze website. Ja, dat is veel, maar daar gaat het hier niet om. We wilden het prestatieprobleem blootleggen. We weten dat dit script geoptimaliseerd kan worden om beter te presteren.

MySQL-database in Zone 2
Zone 1 – pool 1: 33 seconden
Zone 1 – pool 2: 32 seconden

Zone 2 – pool 1: 32 seconden
Zone 2 – pool 2: 32 seconden

Zone 3 – pool 1: 115 seconden
Zone 3 – pool 2: 117 seconden

En toen, als klap op de vuurpijl, hebben we de setup omgedraaid met een database in Zone 3. Zie hieronder de resultaten die we hoopten te zien om dit onderzoek af te sluiten.

MySQL-database in Zone 3
Zone 1: 120 seconden
Zone 2: 122 seconden
Zone 3: 33 seconden

We zagen dezelfde consistentie terugkomen, elke keer opnieuw, ook toen we minder maar grotere database-aanroepen draaiden.

MySQL-database in Zone 2
16 DB-queries, single threaded.

Zone 1: Totale tijd voor queries uit log: 9,57 ms
Zone 2: Totale tijd voor queries uit log: 9 ms
Zone 3: Totale tijd voor queries uit log: 49,96 ms

Websiteprestaties in Azure

Als we onze database in Zone 2 draaien met de API-pod in Zone 1, daalt de initiële laadtijd van onze website met minstens 400 milliseconden bij de eerste page load, vergeleken met de configuratie waarin de API-pod in Zone 3 staat.

Dat betekent dat de setup met de database in Zone 2 en de API-pod in Zone 1 een veel snellere initiële responstijd voor de website oplevert dan wanneer de API-pod in Zone 3 staat en de database in Zone 2.

Er zit hier een foutmarge, maar uit deze resultaten kunnen we concluderen dat je, als je je API geografisch over twee zones wilt verdelen, nooit consistent kunt presteren met Zone 3. Zones 1 en 2 zijn de juiste keuze.

We moeten eerlijk zijn: deze prestatie-anomalie doet zich alleen voor bij een pod met een databaseverbinding. Onze website (die geen databaseverbinding heeft) in Zone 3 draaien had vrijwel geen meetbaar effect, zolang de API-pod in Zone 1 draaide en de database in Zone 2 stond.

Dieper duiken in de latency-problemen van Zone 3

Dit prestatieverschil in Zone 3 was voor ons verbijsterend. Volgens de best practices van Microsoft zou de fysieke nabijheid van applicatieservers bij hun databases binnen dezelfde regio de latency moeten minimaliseren. Onze bevindingen schetsten echter een ander beeld: de keuze van een zone binnen een regio kan flink invloed hebben op de performance van je applicatie.

Ons onderzoek was behoorlijk grondig. We hebben mogelijke variabelen uitgesloten, zoals onze eigen codebase, PHP-configuratie, MySQL-performance en meer. De aanhoudende latencyproblemen, vooral bij single-threaded cron jobs in PHP, wezen uiteindelijk richting een structureel probleem in de netwerkarchitectuur van Zone 3, of ergens in de deployment.

Samenwerking en leren

Ons traject, gedragen door de samenwerking met Pionative, onderstreept hoe waardevol het is om samen te werken als je door de complexiteit van de cloud moet navigeren. Hoe dieper we in deze latency-anomalie doken, hoe duidelijker werd dat we niet alleen onze eigen deployment wilden optimaliseren, maar onze bevindingen ook wilden teruggeven aan de bredere Azure-community.

Deze latency-impact is te groot om te negeren in onze productieomgeving.

Implicaties en vervolgstappen

Deze anomalie in Zone 3 roept discussies op over de optimale zonekeuze en deploymentstrategieën binnen de regio West-Europa van Azure. Is dit de reden dat Zone 3 de dunstbevolkte zone is? Online is er hier zo te zien weinig over te vinden. Daarom heb ik deze post geschreven: het kostte ons letterlijk dagen om dit prestatieverschil op te sporen.

Dit gaat invloed hebben op onze productieomgeving. We draaien onze DB in Zone 1 of 2, en de API moet in een van deze zones staan. Zone 3 kan gebruikt worden voor pods die met de API praten.

Deze latency-anomalie in Zone 3 was voor ons meer dan een uitdaging. We zagen het als een kans om te leren, aan te passen en onze kennis te verbreden. Terwijl we blijven samenwerken, testen en onze aanpak verfijnen, groeit ons Azure-traject uit tot een zeer interessante technische verkenning die onze toolkit voor de toekomst verruimt.

Deze post is een vervolg op GIT deployment-strategieën binnen Kubernetes-omgevingen. Lees eerst deze post:

CI/CD pipeline with Docker and Git branching strategyExplore advanced CI/CD with Docker & Git. Master deploying Docker artifacts via Git branching. Dive into strategies for DEV, STAGING, LIVE environments. Perfect your pipeline now! All Subjects MatterRemco Loup.

In een CI/CD-pipeline die draait om Docker artifacts, met de focus op één enkele branch, vraagt een efficiënte hotfix-strategie om een kleine afwijking van de standaardaanpak. Zo zorgen we dat kritieke fixes snel gedeployd worden. Laten we onze aanpak voor hotfixes in deze Docker-gerichte omgeving uitwerken, op basis van de branch-architectuur uit de post hierboven.

Wanneer is een hotfix nodig?

Hotfixes zijn cruciaal voor de stabiliteit en betrouwbaarheid van elke software in productie. Ze zijn meestal nodig in situaties die directe actie vragen. Weten wanneer je een hotfix inzet, is essentieel om je CI/CD-pipeline goed te beheren, zeker als je werkt met Docker artifacts en een gestroomlijnde branch-strategie met één hoofdbranch. Dit zijn onze scenario’s waarin een hotfix nodig kan zijn:

1. Beveiligingslekken: Een van de meest urgente redenen voor een hotfix is het ontdekken van een beveiligingslek in je applicatie. Of het nu gaat om blootgestelde data, risico op ongeautoriseerde toegang of een andere kwetsbaarheid die kwaadwillenden kunnen misbruiken: je moet snel handelen om het lek te dichten en je gebruikers en data te beschermen.
2. Kritieke bugs die de gebruikerservaring raken: Als een serieuze bug door je testproces heen glipt en in productie belandt, kan dat de gebruikerservaring flink raken. Dat kan van alles zijn: een kapotte kernfunctionaliteit waardoor gebruikers de applicatie niet meer kunnen gebruiken, of ernstige performanceproblemen die leiden tot timeouts of crashes. Raakt het probleem een groot deel van je gebruikers? Dan is een hotfix op zijn plaats.
3. Compliance-problemen: Sommige applicaties hebben te maken met wettelijke of regelgevende eisen. Als er een compliance-probleem wordt geconstateerd dat je juridische positie of de privacy van gebruikers kan raken, moet dat snel met een hotfix worden opgelost om boetes of verlies van vertrouwen te voorkomen.
4. Risico op dataverlies: Situaties waarin gebruikersdata verloren kan raken of corrupt kan worden, vragen om directe actie. Of het nu een fout is in hoe data wordt opgeslagen, bijgewerkt of opgehaald: deploy dan een hotfix om verlies of corruptie van gebruikersdata te beperken.
5. Falende betalingen of transacties: Voor applicaties die betalingen of andere transacties verwerken, zijn problemen die transacties blokkeren of tot financiële discrepanties leiden kritiek. Zulke problemen schaden niet alleen het vertrouwen van gebruikers, maar kunnen ook financiële gevolgen hebben voor zowel gebruikers als de dienstverlener. Een hotfix is dan noodzakelijk.

Een hotfix deployen

Als er een kritiek probleem in de productieomgeving wordt geconstateerd, is het doel om zo snel mogelijk een hotfix te ontwikkelen, testen en deployen. Omdat MAIN onze hoofdbranch voor development is en we Docker artifacts genereren voor deployment, hebben we een proces nodig dat snelle interventie mogelijk maakt zonder het lopende werk te verstoren.

1. Een hotfix-branch aanmaken: In plaats van te branchen vanaf je Production branch (LIVE bestaat in deze strategie immers niet meer in de Git-repository), maak je de hotfix-branch vanaf de commit die op dat moment in productie draait. Zo is de hotfix gebaseerd op exact de versie die in de productieomgeving draait. De specifieke commit vind je via tags of Docker image-labels die gekoppeld zijn aan de productie-deployment.
2. De hotfix ontwikkelen en testen: De kritieke fix wordt ontwikkeld binnen deze hotfix-branch. De urgentie vraagt om een gerichte aanpak: pak het probleem aan met minimale wijzigingen om testen en deployen te versnellen. Ook onder tijdsdruk is het naleven van de Definition of Done (DoD) cruciaal voor de stabiliteit en betrouwbaarheid van de hotfix. Dat kan een compactere versie van de DoD zijn, met prioriteit voor de kritieke tests en checks die garanderen dat de fix geen nieuwe problemen introduceert.
3. Een Docker artifact voor de hotfix maken: Zodra de hotfix aan de afgesproken DoD-criteria voldoet, bouwt een geautomatiseerd proces een Docker image van de hotfix-branch. Dit Docker artifact krijgt een passende tag, zodat duidelijk is waar het voor dient en hoe urgent het is.
4. De hotfix deployen: Het nieuwe Docker artifact wordt direct in de productieomgeving gedeployd, waarbij de gebruikelijke route via DEV en STAGING naar PRODUCTION wordt overgeslagen. Deze deployment is alleen te rechtvaardigen door de kritieke aard van de fix en de tests die erop zijn uitgevoerd.
5. Terugmergen en consistentie bewaken: Als de hotfix succesvol in productie draait, is het essentieel om de wijzigingen terug te mergen naar de MAIN branch en eventuele andere relevante branches of tags. Pas deze stap zorgt ervoor dat de fix wordt opgenomen in het lopende developmentwerk en toekomstige releases, en dat je geen regressie krijgt!!

Snel deployen en zo min mogelijk storing

• Geautomatiseerde processen: Automatisering speelt een sleutelrol in deze strategie, van het maken van het Docker artifact tot de deployment. Geautomatiseerde tests, builds en deployments zorgen dat het hotfix-proces zo snel en efficiënt mogelijk verloopt.
• Communicatie en monitoring: Snelle deployment van hotfixes vraagt om heldere communicatie binnen het team en nauwe monitoring van de productieomgeving na de deployment, om te verifiëren dat de fix werkt en geen nieuwe problemen introduceert.
• Documentatie en review: Het documenteren van het hotfix-proces en het doen van post-mortem-reviews helpt om de hotfix-strategie te verfijnen, zodat het team bij toekomstige problemen nog effectiever kan reageren.

Conclusie

In een CI/CD-pipeline met Docker en Git Flow als hoofdstrategie vraagt een hotfix om een strakke aanpak: gebruik de automatisering die er al is en focus op snelle, gerichte fixes. Door hotfix-branches te baseren op de commit die in productie staat, fixes te bouwen en testen volgens een goed gedefinieerde Definition of Done, en de Docker-artifacts direct naar productie te deployen, lost een team kritische problemen snel op zonder de stabiliteit en integriteit van de applicatie in gevaar te brengen.

In deze post ga ik in op het beheren van een CI/CD-pipeline met Docker, met de nadruk op een Git branching-strategie met een development- (DEV), staging- (STAGING) en production-branch (LIVE). Het doel is duidelijk maken welke rol elke branch speelt in het proces, en vooral hoe Docker-artifacts binnen dat stramien worden aangemaakt en beheerd.

Docker-deployments met Git Flow en meerdere branches

De kern van onze branching-strategie bestond uit drie branches:

1. DEV: Hier gebeurt alle ontwikkeling. Elke nieuwe feature, bugfix of verbetering start in een feature branch, afgesplitst van DEV. Is het werk af, gereviewd en voldoet het aan de Definition of Done (DoD), dan wordt het gemerged naar DEV.
2. STAGING: Deze branch spiegelt een pre-productieomgeving. Hier worden geïntegreerde features uit DEV als geheel getest en door stakeholders geaccepteerd, zodat we zeker weten dat alles samenwerkt.
3. MASTER: De branch die de huidige staat van onze live-omgeving weerspiegelt. Alleen grondig geteste en door stakeholders goedgekeurde wijzigingen uit STAGING halen het tot Productie.

Git Branching and Branching StrategyIn this post, we will go over why branching is required, the difference between development, staging… DEV CommunityPreetham

Dit was onze variant op een Git Flow-strategie, die we tot nu toe gebruikten. Zodra je met artifacts gaat werken, verandert dat allemaal terug naar een normale Git Flow-structuur. We hebben nog steeds omgevingen die draaien (Dev, Staging en Prod). Het echte verschil is dat code nu één keer gecommit wordt, in plaats van gemerged te worden naar een branch die op Staging of in Productie draait.

In plaats daarvan hebben we nu één branch, die we Main noemen. Daar wordt na een geslaagde code merge met Docker images een runnable artifact aangemaakt. Alles wat we op Staging of in Productie deployen is een specifieke versie van een eerder aangemaakt artifact.

Het grootste verschil: STAGING en PROD zijn geen branches meer waar je code in merged. Het zijn omgevingen geworden die een specifieke versie van een Docker image draaien. Dat brengt eigen uitdagingen met zich mee, zeker bij een hotfix. Hotfixen krijgt een eigen post, die je na deze kunt lezen. Ik loop het nu eerst stap voor stap door, zonder de hotfix erbij. Het is al omvangrijk genoeg zo.

Wat is een artifact?

Een Docker-artifact, vaak door elkaar gehaald met een Docker image, is een lichtgewicht, zelfstandig uitvoerbaar package dat alles bevat wat nodig is om een stuk software te draaien: de code, een runtime, libraries, omgevingsvariabelen en configuratiebestanden. Simpel gezegd: een snapshot van je applicatie én de omgeving eromheen, samen verpakt, klaar om overal gedeployed en gedraaid te worden waar Docker is geïnstalleerd. Zo weet je dat alles in verschillende omgevingen consistent werkt.

Het belang van de DoD bij het mergen van code

Een volledige en heldere Definition of Done (DoD) speelt in dit nieuwe proces een sleutelrol, zeker nu alle wijzigingen in één enkele branch gemerged worden die een Docker image moet opleveren die runnable en deployable is:

• Kwaliteitsborging: De DoD zorgt dat alle wijzigingen — nieuwe features, verbeteringen en hotfixes — die terug in MAIN gemerged worden aan een consistent kwaliteitsniveau voldoen. Denk aan code quality checks, succesvol doorlopen geautomatiseerde tests en het volgen van security best practices.
• Regressie voorkomen: Door de DoD toe te passen op alle merges naar MAIN voorkomt het team regressies en zorgt het dat nieuwe wijzigingen bestaande functionaliteit niet breken. Cruciaal voor de integriteit en stabiliteit van de codebase.
• Deployments soepeler laten verlopen: Een duidelijke en volledige DoD maakt deployments makkelijker, omdat alleen volledig gecontroleerde, deploy-klare wijzigingen in MAIN gemerged worden. Zo verspil je geen resources aan het bouwen van Docker images met bugs of die helemaal niet werken, en dat levert efficiëntere en betrouwbaardere artifacts op.

Artifacts aanmaken en beheren

De eerste voorwaarde om dit proces te laten werken: zodra een afgesplitste branch terug in MAIN gemerged wordt, start dat een geautomatiseerd proces in onze CI/CD-pipeline. Dit gebeurt er:

1. Geautomatiseerde tests: Eerst draaien de geautomatiseerde tests om te checken of de nieuwe wijzigingen aan onze kwaliteitsnormen voldoen. Cruciaal voor een stabiele branch.
2. Docker-artifact aanmaken: Zijn alle tests geslaagd, dan wordt er een Docker image (ons artifact) van de MAIN-branch gebouwd. MAIN is immers de enige branch die de laatste staat van alle afgeronde ontwikkeling vertegenwoordigt. Van daaruit genereren we artifacts die “shippable” producten kunnen worden.
3. Waarom MAIN voor Docker-artifacts?: Door artifacts op dit moment aan te maken vangen we integratieproblemen vroeg op. Omdat elke feature die in MAIN gemerged wordt als release-klaar wordt beschouwd, heb je door hier een artifact te genereren altijd een geteste en potentieel deploybare versie van je product bij de hand.

Van branches naar omgevingen

In traditionele Git-workflows staan branches als STAGING en PROD voor verschillende fasen in het ontwikkelproces, van testen tot productie. In een Docker-gecentreerde CI/CD-pipeline verschuift de focus: deze branches dienen niet langer voor code-integratie, maar als referentie voor deployment-omgevingen.

Deployen naar STAGING

• Docker-artifacts aanmaken: zodra de ontwikkeling klaar is en gemerged is naar de MAIN-branch, wordt er automatisch een Docker-artifact aangemaakt. Dat artifact is een snapshot van je applicatie op dat moment, met alle wijzigingen die gemerged zijn.
• Deployen in plaats van mergen: de rol van de STAGING-omgeving is om dit Docker-artifact te testen onder omstandigheden die sterk lijken op productie. In plaats van code van MAIN naar een STAGING-branch te mergen, deploy je het Docker-artifact naar een STAGING-omgeving. De code zelf beweegt dus niet tussen branches; het is de gecompileerde en gecontaineriseerde versie van je applicatie die getest wordt.
• Het doel van STAGING: de STAGING-omgeving is essentieel voor uitgebreide tests, waaronder performance- en security-assessments. Het is een laatste check om te verifiëren dat alles werkt zoals verwacht in een productie-achtige omgeving, zonder je echte gebruikers direct te raken.

Naar productie

• Goedkeuring van stakeholders: zodra je Docker-artifact grondig getest is in STAGING en goedgekeurd is door de stakeholders, is het klaar voor productie. Deze stap is cruciaal om te garanderen dat alle features, fixes en updates aan de nodige standaarden en verwachtingen voldoen.
• Deployen naar productie: de overgang van STAGING naar PROD betekent dat je het geteste Docker-artifact deployt naar je productieomgeving. Dit deploymentproces garandeert consistentie: het exacte artifact dat in STAGING getest is, wordt naar PROD gedeployd. Zo zijn er geen verschillen tussen geteste en gedeployde code.

Belangrijkste punten

• Geen branch-merges meer voor deployment: in deze gestroomlijnde workflow worden STAGING- en PROD-branches niet meer gebruikt om code te mergen. In plaats daarvan verwijzen ze naar specifieke deployment-omgevingen waar Docker-artifacts voor tests en productie gedeployd worden.
• Focus op artifacts: de nadruk ligt op het aanmaken, testen en deployen van Docker-artifacts. Deze artifacts vertegenwoordigen stabiele versies van je applicatie, klaar voor STAGING en uiteindelijk voor PROD.
• Consistentie en betrouwbaarheid: door hetzelfde Docker-artifact van STAGING naar PROD te deployen, weet je zeker dat wat getest is exact is wat er uitgebracht wordt. Dat vergroot de betrouwbaarheid en voorspelbaarheid van je deployments.

Deze aanpak vereenvoudigt het deploymentproces, verkleint het risico op fouten en zorgt ervoor dat elke release grondig getest wordt in een omgeving die productie zo nauw mogelijk benadert.

Zijn meerdere branches nog nodig?

In deze nieuwe workflow hebben de STAGING- en PROD-branches in de Git branching strategy geen actieve functie meer en zijn ze dus overbodig geworden. Ze hielpen om bij te houden welke versies van de code naar welke omgeving gedeployd waren. Dat probleem hebben we nu opgelost door een specifieke versie van een artifact te draaien.

Conclusie

Door Docker op te nemen in onze Git branching strategy stroomlijnen we het hele traject van development tot deployment: elke merge naar MAIN triggert een Docker-image met de potentie om naar productie te gaan. De sleutel van deze strategie is het vroeg in de developmentcyclus aanmaken van Docker-artifacts, zodat continuous integration en delivery mogelijk blijven zonder in te leveren op kwaliteit en stabiliteit.

Door de veranderingen aan de Git-branches te begrijpen en het proces van het aanmaken en deployen van Docker-artifacts, kunnen we met vertrouwen omgaan met de complexiteit van CI/CD. Zo leveren we alle nieuwe features en fixes zo efficiënt en betrouwbaar mogelijk af bij de gebruikers.

Hotfixes

We hebben het nog niet gehad over hotfixes. Zoals ik al zei, verdient dit een eigen post. Je leest hier alles over hotfixes en de valkuilen die daarbij komen kijken.

Hotfixing with Docker Artifacts in a Single Branch StrategyMaster hotfixes in Kubernetes with Docker. Learn to rapidly deploy critical fixes in a CI/CD pipeline focusing on streamlined branching. Perfect for tackling urgent issues without disrupting flow. Dive in now. All Subjects MatterRemco Loup.

Wat je moet weten om ons probleem te snappen

We werken aan een nieuwe website met veel nadruk op afbeeldingen. We hebben al www.333travel.nl, dat als reisproduct natuurlijk al zwaar leunt op afbeeldingen. Onze nieuwe website laadt zelfs afbeeldingen met een nog hogere resolutie, omdat de nadruk op het luxe gevoel ligt. Deze site is gericht op de luxe reiziger: www.travelplatinum.nl. Het project dat onze afbeeldingen serveert, static.333travel.nl, draait al een paar jaar zonder gemelde problemen voor de 333travel-website.

Het probleem

Het probleem werd gemeld door onze thuiswerkers. Zij merkten dat bij het werken vanuit huis veel afbeeldingen op TravelPlatinum soms niet laadden (en dat een refresh het meestal oploste). Ze gaven ook aan dat alles gewoon werkte vanuit kantoor. Dat was voor ons het startpunt van een zoektocht naar de boosdoener.

We zagen in de browsers die we gebruiken (Edge en Chrome) meldingen in de console van de mislukte afbeeldingen: ERR_HTTP2_PROTOCOL_ERROR. Met die melding in ons achterhoofd begonnen we in de logs op de server te zoeken. We draaien Nginx als webserver.

We vonden snel een spoor dat bij elke afbeelding opdook die volgens ons niet goed geladen was. We konden het probleem zelf nog niet reproduceren.

0.0.0.0 - - [06/Nov/2023:15:45:02 +0100] “GET /web-images/10/2023/653775730fc66/Jazan—Al-qahar-mountains-1200.webp HTTP/2.0” 206 183064 “https://www.travelplatinum.nl/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0”

Let op de 206 hier. Dat betekent partial content.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/206

Dat was vreemd, want onze webserver ondersteunde helemaal geen partial loading van afbeeldingen. We sturen nooit headers met iets als een range, terwijl dat nodig is om partial content te kunnen leveren.

Onze poging om het probleem op te lossen

Dus daar doken we als eerste in. Ik kwam erachter dat Nginx standaard een header meestuurt die Content-Type: bytes teruggeeft. Ik snap niet waarom ik zou willen dat onze image server met een ok-antwoord reageert op een 206-request. We hebben dit uitgezet met de volgende setting in ons server block.

server {
server_name static.333travel.nl;
max_ranges 0;
}

We vroegen de mensen die het probleem hadden om het te melden als het weer gebeurde. Helaas was dat snel het geval. De foutmelding in onze logging was wel veranderd. Edge en Chrome bleven dezelfde nutteloze ERR_HTTP2_PROTOCOL_ERROR in de console tab spuwen. In de timeline zagen we ook dat deze afbeeldingen op een bepaald punt stopten met laden.

0.0.0.0 - - [08/Nov/2023:14:22:27 +0100] “GET /web-images/06/2020/5ed7ad48d3d79/mexico-yucatan-chichen-itza-ik-kil-cenote.jpeg HTTP/2.0” 200 0 “https://vue-boss.333office.nl/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0”

We krijgen nu een header met een lengte van 0 bytes en een response met http 200 (ok). Het wordt hier echt vreemd. De header geeft bij inspectie in de browser wél het juiste aantal bytes terug in de response header. Waarom zegt de log van Nginx dan dat hij met een size van 0 antwoordt? Hier werd het raar en we wisten eigenlijk niet wat we verder moesten doen. We moesten het probleem eerst zelf kunnen reproduceren voordat we echt konden troubleshooten.

Ik probeerde een fout te simuleren met ab (apache benchmark). Ik begon voorzichtig met 500 requests en 50 gelijktijdige requests. Het probleem werd bij mij nooit getriggerd. Daarna ging ik in kleine stapjes omhoog tot 10.000 requests met 700 gelijktijdige requests, zonder het gemelde probleem ook maar één keer te zien. De serverload leek alles ook prima aan te kunnen. Het ging om een afbeelding van zo’n 500kb die ik daar opvroeg.

De feiten

1. Een traag netwerkprofiel instellen in de network tab bij het inspecteren simuleerde het probleem voor ons niet.
2. De fout werd nog steeds alleen gemeld door 2 gebruikers die vanuit huis werkten.
3. Op kantoor hadden ze geen enkel probleem.
4. De site 333travel.nl laden gaf helemaal geen probleem. Elke afbeelding werkte daar ook voor die 2 thuiswerkers.
5. Testen via een 5g-verbinding op allerlei plekken die we konden bedenken simuleerde het probleem voor mij geen enkele keer.
6. ab (apache benchmark) met 10.000 requests en 700 gelijktijdige requests triggerde het probleem nooit.

Er was nog één verschil, en dat was het domein dat de afbeeldingen serveerde. 333travel kreeg een Cross origin header van same_site terug, wat klopt, want het domein is hetzelfde. Dus ik voegde een header toe aan de static.

server {
server_name static.333travel.nl;
max_ranges 0;
add_header ‘Access-Control-Allow-Origin’ ‘*’;
}

Zo krijgt elke bron die afbeeldingen van onze static.333travel.nl wil gebruiken hetzelfde antwoord. Dit loste niets op van het gemelde probleem.

We hadden nog steeds moeite om het probleem zelf te simuleren. We waren er vrij zeker van dat het alleen getriggerd werd op een of andere slechte verbinding bij een bezoek aan TravelPlatinum. Een bezoek aan 333travel, dat de afbeeldingen van dezelfde static server serveert, liet het probleem dat we op TravelPlatinum ervaren nooit zien.

Een slechte wifi-verbinding simuleren

We wilden zo graag een slechte wifi-verbinding simuleren. Ik verplaatste mezelf naar een plek buiten ons kantoor waar de wifi slecht was, en eindelijk zag ik het probleem met eigen ogen. Eindelijk iets om mee te testen. Toch bleef het raar dat we een of andere trage/slechte wifi nodig hadden om dit te simuleren. Je zou zeggen dat je profiel op slow 3g zetten in de developer tools van de browser hetzelfde gedrag zou geven.

Nu konden we eindelijk gaan testen vanuit onze development-omgeving. We begonnen te vermoeden dat het project zelf iets raars deed, misschien iets met javascript dat de verbinding sloot of zo. Dus begonnen we een stripped-down versie van de TravelPlatinum-website te bouwen om zonder javascript te testen.

Het probleem dat afbeeldingen niet laadden was er nog steeds..

We besloten exact dezelfde html van 333travel.nl over te nemen om daarmee te testen en zo een gelijke omgeving te creëren. 333travel deed het immers bij elke refresh nog prima.

Het probleem dat afbeeldingen niet laadden was er nog steeds..

We wilden dit nog beter kunnen simuleren, want onze slechte wifi-plek was niet bepaald een bureau; we zaten op een trap het probleem te debuggen. Ik besloot een 2^nd wifi-hotspot op te zetten in ons kantoor met een beperkte verbinding van 3mbit om te zien waar dat ons zou brengen. Dit was het! We konden nu bij elke refresh een heleboel kapotte afbeeldingen op TravelPlatinum simuleren! We komen in elk geval ergens. Bedenk wel dat de 333travel-website nog steeds elke afbeelding zonder problemen laadde.

We lieten de nginx-logs op dat moment voor wat ze waren, omdat we erachter waren gekomen dat we in die richting niets gingen oplossen. Nginx gaf nog steeds een ok terug op een header met 0 bytes. Als nginx dat ok vindt met de juiste headers op zijn plek, gaat dat bericht ons op dat moment niet helpen het probleem op te lossen.

Testen met Firefox

Op het moment dat ik deze wifi-hotspot aanmaakte, waren we net zover dat we afbeeldingen konden testen met alleen de html image tag en verder niets geladen in het project. Ook dat brak onze afbeeldingen. Ik stelde toen voor om Firefox er even bij te pakken, gewoon om te zien of die zich anders gedroeg, want ik vermoedde dat het browsergerelateerd was — hoe de browser reageert op wat er gebeurt. Of in elk geval zou hij misschien een andere foutmelding geven. Iets waar we onze zoektocht naar de oplossing op konden richten.

We zagen dat Firefox de afbeeldingen inderdaad regel voor regel laadde op de 3mbit-verbinding. Maar plotseling stopte het laden, met kapotte afbeeldingen als gevolg die voor zo’n 50% geladen waren of helemaal niet. Eindelijk zagen we eens iets anders! Edge/Chrome lieten nog steeds helemaal geen afbeelding zien en gaven me een nutteloze foutmelding. Nu drong eindelijk tot me door dat de static de afbeeldingen daadwerkelijk aan het versturen was en de browser ze ontving, maar dat de verbinding op de een of andere manier te vroeg gesloten werd.

De oplossing

En dat was het moment waarop ik het probleem eindelijk vond. Een header die ik al tijden geleden op globaal niveau in Nginx had gezet tijdens een performance-tuningsessie.

send_timeout 2;

Wat send timeout volgens mij doet, is de verbinding X seconden openhouden na het niet ontvangen van data. De standaard is 60 seconden en ik had hem op 2 seconden gezet zodat we geen 60 seconden lang open verbindingen zouden hebben die niets doen.

Waarom zou dat het probleem zijn, terwijl ik Firefox duidelijk de afbeelding regel voor regel zag laden? Er wordt dan toch constant data verstuurd? Waarom zou deze setting dan gerelateerd zijn aan het sluiten van de verbinding.

Sets a timeout for transmitting a response to the client. The timeout is set only between two successive write operations, not for the transmission of the whole response. If the client does not receive anything within this time, the connection is closed.

Nou, het blijkt dat dit op tragere verbindingen wél getriggerd wordt. Nginx interpreteert dit als een stalled request. En het sluit de hele verbinding naar in ons geval static.333travel.nl. De gedeeltelijk geladen afbeelding en elke afbeelding daarna die niet geladen werd, wordt niet opnieuw geladen omdat de verbinding met static gesloten is.

Waarom het simuleren van een trage verbinding in de developer tools dit probleem niet triggert, weet ik nog steeds niet zeker. Ik heb een paar theorieën: een slechte wifi-verbinding zorgt ook voor meer latency en verloren packets die opnieuw verstuurd moeten worden. Maar de echte reden ken ik niet. Ik weet niet hoe deze browsers een trage verbinding simuleren.

Deze send_timeout op 8 seconden zetten zoals hieronder loste ons probleem volledig op.

server {
server_name static.333travel.nl;
max_ranges 0;
add_header ‘Access-Control-Allow-Origin’ ‘*’;
send_timeout 8;
}

Conclusie

We hebben veel geleerd, en we hebben het probleem opgelost. Raar blijft wel dat dit al die tijd alleen op ons TravelPlatinum-project getriggerd werd. We balanceerden blijkbaar op de grens met de send_timeout-setting, omdat de afbeeldingen op TravelPlatinum voor meer load zorgen.

Nog iets belangrijks om te onthouden: een trage verbinding instellen in je developer tools is geen echte simulatie van een trage verbinding. Je kunt simuleren wat je wilt, maar je hebt echte praktijksituaties nodig om echt te meten of alles goed werkt.

Notepad++ regexp

Bijvoorbeeld om je php-fpm access/slow log te controleren. Gebruik mark in Notepad++ om alle regels te markeren die trager zijn dan x/y.

10000ms en trager 

^.*\s(\d{5,}\.\d{3}ms).*

5000ms en trager 

^.*\s(5\d{3}\.\d{2,}ms|\d{5,}\.\d{2,}ms).*

DNS-tools om de overdracht van je DNS automatisch te controleren

sudo apt update
sudo apt install dnsutil

nano check_nameservers.sh

#!/bin/bash

DOMAIN="jouwdomein.com"
EXPECTED_NS1="ns1.cloudflare.com."
EXPECTED_NS2="ns2.cloudflare.com."

# Get the current nameservers
CURRENT_NS=$(dig NS $DOMAIN +short)

# Check if the current nameservers match the expected ones
if [[ $CURRENT_NS == *"$EXPECTED_NS1"* && $CURRENT_NS == *"$EXPECTED_NS2"* ]]; then
    echo "Nameservers are correctly set to Cloudflare."
else
    echo "Nameservers have not yet switched to Cloudflare."
fi

chmod +x check_nameservers.sh

watch -n 1 ./check_nameservers.sh

Update (13-11-2024)

Op de een of andere manier was ik de stap kwijt om een nieuw image aan te maken en daar alle builder-items uit te kopiëren. Het veranderde niets aan de werking van het image, maar de grootte is nu veel kleiner: van ruim 2gb naar onder de 100mb. Ergens tijdens mijn eerdere debuggen is die stap verloren gegaan. De laatste update staat hieronder dus opnieuw.

Latency Anomaly: An attempt to untangle Azure Performance issues in Western EuropeUnveiling a significant Azure performance issue: Zone 3’s unexpected latency anomaly in the Western Europe region challenges cloud deployment strategies All Subjects MatterRemco Loup.

Introductie

Hieronder vind je een werkende Dockerfile die ik heb gemaakt, met de onderstaande compatibiliteitseisen die ik zelf had. Ik plaats dit hier als eigen archief, en natuurlijk om te delen. Ik heb de volgende ondersteuning toegevoegd.

• HTTP/2 HPACK
• HTTP/3
• BoringSSL
• Brotli-ondersteuning

Deze versie van Nginx ondersteunt HTTP/3 quic en Brotli-compressie als belangrijkste voordelen, plus wat andere fixes. Tegenwoordig geen Brotli-ondersteuning hebben is gewoon een stap terug in de DeLorean.

Meer info over hoe HPACK je HTTP/2 versnelt. En hier lees je meer details over BoringSSL.

Brotli vergeleken met GZIP

Zoals gezegd is dit een Nginx-versie die Brotli ondersteunt. Brotli is erg nuttig omdat het een beter compressie-algoritme is dan GZIP. Ben je nog niet overtuigd, kijk dan de video hieronder.

Nginx basis Dockerfile

Dit is de basis van mijn dockerfile die alle bovengenoemde dingen regelt. Je kunt dit natuurlijk aanpassen of andere versies van alpine of Nginx gebruiken, zolang het bouwen van de andere modules maar niet breekt. Ik heb Nginx, NJS en BoringSSL ook naar de nieuwste versies geüpdatet.

Ik gebruik dit image in plaats van de officiële Nginx om al mijn webprojecten te draaien. Zie dit als een basisimage waarin je al je draaiende webserver-projecten definieert. Je krijgt er “gratis” Brotli-compressie en HTTP/3-ondersteuning bij, zodat je je sites sneller en actueler kunt maken.

##################################################
# Nginx with Quiche (HTTP/3) and Brotli
# VERSION 1.05 / 13-11-2024
##################################################
# This build compiles Nginx with Brotli and
# HTTP/3 support. It uses a multi-stage build to
# minimize the final image size by copying only
# the necessary artifacts from the builder image.
# Based on Alpine for a lean and efficient image.
##################################################

# Builder Stage
FROM alpine:latest AS builder

# Set the versions of Nginx, NJS, and BoringSSL
ENV NGINX_VERSION=1.27.2
ENV NJS_VERSION=0.8.7
ENV BORINGSSL_VERSION=c59bf8bf189dcbde868e04efcd53b705ed155231
ENV BORINGSSL="/tmp/boring-nginx"

# Build-time metadata
ARG BUILD_DATE
ARG VCS_REF

# Install dependencies for building Nginx
RUN addgroup -S nginx \
  && adduser -D -S -h /var/cache/nginx -s /sbin/nologin -G nginx nginx \
  && apk update \
  && apk upgrade \
  && apk add --no-cache ca-certificates openssl \
  && update-ca-certificates \
  && apk add --no-cache --virtual .build-deps \
      gcc libc-dev make pcre-dev zlib-dev linux-headers gnupg \
      libxslt-dev gd-dev geoip-dev perl-dev \
  && apk add --no-cache --virtual .brotli-build-deps \
      autoconf libtool automake git g++ cmake go perl rust cargo patch \
      libxml2-dev byacc flex libstdc++ libmaxminddb-dev lmdb-dev file openrc

# Install and build BoringSSL
RUN mkdir $BORINGSSL \
  && cd $BORINGSSL \
  && git clone https://boringssl.googlesource.com/boringssl \
  && cd boringssl \
  && git checkout -q ${BORINGSSL_VERSION} \
  && mkdir build \
  && cd build \
  && cmake -DBUILD_SHARED_LIBS=1 .. \
  && make

# Prepare BoringSSL for Nginx compilation
RUN mkdir -p "$BORINGSSL/boringssl/.openssl/lib" \
  && cd "$BORINGSSL/boringssl/.openssl" \
  && ln -s ../include include \
  && cd "$BORINGSSL/boringssl" \
  && cp "build/crypto/libcrypto.so" ".openssl/lib" \
  && cp "build/ssl/libssl.so" ".openssl/lib" \
  && cp ".openssl/lib/libssl.so" /usr/lib/ \
  && cp ".openssl/lib/libcrypto.so" /usr/lib/

# Clone Nginx modules
RUN mkdir /usr/src \
  && cd /usr/src \
  && git clone --depth=1 --recursive --shallow-submodules https://github.com/google/ngx_brotli \
  && git clone --branch $NJS_VERSION --depth=1 --recursive --shallow-submodules https://github.com/nginx/njs

# Build Nginx with modules
RUN cd /usr/src \
  && wget -qO nginx.tar.gz https://nginx.org/download/nginx-$NGINX_VERSION.tar.gz \
  && tar -zxC /usr/src -f nginx.tar.gz \
  && rm nginx.tar.gz \
  && cd /usr/src/nginx-$NGINX_VERSION \
  && mkdir /root/.cargo \
  && echo $'[net]\ngit-fetch-with-cli = true' > /root/.cargo/config.toml \
  && ./configure --prefix=/etc/nginx \
      --sbin-path=/usr/sbin/nginx \
      --modules-path=/usr/lib/nginx/modules \
      --conf-path=/etc/nginx/nginx.conf \
      --error-log-path=/var/log/nginx/error.log \
      --http-log-path=/var/log/nginx/access.log \
      --pid-path=/var/run/nginx.pid \
      --lock-path=/var/run/nginx.lock \
      --http-client-body-temp-path=/var/cache/nginx/client_temp \
      --http-proxy-temp-path=/var/cache/nginx/proxy_temp \
      --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \
      --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \
      --http-scgi-temp-path=/var/cache/nginx/scgi_temp \
      --user=nginx \
      --group=nginx \
      --with-pcre-jit \
      --with-http_ssl_module \
      --with-http_realip_module \
      --with-http_addition_module \
      --with-http_sub_module \
      --with-http_dav_module \
      --with-http_flv_module \
      --with-http_mp4_module \
      --with-http_gunzip_module \
      --with-http_gzip_static_module \
      --with-http_random_index_module \
      --with-http_secure_link_module \
      --with-http_stub_status_module \
      --with-http_auth_request_module \
      --with-http_xslt_module=dynamic \
      --with-http_image_filter_module=dynamic \
      --with-http_geoip_module=dynamic \
      --with-http_perl_module=dynamic \
      --with-threads \
      --with-stream \
      --with-stream_ssl_module \
      --with-stream_ssl_preread_module \
      --with-stream_realip_module \
      --with-stream_geoip_module=dynamic \
      --with-http_slice_module \
      --with-mail \
      --with-mail_ssl_module \
      --with-compat \
      --with-file-aio \
      --with-http_v2_module \
      --with-http_v3_module \
      --add-module=/usr/src/ngx_brotli \
      --add-module=/usr/src/njs/nginx \
      --with-cc-opt="-I$BORINGSSL/boringssl/include -Wno-error" \
      --with-ld-opt="-L$BORINGSSL/boringssl/build/ssl -L$BORINGSSL/boringssl/build/crypto" \
      --with-select_module \
      --with-poll_module \
      --build="docker-nginx-http3-$VCS_REF-$BUILD_DATE ngx_brotli-$(git --git-dir=/usr/src/ngx_brotli/.git rev-parse --short HEAD) njs-$(git --git-dir=/usr/src/njs/.git rev-parse --short HEAD)" \
  && touch "$BORINGSSL/boringssl/.openssl/include/openssl/ssl.h" \
  && make -j$(getconf _NPROCESSORS_ONLN) \
  && make install \
  && rm -rf /etc/nginx/html/ \
  && mkdir /etc/nginx/conf.d/ \
  && mkdir -p /usr/share/nginx/html/ \
  && install -m644 html/index.html /usr/share/nginx/html/ \
  && install -m644 html/50x.html /usr/share/nginx/html/ \
  && ln -s /usr/lib/nginx/modules /etc/nginx/modules \
  && strip /usr/sbin/nginx* \
  && strip /usr/lib/nginx/modules/*.so \
  && rm -rf /etc/nginx/*.default /etc/nginx/*.so \
  && rm -rf /usr/src \
  && apk add --no-cache --virtual .gettext gettext \
  && mv /usr/bin/envsubst /tmp/ \
  \
  # Determine runtime dependencies
  && runDeps="$( \
      scanelf --needed --nobanner /usr/sbin/nginx /usr/lib/nginx/modules/*.so /tmp/envsubst \
      | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
      | sort -u \
      | xargs -r apk info --installed \
      | sort -u \
    )" \
  && echo "$runDeps" > /nginx-run-deps.txt \
  \
  # Cleanup
  && apk del .brotli-build-deps .build-deps .gettext \
  && rm -rf /root/.cargo \
  && rm -rf /var/cache/apk/* \
  && mv /tmp/envsubst /usr/local/bin/ \
  && mkdir -p /etc/ssl/private \
  && openssl req -x509 -newkey rsa:4096 -nodes -keyout /etc/ssl/private/localhost.key -out /etc/ssl/localhost.pem -days 365 -sha256 -subj '/CN=localhost' \
  && ln -sf /dev/stdout /var/log/nginx/access.log \
  && ln -sf /dev/stderr /var/log/nginx/error.log

# Final Stage
FROM alpine:latest

# Copy Nginx and related files from the builder stage
COPY --from=builder /usr/sbin/nginx /usr/sbin/nginx
COPY --from=builder /etc/nginx /etc/nginx
COPY --from=builder /usr/lib/nginx /usr/lib/nginx
COPY --from=builder /usr/share/nginx /usr/share/nginx
COPY --from=builder /usr/local/bin/envsubst /usr/local/bin/envsubst
COPY --from=builder /var/log/nginx /var/log/nginx
COPY --from=builder /var/cache/nginx /var/cache/nginx
COPY --from=builder /var/run /var/run
COPY --from=builder /etc/ssl /etc/ssl
COPY --from=builder /usr/lib/libssl.so* /usr/lib/
COPY --from=builder /usr/lib/libcrypto.so* /usr/lib/
COPY --from=builder /nginx-run-deps.txt /nginx-run-deps.txt

# Install runtime dependencies
RUN apk add --no-cache ca-certificates openssl libstdc++ libgcc \
  && apk add --no-cache $(cat /nginx-run-deps.txt) \
  && rm /nginx-run-deps.txt \
  && update-ca-certificates \
  \
  # Forward logs to Docker
  && ln -sf /dev/stdout /var/log/nginx/access.log \
  && ln -sf /dev/stderr /var/log/nginx/error.log

# Create nginx user and group
RUN addgroup -S nginx \
  && adduser -D -S -h /var/cache/nginx -s /sbin/nologin -G nginx nginx

# Expose ports
EXPOSE 80 443

STOPSIGNAL SIGTERM

CMD ["nginx", "-g", "daemon off;"]

Nginx.conf-voorbeeld

Hier vind je een voorbeeld van een nginx.conf die je een idee geeft hoe ik mijn nginx-omgeving draai.

Het belangrijkste verschil in dit bestand ten opzichte van de normale nginx.conf zijn de brotli-compressie-instellingen.

user nginx;
worker_processes auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

include /etc/nginx/modules-enabled/*.conf;

events {
	worker_connections 1024;
}

http {
	##
	# Basic Settings
	##
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 65;
	types_hash_max_size 2048;

	proxy_connect_timeout  300s;
	proxy_send_timeout  300s;
	proxy_read_timeout  300s;
	fastcgi_send_timeout 300s;
	fastcgi_read_timeout 300s;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	##
	# SSL Settings
	##
	ssl_protocols TLSv1.2 TLSv1.3;
	ssl_prefer_server_ciphers on;

	##
	# Logging Settings
	##
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

	##
	# Gzip Settings
	##
	gzip on;
	gzip_vary on;
	gzip_proxied any;
	gzip_comp_level 6;
	gzip_buffers 16 8k;
	gzip_http_version 1.1;
	gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

	##
	# Brotli Settings (modify the brotli_comp_level to match your optimal cpu load vs compression)
	##
	brotli on;
	brotli_static on;
	brotli_comp_level 11;
	brotli_types
	text/plain
	text/css
	text/xml
	text/javascript
	text/x-component
	application/xml
	application/xml+rss
	application/javascript
	application/json
	application/atom+xml
	application/vnd.ms-fontobject
	application/x-font-ttf
	application/x-font-opentype
	application/x-font-truetype
	application/x-web-app-manifest+json
	application/xhtml+xml
	application/octet-stream
	font/opentype
	font/truetype
	font/eot
	font/otf
	font/woff
	font/woff2
	image/svg+xml
	image/x-icon
	image/vnd.microsoft.icon
	image/bmp;

	##
	# Virtual Host Configs
	##
	include /etc/nginx/conf.d/*.conf;
}

Site.conf-voorbeeld

Let op: hoe hoger je de brotli-compressie instelt, hoe cpu-intensiever het wordt. TTFB (time to first byte) kan een probleem worden als de compressieratio te hoog staat in combinatie met een trage kubernetes-omgeving, hoge loads, of alles daartussenin. Test dus met realistische scenario’s en pas het daarop aan. Dit is niet alleen een Brotli-probleem; Gzip heeft dezelfde nadelen als je de compressieniveaus te hoog zet, terwijl de afname in bestandsgrootte het niet waard is.

Je kunt dit bestand gebruiken om alle HTTP/3-instellingen hieronder over te nemen. Dit optimaliseert en activeert HTTP/3-ondersteuning voor je site.

server {
       	# HTTP/3 and Quic Listen
      	listen 443 quic reuseport;
        http3 on;

        # HTTP/3 Add Alt-Svc header negotiation.
        add_header alt-svc 'h2=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400' always;
        
        # HTTP/2 Listen
        listen 443 ssl http2;
        http2 on;

        # Certificate locations for HTTPS.
	    ssl_certificate /etc/ssl/certs/wildcard-cert-23.crt;
        ssl_certificate_key /etc/ssl/private/wildcard-cert-23.key;

        # Enable SSL settings for performance.
        ssl_session_cache shared:SSL:50m;
        ssl_session_timeout 1d;
        ssl_session_tickets off;
        # Enable SSL settings for security.
        ssl_prefer_server_ciphers on;
        ssl_protocols TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;

        # Base settings (root and hostname).
        root /var/www/html;
        index index.php index.html index.htm;
        server_name kubernetes.servername.nl;

        # HTTP/2 settings
        http2_push_preload on;
        # /End of HTTP/2.

        # HTTP/3 settings
        # Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to
        # prevent replay attacks.
        # @see: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data
        ssl_early_data on;
        quic_retry on;
        quic_gso on;
        quic_host_key /etc/ssl/private/wildcard-cert-23.key;
        # /End of HTTP/3.

        location / {
                try_files $uri $uri/ /index.php?$query_string;
	    }

        location ~ \.php$ {
                try_files $uri =404;
                # Bunch of PHP and FPM settings
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass your-php-fpm-instance:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info
                
                # Add a bunch of other headers based on your desired settings.
                add_header X-protocol $server_protocol always;   
                add_header X-Cache $upstream_cache_status always;
                add_header X-Frame-Options SAMEORIGIN always;
                add_header X-Content-Type-Options nosniff always;
                add_header X-XSS-Protection "1; mode=block";
                add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload" always;
                add_header Referrer-Policy strict-origin-when-cross-origin;
                add_header Pragma public;
                add_header Cache-Control "public";
        }
}

Meerdere H3-verbindingen vanaf één Nginx

Hier leg ik uit hoe je meerdere server blocks binnen Nginx met HTTP/3 kunt laten werken. Er zitten wat haken en ogen aan, omdat http3 UDP gebruikt met de instelling reuseport, waardoor je poort 443 niet meerdere keren kunt toewijzen bij gebruik van HTTP/3.

add_header alt-svc 'h2=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400' always;

Dit deel van de header meldt dat onze HTTP/3-verbinding poort 443 accepteert. Heb je een enkele nginx-container met meerdere geconfigureerde server blocks, dan krijg je problemen met het hergebruik van poort 443.

Met HTTP/3 kun je een poort maar één keer definiëren binnen een server block. Heb je meerdere server blocks, dan kun je je website via andere poorten dan 443 laten communiceren met behulp van deze alt-svc-header, die de browser vertelt dat hij HTTP/3 accepteert en op welke poort.

add_header alt-svc 'h2=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400' always;

add_header alt-svc 'h2=":443"; ma=86400, h3-29=":444"; ma=86400, h3=":444"; ma=86400' always;

Let op de verschillen in de h3-poorten hier. Zo kun je meerdere server blocks h3 laten gebruiken door unieke poorten op te geven.

Het enige wat je hoeft te doen is je instance naar de juiste poort laten luisteren die in je alt-svc-header staat. Als er een succesvolle verbinding mogelijk is, zal de browser proberen over te stappen op h3. Hieronder een voorbeeld van hoe je kunt luisteren op poort 443 en 444 met HTTP/3.

server {

        server_name http3-port-443

       	# HTTP/3 and Quic Listen
      	listen 443 quic reuseport;
        http3 on;

        # HTTP/3 Add Alt-Svc header negotiation.
        add_header alt-svc 'h2=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400' always;
        
        # HTTP/2 Listen
        listen 443 ssl http2;
        http2 on;
        
        # HTTP/3 settings
        # Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to
        # prevent replay attacks.
        # @see: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data
        ssl_early_data on;
        quic_retry on;
        quic_gso on;
        quic_host_key /etc/ssl/private/wildcard-cert-23.key;
        # /End of HTTP/3.

        location / {
                try_files $uri $uri/ /index.php?$query_string;
	}
}

server {

        server_name http3-port-444

       	# HTTP/3 and Quic Listen
      	listen 444 quic reuseport;
        http3 on;

        # HTTP/3 Add Alt-Svc header negotiation.
        add_header alt-svc 'h2=":443"; ma=86400, h3-29=":444"; ma=86400, h3=":444"; ma=86400' always;
        
        # HTTP/2 Listen
        listen 443 ssl http2;
        http2 on;
        
        # HTTP/3 settings
        # Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to
        # prevent replay attacks.
        # @see: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data
        ssl_early_data on;
        quic_retry on;
        quic_gso on;
        quic_host_key /etc/ssl/private/wildcard-cert-23.key;
        # /End of HTTP/3.

        location / {
                try_files $uri $uri/ /index.php?$query_string;
	}
}

Zo eenvoudig is het om je reverse proxy of meerdere server blocks een H3-verbinding te laten opzetten. Je moet wel de juiste port forwards instellen in je firewall/netwerk.

Met docker configureer je dit zoals hieronder weergegeven. Bij het opgeven van UDP moet je in docker elke poort apart specificeren. Hieronder mijn voorbeeld met UDP-poorten 443 tot en met 449.

services:
  ############################################################
  # proxy webservice to connect to multiple nginx instances
  ############################################################
  reverse-proxy:
    image: custom-build-nginx:latest
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '443:443/udp'
      - '444:444/udp'
      - '445:445/udp'
      - '446:446/udp'
      - '447:447/udp'
      - '448:448/udp'
      - '449:449/udp'
    volumes:

Update (03-04-2024)

Wat versienummers toegevoegd aan mijn dockerfile om versies beter te kunnen vergelijken. Ik heb de build van gisteren ook opgeschoond en besloten om een ENV toe te voegen voor het instellen van de boringssl-versie. Omdat hun build mijn dockerfile kapotmaakte, updaten we die maar handmatig. Verder heb ik nginx geüpdatet naar 1.25.4 en NJS naar 0.8.3 en de build geverifieerd.

Update (02-04-2024)

Pas recent kwam ik erachter dat een update van BoringSSL van rond 28 februari mijn build van BoringSSL had gebroken. Hieronder de bijgewerkte dockerfile die weer compileert. Ik moest libssl als shared library bouwen om het weer te laten werken. Ik ga dit image nog wat verder opruimen, maar het werkt in elk geval weer.

Update (18-03-2024)

Ik heb een sectie toegevoegd die uitlegt hoe je meerdere H3-verbindingen kunt gebruiken als je een Nginx hebt met meer dan één server block. Dit is ook de sleutel als je Nginx als Reverse Proxy gebruikt en gebruik wilt maken van H3.

Update (04-09-2023)

Ik kwam erachter dat deze build niet meer compileerde door een verandering in de brotli-broncode? Het had misschien te maken met updates van GitHub die ik niet had vastgelegd in deze Dockerfile. Ik heb het bestand volledig omgebouwd zodat het werkt met de bijgewerkte Nginx 1.25.2, die HTTP/3-ondersteuning “ingebouwd” heeft. Ook heb ik ervoor gezorgd dat we weer native Brotli-ondersteuning hebben. Dit zou vanaf nu moeten blijven werken.

Update (30-08-2023)

Ik heb de modsec-ondersteuning die er eerst in zat verwijderd. Die gaf willekeurige errors en omdat ik hem toch niet gebruik, heb ik hem eruit gehaald. Misschien komt hij later terug.

Introductie

In deze post leg ik mijn persoonlijke setup uit: hoe ik mijn Windows Terminal gebruik, plus wat andere tips. Dus als je iemand wilt imponeren terwijl je werkt in je favoriete koffiezaak, door ze het gevoel te geven dat je voor Nasa werkt — dan zit je hier goed! Grapjes terzijde: als je dag in dag uit met iets werkt, mag het er op z’n minst een beetje mooi uitzien, toch?

Ik begin met een lijst van alles wat ik geïnstalleerd heb, daarna leg ik uit wat het allemaal doet.

ZSH en het p10k-thema

GitHub - ohmyzsh/ohmyzsh: 🙃 A delightful community-driven (with 2,100+ contributors) framework for managing your zsh configuration. Includes 300+ optional plugins (rails, git, macOS, hub, docker, homebrew, node, php, python, etc), 140+ themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community.🙃 A delightful community-driven (with 2,100+ contributors) framework for managing your zsh configuration. Includes 300+ optional plugins (rails, git, macOS, hub, docker, homebrew, node, php, pyth… GitHubohmyzsh

GitHub - romkatv/powerlevel10k: A Zsh themeA Zsh theme. Contribute to romkatv/powerlevel10k development by creating an account on GitHub. GitHubromkatv

Quick start guide | SpaceVimA quick start guide which will tell you how to install and configure SpaceVim, also provides a list of resources for learning SpaceVim.SpaceVimShidong Wang

De bovenstaande items heb ik geïnstalleerd voor de look and feel van mijn shell. Ik gebruik Windows Terminal en daardoor ziet mijn terminal er goed uit en worden de juiste gegevens onderscheiden door kleuren in de shell.

ohmyzsh is het framework waarmee ik mijn ZSH-configuratie beheer. Het thema dat ik geïnstalleerd heb is p10k. Dit thema is enorm flexibel aan te passen.

SpaceVim is een van de beste visuele editors om alles in Linux te bewerken wat je nodig hebt. Kijk zelf maar via de link.

Hier een screenshot van hoe mijn persoonlijke shell eruitziet. Ik deel hieronder ook de JSON-config van mijn Windows Terminal. Het font dat ik gebruik is de standaard nerd font die bij p10k zit. Dat is de Meslo Gorgeous monospace Nerd font.

De kleuren die ik gebruik heten Atom One Dark. Een subtiel pastelkleurig font.

In het JSON-bestand hieronder vind je een paar leuke extra’s om je ervaring nog verder aan te passen.

Kali Linux

Ik heb Kali Linux geïnstalleerd als seamless overlay. Dat betekent dat je Kali visueel native binnen Windows kunt draaien. Zie de screenshot hieronder om te zien hoe netjes dat eruitziet! Via de link hieronder lees je hoe je dit met Kali aan de praat krijgt.

Win-KeX | Kali Linux DocumentationWindows Subsystem for Linux 2 & Win-KeX Kali Linux

"commandline": "wsl -d kali-linux kex --sl --wtstart -s",

Externe SSH in Windows Terminal

Je kunt met Windows Terminal ook makkelijk inloggen op (externe) servers die tokens vereisen.

"commandline": "ssh -i \"~/.ssh/id_rsa\" username@ip-address",

Kijk via de link hieronder hoe je dit configureert.

Windows Terminal-config

Hier is de JSON voor de Windows Terminal, met als laatste deel het kleurenthema dat ik gebruik, en de instellingen voor de look and feel. Er staan ook voorbeelden in voor het seamless draaien van Kali en een SSH-sessie met tokens.

    "profiles": 
    {
        "defaults": 
        {
            "antialiasingMode": "cleartype",
            "backgroundImage": null,
            "backgroundImageAlignment": "bottom",
            "backgroundImageOpacity": 0.8,
            "colorScheme": "Atom One Dark",
            "cursorShape": "vintage",
            "experimental.retroTerminalEffect": false,
            "font": 
            {
                "face": "MesloLGS NF"
            },
            "opacity": 75,
            "useAcrylic": true
        },
        "list": 
        [
            {
                "commandline": "wsl -d kali-linux kex --sl --wtstart -s",
                "guid": "{55ca431a-3a87-5fb3-83cd-11ececc031d2}",
                "hidden": false,
                "icon": "C:\\Users\\icons\\kali-menu.png",
                "name": "Kali Seamless overlay",
                "startingDirectory": "%USERPROFILE%"
            },
            {
                "commandline": "ssh -i \"~/.ssh/id_rsa\" username@ip-address",
                "guid": "{0caa0dad-35be-5f56-a8ff-afceaeaa6103}",
                "hidden": false,
                "name": "External test server"
            }
        ]
    },
    "schemes": 
    [
        {
            "background": "#282C34",
            "black": "#000000",
            "blue": "#61AFEF",
            "brightBlack": "#5C6370",
            "brightBlue": "#61AFEF",
            "brightCyan": "#56B6C2",
            "brightGreen": "#98C379",
            "brightPurple": "#C678DD",
            "brightRed": "#E06C75",
            "brightWhite": "#FFFFFF",
            "brightYellow": "#D19A66",
            "cursorColor": "#FFFFFF",
            "cyan": "#56B6C2",
            "foreground": "#CCCCCC",
            "green": "#98C379",
            "name": "Atom One Dark",
            "purple": "#C678DD",
            "red": "#E06C75",
            "selectionBackground": "#FFFFFF",
            "white": "#ABB2BF",
            "yellow": "#D19A66"
        }
    ],
    "themes": [],
    "useAcrylicInTabRow": true

Addins die je shell er nog beter uit laten zien en nog beter laten werken

Hieronder vind je nog wat links die je shell-ervaring nog beter maken. Het is een verzameling tools die ik dagelijks gebruik. Aan de bookmarks kun je al zien wat ze doen. Ik zou aanraden om elke link door te lezen en te bepalen of dit ook je leven makkelijker maakt.

Zelf vind ik Exa het leukst. Dit is een vervanging voor het ’ls’-commando, met veel meer zichtbaarheid dankzij kleuren en iconen voor mappen en dergelijke. Ook htop gebruik ik al jaren als mijn go-to process manager.

GitHub - BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respecting your gitignoreripgrep recursively searches directories for a regex pattern while respecting your gitignore - GitHub - BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respec… GitHubBurntSushi

GitHub - nvbn/thefuck: Magnificent app which corrects your previous console command.Magnificent app which corrects your previous console command. - GitHub - nvbn/thefuck: Magnificent app which corrects your previous console command. GitHubnvbn

GitHub - rupa/z: z - jump aroundz - jump around. Contribute to rupa/z development by creating an account on GitHub. GitHubrupa

GitHub - ogham/exa: A modern replacement for ‘ls’.A modern replacement for ‘ls’. Contribute to ogham/exa development by creating an account on GitHub. GitHubogham

htop - an interactive process vieweran interactive process viewer