Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not able to run with pgsql and docker #155

Closed
janhoy opened this issue Jun 10, 2020 · 8 comments
Closed

Not able to run with pgsql and docker #155

janhoy opened this issue Jun 10, 2020 · 8 comments

Comments

@janhoy
Copy link

janhoy commented Jun 10, 2020

Describe the bug
Trying to use a Postgres DB for docker-compose is hard and fails.

To Reproduce
Steps to reproduce the behavior:

  1. Create a pgsql db somewhere (not in docker)
  2. Modify docker-compose.prod.yaml to point to that DB (with app image from hub)
  3. Start the app (docker-compose up)
  4. Fails because 'pg' db driver is not bundled in o19s/quepid
  5. Clone Dockerfile.prod, Gemfile and config locally, add pg ~> 0.18 to Gemfile (and Gemfile.lock) and modify docker-compose file accordingly (see Dockerfile)
  6. Build container and try again
  7. Now we get started, to the point where db:setup is run
  8. db setup fails with (see full log)
    rake aborted!
    ActiveRecord::StatementInvalid: PG::DuplicateTable: ERROR:  relation "user_id" already exists
    : CREATE  INDEX  "user_id" ON "cases" USING btree ("user_id")
    

Expected behavior

  • Docker image should ship with the most common db drivers including postgres, oracle etc
  • DB schema.rb and migrations should work across different databases
@janhoy
Copy link
Author

janhoy commented Jun 10, 2020

No urge to fix this, I gave up and use a standalone MySql instead, which btw worked like a charm :)

@epugh
Copy link
Member

epugh commented Jun 10, 2020

My feeling is that the type of database is kind of an internal detail to Quepid... Kind of like when Solr went from a WAR deployable in Tomcat or Jetty to the servlet container being a internal detail to Solr. Supporting multiple databases would require a much more comprehensive CI process than we have today ;-)

@janhoy
Copy link
Author

janhoy commented Jun 10, 2020

Ok, that can be a choice you make. If so, I'd document it clearly and remove DB_ADAPTER variable from docker-compose and instead hardcode it in database.yml with a comment that it will NOT work with anything else.

Where I'm coming from is we plan to deploy Quepid as a container in our environment, but at the same time we don't want to keep the DB on the same host where it can get lost. We use ECS for containers and RDS for databases. It worked fine once I provisioned a MySql RDS db.

@janhoy janhoy closed this as completed Jun 10, 2020
@epugh
Copy link
Member

epugh commented Jun 10, 2020 via email

@epugh
Copy link
Member

epugh commented Jun 10, 2020

Keep ticket open till we update the documentation etc.

@epugh epugh reopened this Jun 10, 2020
@janhoy
Copy link
Author

janhoy commented Jun 10, 2020

My feedback on installation guide wiki is:

  • The guide works for 6.2 but not for current latest image
    • I.e. thor user:grant_administrator does not exist in 6.1.1, and syntax for user:create is also different
    • So perhaps documentation should be in the git repo and not wiki, and tell people to first browse to some tag corresponding with latest hub image to get the correct documentation

The only thing I did to talk to RDS in AWS was to change DB_HOST, DB_USERNAME, DB_PASSWORD and DATABASE_URL in docker-compose :) Btw: Why do you need DATABASE_URL when we just configured all parts of it in the other vars? Well, the only part missing to construct DATABASE_URL would be DB_PORT

@epugh
Copy link
Member

epugh commented Jun 11, 2020

Interesting on the DATABASE_URL versus teh DB_HOST etc.. I don't know why it's like that, though I think it's a pattern that I've seen... not sure why!

epugh added a commit that referenced this issue Jun 11, 2020
…around. Also can reduce number of parameters in the production setup. fixes #155
@epugh
Copy link
Member

epugh commented Jun 11, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants