Cloning environment in elastic beanstalk - ruby-on-rails

Question

I am wanting to update my Rails EB Linux to 2.12.2 from 1.11.8, so I cloned the environment and committed to it but I am getting this error:
PG::ConnectionBad (could not connect to server: Connection timed out
Is the server running on host "example.ccexample.us-east-1.rds.amazonaws.com" (111.11.21.22) and accepting
TCP/IP connections on port 5432?
Another error -- likely the same issue?:
/opt/elastticbeanstalk/hooks/appdeploy/pre/12_db_migration.sh failed.
My env variables are all correct so shouldn't the database just simply connect?
This is the error log:
[2020-12-31T22:05:28.834Z] INFO [5012] - [Application update app-example/AppDeployStage0/AppDeployPreHook/12_db_migration.sh] : Starting activity...
[2020-12-31T22:07:45.564Z] INFO [5012] - [Application update example/AppDeployStage0/AppDeployPreHook/12_db_migration.sh] : Activity execution failed, because: ++ /opt/elasticbeanstalk/bin/get-config container -k script_dir
+ EB_SCRIPT_DIR=/opt/elasticbeanstalk/support/scripts
++ /opt/elasticbeanstalk/bin/get-config container -k app_staging_dir
+ EB_APP_STAGING_DIR=/var/app/ondeck
++ /opt/elasticbeanstalk/bin/get-config container -k app_user
+ EB_APP_USER=webapp
++ /opt/elasticbeanstalk/bin/get-config container -k support_dir
+ EB_SUPPORT_DIR=/opt/elasticbeanstalk/support
+ . /opt/elasticbeanstalk/support/envvars-wrapper.sh
+++ /opt/elasticbeanstalk/bin/get-config container -k support_dir
++ EB_SUPPORT_DIR=/opt/elasticbeanstalk/support
++ set +x
+ RAKE_TASK=db:migrate
+ . /opt/elasticbeanstalk/support/scripts/use-app-ruby.sh
++ . /usr/local/share/chruby/chruby.sh
+++ CHRUBY_VERSION=0.3.9
+++ RUBIES=()
+++ for dir in '"$PREFIX/opt/rubies"' '"$HOME/.rubies"'
+++ [[ -d /opt/rubies ]]
++++ ls -A /opt/rubies
+++ [[ -n ruby-2.4.10
ruby-2.5.8
ruby-2.6.6
ruby-current ]]
+++ RUBIES+=("$dir"/*)
+++ for dir in '"$PREFIX/opt/rubies"' '"$HOME/.rubies"'
+++ [[ -d /.rubies ]]
+++ unset dir
+++ cat /etc/elasticbeanstalk/.ruby_version
++ chruby 2.5.8
++ case "$1" in
++ local dir match
++ for dir in '"${RUBIES[#]}"'
++ dir=/opt/rubies/ruby-2.4.10
++ case "${dir##*/}" in
++ for dir in '"${RUBIES[#]}"'
++ dir=/opt/rubies/ruby-2.5.8
++ case "${dir##*/}" in
++ match=/opt/rubies/ruby-2.5.8
++ for dir in '"${RUBIES[#]}"'
++ dir=/opt/rubies/ruby-2.6.6
++ case "${dir##*/}" in
++ for dir in '"${RUBIES[#]}"'
++ dir=/opt/rubies/ruby-current
++ case "${dir##*/}" in
++ [[ -z /opt/rubies/ruby-2.5.8 ]]
++ shift
++ chruby_use /opt/rubies/ruby-2.5.8 ''
++ [[ ! -x /opt/rubies/ruby-2.5.8/bin/ruby ]]
++ [[ -n '' ]]
++ export RUBY_ROOT=/opt/rubies/ruby-2.5.8
++ RUBY_ROOT=/opt/rubies/ruby-2.5.8
++ export RUBYOPT=
++ RUBYOPT=
++ export PATH=/opt/rubies/ruby-2.5.8/bin:/opt/elasticbeanstalk/lib/ruby/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
++ PATH=/opt/rubies/ruby-2.5.8/bin:/opt/elasticbeanstalk/lib/ruby/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
+++ /opt/rubies/ruby-2.5.8/bin/ruby -
++ eval 'export RUBY_ENGINE=ruby;
export RUBY_VERSION=2.5.8;
export GEM_ROOT="/opt/rubies/ruby-2.5.8/lib/ruby/gems/2.5.0";'
+++ export RUBY_ENGINE=ruby
+++ RUBY_ENGINE=ruby
+++ export RUBY_VERSION=2.5.8
+++ RUBY_VERSION=2.5.8
+++ export GEM_ROOT=/opt/rubies/ruby-2.5.8/lib/ruby/gems/2.5.0
+++ GEM_ROOT=/opt/rubies/ruby-2.5.8/lib/ruby/gems/2.5.0
++ (( 0 != 0 ))
+ cd /var/app/ondeck
+ su -s /bin/bash -c 'bundle exec /opt/elasticbeanstalk/support/scripts/check-for-rake-task.rb db:migrate' webapp
I also updated the config.yml with the new environment names:
branch-defaults:
master:
environment: NewName
environment-defaults:
NewName:
branch: null
repository: null
RevoltVendor-env:
branch: null
repository: null
global:
application_name: App Name
default_ec2_keyname: null
default_platform: Puma with Ruby 2.5 running on 64bit Amazon Linux
default_region: us-east-1
include_git_submodules: true
instance_profile: null
platform_name: null
platform_version: null
profile: eb-cli
sc: git
workspace_type: Application
Any help would be appreciated

Answer 1

Based on the comments.
The issue was caused by wrong security group (SG) inbound rules in RDS. The EB cloning operation creating new SG, which was not reflected in the SG of the RDS.
The solution was to update the SG of the RDS and add the SG associated with the cloned EB environment.