asciinema / asciinema-server

Platform for hosting and sharing terminal session recordings
https://docs.asciinema.org/manual/server/
Apache License 2.0
2.29k stars 263 forks source link

502 Bad Gateway - nginx #398

Closed W4JEW closed 2 years ago

W4JEW commented 2 years ago

From what I see in the logs for the containers, it looks like the documentation is missing several mandatory configuration options.

I think the first one that's the deal breaker is for Postgres (see below for the logs)

Error: Database is uninitialized and superuser password is not specified.
       You must specify POSTGRES_PASSWORD to a non-empty value for the
       superuser. 

And anything else that attempts to start after postgres fails because the database wasn't created.

I've followed the instructions available here pretty much verbatim: https://github.com/asciinema/asciinema-server/wiki/Installation-guide

I'm trying to install the Docker container on Ubuntu 20.04. Once I clone the repository, I made a copy of .env.production.sample and configured the following parameters:

URL_SCHEME=http URL_HOST= URL_PORT=80

SECRET_KEY_BASE= <ran docker-compose run --rm phoenix gen_secret to generate the secret and pasted it here> DATABASE_URL= SIGN_UP_DISABLED=true ASCIICAST_GC_DAYS=7

MAILNAME=mailhost.domain.com SMTP_FROM_ADDRESS=me@domain.com SMTP_REPLY_TO_ADDRESS=me@domain.com

GMAIL_USER= <set to my Google Workspace user ID: admin@domain.com> GMAIL_PASSWORD = should be obvious

All of the AWS S3 attributes were left commented out.

Then I ran docker pull asciinema/asciinema-server:latest to download the latest image. This wasn't really needed since the command to generate the secret key already downloaded the image.

FYI - running the docker command to generate the secret key also downloaded the Docker containers and both Postgres and SMTP were running.

Created the postgres container: docker-compose up -d postgres

I removed the SMTP container, then ran docker-compose up -d to start everything.

That's pretty much it - and every time I try to connect to the server via http:// URL I get the Nginx 502 error. I can't figure out what's breaking.

When I look at the logs for the nginx container, I see:

