I'm trying to run a simple postgres with docker-compose, which is more challenging than I thought. I'm running it on a Raspberry Pi 4 Model B Rev 1.1 with docker-compose at 1.27.4.
It fails after calling docker-compose up with the following output:
mydb_1 | Success. You can now start the database server using:
mydb_1 |
mydb_1 | pg_ctl -D /var/lib/postgresql/data -l logfile start
mydb_1 |
mydb_1 | waiting for server to start....[36] LOG: starting PostgreSQL 13.1 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 32-bit
mydb_1 | [36] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
mydb_1 | ......[36] LOG: startup process (PID 37) was terminated by signal 11: Segmentation fault
mydb_1 | [36] LOG: aborting startup due to startup process failure
mydb_1 | [36] LOG: database system is shut down
mydb_1 | pg_ctl: could not start server
mydb_1 | Examine the log output.
mydb_1 | stopped waiting
docker-compose.yaml
version: '3'
services:
mydb:
image: postgres:13.1-alpine
environment:
- POSTGRES_USER=synapse
- POSTGRES_PASSWORD=test
volumes:
- synapse-db:/var/lib/postgresql/data
volumes:
synapse-db:
Any ideas why this might happen?
I had the same issue with the latest images (I tried all from 9 to 13).
Looks like the problem is the latest build, so I replaced 9-alpine version which was commited a couple of days ago with 9.4.23-alpine which is 3 months old and the problem disappeared.
So try to pick any version older than a week here https://hub.docker.com/r/arm32v7/postgres/tags?page=1&ordering=last_updated
The option
security_opt:
- seccomp:unconfined
in docker-compose worked for me.
I'm experiencing the same issue here even when removing the old database by removing the volume which contains it.
I tried with postgres:12-alpine and postgres:9-alpine and same result:
...
waiting for server to start....LOG: startup process (PID 30) was terminated by signal 11: Segmentation fault
LOG: aborting startup due to startup process failure
LOG: database system is shut down
pg_ctl: could not start server
...
After investigation, this is again the alpine:3.13 hell on raspbian as described here: https://github.com/docker-library/redis/issues/269#issuecomment-778588162
Just install the latest version of libseccomp as described in this comment and restart everything, it should work...:
wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.2-2_armhf.deb
sudo dpkg -i libseccomp2_2.5.2-2_armhf.deb
Related
I have a docker compose setup that was working before (for several months) but after restarting the Pi its now not working :(
Whats to be noted is that when pointing the DB to an empty DB folder, there are no restarts of the Postgres container and no errors. I tried one backup from the past for the DB data folder but still getting the error. Not sure why?
Here is the error postgres is returning:
PostgreSQL Database directory appears to contain a database; Skipping initialization
2021-03-30 13:38:46.052 UTC [1] LOG: starting PostgreSQL 12.1 (Debian 12.1-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
2021-03-30 13:38:46.053 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2021-03-30 13:38:46.053 UTC [1] LOG: listening on IPv6 address "::", port 5432
2021-03-30 13:38:46.063 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-03-30 13:38:48.195 UTC [1] LOG: startup process (PID 26) was terminated by signal 11: Segmentation fault
2021-03-30 13:38:48.195 UTC [1] LOG: aborting startup due to startup process failure
2021-03-30 13:38:48.272 UTC [1] LOG: database system is shut down
Here is part of the docker compose file for the DB:
miniflux-db:
container_name: miniflux-db
image: postgres:12-alpine
environment:
- POSTGRES_USER=${MINIFLUX_DB_USER}
- POSTGRES_PASSWORD=${MINIFLUX_DB_PASSWORD}
restart: unless-stopped
volumes:
- ${MINIFLUX_DB}:/var/lib/postgresql/data:shared
networks:
- miniflux-net
Info:
Raspberry Pi 4
Docker version 20.10.5, build 55c4c88
I can't even port the data to version 13 of Postgres nor use the Postgres DB folder on an Intel architecture. Had I known that Postgres DB data folder is architecture-bound I would not have chosen it!
Any help pls? Thanks!
try this:
wget http://ftp.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.1-1_armhf.deb
sudo dpkg -i libseccomp2_2.5.1-1_armhf.deb
I my case I had to prune docker then it worked.
You can try this: Segmentation fault on RPi #812
Raspbian OS has a old version from libseccomp, you need to upgrade this lib manually.
If you have some volumes used by container, remove then before start postgres container again.
I have a PostgreSQL database for some sensoric data on my Raspberry Pi. It runs on the postgres:12-alpine tag without automatic updates yet. Before the update, I got the following version string:
('PostgreSQL 12.3 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 9.3.0) 9.3.0, 32-bit',)
After I noticed that it was a bit out of date, I pulled the latest image with the following version string:
('PostgreSQL 12.6 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 32-bit',)
This worked, but I noticed that new inserted sensor data got a timestamp from 2038 when using NOW(). It seems complicated to solve with Alpine, maybe also an Alpine issue. I already had trouble with issues created by their musl usage. Since the normal image is not too much larger (109MB vs 62MB), I switched to the regular postgres:12 image.
Since the container was started with the normal Debian image, the startup failed:
postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2021-03-31 17:00:05.213 UTC [1] LOG: starting PostgreSQL 12.3 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 9.3.0) 9.3.0, 32-bit
postgres_1 | 2021-03-31 17:00:05.214 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-03-31 17:00:05.214 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-03-31 17:00:05.226 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-03-31 17:00:11.083 UTC [1] LOG: startup process (PID 20) was terminated by signal 11: Segmentation fault
postgres_1 | 2021-03-31 17:00:11.084 UTC [1] LOG: aborting startup due to startup process failure
postgres_1 | 2021-03-31 17:00:14.480 UTC [1] LOG: database system is shut down
pms_postgres_1 exited with code 1
Same issue with the Debian image:
postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2021-03-31 17:11:19.733 UTC [1] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on arm-unknown-linux-gnueabihf, compiled by gcc (Debian 8.3.0-6) 8.3.0, 32-bit
postgres_1 | 2021-03-31 17:11:19.738 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2021-03-31 17:11:19.738 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2021-03-31 17:11:19.752 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2021-03-31 17:11:28.520 UTC [1] LOG: startup process (PID 27) was terminated by signal 11: Segmentation fault
postgres_1 | 2021-03-31 17:11:28.520 UTC [1] LOG: aborting startup due to startup process failure
postgres_1 | 2021-03-31 17:11:35.024 UTC [1] LOG: database system is shut down
pms_postgres_1 exited with code 1
It's also not working with the latest 12.6 release. I'm assuming that the problem was, I switched from Alpine to Debian AND also updated the PostgreSQL version with the pull. So PSQL 12.3 on Alpine was upgraded to PSQL 12.6 on Debian.
Why does this Segmentation fault error occur and how can I fix it?
My docker-compose.yml:
version: '2.4'
volumes:
#postgres-data_new:
postgres-data:
services:
postgres:
image: postgres:12.6
#image: postgres:12.3-alpine
#image: postgres:12-alpine
restart: always
volumes:
- postgres-data:/var/lib/postgresql/data
- ./create-tables.sql:/docker-entrypoint-initdb.d/create-tables.sql
environment:
POSTGRES_PASSWORD: xx
POSTGRES_DB: xxx
ports:
- 5432:5432
create-tables.sql just creates a very basic measure data table:
create table if not exists sensors(
id SERIAL PRIMARY KEY,
soilMoisture NUMERIC NOT NULL,
temp NUMERIC NOT NULL,
dateTime timestamp NOT NULL
);
It seems that the problem is an outdated libseccomp version on the host: libseccomp 2.4.2 or newer and Docker to 19.03.9 or newer are required. But my RPI has just 2.3.3 from the repos:
# dpkg -l | grep libseccomp
ii libseccomp2:armhf 2.3.3-4 armhf high level interface to Linux seccomp filter
There are two ways to fix this, but only for new containers with fresh volumes. I still couldn't get my existing database from the volume working with that.
#1 Install a newer version manually and bypass the package manager
At least until the repos got updated. I guess this will happen after some time, then we can use the version provided by Raspbians repos again.
wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.1-1_armhf.deb
sudo dpkg -i libseccomp2_2.5.1-1_armhf.deb
#2 Disable it in docker-compose.yml as workaround
security_opt:
- seccomp:unconfined
But this will reduce the security of the host against malicious code in the container, so updating the library seems to be a more secure solution.
I am trying to set up a postgres container to start and run initializing the creation of a table. I've succeeded with the straight image from docker but now that I am trying to extend the image a little to create tables when it's produced and I can't get it running. Based off what I've read here How to create User/Database in script for Docker Postgres, this is what I have:
Dockerfile:
FROM library/postgres
COPY init.sql /docker-entrypoint-initdb.d/
init.sql:
CREATE TABLE incident_disposition (
incident_disposition_code VARCHAR,
incident_disposition_code_description VARCHAR
);
From what I understand, FROM library . . . pulls the postgres image from docker hub and the COPY pushes my init.sql script into the entry point so there is no need for a big dockerfile correct?
I then build the image no issue:
Build
docker build -t my_postgres_image .
But when I run I get the issues:
Run
docker run --name testing my_postgres_image --publish 8000:8080 --detach -e POSTGRES_PASSWORD=postgres -d postgres
Errors from logs
Error: Database is uninitialized and superuser password is not specified.
You must specify POSTGRES_PASSWORD to a non-empty value for the
superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
connections without a password. This is *not* recommended.
See PostgreSQL documentation about "trust":
https://www.postgresql.org/docs/current/auth-trust.html
Attempt from comment:
docker container logs testing
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2020-03-26 14:06:51.064 UTC [46] LOG: starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2020-03-26 14:06:51.072 UTC [46] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2020-03-26 14:06:51.108 UTC [47] LOG: database system was shut down at 2020-03-26 14:06:50 UTC
2020-03-26 14:06:51.119 UTC [46] LOG: database system is ready to accept connections
done
server started
/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sql
CREATE TABLE
2020-03-26 14:06:51.231 UTC [46] LOG: received fast shutdown request
waiting for server to shut down....2020-03-26 14:06:51.232 UTC [46] LOG: aborting any active transactions
2020-03-26 14:06:51.233 UTC [46] LOG: background worker "logical replication launcher" (PID 53) exited with exit code 1
2020-03-26 14:06:51.234 UTC [48] LOG: shutting down
2020-03-26 14:06:51.290 UTC [46] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
2020-03-26 14:06:51.345 UTC [1] LOG: starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2020-03-26 14:06:51.345 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2020-03-26 14:06:51.345 UTC [1] LOG: listening on IPv6 address "::", port 5432
2020-03-26 14:06:51.361 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2020-03-26 14:06:51.387 UTC [64] LOG: database system was shut down at 2020-03-26 14:06:51 UTC
2020-03-26 14:06:51.398 UTC [1] LOG: database system is ready to accept connections
2020-03-26 14:07:27.715 UTC [72] ERROR: relation "incident_disposition" does not exist at character 15
2020-03-26 14:07:27.715 UTC [72] STATEMENT: select * from incident_disposition;
In addition to comments
Due to recent docker image's updates postgres images do not allow to connect to DB without a password from anywhere. So you need to specify username/password
docker run -p 8000:8080 -e POSTGRES_PASSWORD=postgres --name testing -d my_postgres_image
Or if you still don't want to use password, you can just set POSTGRES_HOST_AUTH_METHOD=trust environment variable:
docker run -p 8000:8080 -e POSTGRES_HOST_AUTH_METHOD=trust --name testing -d my_postgres_image
It is a typical Initialization scripts issue.
You can file the full explaination in postgresql docker page. https://hub.docker.com/_/postgres
Here is the brief intro:
1. One common problem is that if one of your /docker-entrypoint-initdb.d scripts fails (which will cause the entrypoint script to exit) and your orchestrator restarts the container with the already initialized data directory, it will not continue on with your scripts.
note:
in your case, you may need clean the historical docker containers(stopped) by
step 1: docker ps |grep
step 2: docker rm -f -v
Or if you are using docker-compose, the historical orchestrator could be easily removed by docker-compose down -v.
I am in the process of experimenting/tinkering/learning/breaking with Docker. I am currently writing Docker code to create a snapshotted testing environment for my application.
By snapshotted I mean that my database is reset on purpose on every restart, so that I can work with old data at a certain time. What is peculiar in my case is that I want to populate a Postgresql database at build time, not at start time. Postgresql image is ready for populating the db with sql scripts at container start, but it takes hours.
My application is made by a Tomcat 8.5 server running my WAR and a Postgresql database, which is the focus of my question now. I am creating a Gist while I write for full code.
The code I have done
Full code on Gist
I have followed a tutorial on how to build a Docker image of Postgres with a full database, rather than have Postgres populate itself on boot. This because I have a million record database and only a .sql.gz dump that sysop gave me.
So the relevant parts of the Dockerfile are
WORKDIR /opt/setup/
COPY db-setup.sh /opt/setup/
COPY db-pack.sh /opt/setup/
COPY db-run.sh /opt/setup/
RUN ./db-setup.sh
RUN ./db-pack.sh
#VOLUME $PGDATA (Note it is commented out, now)
EXPOSE 5432
The db-setup.sh is run on image build, and picks files from data-scripts.d. Of course I am not allowed to share the contents of the dump, but it's a plain .sql.gz with plenties of OIDs that take a huge amount of time to restore. The db-setup.sh shown in Gist is derived from both the tutorial and the original Postgres image so that it handles correctly the compression (the tutorial only uses plain SQL)
Build succeeds, startup fails
When I build the image, it takes considerable amount of time to load the data, which is what I want
2019-08-07 07:57:04.149 UTC [49] LOG: database system was shut down at 2019-08-07 07:57:03 UTC
2019-08-07 07:57:04.231 UTC [48] LOG: database system is ready to accept connections
done
server started
./db-setup.sh: running methodinv_pcp3.sql.gz
2019-08-07 08:49:52.052 UTC [117] ERROR: canceling autovacuum task
2019-08-07 08:49:52.052 UTC [117] CONTEXT: automatic analyze of table "postgres.public.ftt_interactive_data_492"
2019-08-07 08:49:59.086 UTC [118] ERROR: canceling autovacuum task
2019-08-07 08:49:59.086 UTC [118] CONTEXT: automatic analyze of table "postgres.public.ftt_oper_492"
2019-08-07 08:50:34.086 UTC [118] ERROR: canceling autovacuum task
2019-08-07 08:50:34.086 UTC [118] CONTEXT: automatic analyze of table "postgres.public.ftt_validation_492"
2019-08-07 08:51:11.889 UTC [119] ERROR: canceling autovacuum task
2019-08-07 08:51:11.889 UTC [119] CONTEXT: automatic analyze of table "postgres.public.ftt_oper_492"
2019-08-07 08:54:21.131 UTC [123] ERROR: canceling autovacuum task
2019-08-07 08:54:21.131 UTC [123] CONTEXT: automatic analyze of table "postgres.public.ftt_oper_492"
waiting for server to shut down...2019-08-07 08:54:28.652 UTC [48] LOG: received fast shutdown request
.2019-08-07 08:54:28.797 UTC [48] LOG: aborting any active transactions
2019-08-07 08:54:28.799 UTC [48] LOG: worker process: logical replication launcher (PID 55) exited with exit code 1
2019-08-07 08:54:28.800 UTC [50] LOG: shutting down
..2019-08-07 08:54:31.407 UTC [48] LOG: database system is shut down
done
When I run the image with docker run, startup fails because it can't find Postgres configuration
D:\IdeaProjects\pcp\ftt-containers\ftt-db-method>docker run -p 5432:5432 -l ftt-db-method ftt-db-method:latest
Restoring /var/lib/postgresql/data ...
Done.
Launching command: postgres ...
postgres: could not access the server configuration file "/var/lib/postgresql/data/postgresql.conf": No such file or directory
Originally, my Dockerfile exposed a VOLUME which is now commented out. The above output occurs both when I declare a volume (which is not exactly what I want, I am new to Docker and copied&pasted on first chance) and when I comment the volume out.
Question
What is wrong with the Docker image of Postgres fully loaded with s**tloads of data I am experimenting?
How can I effectively start Postgres with an already full database that will not (necessarily) survive container restarts?
Edit 1
By bash-ing into the container I have found that the data dump created during build time is 10K, so basically empty.
This doesn't solve my problem yet, but answers why Postgres is unable to find its beloved data dir
Edit 2
I was able to bash into a temporary container, in particular between the moment the database is restored and the data lib is packed.
Basically the Dockerfile does
RUN ./db-setup.sh
Which executes the restore of the sql
echo "$0: running $f"; gunzip -c "$f" | "${psql[#]}" > /dev/null 2>&1 ; echo ;;
The output is saved to a temporary container.
Now Dockerfile does
RUN ./db-pack.sh
Which tars /var/lib/postgresql/data into /zdata. I have
2019-08-07 16:43:51.532 UTC [42] LOG: received fast shutdown request
waiting for server to shut down....2019-08-07 16:43:51.676 UTC [42] LOG: aborting any active transactions
2019-08-07 16:43:51.679 UTC [42] LOG: worker process: logical replication launcher (PID 49) exited with exit code 1
2019-08-07 16:43:51.681 UTC [44] LOG: shutting down
...2019-08-07 16:43:54.952 UTC [42] LOG: database system is shut down
done
server stopped
Removing intermediate container 8dbe2a4e776a
---> 263896b905ce
Step 15/19 : RUN ./db-pack.sh
---> Running in 56132ecb90cc
Packing data folder: /var/lib/postgresql/data
Pack & clean finished successfully.
Removing intermediate container 56132ecb90cc
---> 1a7f8d68e8df
Step 16/19 : VOLUME $PGDATA
---> Running in 10d222beed81
Removing intermediate container 10d222beed81
---> e1a9355882d1
So I tagged 263896b905ce (YHMV if you replicate on your pc) into a new image, then executed bash on it. The data dir was empty, the script would have packed nothing
docker tag 263896b905ce examine
docker run -it --entrypoint /bin/bash examine
root#ab963ace16a1:/opt/setup# ls
data-scripts.d db-pack.sh db-run.sh db-setup.sh
root#ab963ace16a1:/opt/setup# cd /zdata/
root#ab963ace16a1:/zdata# ls
root#ab963ace16a1:/zdata# cd /var/lib/postgresql/
root#ab963ace16a1:/var/lib/postgresql# ls
data
root#ab963ace16a1:/var/lib/postgresql# cd data/
root#ab963ace16a1:/var/lib/postgresql/data# ls
root#ab963ace16a1:/var/lib/postgresql/data# ls -lah
total 8.0K
drwxrwxrwx 2 postgres postgres 4.0K Jul 17 23:55 .
drwxr-xr-x 1 postgres postgres 4.0K Jul 17 23:55 ..
root#ab963ace16a1:/var/lib/postgresql/data#
root#ab963ace16a1:/var/lib/postgresql/data# ls^C
root#ab963ace16a1:/var/lib/postgresql/data# exit
exit
Fixed
According to https://stackoverflow.com/a/52762779/471213
"why doesn't VOLUME work?" When you define a VOLUME in the Dockerfile, you can only define the target, not the source of the volume. During the build, you will only get an anonymous volume from this. That anonymous volume will be mounted at every RUN command, prepopulated with the contents of the image, and then discarded at the end of the RUN command. Only changes to the container are saved, not changes to the volume.
So I had basically to run both RUNs at the same time
RUN ./db-setup.sh && ./db-pack.sh
#RUN ./db-pack.sh
When using the https://github.com/kiasaki/docker-alpine-postgres image in docker compose, the scripts inside /docker-entrypoint.initdb.d are not being executed as I view from the logs:
db_1 | LOG: database system was shut down at 2016-09-05 18:16:02 UTC
db_1 | LOG: MultiXact member wraparound protections are now enabled
db_1 | LOG: database system is ready to accept connections
db_1 | LOG: autovacuum launcher started
The thing is, if I build the Dockerfile standalone and run the container, it will execute the sql files inside the folder, like you can see from the logs:
waiting for server to start....LOG: database system was shut down at 2016-09-05 18:28:18 UTC
LOG: MultiXact member wraparound protections are now enabled
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
done
server started
/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/syna-setup.sql
CREATE TABLE
INSERT 0 1
CREATE TABLE
waiting for server to shut down...LOG: received fast shutdown request
.LOG: aborting any active transactions
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
done
server stopped
LOG: database system was shut down at 2016-09-05 18:28:21 UTC
LOG: MultiXact member wraparound protections are now enabled
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
The docker-compose.yml:
version: '2'
services:
db:
build: ./db
environment:
- POSTGRES_PASSWORD=testpass
restart: always
app:
build: ./app
ports:
- "5000:5000"
volumes:
- .:/app/src
depends_on:
- db
environment:
- DB_SERVER=postgres://postgres:testpass#db:5432/postgres
What am I doing wrong here?
UPDATED as he use his own Dockerfile, not from the github link.
Could you proide the docker run command so that if I build the Dockerfile standalone and run the container, it will execute the sql files inside the folder. You should mount some directory to the container so it can find the SQL files.
I read the Dockerfile at https://github.com/kiasaki/docker-alpine-postgres/blob/master/Dockerfile and asked myself where are the SQL files? It just make the directory without copy SQL files
mkdir /docker-entrypoint-initdb.d
Then, in the docker-entrypoint.sh, it check if there's any SQL file to execute
for f in /docker-entrypoint-initdb.d/*; do
case "$f" in
*.sh) echo "$0: running $f"; . "$f" ;;
*.sql) echo "$0: running $f"; psql --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" < "$f" && echo ;;
*) echo "$0: ignoring $f" ;;
esac
echo
done
I think we should mount a SQL directory, like
version: '2'
services:
db:
build: ./db
environment:
- POSTGRES_PASSWORD=testpass
restart: always
entrypoint:
- docker-entrypoint.sh
volumes:
- ./docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d
- ./docker-entrypoint.sh:/docker-entrypoint.sh