Å publisere en Docker-applikasjon

I Dockerfile-øvelsen bygde du et image og startet appen med docker run. Har du gjort den valgfrie Compose-øvelsen, kan du bruke Compose i stedet. Her skal du få samme app til å svare gjennom et DNS-navn og en tilgjengelig proxy. Du kan bruke egen app eller testappen fra Dockerfile-øvelsen.

Gjør først den direkte testen, deretter HTTP gjennom proxyen. Grunnløypen er ferdig når navnet gir det forventede appsvaret og du kan forklare leddene. HTTPS og installasjon av en egen proxy er viderevalg med egne forutsetninger.

Når Flask-applikasjonen kjører på en server med en port, kan en reverse proxy ta imot forespørsler på vegne av applikasjonen og sende dem videre til riktig container. Da kan brukeren bruke et domenenavn i stedet for IP-adresse og portnummer. Du trenger et DNS-navn og en proxy som du har tilgang til å konfigurere, og et sertifikat hvis tjenesten skal bruke HTTPS.

DNS svarer med en adresse og transporterer ikke nettsiden. I figuren avslutter proxyen HTTPS-forbindelsen og bruker HTTP videre i et avgrenset internt nett. Nettleseren mottar svaret gjennom proxyen.

Før du begynner

Du trenger en fungerende container fra Dockerfile-øvelsen (eller Compose-øvelsen) og disse opplysningene fra testmiljøet:

• APP-VM-IP: adressen til VM-en som kjører appen; her brukes port 5000.
• PROXY-IP: adressen klienten skal nå proxyen på, med HTTP på port 80.
• APP-NAVN: et DNS-navn som peker til proxyen. App og proxy kan ligge på ulike VM-er.

Du trenger tilgang til å opprette en Proxy Host i Nginx Proxy Manager og tillatelse til forbindelsen fra proxyen til appen. Plassholderne over må erstattes med verdiene dine. Er DNS eller proxytilgang ikke tilgjengelig, gjør du den lokale testen og forklarer figuren. Det gir ikke en fullført publiseringstest.

1. Kontroller appen lokalt

Arbeid i prosjektmappen på app-VM-en. Kommandoene under bruker containernavnet min-app fra Dockerfile-øvelsen. Med portbindingen derfra skal denne testen gi hovedsiden:

docker ps
curl --fail --show-error http://127.0.0.1:5000/

Du kan bruke /status som et fast kontrollpunkt. Finnes denne ruten ikke fra før, legger du den etter de andre fullstendige rutefunksjonene og før if __name__ == "__main__": i app.py:

@app.route("/status")
def status():
    return {"status": "ok"}

Bygg, start og test på nytt:

docker build -t min-app .
docker rm -f min-app
docker run -d --name min-app -p 127.0.0.1:5000:5000 min-app
curl --fail --show-error http://127.0.0.1:5000/status

Bruker du Compose, erstatter docker compose up -d --build de tre første kommandoene.

Forvent HTTP 200 og JSON med "status": "ok". Har appen allerede /status, bruk det dokumenterte svaret der i stedet for å lage en ny rute med samme navn. Dette kontrollerer ruten, ikke alle appfunksjoner.

2. Gjør appen tilgjengelig for proxyen

Oppskriften videre bruker app-VM-ens nettverksadresse. Er porten bare bundet til 127.0.0.1, starter du containeren på nytt med VM-ens faktiske adresse i portkoblingen. Begrens nettverkstilgangen til nødvendige kilder; en adressebinding alene begrenser ikke hvilke klienter som får koble til.

docker rm -f min-app
docker run -d --name min-app -p APP-VM-IP:5000:5000 min-app
curl --fail --show-error http://APP-VM-IP:5000/status

Bruker du Compose, erstatter du i stedet portlinjen under app i compose.yaml med "APP-VM-IP:5000:5000" og kjører docker compose up -d.

Kjør testen på app-VM-en og fra proxyens nettverksmiljø, eller fra en testklient med samme tillatte tilgang. Proxyens faktiske forbindelse kontrolleres også med navnet i neste del. Etter endret binding tester du VM-adressen, ikke 127.0.0.1. Ikke åpne porten mot hele internett. Segmentering gir støtte til tilgangsregelen.

Fra domene til container

Det skjer flere ting når en bruker åpner et navn som https://app.example.test. Dette er et eksempelnavn; erstatt det med navnet som faktisk er satt opp i testmiljøet ditt:

