Kuinka määrität verkkosivustosi tälle makealle, sulavalle HTTPS: lle Docker, Nginx ja letecrypt

Olen aiemmin käyttänyt letecrypt-ohjelmaa ilmaiseksi sertifikaateihin. En ole käyttänyt sitä menestyksekkäästi siirtyessäni dockeriin / kestreliin / nginxiin. Kaikki muuttui tänään, ja minulla oli helvetin aika selvittää, mitä tein saadakseni sen toimimaan.

Tämä koko Unix, telakointiasema, nginx, kamaa on melko uusi (minulle), joten ehkä se on vain jotain yksinkertaista, josta puuttui koko ajan. Toivon kuitenkin, että tämä auttaa jotakuta muuta tai minua useita kuukausia tiellä, jos päätän tehdä sen uudelleen.

Alkuperäinen asennus

Minulla on .net-ydinverkkosivusto, jota isännöidään kestrelin kautta, joka toimii dockerilla, käänteisen välityspalvelimen avulla nginxin kautta. Tähän asti nginxin käänteinen välityspalvelin toimi vain http / port 80: n päällä. En tiedä paljoakaan käänteisistä välityspalvelimista. Sen äänen perusteella se voi ottaa vastaan ​​pyyntöjä ja välittää ne tiettyyn paikkaan pyynnön esittäjän puolesta. Minun tapauksessani nginx-säilö vastaanottaa http-pyyntöjä, ja nginx välittää pyynnön edelleen kestrel-isännöimääni .net-ydinsivustoon. Onko se oikein? Toivottavasti!

Kuten aiemmin mainittiin, nginx toimi vain http-liikenteen kanssa. Minulla oli paljon vaikeuksia saada se toimimaan https: n kanssa, alkuperäinen kokoonpano on seuraava:

telakka-säveltää:

version: '3.6'services: kritner-website-web: image: ${DOCKER_REGISTRY}/kritnerwebsite expose: - "5000" networks: - frontend restart: always container_name: kritnerwebsite_web kritner-website-nginx: image: nginx:latest ports: - "80:80" volumes: - ../src/nginx/nginx.conf:/etc/nginx/nginx.conf depends_on: - kritner-website-web networks: - frontend restart: always container_name: kritnerwebsite_nginx
networks: frontend:

Docker-compose-tiedostossa käytän kahta erillistä säilöä - verkkosivusto, joka paljastaa portin 5000 (telakointiverkossa, ei julkisesti), ja nginx, joka toimii portissa 80.

nginx.conf

