docker hub arm64v8/postgres
https://hub.docker.com/r/arm64v8/postgres
Note: the description for this image is longer than the Hub length limit of 25000, so has been trimmed. The full description can be found at https://github.com/docker-library/docs/tree/master/postgres/README.md. See docker/hub-beta-feedback#238 for more information.
Note: this is the "per-architecture" repository for the arm64v8
builds of the postgres
official image -- for more information, see "Architectures other than amd64?" in the official images documentation and "An image's source changed in Git, now what?" in the official images FAQ.
Quick reference
Maintained by: the PostgreSQL Docker Community
Where to get help: the Docker Community Forums, the Docker Community Slack, or Stack Overflow
Supported tags and respective Dockerfile
links
13.3
,13
,latest
13.3-alpine
,13-alpine
,alpine
12.7
,12
12.7-alpine
,12-alpine
11.12
,11
11.12-alpine
,11-alpine
10.17
,10
10.17-alpine
,10-alpine
9.6.22
,9.6
,9
9.6.22-alpine
,9.6-alpine
,9-alpine
9.5.25
,9.5
9.5.25-alpine
,9.5-alpine
Quick reference (cont.)
Where to file issues: https://github.com/docker-library/postgres/issues
Supported architectures: (more info)
amd64
,arm32v5
,arm32v6
,arm32v7
,arm64v8
,i386
,mips64le
,ppc64le
,s390x
Published image artifact details: repo-info repo's
repos/postgres/
directory (history) (image metadata, transfer size, etc)Image updates: official-images repo's
library/postgres
label
official-images repo'slibrary/postgres
file (history)Source of this description: docs repo's
postgres/
directory (history)
What is PostgreSQL?
PostgreSQL, often simply "Postgres", is an object-relational database management system (ORDBMS) with an emphasis on extensibility and standards-compliance. As a database server, its primary function is to store data, securely and supporting best practices, and retrieve it later, as requested by other software applications, be it those on the same computer or those running on another computer across a network (including the Internet). It can handle workloads ranging from small single-machine applications to large Internet-facing applications with many concurrent users. Recent versions also provide replication of the database itself for security and scalability.
PostgreSQL implements the majority of the SQL:2011 standard, is ACID-compliant and transactional (including most DDL statements) avoiding locking issues using multiversion concurrency control (MVCC), provides immunity to dirty reads and full serializability; handles complex SQL queries using many indexing methods that are not available in other databases; has updateable views and materialized views, triggers, foreign keys; supports functions and stored procedures, and other expandability, and has a large number of extensions written by third parties. In addition to the possibility of working with the major proprietary and open source databases, PostgreSQL supports migration from them, by its extensive standard SQL support and available migration tools. And if proprietary extensions had been used, by its extensibility that can emulate many through some built-in and third-party open source compatibility extensions, such as for Oracle.
How to use this image
start a postgres instance
$ docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d arm64v8/postgres
The default postgres
user and database are created in the entrypoint with initdb
.
The postgres database is a default database meant for use by users, utilities and third party applications.
... or via psql
$ docker run -it --rm --network some-network arm64v8/postgres psql -h some-postgres -U postgres
psql (9.5.0)
Type "help" for help.
postgres=# SELECT 1;
?column?
----------
1
(1 row)
... via docker stack deploy
or docker-compose
Example stack.yml
for postgres
:
# Use postgres/example user/password credentials
version: '3.1'
services:
db:
image: postgres
restart: always
environment:
POSTGRES_PASSWORD: example
adminer:
image: adminer
restart: always
ports:
- 8080:8080
Run docker stack deploy -c stack.yml postgres
(or docker-compose -f stack.yml up
), wait for it to initialize completely, and visit http://swarm-ip:8080
, http://localhost:8080
, or http://host-ip:8080
(as appropriate).
How to extend this image
There are many ways to extend the postgres
image. Without trying to support every possible use case, here are just a few that we have found useful.
Environment Variables
The PostgreSQL image uses several environment variables which are easy to miss. The only variable required is POSTGRES_PASSWORD
, the rest are optional.
Warning: the Docker specific variables will only have an effect if you start the container with a data directory that is empty; any pre-existing database will be left untouched on container startup.
POSTGRES_PASSWORD
This environment variable is required for you to use the PostgreSQL image. It must not be empty or undefined. This environment variable sets the superuser password for PostgreSQL. The default superuser is defined by the POSTGRES_USER
environment variable.
Note 1: The PostgreSQL image sets up trust
authentication locally so you may notice a password is not required when connecting from localhost
(inside the same container). However, a password will be required if connecting from a different host/container.
Note 2: This variable defines the superuser password in the PostgreSQL instance, as set by the initdb
script during initial container startup. It has no effect on the PGPASSWORD
environment variable that may be used by the psql
client at runtime, as described at https://www.postgresql.org/docs/current/libpq-envars.html. PGPASSWORD
, if used, will be specified as a separate environment variable.
POSTGRES_USER
This optional environment variable is used in conjunction with POSTGRES_PASSWORD
to set a user and its password. This variable will create the specified user with superuser power and a database with the same name. If it is not specified, then the default user of postgres
will be used.
Be aware that if this parameter is specified, PostgreSQL will still show The files belonging to this database system will be owned by user "postgres"
during initialization. This refers to the Linux system user (from /etc/passwd
in the image) that the postgres
daemon runs as, and as such is unrelated to the POSTGRES_USER
option. See the section titled "Arbitrary --user
Notes" for more details.
POSTGRES_DB
This optional environment variable can be used to define a different name for the default database that is created when the image is first started. If it is not specified, then the value of POSTGRES_USER
will be used.
POSTGRES_INITDB_ARGS
This optional environment variable can be used to send arguments to postgres initdb
. The value is a space separated string of arguments as postgres initdb
would expect them. This is useful for adding functionality like data page checksums: -e POSTGRES_INITDB_ARGS="--data-checksums"
.
POSTGRES_INITDB_WALDIR
This optional environment variable can be used to define another location for the Postgres transaction log. By default the transaction log is stored in a subdirectory of the main Postgres data folder (PGDATA
). Sometimes it can be desireable to store the transaction log in a different directory which may be backed by storage with different performance or reliability characteristics.
Note: on PostgreSQL 9.x, this variable is POSTGRES_INITDB_XLOGDIR
(reflecting the changed name of the --xlogdir
flag to --waldir
in PostgreSQL 10+).
POSTGRES_HOST_AUTH_METHOD
This optional variable can be used to control the auth-method
for host
connections for all
databases, all
users, and all
addresses. If unspecified then md5
password authentication is used. On an uninitialized database, this will populate pg_hba.conf
via this approximate line:
echo "host all all all $POSTGRES_HOST_AUTH_METHOD" >> pg_hba.conf
See the PostgreSQL documentation on pg_hba.conf
for more information about possible values and their meanings.
Note 1: It is not recommended to use trust
since it allows anyone to connect without a password, even if one is set (like via POSTGRES_PASSWORD
). For more information see the PostgreSQL documentation on Trust Authentication.
Note 2: If you set POSTGRES_HOST_AUTH_METHOD
to trust
, then POSTGRES_PASSWORD
is not required.
Note 3: If you set this to an alternative value (such as scram-sha-256
), you might need additional POSTGRES_INITDB_ARGS
for the database to initialize correctly (such as POSTGRES_INITDB_ARGS=--auth-host=scram-sha-256
).
PGDATA
This optional variable can be used to define another location - like a subdirectory - for the database files. The default is /var/lib/postgresql/data
. If the data volume you're using is a filesystem mountpoint (like with GCE persistent disks) or remote folder that cannot be chowned to the postgres
user (like some NFS mounts), Postgres initdb
recommends a subdirectory be created to contain the data.
For example:
$ docker run -d \
--name some-postgres \
-e POSTGRES_PASSWORD=mysecretpassword \
-e PGDATA=/var/lib/postgresql/data/pgdata \
-v /custom/mount:/var/lib/postgresql/data \
arm64v8/postgres
This is an environment variable that is not Docker specific. Because the variable is used by the postgres
server binary (see the PostgreSQL docs), the entrypoint script takes it into account.
Docker Secrets
As an alternative to passing sensitive information via environment variables, _FILE
may be appended to some of the previously listed environment variables, causing the initialization script to load the values for those variables from files present in the container. In particular, this can be used to load passwords from Docker secrets stored in /run/secrets/<secret_name>
files. For example:
$ docker run --name some-postgres -e POSTGRES_PASSWORD_FILE=/run/secrets/postgres-passwd -d arm64v8/postgres
Currently, this is only supported for POSTGRES_INITDB_ARGS
, POSTGRES_PASSWORD
, POSTGRES_USER
, and POSTGRES_DB
.
Initialization scripts
If you would like to do additional initialization in an image derived from this one, add one or more *.sql
, *.sql.gz
, or *.sh
scripts under /docker-entrypoint-initdb.d
(creating the directory if necessary). After the entrypoint calls initdb
to create the default postgres
user and database, it will run any *.sql
files, run any executable *.sh
scripts, and source any non-executable *.sh
scripts found in that directory to do further initialization before starting the service.
Warning: scripts in /docker-entrypoint-initdb.d
are only run if you start the container with a data directory that is empty; any pre-existing database will be left untouched on container startup. 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.
For example, to add an additional user and database, add the following to /docker-entrypoint-initdb.d/init-user-db.sh
:
#!/bin/bash
set -e
psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" --dbname "$POSTGRES_DB" <<-EOSQL
CREATE USER docker;
CREATE DATABASE docker;
GRANT ALL PRIVILEGES ON DATABASE docker TO docker;
EOSQL
These initialization files will be executed in sorted name order as defined by the current locale, which defaults to en_US.utf8
. Any *.sql
files will be executed by POSTGRES_USER
, which defaults to the postgres
superuser. It is recommended that any psql
commands that are run inside of a *.sh
script be executed as POSTGRES_USER
by using the --username "$POSTGRES_USER"
flag. This user will be able to connect without a password due to the presence of trust
authentication for Unix socket connections made inside the container.
Additionally, as of docker-library/postgres#253, these initialization scripts are run as the postgres
user (or as the "semi-arbitrary user" specified with the --user
flag to docker run
; see the section titled "Arbitrary --user
Notes" for more details). Also, as of docker-library/postgres#440, the temporary daemon started for these initialization scripts listens only on the Unix socket, so any psql
usage should drop the hostname portion (see docker-library/postgres#474 (comment) for example).
Database Configuration
There are many ways to set PostgreSQL server configuration. For information on what is available to configure, see the postgresql.org docs for the specific version of PostgreSQL that you are running. Here are a few options for setting configuration:
Use a custom config file. Create a config file and get it into the container. If you need a starting place for your config file you can use the sample provided by PostgreSQL which is available in the container at
/usr/share/postgresql/postgresql.conf.sample
(/usr/local/share/postgresql/postgresql.conf.sample
in Alpine variants).- Important note: you must set
listen_addresses = '*'
so that other containers will be able to access postgres.
$ # get the default config
$ docker run -i --rm postgres cat /usr/share/postgresql/postgresql.conf.sample > my-postgres.conf $ # customize the config $ # run postgres with custom config
$ docker run -d --name some-postgres -v "$PWD/my-postgres.conf":/etc/postgresql/postgresql.conf -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres -c 'config_file=/etc/postgresql/postgresql.conf'- Important note: you must set
Set options directly on the run line. The entrypoint script is made so that any options passed to the docker command will be passed along to the
postgres
server daemon. From the docs we see that any option available in a.conf
file can be set via-c
.$ docker run -d --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres -c shared_buffers=256MB -c max_connections=200
Locale Customization
You can extend the Debian-based images with a simple Dockerfile
to set a different locale. The following example will set the default locale to de_DE.utf8
:
FROM arm64v8/postgres:9.4
RUN localedef -i de_DE -c -f UTF-8 -A /usr/share/locale/locale.alias de_DE.UTF-8
ENV LANG de_DE.utf8
Since database initialization only happens on container startup, this allows us to set the language before it is created.
Also of note, Alpine-based variants do not support locales; see "Character sets and locale" in the musl documentation for more details.
Additional Extensions
When using the default (Debian-based) variants, installing additional extensions (such as PostGIS) should be as simple as installing the relevant packages (see github.com/postgis/docker-postgis for a concrete example).
When using the Alpine variants, any postgres extension not listed in postgres-contrib will need to be compiled in your own image (again, see github.com/postgis/docker-postgis for a concrete example).
Arbitrary --user
Notes
As of docker-library/postgres#253, this image supports running as a (mostly) arbitrary user via --user
on docker run
.
The main caveat to note is that postgres
doesn't care what UID it runs as (as long as the owner of /var/lib/postgresql/data
matches), but initdb
does care (and needs the user to exist in /etc/passwd
):
$ docker run -it --rm --user www-data -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres
The files belonging to this database system will be owned by user "www-data".
...
$ docker run -it --rm --user 1000:1000 -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres
initdb: could not look up effective user ID 1000: user does not exist
The three easiest ways to get around this:
use the Debian variants (not the Alpine variants) and thus allow the image to use the
nss_wrapper
library to "fake"/etc/passwd
contents for you (see docker-library/postgres#448 for more details)bind-mount
/etc/passwd
read-only from the host (if the UID you desire is a valid user on your host):$ docker run -it --rm --user "$(id -u):$(id -g)" -v /etc/passwd:/etc/passwd:ro -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres
The files belonging to this database system will be owned by user "jsmith".
...initialize the target directory separately from the final runtime (with a
chown
in between):$ docker volume create pgdata
$ docker run -it --rm -v pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword arm64v8/postgres
The files belonging to this database system will be owned by user "postgres".
...
( once it's finished initializing successfully and is waiting for connections, stop it )
$ docker run -it --rm -v pgdata:/var/lib/postgresql/data bash chown -R 1000:1000 /var/lib/postgresql/data
$ docker run -it --rm --user 1000:1000 -v pgdata:/var/lib/postgresql/data arm64v8/postgres
LOG: database system was shut down at 2017-01-20 00:03:23 UTC
LOG: MultiXact member wraparound protections are now enabled
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
Caveats
If there is no database when postgres
starts in a container, then postgres
will create the default database for you. While this is the expected behavior of postgres
, this means that it will not accept incoming connections during that time. This may cause issues when using automation tools, such as docker-compose
, that start several containers simultaneously.
Also note that the default /dev/shm
size for containers is 64MB. If the shared memory is exhausted you will encounter ERROR: could not resize shared memory segment . . . : No space left on device
. You will want to pass --shm-size=256MB
for example to docker run
, or alternatively in docker-compose
See "IPVS connection timeout issue" in the Docker Success Center for details about IPVS connection timeouts which will affect long-running idle connections to PostgreSQL in Swarm Mode using overlay networks.
Where to Store Data
Important note: There are several ways to store data used by applications that run in Docker containers. We encourage users of the arm64v8/postgres
images to familiarize themselves with the options available, including:
- Let Docker manage the storage of your database data by writing the database files to disk on the host system using its own internal volume management. This is the default and is easy and fairly transparent to the user. The downside is that the files may be hard to locate for tools and applications that run directly on the host system, i.e. outside containers.
- Create a data directory on the host system (outside the container) and mount this to a directory visible from inside the container. This places the database f
docker hub arm64v8/postgres的更多相关文章
- 配置 Docker 加速器(Docker Hub Mirror)
Docker 加速器是什么,我需要使用吗? 使用 Docker 的时候,需要经常从官方获取镜像,但是由于显而易见的网络原因,拉取镜像的过程非常耗时,严重影响使用 Docker 的体验.因此 DaoCl ...
- Docker Hub仓库注册,使用
首先保证可以访问Docker Hub,所以需要先把host替换一下 : Google hosts ; 然后就是注册Docker Hub账户:https://hub.docker.com/; 然后就是在 ...
- 利用Docker Hub上的Nginx部署Web应用
Docker Hub上提供了很多镜像,如Nginx,我们不需要自己从ubuntu开始装Nginx再做发布,只需要先下载镜像到本地 docker pull nginx 在/opt下新建文件夹API,将需 ...
- docker学习笔记7:发布镜像到docker hub上
镜像创建好后,很重要的一个操作就是共享和发布.可以将自己创建的镜像发布到docker hub上,也可以发布到自己的私有docker hub上. 要想发布镜像到dokcer hub上,首先要在dokce ...
- docker学习笔记4:利用docker hub上的mysql镜像创建mysql容器
docker hub上有官方的mysql镜像,我们可以利用它来创建mysql容器,作为一个服务容器使用. 1.下载mysql镜像 docker pull mysql 2.创建镜像 docker run ...
- Docker Hub工作流程-Docker for Web Developers(6)
在Github上创建项目仓库 和创建其他Github项目一样,在Github创建一个仓库,然后在仓库里面增加一个dockerfile,然后提交并推送到Github上. 我已经创建的仓库地址:https ...
- 在Docker Hub上查找可用的Image映像
任何人都可以创建Docker Image映像,你可以浏览Docker Hub来查找这些Image映像. 定位Whalesay 映像 打开你的浏览器,浏览Docker Hub: Docker Hub包含 ...
- Docker Hub
目前 Docker 官方维护了一个公共仓库 Docker Hub,其中已经包括了超过 15,000 的镜像.大部分需求,都可以通过在 Docker Hub 中直接下载镜像来实现. 登录 可以通过执行 ...
- 构建自定义docker镜像,上传至docker hub
docker 优势 (外部参考) Docker 让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后 发布到任何流行的Linux机器上,便可以实现虚拟化.Docker改变了虚拟化的方 式,使 ...
- docker hub加速访问设置
前言:docker是国外的,虽然有个版本开源免费,但是其docker hub还是在国外,刚刚安装后,拉镜像就会发现,连接请求超时,中断服务,这是因为防火墙的问题,所以要将源指向国内的知名docker ...
随机推荐
- 消除视觉Transformer与卷积神经网络在小数据集上的差距
摘要:本文通过多种操作构建混合模型,增强视觉Transformer捕捉空间相关性的能力和其进行通道多样性表征的能力,弥补了Transformer在小数据集上从头训练的精度与传统的卷积神经网络之间的差距 ...
- vue3,对比 vue2 有什么优点?
摘要:Vue3新版本的理念成型于 2018 年末,当时的 Vue 2 已经有两岁半了.比起通用软件的生命周期来这好像也没那么久,Vue3在2020年正式推出,在源码和API都有较大变化,性能得到了显著 ...
- 数仓无损压缩算法:gzip算法
摘要:一种无损的压缩数据格式,是一个在类Unix上的一种文件解压缩软件. 本文分享自华为云社区<GaussDB(DWS) gzip算法简介>,作者:hw0086. [算法原理] gzip是 ...
- nodejs升级到最新LTS版本方法汇总:linux/mac/window—npm/yum/ssh
nodejs不同版本的差异还是蛮多的,比如obj?.a 在nodejs12是不支持的,必须得升级到14才可以.但是centos yum 默认安装的,或者系统集成的nodejs版本都是很老的.项目上传到 ...
- docker-compose部署SpringCloud
1.安装 docker-compose 将 docker-compose-Linux-x86_64 传到 /usr/local/bin 目录下,并改名为 docker-compose 2.设置权限 ...
- 【OpenSSL】Visual Studio 2019配置OpenSSL 3.0开发环境
OpenSSL从1.0.2版本升级为3.0.3版本后,需要对代码进行重构.如果不可用的代码太多,需要重新开一个项目.重新配置开发环境. [第一步]登录http://slproweb.com/,下载Wi ...
- echarts折线图美化(颜色渐变、背景透明、隐藏坐标轴)
echarts折线图美化(颜色渐变.背景透明.隐藏坐标轴) https://blog.csdn.net/Changeable0127/article/details/81333559?utm_medi ...
- Oracle数据库学习总结
SQL 笔记 ch3_cn 1.数据类型记录 char(n) 定长字符 varchar(n) 可变长字符 numeric(p,d) 定点数,总位数p,小数点后位数q float(n) n位浮点数 2. ...
- Kubernetes APIServer 最佳实践
1. kubernetes 整体架构 kubernetes 由 master 节点和工作节点组成.其中,master 节点的组件有 APIServer,scheduler 和 controller-m ...
- gitee 创建代码仓库,并提交本地代码
本文为博主原创,转载请注明出处: 1. 配置本地 gitee 的配置: git config --global user.name "xiangBaxiang" git confi ...