Postgres.template.yml e a configuração multi-container

Dev
1

Percebi que, ao migrarmos para o modo de múltiplos contêineres, a restauração do banco de dados resultou em tempo de inatividade inesperado do site (enquanto o backup é carregado no banco de dados):

Então, fiz algumas investigações no postgres.template.yml e notei que app.yml e o caminho para o contêiner autônomo standalone (que compartilha espaço) estão hardcoded neste modelo.

De modo algum sou um especialista nesses arquivos (ainda), e como o código contém principalmente “echos” informativos, o conteúdo parece mais “informativo para o usuário” do que problemático:

Exemplos do Modelo 
echo Execute: "./launcher stop app"
           echo Execute: "sudo mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old"
           echo Execute: "./launcher rebuild app"
           echo
           echo Execute: "./launcher enter app"
           echo Execute: "cd /shared/postgres_backup"
           echo Execute: "sv stop unicorn"
           echo Execute: "sudo -iu postgres dropdb discourse"
           echo Execute: "sudo -iu postgres createdb discourse"
           echo Execute: "sudo -iu postgres psql discourse < backup.db"
           echo Execute: "exit"
           echo Execute: "./launcher rebuild app"
           exit 1

          if [ "$PG_MAJOR_OLD" = "9.5" ]; then
             echo 'Em containers/app.yml: Altere "templates/postgres.template.yml" PARA "templates/postgres.9.5.template.yml"'
             echo
           fi

etc, etc.

Parece que quase tudo é “informativo e não problemático, presumo”.

Provavelmente não é importante, mas como vários tutoriais no site mencionam este modelo e a renomeação do contêiner de dados para “data” e do contêiner web para “web-only”, por exemplo, achei que valia a pena mencionar.

Apenas para seu conhecimento, talvez para uma análise futura, lá na frente…