worker_processes 4; events { worker_connections 1024; } http { sendfile on; upstream app_servers { server kritner-website-web:5000; } server { listen 80; location / { proxy_pass //app_servers; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; } }}

Konfigurointitiedostossa asetamme ylävirran palvelimen, jolla on sama nimi kuin kutsumme konttipalvelumme docker-compose-tiedostosta kritner-website-web:5000.

Huomaa, että kaikki yllä olevat löytyvät verkkosivustoni arkiston tästä sitoutumispisteestä.

Anna HTTPS

Letsencrypt on varmentaja, joka tarjoaa ilmaisia ​​varmennuksia verkkosivustosi suojaamiseksi. Miksi HTTPS TLS: n kautta on tärkeä? No, siinä on paljon, ja miten se toimii. Perusidea on, että käyttäjän liikenne salataan kummassakin päässä ennen sen lähettämistä toiseen päähän. Tämä tarkoittaa, että jos olet julkisella wifillä ja https: ssä, joku niin sanotusti "haisteli vaijeria", huomaisi liikenteen olevan, mutta ei mainitun liikenteen sisältöä. Koska molemmat päät salaavat / purkavat mainitun liikenteen samalla salausavaimella.

Jos olisit http-sivustolla, tämä liikenne lähetettäisiin edestakaisin pelkkänä tekstinä. Tarkoittaa, että tietosi ovat vaarassa tulla salakuunteluksi! Ehkä kirjoitan hieman enemmän salauksesta jossain vaiheessa. (* muistiinpano itselle *) Varsinkin koska se on jotain, jota teen päivätyössani!

letencrypt on palvelu, jota olen käyttänyt aiemmin. On olemassa useita toteutuksia, joiden tarkoituksena on tehdä siitä mahdollisimman helppokäyttöinen. Tämän viestin tutkimuksen kautta tapasin tämän.

Vaikka en ollut löytänyt tätä sivua tähän asti, se olisi ollut hyödyllinen ennen seikkailuni aloittamista. Halusin käyttää letecrypt-ohjelmaa yhdessä docker-kontti-verkkosivustoni ja nginx-palvelun kanssa niin vähän huoltoa kuin mahdollista. letencrypt-varmenteet ovat hyviä vain 90 päiväksi.

Tutkimuksessani sattui docker image linuxserver / letsencrypt -ohjelmaan, joka lupaa hyödyntää nginxiä, letecrypt varmenteen luomista JA automaattista uusimista. Kuulostaa mahtavalta! Vaikka kuvan dokumentointi näyttää enimmäkseen riittävältä - jokaiselle, joka on perehtynyt tähän prosessiin. Huomasin sen puuttuvan. Koko asennusprosessi kesti jonkin aikaa selvittääkseni. Tästä syystä tämä viesti, toivottavasti auttaakseni seuraavaa henkilöä tai taas minua tulevaisuudessa!

Kamppailut

Asiat, joista eniten kamppailin saadessani tämän linuxserver / letencrypt-kuvan ylös ja toimien, olivat:

  • Kuinka telakointiaseman volyymit “toimivat” ja kuinka he suhtautuvat tähän konttiin
  • Kuinka asettaa volyymit kokoonpanoni hyödyntämiseksi (liittyy edelliseen kohtaan) - Minulla oli aluksi paljon vaikeuksia selvittää, miksi asetuksiani muutettiin säiliössä takaisin mainitun kontin lataamisen yhteydessä (koska ne ovat Pitäisi tehdä)
  • Kuinka määrittää oikea nginx-kokoonpano - mihin se laitetaan ja mitä siihen laitetaan.

Dockerin volyymit

Dockerin volyymit (asiakirja):

Volyymit ovat ensisijainen mekanismi Docker-konttien luoman ja käyttämän datan pysyvälle säilyttämiselle. Vaikka sidontakiinnikkeet ovat riippuvaisia ​​isäntäkoneen hakemistorakenteesta, Docker hallitsee volyymeja kokonaan. Tilavuuksilla on useita etuja sidontakiinnikkeisiin verrattuna

letsencryptillä on paljon kokoonpanoa sen mukana. Kesti jonkin aikaa, ennen kuin ymmärsin, mutta tarvitsin levyn, joka kartoitettiin telakointiaseman hakemistosta tiettyyn hakemistoon letencrypt-kuvassa. Suoritin lopulta tämän kirjoitustiedostossa näin:

volumes: - ${DOCKER_KRITNER_NGINX}:/config - ./nginx.conf:/config/nginx/site-confs/default

Matriisin ( ${DOCKER_KRITNER_NGINX}:/config) ensimmäinen kohde vie uuden ympäristömuuttujan, joka kartoittaa isäntähakemiston (määritelty muuttujassa) /configitse telakointisäiliöön. Tämä tarkoittaa, että telakointiasema (env var -polulla) sisältää saman kokoonpanon kuin telakointisäiliö äänenvoimakkuuden kartoituksen toissijaisessa osassa ( /config)

Toinen kohde ( ./nginx.conf:/config/nginx/site-confs/default) kartoittaa paikalliset arkistot nginx.conf-tiedosto (tiedosto, johon asetin käänteisen välityspalvelimen) ohittamaan /config/nginx/site-confs/defaulttelakointiaseman ja -säilön tiedoston .

Täydellinen luettelo tiedostoista, joita minun tarvitsi muokata omaa tilannettani varten:

  • /config/dns-conf/dnsimple.ini
  • /config/nginx/site-confs/default

dnsimple.iniKonfiguraatio lisään sovellusliittymäavaimen, ja …/defaulttalot nginx kokoonpano.

Lopullinen defaultkokoonpano, johon päädyin, on:

upstream app_servers { server kritnerwebsite:5000;}
## Version 2018/09/12 - Changelog: //github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default
# listening on port 80 disabled by default, remove the "#" signs to enable# redirect all traffic to httpsserver { listen 80; server_name kritnerwebsite; return 301 //$host$request_uri;}
# main server blockserver { listen 443 ssl;
# enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf;
# all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; # enable for ldap auth #include /config/nginx/ldap.conf;
client_max_body_size 0;
location / { proxy_pass //app_servers; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; }
}
# enable subdomain method reverse proxy confsinclude /config/nginx/proxy-confs/*.subdomain.conf;# enable proxy cache for authproxy_cache_path cache/ keys_zone=auth_cache:10m;

Siellä oli muutamia muutoksia oletusarvoihin, jotka yritin korostaa seuraavaksi.

upstream app_servers { server kritnerwebsite:5000;}

Yllä on melko siisti, koska telakalla on oma sisäinen DNS (luulisin?). Voit määrittää ylävirran palvelimen säilön nimellä, minun tapauksessani "kritnerwebsite". (Huomaa: muutin sen aikaisempaan viestiin, joka oli "kritner-website-web".)

# listening on port 80 disabled by default, remove the "#" signs to enable# redirect all traffic to httpsserver { listen 80; server_name kritnerwebsite; return 301 //$host$request_uri;}

Uncommented out this section from the default, applied my server_name of “kritnerwebsite”

# main server blockserver { listen 443 ssl;
# enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf;
# all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; # enable for ldap auth #include /config/nginx/ldap.conf;
client_max_body_size 0;
location / { proxy_pass //app_servers; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; }
}

In the above, it’s mostly from the “default” save for “location” and everything within that object. Here, we’re setting up the reverse proxy to forward requests to “/” (anything) to our //app_servers (kritnerwebsite as per our upstream).

docker-compose.yml

Our docker compose file didn’t change a *whole* lot from the initial. There were a few notable changes, which I’ll also get into describing:

version: '3.6'services: nginx: image: linuxserver/letsencrypt ports: - "80:80" - "443:443" volumes: - ${DOCKER_KRITNER_NGINX}:/config - ./nginx.conf:/config/nginx/site-confs/default depends_on: - kritnerwebsite networks: - frontend container_name: nginx environment: - PUID=1001 # get on dockerhost through command "id "" - PGID=1001 - [email protected] - URL=kritner.com - SUBDOMAINS=www - TZ=America/NewYork - VALIDATION=dns # using dns validation - DNSPLUGIN=dnsimple # via dnsimple, note there is additional configuration require separate from this file # - STAGING=true # this should be uncommented when testing for initial success, to avoid some rate limiting
kritnerwebsite: image: ${DOCKER_REGISTRY}/kritnerwebsite networks: - frontend expose: - "5000" restart: always container_name: kritnerwebsite networks: frontend:

for the new parts:

nginx: image: linuxserver/letsencrypt

Using a different image — linuxserver/letsencrypt instead of nginx. This image has nginx included, but also certbot, along with a cronjob to run certbot at application start.

ports: - "80:80" - "443:443"

Now we’re using both http and https ports (though note, we’re redirecting http calls to https via the nginx config).

volumes: - ${DOCKER_KRITNER_NGINX}:/config - ./nginx.conf:/config/nginx/site-confs/default

Already discussed earlier in the post, we’re using these volumes to properly set up the nginx configuration, with our dnsimple api key, as well as our reverse proxying to the kritnerwebsite.

environment: - PUID=1001 # get on dockerhost through command "id " - PGID=1001 - [email protected] - URL=kritner.com - SUBDOMAINS=www - TZ=America/NewYork - VALIDATION=dns # using dns validation - DNSPLUGIN=dnsimple # via dnsimple, note there is additional configuration require separate from this file # - STAGING=true # this should be uncommented when testing for initial success, to avoid some rate limiting

Environment variables needed as per the letsencrypt documentation can be found here.

  • PUID/PGID — get on dockerhost through command “id ”
  • Email — well, your email (used for cert expiration emails apparently)
  • URL — the main domain URL
  • subdomains — any subdomains to the URL to be certified
  • TZ — timezone
  • Validation — the type of validation to do — I’m using DNSimple, so i needed DNS in this field. Other options are html, tls-sni
  • dnsplugin — dnsimple — other options are cloudflare, cloudxns, digitalocean, dnsmadeeasy, google, luadns, nsone, rfc2136 and route53 as per the letsencrypt documentation
  • Vaihe = tosi - käytin tätä testatakseni kaikki erilaiset yritykseni ennen sen saamista toimimaan. letencryptillä on nopeudenrajoitin, kun sitä ei käytetä lavastustilassa (tai ainakin lavastuksessa sitä on vaikeampi ajaa vastaan).

Kaikki edellä mainitut muutokset, kokeilu, epäonnistuminen ja lopulta onnistuminen löytyvät tästä vetopyynnöstä.

Lopputulos?

ja osoitteesta //www.ssllabs.com/ -

Ei "A +", mutta ei todellakaan ole huono yhden ennalta rakennetun telakointikuvan käyttämisestä HTTP-tarpeitani varten!

Liittyvät:

  • Siirtyminen “A”: sta ”A +”: ksi osoitteessa ssllabs.com