sequenceDiagram
    participant B as Nettleser
    participant D as DNS
    participant P as Nginx Proxy Manager
    participant F as Flask-container

    B->>D: Finn IP-adressen til domenet
    D-->>B: Proxyens IP-adresse
    B->>P: Forespørsel til domenet
    P->>P: Finn riktig Proxy Host
    P->>F: Videresend til intern port 5000
    F-->>P: Returner HTML-side
    P-->>B: Returner svaret

Det er derfor lurt å teste ett lag om gangen, i stedet for å feilsøke DNS, proxy og Flask samtidig.

Nginx Proxy Manager

Nginx Proxy Manager er et webgrensesnitt for Nginx. Her bruker du en tilgjengelig installasjon og lager én Proxy Host. Du trenger ikke installere en ny proxy for hver app.

Opprett en Proxy Host:

1. Skriv APP-NAVN, navnet som faktisk er satt opp for tjenesten.
2. Velg http som scheme for forbindelsen fra Nginx Proxy Manager til containeren.
3. Skriv APP-VM-IP som forward hostname. 127.0.0.1 inne i en proxycontainer betyr proxycontaineren selv.
4. Skriv containerens publiserte port, for eksempel 5000.
5. Lagre og åpne http://APP-NAVN/status fra klienten.

Navnet skal slå opp til PROXY-IP. Du kan kontrollere oppslaget med nslookup APP-NAVN på klienten. HTTP-testen skal gi samme statussvar som den direkte testen. Å få opp proxyens standardside viser ikke at forespørselen traff appen.

Viderevalg: HTTPS

Når HTTP virker og du har et gyldig sertifikat for navnet, åpner du SSL-fanen, velger sertifikatet og tester https://APP-NAVN/status. Et internt eksempelnavn som app.example.test kan ikke få et offentlig sertifikat fra Let’s Encrypt; da trenger du et sertifikat fra en intern utsteder som klienten stoler på. DNS-oppslaget alene setter ikke opp HTTPS. HTTP-grunnløypen er lokal øving; ved behandling av innlogging eller andre beskyttelsesverdige data trenger du HTTPS.

Proxyen må kunne nå porten på serveren. Hvis containeren kjører på en annen VM, må nettverk og brannmur tillate trafikken mellom VM-ene. Du trenger ikke eksponere Flask-porten direkte mot hele internett når Nginx Proxy Manager er inngangspunktet; begrens tilgangen med brannmur etter skolens oppsett.

Viderevalg: Egen proxy

Installer bare en egen proxy når du faktisk trenger en og har et eget testmiljø. Bruk Nginx Proxy Managers installasjonsveiledning. Deretter går du tilbake til oppretting av Proxy Host over. Dette er et eget oppsett, ikke et forkrav til å bruke en eksisterende proxy.

Feilsøking

docker ps
docker logs -f min-app
ss -tulpn

Bruker du Compose, heter de to første docker compose ps og docker compose logs -f. Kjør kommandoene én om gangen på app-VM-en. Avslutt logs -f med Ctrl+C. ps viser containerstatus, loggen viser appens meldinger, og ss kan gi støtte til å undersøke lytteporter. Bruk resultatet fra den konkrete HTTP-testen til å kontrollere tilgang.

Test i denne rekkefølgen:

1. På app-VM-en etter endret binding: curl --fail --show-error http://APP-VM-IP:5000/status.
2. Fra proxyens nettverksmiljø: samme adresse, port og rute. En vilkårlig klient kan ha andre tilgangsregler.
3. Fra klienten gjennom navnet: nslookup APP-NAVN, deretter http://APP-NAVN/status. Test HTTPS separat hvis det er konfigurert.

Hvis punkt 1 feiler, undersøk app, containerstatus, adresse og portbinding. Hvis punkt 1 virker og punkt 2 feiler, undersøk forbindelsen og tilgangsreglene fra proxyen. Hvis punkt 2 virker og punkt 3 feiler, undersøk DNS, Proxy Host og valgt protokoll. HTTP 404 betyr at en HTTP-server svarte, men ruten kan være feil; 502 fra proxyen peker mot forbindelsen eller svaret fra appen. Noter hva testen avgrenser før du endrer noe.

Neste steg

Vis statussvaret gjennom navnet og forklar forskjellen mellom DNS-oppslaget og videresendingen i proxyen. Pek også ut klient, proxy og app i figuren eller egen skisse. Du kan forklare muntlig eller skriftlig. Oppgi testadresse, forventet/faktisk svar og om du har prøvd HTTP eller HTTPS. Ved avvik bruker du testrekkefølgen over før du går videre.

Når grunnløypen virker, kan du bruke oppsettet videre i prosjektet. Docker - Publisere container med workflow er videre opplæring i å automatisere bygging og publisering av imaget.

Kilder: Docker: portbinding, Nginx Proxy Manager og Flask: ruter og svar.