Deployment failure with Docker entrypoint script

So I modified my Dockerfile to use an entrypoint.sh and switched to a different branch than my main repo branch. I’m running into deployment issues now:

Here’s my Dockerfile:

FROM ruby:3.1.2-alpine3.15 AS development
RUN apk add --no-cache --virtual build-dependencies \
build-base git zlib zlib-dev gcc g++ patch readline \
readline-dev autoconf automake libtool make gcompat
RUN apk add --no-cache tzdata postgresql-dev postgresql-libs chromium chromium-chromedriver curl
RUN mkdir -p /app
COPY . /app
COPY ./entrypoint.sh /usr/bin/entrypoint.sh
RUN chmod +x /usr/bin/entrypoint.sh
WORKDIR /app
RUN gem install debase-ruby_core_source && gem install debase -v '0.2.5.beta2'
RUN bundle install

FROM development AS production
RUN apk del build-dependencies
ENTRYPOINT ["/usr/bin/entrypoint.sh"]
EXPOSE 3000
CMD ["bundle","exec","rails","server","-b","0.0.0.0"]

Here’s my entrypoint.sh:

bundle exec rails db:prepare
bundle exec rails tailwindcss:build
exec "$@" # Executes the image

Can you show me your application logs?

Here you go.

Can you add #! /bin/sh in your entrypoint.sh?

#! /bin/sh
bundle exec rails db:prepare
bundle exec rails tailwindcss:build
exec "$@" # Executes the image

cf this Qovery tutorial

Thanks. That appears to have worked, although now it appears the database connection is timing out.

So I made DATABASE_URL an alias of QOVERY_POSTGRESQL_Z079DACDF_DATABASE_URL
In the Development environment, so I’m not entirely sure what’s wrong there. I’ll do some additional testing. Perhaps a redeploy is needed.

Unfortunately your forum won’t let me embed further images.

Now it is complaining that containers are unready.

Interesting.

You need to make an alias of QOVERY_POSTGRESQL_Z079DACDF_DATABASE_URL_INTERNAL.

Basically, the difference between both is the network used.

_DATABASE_URL_INTERNAL use your internal network to connect to the database (it’s local domain pointing to a local IP address behind).

_DATABASE_URL use the external network when your DB is configured with visibility PUBLIC.


CC @Florian_Lepont @a_carrano

1 Like

AHA! Yes, that worked.

So the app stack I’m testing using both SQL database and a caching server. So that DATABASE_INTERNAL address for the SQL database is now aliased as DATABASE_URL, but the Redis DATABASE_INTERNAL I have aliased as REDIS_URL.

App is up and running. Thanks. I can do some testing before I go on vacation now, and once I’m back look into the Github integration. Looks very promising, I like the idea of this being a developer-friendly layer over our existing tooling.

Thanks very much.

1 Like