Início
Versões
Imagens
Inicializando o banco
Rodando comando PostgreSQL em containers
Variáveis de Ambiente
Ponto de montagem de Volumes
Alterando senhas
Criando um banco a partir de um template
Início
O OpenShift fornece uma imagem Docker para rodar PostgreSQL. Esta imagem provê serviços de banco baseado no usuário e senha fornecidos pela configuração.
Versões
A versão atual que o OpenShift suporta do PosrgreSQL é a 9.2, 9.4 e 9.5.
Imagens
Estas imagens estão disponíveis na distribuição CentOS 7:
Imagens baseadas em CentOS 7
Esta imagem está disponível no DockerHub. Para fazer download:
$ docker pull openshift/postgresql-92-centos7
$ docker pull centos/postgresql-94-centos7
$ docker pull centos/postgresql-95-centos7
Para usar essa imagem, você pode acessa-las diretamente através desse registro de imagens, ou enviar para seu registro OpenShift Docker. Adicionalmente, você pode criar uma image stream que aponte para a imagem, no seu registro Docker ou numa localização externa. Os recursos do seu OpenShift podem agora fazer referencia ao ImageStream. Você pode encontrar exemplo de definições de image streams para todas as imagens do OpenShift.
Inicializando o banco
A primeira vez que você usa o volume compartilhar, a base é criada utilizando o usuário administrador e o usuário postgres do PostgrSQL (se você especificar a variável POSTGRESQL_ADMIN_PASSWORD). Depois disso o daemon do PostgreSQL inicia. Se você esta montando o volume em outro container, então a base, usuário da base e o usuário administrador não são criados e então o PostgreSQL inicia.
O comando a seguir cria um novo pod com o banco e o PostgreSQL executando no container:
$ oc new-app -e POSTGRESQL_USER=<username>,POSTGRESQL_PASSWORD=<password>,POSTGRESQL_DATABASE=<database_name> centos/postgresql-94-centos7
Rodando comando PostgreSQL em containers
O OpenShift utiliza Software Collections(SCLs) para instalar e iniciar o PostgreSQL. Se você quer executar algum comando PostgreSQL dentro de um container em execução(para debug), você deve executar usando o bash.
Para fazer isso, primeiro identifique o nome do pod que esta rodando o PostgreSQL. Por exemplo, você pode ver a lista de pods no seu projeto ao executar:
$ oc get pods
Então conecte no pod com o seguinte comando:
$ oc rsh <pod>
Quando você logar no container, a SCL é automaticamente ativada.
Você pode agora rodar o comando psql a partir do bash para iniciar uma sessão interativa do PostgreSQL e executar operações do PostgreSQL. Exemplo, para autenticar com o usuário da base:
bash-4.2$ PGPASSWORD=$POSTGRESQL_PASSWORD psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER
psql (9.2.8)
Type "help" for help.
default=>
Quando finalizado, entre com \q para fazer logout da sessão do PostgreSQL.
Variáveis de Ambiente
O usuário do PostgreSQL, senha e nome da base devem ser configurados com as seguintes variáveis de ambiente:
Tabela 1. Variáveis de ambiente do PostgreSQL
Nome da Variável | Descrição |
POSTGRESQL_USER | Nome da conta de usuário a ser criado. Este usuário tem total acesso ao banco. |
POSTGRESQL_PASSWORD | Senha para o usuário acima. |
POSTGRESQL_DATABASE | Nome da base. |
POSTGRESQL_ADMIN_PASSWORD | Senha opcional para o usuário postgres. Se não for setada, então logins remotos utilizando a conta postgres não será possível. Conexões locais a partir do container é sempre permitida sem senha. |
![]() |
Você deve especificar usuário, senha e nome da base. Se você não especificar os três, o pod vai falhar para iniciar e o OpenShift vai ficar num loop tentando reiniciar. |
As configurações do PostgreSQL podem ser configuradas com as seguintes variáveis de ambiente:
Tabela 2. Configurações adicionais do PostgreSQL
Nome da Variável | Descrição | Default |
POSTGRESQL_MAX_CONNECTIONS | O número máximo de conexões permitida. | 100 |
POSTGRESQL_SHARED_BUFFERS | Configura quanta memória é dedicada ao PostgreSQL para cache de dados. | 32M |
Ponto de montagem de Volumes
A imagem do PostgreSQL pode ser executada com volumes montados, para habilitar persistent storage para o banco:
- /var/lib/pgsql/data - Este é o diretório onde o PostgreSQL armazena os arquivos do banco.
Alterando senhas
As senhas são parte da configuração da imagem, entretanto o único meio de alterar senhas para o usuário do banco(POSTGRESQL_USER) e usuário administrador postgres, é ao alterar as variáveis de ambiente POSTGRESQL_PASSWORD e POSTGRESQL_ADMIN_PASSWORD respectivamente.
Você pode ver as senhas atuais no pod ou no deployment config do console web ou ao listar as variáveis de ambiente na CLI:
$ oc env pod <pod_name> --list
Alterar a senha do banco através do comandos SQL ou qualquer outro meio que não seja através das variáveis de ambiente vai causar um erro de configuração entre os valores armazenados nas variáveis e as senhas atuais. Sempre que um container de banco for iniciado, ele reseta as senhas e define os valores setados nas variáveis de ambiente.
Para alterar estas senhas, atualize uma ou ambas das variáveis de ambiente designadas no deployment config, usando o comando oc env. Se múltiplos deployment configs utilizam estas variáveis, por exemplo no caso de uma aplicação criada a partir de um template, você deve atualizar as variáveis em cada deployment config para que as senhas sejam sincronizadas em todo lugas. Isso pode ser feito em um único comando:
$ oc env dc <dc_name> [<dc_name_2> ...] POSTGRESQL_PASSWORD=<new_password> POSTGRESQL_ADMIN_PASSWORD=<new_admin_password>
![]() |
Dependendo da sua aplicação, talvez tenha outras variáveis de ambiente para senhas em outras partes da aplicação que também devem ser atualizadas. Exemplo, pode ter uma variável mais genérica DATABASE_USER em um pod front-end que deve sempre fazer um match com a senha do usuário do banco. Tenha certeza que as senhas foram sincronizadas em todas as variáveis de ambiente de suas aplicações, se não seus pods podem falhar numa trigger de redeploy. |
Atualizar as variáveis de ambiente, acionam o redeployment do banco no servidor se você tiver uma trigger de alteração de configuração. Em outro caso, você deve iniciar manualmente um novo deployment para aplicar as alterações de senhas.
Para verificar se as novas senhas estão funcionando, primeiro abra uma sessão ao pod que esta rodando o PostgreSQL:
$ oc rsh <pod>
A partir do bash, verifique a nova senha do usuário:
bash-4.2$ PGPASSWORD=<new_password> psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"
Se a senha foi alterada corretamente, você deve ver uma tabela igual a essa:
current_database | current_user
------------------+--------------
default | django
(1 row)
A partir do bash, verifique a nova senha do usuário administrador postgres:
bash-4.2$ PGPASSWORD=<new_admin_password> psql -h postgresql $POSTGRESQL_DATABASE $POSTGRESQL_USER -c "SELECT * FROM (SELECT current_database()) cdb CROSS JOIN (SELECT current_user) cu"
Se a senha foi alterada corretamente, você deve ver uma tabela igual a essa:
current_database | current_user
------------------+--------------
default | postgres
(1 row)
Criando um banco a partir de um template
O OpenShift fornece um template para criar um novo serviço de banco de forma simplificada. O template fornece alguns campos para definir todas as variáveis de ambiente obrigatórias(usuário, senha, nome do banco, etc) com os valores pré-definidos default, incluindo geração de senhas aleatórias. Define também o deployment config e o serviço.
O template do PostgreSQL deve ser registrado no projeto default do openshift pelo seu administrador durante o setup inicial. Veja Carregando default image streams e templates para mais detalhes.
O template disponível:
- PostgreSQL-persistent utiliza um volume persistente para os dados do banco, o que significar que os dados vão permanecer a um restart do pod. Usando volumes persistente, requer um volume persistent pool definido no deployment do OpenShift. As instruções para configurar um pool estão aqui.
Você pode achar instruções para instanciar templates ao seguir estas instruções.
Assim que você instanciar o serviço, você pode copiar o usuário, senha e nome da base em variáveis de ambiente dentro de um deployment config para que outro componente possa acessar o banco. O componente pode acessar a base através do serviço que foi definido.
Comentários
0 comentário
Por favor, entre para comentar.