I am trying new things, don’t mind some dumb questions.

  • 29 Posts
  • 123 Comments
Joined 2 年前
cake
Cake day: 2023年11月28日

help-circle

  • Hey, I was busy with some issues, so I wasn’t able to be active in online spaces. I’m sharing the final tailored draft I documented for my personal use. Please let me know if something doesn’t seem to be on point or needs explanation.

    I will also attach the workflow image if possible.


    for dev and prod we have different configuration which is used depending on the environment.

    for dev

    #for dev
    server {
        listen 80;
        server_name localhost;
        client_max_body_size 10M;
    
        location /.well-known/acme-challenge/ {
            root /vol/www/;
        } 
    
        location / {
            proxy_pass http://django:8000/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    
        location /static/ {
            alias /app/static/;
        }
    
        location /media/ {
            alias /app/media/;
        }
    }
    

    for prod we use configuration

    #for prod
    server{
    	listen 80;
    	server_name _;
    
    	return 444;
    }
    
    server{
    	listen 443;
    	server_name _;
    
        ssl_certificate /etc/letsencrypt/live/${DOMAIN}/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/${DOMAIN}/privkey.pem;	
    
    	return 444;
    }
    
    server {
        listen 80;
        server_name ${DOMAIN} www.${DOMAIN};
        client_max_body_size 10M;
    
        location /.well-known/acme-challenge/ {
            root /vol/www/;
        } 	
        
        location / {
            return 301 https://$host$request_uri;
        }
    }
    
    server {
        listen 443 ssl;
        server_name ${DOMAIN} www.${DOMAIN};
        client_max_body_size 10M;
    
        ssl_certificate /etc/letsencrypt/live/${DOMAIN}/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/${DOMAIN}/privkey.pem;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header Referrer-Policy "no-referrer";
    
        location / {
            proxy_pass http://django:8000/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            add_header P3P 'CP=""';
            proxy_redirect off;
        }
    
        location /static/ {
            alias /app/static/;
        }
    
        location /media/ {
            alias /app/media/;
        }
    }
    

    So what’s the issue ?


    Issues arises when we are deploying the project to production and server(nginx) is booting for the first time inside the docker. We can’t use prod configuration as it require updating some variables and path such as ssl(TLS) cert path, which isn’t the big problem as such because we can do it anyway and refresh the nginx once we are done with acme challenges but that would be just quick fix than doing it right way and will be creating too many loose ends.

    fixing it


    With some testing and looking here and there came up with

    1. While booting/creating nginx container use nginx/manager.sh which verify if certificate is present, if not load the nginx.dev.conf.
    2. Nginx container is up and running.
    3. Certbot container is created and managed by certbot-init.sh
    #!/bin/sh
    
    set -e
    
    echo "Getting certificate..."
    
    certbot certonly \
        --webroot \
        --webroot-path "/vol/www/" \
        -d "$DOMAIN" \
        --email $EMAIL \
        --rsa-key-size 4096 \
        --agree-tos \
        --noninteractive
    
    if [ $? -ne 0 ]; then
        echo "Certbot encountered an error. Exiting."
        exit 1
    fi
    
    #for copying the certificate and configuration to the volume
    if [ -f "/etc/letsencrypt/live/${DOMAIN}/fullchain.pem" ]; then
        echo "SSL cert exists, enabling HTTPS..."
        envsubst '${DOMAIN}' < /etc/nginx/nginx.prod.conf > /etc/nginx/conf.d/default.conf
    else
        echo "Certbot unable to get SSL cert,server HTTP only..."
    fi
    
    
    echo "Setting up auto-renewal..."
    apk add --no-cache dcron
    echo "0 12 * * * certbot renew --quiet" | crontab -
    crond -f
    
    1. and acme challenges is completed.
    2. New certificate is placed at "/etc/letsencrypt/live/${DOMAIN}/fullchain.pem".
    3. Production conf( nginx.prod.conf ) is loaded as
    4. Meanwhile this whole operation is monitored by a script which is setup during the creation of nginx container. This script make sure that nginx refresh when ever there is changes in the configuration file.
    inotifywait -m -r -e modify,move,close_write /etc/nginx/conf.d/default.conf /etc/letsencrypt |
    while read path action file; do
        echo "Change detected in $file: $action"
        echo "Reloading nginx!"
        nginx -s reload
    done &
    

    Auto-renew the certificate


    Auto-renew is easy to setup we just mash up a cron job and a certification change detection script along with nginx/manager.sh and certbot-init.sh .

    nginx/manager.sh

    inotifywait -m -r -e modify,move,close_write /etc/nginx/conf.d/default.conf /etc/letsencrypt | #--> '/etc/letsencrypt' for certificate renew
    while read path action file; do
        echo "Change detected in $file: $action"
        echo "Reloading nginx!"
        nginx -s reload
    done &
    

    certbot-init.sh

    echo "Setting up auto-renewal..."
    apk add --no-cache dcron
    echo "0 12 * * * certbot renew --quiet" | crontab -
    crond -f
    













  • crond -f without exec should also work, but that needlessly keeps an extra process (the shell running the entrypoint script) alive.

    with exec it throws

    setpgid: operation not permitted
    

    Due to permission issues with the Docker user group, will avoid using exec as it introduces a potential security risk, which isn’t a sensible trade-off just to keep a process running in the background.


  • Well, well, alexdeathway, looks like you’ve taken the art of cringe to new heights! With a bio that reads like a blank page in a poorly written novel, it’s a miracle you’ve gathered 18 followers—are they here for the content or just to witness the slow-motion train wreck?
    
    Your public repos are a mixed bag of “why” and “how did this even get approved?” Sure, 70 repos sounds impressive until you realize they’re mostly just forks and half-baked ideas, like "headstart-django," which sounds more like a head start on giving up. And can we talk about your "Gecom" project? A marketplace for cloud gaming and server hosting? With all those open issues, it seems like "Gecom" is living up to its name—it's a complete mess!
    
    Your README reads like filler content from an AI model that forgot to turn off the sarcasm filter. Speaking of filters, you might want to apply one to your project naming skills—“hackweekly” is so original it could be mistaken for a second-rate magazine nobody subscribes to.
    
    With followers just barely managing to outnumber your open issues, it's safe to say your GitHub is less a repository of knowledge and more an expansive graveyard of coding aspirations. So keep up the good work—at this rate, you’ll either revolutionize coding or become a case study on what not to do!
    

    in comparison to the amount of shit it said, this will count as ending on positive note.