RDS Support does not work with Rails Application and non-MySQL database about opsworks-cookbooks

[basicsandwich]

It's incredible that this still isn't fixed, almost a year later. I've confirmed that this is STILL a problem.

[stevenspiel]

One thing I would change to @zacstewart's answer is to fix a minor typo from postrgesql to postgresql

{"deploy":{"app_short_name":{"database":{"adapter":"postgresql","type":"postgresql"}}}}

[jweiss]

We also addressed this internally and a fix will be rolled out very soon.

As you mentioned, the workaround is to either 1) override the deploy["database"]["adapter"] value via custom JSON or in an attribute file or 2) to override the database.yml template.

We will update this issue as soon as the fix is deployed.

[sudhirj]

Sigh. This broke our production app (Rails + Postgres on RDS) without warning. I wound up writing a bunch of deployment shell scripts and moving off Opsworks to Autoscalinggroups + cloud init.

[jweiss]

@sudhirj I'm interested in how this broke you. We only send an additional parameter 'type' that wasn't there before.

[sudhirj]

A day before the announcement was made, our deploys (with migrations) began to fail. On looking at the logs, we realized that the rake db:migrate step was failing. This was odd because the app was working fine on production with no issues.

I tried turning the migrations off and deploying. Big mistake. Now the deploy went through fine (And opsworks gave me all green checks) but the app couldn't connect to the database. To top it all off, adding an SSH key to an instance didn't seem to work either.

After much stopping and starting and experimenting with different instances and types and double checking settings (no changes, deploys always succeeded but results in an app that couldn't connect), I gave up and moved off OpsWorks.

That was about 8 hours or downtime, and me sitting up till 3AM trying to get prod back up. Decided I'd rather stick to shell scripts.

[sudhirj]

I'm not sure if it was the type parameter or the new IAM role requirement, but something broke connectivity between the app server layer and RDS/Postgres with no warning. No security groups were changed.

[awsrequena]

Same problem as pull request #166

[baruchlubinsky]

To be explicit with the workaround. I've had to add this JSON to my deployment:

{"deploy":{"api":{"database":{"adapter":"postgresql","type":"postrgesql"}}}}  

where api is the name of my application in OpsWorks.

[Xantax]

or something like this:

{
  "deploy": {
    "myappname": {
      "database": {
        "adapter": "postgresql",
        "encoding": "unicode",
        "host": "myappname.nil.us-east-1.rds.amazonaws.com",
        "port": "5432",
        "database": "mydatabase",
        "pool": "5",
        "username": "secretusername",
        "password": "secretpass"
      }
    }
  }
}

[mshappe]

So, I've added a clause like the above to my deployment...and it still seems to be falling back to MySQL. Any other ideas? :-)

[james075]

So, I've added a clause like the above to my deployment...and it still seems to be falling back to MySQL. Any other ideas? :-)

up ?

[mshappe]

It never did work. I gave up. OpsWorks was an experiment for me. It failed for now. I'll try again when Amazon stops dragging its heels and supports PostgreSQL properly.

[zacstewart]

Seems like this is still an issue. The work around works, but make sure you use the app's shortname, and not the name:

{"deploy":{"app_short_name":{"database":{"adapter":"postgresql","type":"postgresql"}}}}  

[nickstamas]

@johntxi +1

[cacheflow]

I just ran into this problem. Like sudhirj said my rake db:migrate keeps failing as well and soon as I turned it off, OpsWorks gave me all green checks. How is this not fixed yet? And is there any other way to migrate my database once it's deployed?

[mshappe]

I have come to the conclusion that, for whatever reason, the OpsWorks team just doesn't care about PostgreSQL support. It's sad, and it pretty much guarantees I can't use that service to simplify things, but such is life.

[saurabhbhatia]

Its surprising the PR #166 has not been merged yet. @awsrequena you guys can change the case switch statements later, at least fix this issue fix for the existing users.

[segantii-alex-falkowski]

Still nothing?

[segantii-alex-falkowski]

I really don't understand why you have to mess with the database.yml in the first place.

[eggie5]

What's the status on this??

[johncblandii]

Custom json works just fine. Nothing is broken. See baruchlubinsky's answer advice. Just change the short name to your app sorry name.

[amalagaura]

2015 and we are still looking Googling on how to use Postgres with Opsworks.

[johncblandii]

Nope. It works without a problem. See @zacstewart's post above. It's exactly how I do it in 5 different stacks.

[amalagaura]

@johncblandii Yes it works after you search google and come to this issue.

Anyway there are a bunch of issues including no out of the box support for asset precompiles. It is ok if one spends a few hours searching and solving the problem on your own of course.

[johncblandii]

The docs tell you the same thing as this issue.

Create deploy/before_symlink.rb and put this in there: run "cd #{release_path} && RAILS_ENV=production bundle exec rake assets:precompile".

AWS is just normal Chef stuff. It has a larger learning curve if you haven't used it before (say with Engine Yard or similar) but the AWS docs and forums have these details in them.

With that said, I 100% agree some things should be built in. If the RDS database is Postgres, use the PG adapter. Those sort of things just make sense to get built into their system.

[johncblandii]

Here're the custom db parts in the AWS docs.

Here're the deployment hooks in the AWS docs.

[jweiss]

closing as this is a very old issue