Usiamo Postgres e Docker dove lavoro e abbiamo finito per fare il seguente:
- Copiare il Dockerfile dal Postgres ufficiali repo modo da poter rendere la propria immagine.
- Modifica docker-entrypoint.sh (https://github.com/docker-library/postgres/blob/8f80834e934b7deaccabb7bf81876190d72800f8/9.4/docker-entrypoint.sh), che è ciò che viene chiamato all'avvio del contenitore.
In cima docker-entrypoint.sh, ho messo il seguente:
# Get the schema
url=$(curl -s -u ${GIT_USER}:${GIT_PASSWORD} "${SQL_SCRIPT_URL}" | python -c 'import sys, json; print json.load(sys.stdin)["download_url"]')
curl ${url} > db.sh
chmod +x db.sh
cp db.sh ./docker-entrypoint-initdb.d
Questo download fondamentalmente uno script di shell da Github che inizializza lo schema per il database. Facciamo questo per gestire le versioni dello schema, quindi quando avvii il tuo contenitore puoi dire quale schema usare tramite una variabile ENV.
Alcune note sul codice:
- abbiamo bisogno di refactoring per tirare roba da Github utilizzando una chiave privata al posto delle credenziali utente.
- La directory ./docker-entrypoint-initdb.d è un punto in cui docker-entrypoint.sh cercherà di eseguire gli script di init per il database. Puoi spostare i file in quella posizione come preferisci. Fai questo se il download da Github non è applicabile.
Grazie. Immagino che lo script sia scritto in modo tale che non abbia importanza se viene eseguito quando il database è già stato creato? Sto pensando se il contenitore DB dovesse essere riavviato. – stewartml
Sì, se si mantiene il database sull'host con i volumi condivisi, quindi quando lo si riavvia si potrebbe ottenere un reclamo che il database esiste già. Ma per cose come le tabelle, puoi usare IF NOT EXISTS in modo che non si lamenti tanto. =) Suppongo che potresti persino fare un controllo migliore per interrogare il database per vedere se gli oggetti esistono e se lo fanno, quindi fermati. – ryan1234