5 Docker komponerer eksempler
Det er en enkel måte å sette opp automatisert applikasjonsdistribusjon med en frontend, en database og noen få passord og tilgangstaster kastet inn for godt mål. Hver gang du kjører Docker-Compose Up fra en katalog som inneholder en Docker-Compose.yml den går gjennom filen og distribuerer applikasjonen din som spesifisert.
For å hjelpe deg med å skrive din egen Docker-komponering.yml her er 5 enkle og forhåpentligvis nyttige YAML -utdrag som du kan blande og matche.
1. Nginx omvendt proxy
Sannsynligvis den vanligste applikasjonen som skal distribueres som en Docker -beholder er Nginx. Nginx kan fungere som omvendt proxy -server og som SSL -termineringspunkt for webapplikasjonene dine. Ulike innholdsstyringssystemer som Ghost og WordPress kan være vert bak en enkelt Nginx Reverse Proxy Server, og dermed er det fornuftig å ha et Nginx Server -utdrag til enhver tid. Det første du trenger er en Nginx -konfigurasjonsfil. Hvis du velger å ikke opprette en, er standard http -server det du vil få.
For eksempel vil jeg opprette en mappe nginx-konfigurasjon i hjemmemappen min. Konfigurasjonsfilen nginx.Conf vil være til stede i denne mappen, sammen med andre filer kataloger som Nginx ville forvente på /etc /nginx. Dette inkluderer SSL -sertifikater og nøkler, og vertsnavn for backend -serverne der trafikken må videresendes.
Denne mappen kan deretter monteres inne i Nginx-beholderen på /etc /nginx (med skrivebeskyttet tillatelse hvis du foretrekker ekstra forsiktighet) og du kan kjøre serveren som en container, men du kan konfigurere den lokalt fra hjemmekatalogen uten å måtte logge inn i beholderen.
Dette er et utvalg:
Versjon: '3'tjenester:
nginx:
Bilde: Nginx: Siste
Volum:
- /Hjem/bruker/nginx-konfigurasjon:/etc/nginx
Porter:
- 80:80
- 443: 443
Spøkelsesblogg
Ghost er en CMS skrevet mest i node.JS og er forenklet, rask og elegant i design. Den er avhengig av Nginx for å rute trafikk til den og bruker MariaDB eller noen ganger SQLite for å lagre data. Du kan distribuere et raskt og skittent Docker -bilde for Ghost ved hjelp av et enkelt utdrag som vist nedenfor:
Versjon: '3'tjenester:
spøkelse:
Bilde: Ghost: Siste
Porter:
- 2368: 2368
Volum:
- spøkelsesdata:/var/lib/spøkelse/innhold/
Volum:
Spøkelsesdata:
Dette skaper et nytt volum og monterer det inne i beholderen for å lagre nettstedets innhold vedvarende. Du kan legge til den forrige Nginx Reverse Proxy -tjenesten i denne komponeringsfilen og ha en spøkelsesblogg for produksjonskarakter i løpet av minutter, forutsatt at du har konfigurert Nginx for å rute relevant trafikk fra port 80 eller 443 til port 2368 på spøkelset container.
Mariadb
MariaDB er ganske nyttig programvare for ikke å være tilgjengelig med et øyeblikks samtale på serveren din. Databaser lager imidlertid mange logger, de faktiske dataene har en tendens til å bli spredt over alt og sette opp databaseservere og/eller klienter går aldri greit. Den nøye utformede Docker-Compose-filen kan dempe noen av problemene ved å prøve å lagre alle relevante data i et enkelt Docker-volum, mens databasen programvare og dens kompleksiteter er gjemt bort i A -beholderen:
Versjon: '3'tjenester:
MYDB:
Bilde: MariaDB
miljø:
- Mysql_root_password = my-Secret-pw
Du kan opprette en ny databasebeholder for hver nye applikasjon, i stedet for å opprette flere brukere i samme database, sette opp privilegier og gå gjennom en smertefull Rigmarole for å sikre at hver app og bruker holder seg på sin egen torv. Du trenger heller ikke å åpne porter på vertssystemet siden databasebeholderen kjøres på sitt eget isolerte nettverk, og du kan ha det slik at bare applikasjonen din kan være en del av det nettverket og dermed få tilgang til databasen.
WordPress Stack
En kulminasjon av alle de forskjellige delene fra bruk av miljøvariabler til å kjøre en frontend-webserver og en backend-database kan kombineres i en Docker-Compose-fil for et WordPress-nettsted, som vist nedenfor:
Versjon: '3.3 'tjenester:
DB:
Bilde: MySQL: 5.7
Volum:
- db_data:/var/lib/mysql
Start på nytt: Alltid
miljø:
Mysql_root_password: SomewordPress
Mysql_database: WordPress
Mysql_user: WordPress
Mysql_password: wordpress
WordPress:
kommer an på:
- db
Bilde: WordPress: Siste
Porter:
- "8000: 80"
Start på nytt: Alltid
miljø:
WordPress_DB_HOST: DB: 3306
WordPress_DB_USER: WordPress
WordPress_DB_Password: WordPress
Volum:
db_data:
Dette er det mest populære eksemplet og nevnes også i den offisielle Docker-Compose-dokumentasjonen. Sjansen er stor for at du ikke vil distribuere WordPress, men komponeringsfilen her kan fremdeles fungere som en rask referanse for lignende applikasjonsstabler.
Docker-Compose med DockerFiles
Så langt har vi bare taklet den rene distribusjonssiden av Docker-Compose. Men sjansen er stor for at du bruker komponering for ikke bare å distribuere, men utvikle, teste og deretter distribuere applikasjoner. Enten du kjører på din lokale arbeidsstasjon, eller på en dedikert CD/CI-server, kan Docker-Compose bygge et bilde ved å bruke DockerFile som er til stede i roten til depotet om applikasjonen din eller en del av applikasjonen:
Versjon: '3'tjenester:
Front-end:
bygge: ./frontend-kode
baksiden:
Bilde: MariaDB
..
Du vil ha lagt merke til at mens backend-tjenesten bruker et eksisterende bilde av MariaDB, er frontend-bildet først bygget fra Dockerfile som ligger inne ./frontend-kodekatalog.
LEGO-blokker av Docker-Compose
Hele funksjonaliteten til Docker-Compose er ganske enkel å forstå hvis vi bare spør oss selv hva det er som vi prøver å bygge. Etter noen få skrivefeil og mislykket forsøk, vil du sitte igjen med et sett med utdrag som fungerer feilfritt og kan settes sammen som LEGO -byggesteiner for å definere applikasjonsdistribusjonen.
Jeg håper de ovennevnte få eksemplene vil gi deg et godt forsprang med det. Du kan finne den komplette referansen for å skrive komponere fil her.