- - [15/Sep/2022:06:22:35 +0000] "GET / HTTP/1.1" 502 560 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36" "-" 2022/09/15 06:22:35 [error] 6#6: *2 connect() failed (113: Host is unreachable) while connecting to upstream, client: , server: _, request: "GET / HTTP/1.1", upstream: "http://172.21.0.3:4000/", host: "" - - [15/Sep/2022:06:22:38 +0000] "GET /favicon.ico HTTP/1.1" 502 560 "http:///" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36" "-" The logs for asciinema_phoenix show: ``` To fix the first issue, run "mix ecto.create". To address the second, you can run "mix ecto.drop" followed by "mix ecto.create". Alternatively you may configure Ecto to use another table for managing migrations: config :asciinema, Asciinema.Repo, migration_source: "some_other_table_for_schema_migrations" The full error report is shown below. ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2966ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by: 1. By tracking down slow queries and making sure they are running fast enough 2. Increasing the pool_size (albeit it increases resource consumption) 3. Allow requests to wait longer by increasing :queue_target and :queue_interval See DBConnection.start_link/2 for more information (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:593: Ecto.Adapters.SQL.raise_sql_call_error/1 (elixir 1.12.1) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2 (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:686: Ecto.Adapters.SQL.execute_ddl/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:641: Ecto.Migrator.verbose_schema_migration/3 (ecto_sql 3.4.5) lib/ecto/migrator.ex:484: Ecto.Migrator.lock_for_migrations/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:406: Ecto.Migrator.run/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:149: Ecto.Migrator.with_repo/3 (asciinema 0.0.1) lib/asciinema/release_tasks.ex:8: anonymous fn/1 in Asciinema.ReleaseTasks.migrate/0 Running db migrations... 06:36:26.110 [error] Could not create schema migrations table. This error usually happens due to the following: * The database does not exist * The "schema_migrations" table, which Ecto uses for managing migrations, was defined by another library * There is a deadlock while migrating (such as using concurrent indexes with a migration_lock) To fix the first issue, run "mix ecto.create". To address the second, you can run "mix ecto.drop" followed by "mix ecto.create". Alternatively you may configure Ecto to use another table for managing migrations: config :asciinema, Asciinema.Repo, migration_source: "some_other_table_for_schema_migrations" The full error report is shown below. ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2968ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by: 1. By tracking down slow queries and making sure they are running fast enough 2. Increasing the pool_size (albeit it increases resource consumption) 3. Allow requests to wait longer by increasing :queue_target and :queue_interval See DBConnection.start_link/2 for more information (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:593: Ecto.Adapters.SQL.raise_sql_call_error/1 (elixir 1.12.1) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2 (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:686: Ecto.Adapters.SQL.execute_ddl/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:641: Ecto.Migrator.verbose_schema_migration/3 (ecto_sql 3.4.5) lib/ecto/migrator.ex:484: Ecto.Migrator.lock_for_migrations/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:406: Ecto.Migrator.run/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:149: Ecto.Migrator.with_repo/3 (asciinema 0.0.1) lib/asciinema/release_tasks.ex:8: anonymous fn/1 in Asciinema.ReleaseTasks.migrate/0 Running db migrations... 06:37:32.355 [error] Could not create schema migrations table. This error usually happens due to the following: * The database does not exist * The "schema_migrations" table, which Ecto uses for managing migrations, was defined by another library * There is a deadlock while migrating (such as using concurrent indexes with a migration_lock) To fix the first issue, run "mix ecto.create". To address the second, you can run "mix ecto.drop" followed by "mix ecto.create". Alternatively you may configure Ecto to use another table for managing migrations: config :asciinema, Asciinema.Repo, migration_source: "some_other_table_for_schema_migrations" The full error report is shown below. ** (DBConnection.ConnectionError) connection not available and request was dropped from queue after 2945ms. This means requests are coming in and your connection pool cannot serve them fast enough. You can address this by: 1. By tracking down slow queries and making sure they are running fast enough 2. Increasing the pool_size (albeit it increases resource consumption) 3. Allow requests to wait longer by increasing :queue_target and :queue_interval See DBConnection.start_link/2 for more information (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:593: Ecto.Adapters.SQL.raise_sql_call_error/1 (elixir 1.12.1) lib/enum.ex:1553: Enum."-map/2-lists^map/1-0-"/2 (ecto_sql 3.4.5) lib/ecto/adapters/sql.ex:686: Ecto.Adapters.SQL.execute_ddl/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:641: Ecto.Migrator.verbose_schema_migration/3 (ecto_sql 3.4.5) lib/ecto/migrator.ex:484: Ecto.Migrator.lock_for_migrations/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:406: Ecto.Migrator.run/4 (ecto_sql 3.4.5) lib/ecto/migrator.ex:149: Ecto.Migrator.with_repo/3 (asciinema 0.0.1) lib/asciinema/release_tasks.ex:8: anonymous fn/1 in Asciinema.ReleaseTasks.migrate/0 ``` The logs for asciinema_postgress show: ``` 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 ``` The only logs that seem to be OK are for the asciinema_smtp container
W4JEW commented 2 years ago

Well, turns out I was correct - there's one step that's missing from your documentation..

The documentation states:

If you go with the provided docker-compose.yml file you don't need to worry about these - they're included and already configured to work with this app.

This is not accurate. There's no mention of having to edit the docker-compose.yml file to include an environment setting and it's not included in the version downloaded via using the git clone command.

It's necessary to specify an authentication parameter in docker-compose.yml, otherwise PostgreSQL doesn't start completely and there's a cascading effect where the other asciinema containers fail.

This is the docker-compose.yml file included with asciinema-server:

services:
  postgres:
    image: postgres:12-alpine
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    container_name: asciinema_postgres
    restart: unless-stopped
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
    ### See https://hub.docker.com/_/postgres/ for more
    ### configuration options for this image.

This is a working example... Note the addition of:

    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
services:
  postgres:
    image: postgres:12-alpine
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
    container_name: asciinema_postgres
    restart: unless-stopped
    volumes:
      - ./volumes/postgres:/var/lib/postgresql/data
    ### See https://hub.docker.com/_/postgres/ for more
    ### configuration options for this image.

Adding those two lines made all the difference. Please update your included docker-compose.yml file or omit/modify the following since it's not accurate:

If you go with the provided docker-compose.yml file you don't need to worry about these - they're included and already configured to work with this app.
W4JEW commented 2 years ago

I accidentally closed this issue. Reopening to ensure this issue gets resolved. See my follow-up comment.