error while building rails app about caprover-cli

[githubsaturn]

By looking at the logs that you shared (the red logs), your server seemed to have completely crashed during the build. Most common case is due to RAM issue. Building your app requires more RAM. Give it a shot with a machine with more RAM.

In general, building an app sometimes requires more RAM than running the app. You can try increasing your Swap Memory, sometimes it works: caprover/caprover#363 (comment)

If swap memory doesn't help, you have to increase the RAM of your machine.

You can also build your image somewhere else (your laptop or CI pipeline) and push the built image to a Docker Registry and just set the name of the image. This is a more advanced method and requires a tutorial if you're not familiar with Docker. One of the users mentioned that they will be writing a tutorial on this sometime soon #4

PS:

If you application logs show that your application is running, the most common case is that your application is binding to a custom port, not port 80. For example, CouchDB runs at port 5984. In this case, go to app's settings on CapRover, go to HTTP Settings, then select 5984 as the "Container Port".

https://caprover.com/docs/troubleshooting.html#successful-deploy-but-502-bad-gateway-error

This is listed under "Successful deploy but 502". This does not apply to you. Yours fails at the deploy stage.

[tistudios]

I don't think it's a RAM issue since it's 4vCPUs and 15 gigs of RAM on the thing and the app built itself on my laptop (1 cpu and 4gb of ram).

Actually the docker idea is interesting. That's what I thought about before I went to bed ->
Make a docker image and then push that image through. If it's not too complicated I'll make a tutorial for you. I know docker.

Thankfully for this specific rails application I found someone has already made a dockerfile in the pull requests. Will update

[tistudios]

Okay after 30 builds I finally got the dockerfile correct! But now the issue is when I go to preview the url it still just shows me 'nothing to deploy'

Puma.rb (the web server)

// frozen_string_literal: true

// Puma can serve each request in a thread from an internal thread pool.
// The `threads` method setting takes two numbers: a minimum and maximum.
// Any libraries that use thread pools should be configured to match
// the maximum value specified for Puma. Default is set to 5 threads for minimum
// and maximum; this matches the default thread size of Active Record.
//
threads_count = ENV.fetch('RAILS_MAX_THREADS') { 5 }
threads threads_count, threads_count

// Specifies the `port` that Puma will listen on to receive requests; default is 3000.
//
port        ENV.fetch('PORT') { 3000 }

// Specifies the `environment` that Puma will run in.
//
environment ENV.fetch('RAILS_ENV') { 'production' }

// Specifies the number of `workers` to boot in clustered mode.
// Workers are forked webserver processes. If using threads and workers together
// the concurrency of the application would be max `threads` * `workers`.
// Workers do not work on JRuby or Windows (both of which do not support
// processes).
//
// workers ENV.fetch("WEB_CONCURRENCY") { 2 }

// Use the `preload_app!` method when specifying a `workers` number.
// This directive tells Puma to first boot the application and load code
// before forking the application. This takes advantage of Copy On Write
// process behavior so workers use less memory.
//
// preload_app!

// Allow puma to be restarted by `rails restart` command.
plugin :tmp_restart

App Log

2019-02-08T21:57:08.826722421Z Puma starting in single mode...
2019-02-08T21:57:19.908229349Z Puma starting in single mode...
2019-02-08T21:57:19.908305648Z * Version 3.12.0 (ruby 2.6.0-p0), codename: Llamas in Pajamas
2019-02-08T21:57:08.826802535Z * Version 3.12.0 (ruby 2.6.0-p0), codename: Llamas in Pajamas
2019-02-08T21:57:08.826808267Z * Min threads: 5, max threads: 5
2019-02-08T21:57:19.908309883Z * Min threads: 5, max threads: 5
2019-02-08T21:57:08.826812412Z * Environment: production
2019-02-08T21:57:11.554894499Z * Listening on tcp://0.0.0.0:3000
2019-02-08T21:57:11.555019319Z Use Ctrl-C to stop
2019-02-08T21:57:19.908312870Z * Environment: production
2019-02-08T21:57:22.675502239Z * Listening on tcp://0.0.0.0:3000
2019-02-08T21:57:22.616447237Z - Gracefully stopping, waiting for requests to finish
2019-02-08T21:57:22.623246352Z === puma shutdown: 2019-02-08 21:57:22 +0000 ===
2019-02-08T21:57:22.675830337Z Use Ctrl-C to stop
2019-02-08T21:57:22.623282604Z - Goodbye!

I have a mongodb database running that's one-click.
HTTPS enabled and forced.

[tistudios]

But it loads an HTML only version of my app when I go to https://name.captain.something.something.com:443

[tistudios]

now the normal url of https://name.captain.something.something.com loads just the html only version

[githubsaturn]

What do you mean by HTML only version?

Also, according to the docs of the app that you are deploying, APP_BASE_URL should not have https:// part in it, just plain domain like something.another.domain.com.

A few additional points:

• This app is very poorly designed in terms of portability. It seems to be specifically designed for Heroku. For example, when you run heroku addons:create mongolab:sandbox, Heroku adds "Heroku specific" environmental variable such as "MONGODB_URI" to your app. Same with other add-ons.
• Basically with every heroku addons:create, Heroku creates a "One Click App" and adds an environmental variables formatted in Heroku way to your application.
• You don't have those environmental variables setup in your environment. Basically deploying this app on any platform, other that Heroku requires reverse engineering every single environmental variable that Heroku sets.

All in all, I would recommend you to reach out to the project maintainers and ask them to redesign the deployment guidelines such that it is open to be deployed anywhere, Heroku or elsewhere. For example, they can provide a docker-compose file. For example, Parse can run on Heroku, but it's not designed only for Heroku. They provide environmental variables that can be set:
https://github.com/parse-community/parse-server#running-parse-server

[tistudios]

totally agree with you there - The app itself will be replaced by something I will custom make. I just wanted to see if i could atleast the frontpage to render. This is all I'm getting rn. https://yuii.serviceplatform.hopintech.com/

[githubsaturn]

This is a placeholder. It means either the build has failed. Or the app exits immediately after running and Docker considers this as a faulty build, so it rolls it back. The latter seems to be the case.

In your app logs, seems like the app is exiting

.......
2019-02-08T21:57:11.554894499Z * Listening on tcp://0.0.0.0:3000
2019-02-08T21:57:11.555019319Z Use Ctrl-C to stop
2019-02-08T21:57:19.908312870Z * Environment: production
2019-02-08T21:57:22.675502239Z * Listening on tcp://0.0.0.0:3000
2019-02-08T21:57:22.616447237Z - Gracefully stopping, waiting for requests to finish
2019-02-08T21:57:22.623246352Z === puma shutdown: 2019-02-08 21:57:22 +0000 ===
2019-02-08T21:57:22.675830337Z Use Ctrl-C to stop
2019-02-08T21:57:22.623282604Z - Goodbye!

[tistudios]

I created a dockerfile that allows the app to be built beautifully. For some reason it's just the css that isn't rendering through.
Here ya go.

FROM ruby:2.6.0
ENV NVM_VERSION v0.34.0
ENV NODE_VERSION v10.15.1
ENV NVM_DIR /usr/local/nvm
RUN mkdir $NVM_DIR
RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash
ENV NODE_PATH $NVM_DIR/$NODE_VERSION/lib/node_modules
ENV PATH $NVM_DIR/versions/node/$NODE_VERSION/bin:$PATH
RUN echo "source $NVM_DIR/nvm.sh && \
    nvm install $NODE_VERSION && \
    nvm alias default $NODE_VERSION && \
    nvm use default" | bash
RUN apt-get update -qq -y && apt install -y build-essential openssl curl libpq-dev git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libgmp-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion pkg-config
ENV APP_HOME /app
RUN mkdir $APP_HOME
WORKDIR $APP_HOME
ADD Gemfile* $APP_HOME/
# Setting env up
ENV RAILS_ENV='production'
ENV RACK_ENV='none' 
# Adding gems
RUN gem install bundler -v 1.17.3
RUN gem install execjs
RUN bundle install
# Adding project files
COPY . .
RUN bundle exec rake assets:precompile
EXPOSE 8080
# CMD ["bundle", "exec", "puma", "-C", "config/puma.rb"]
CMD rails s -e production

[githubsaturn]

I created a dockerfile that allows the app to be built beautifully :) For some reason it's just the css that isn't rendering through.

That's so bizarre. I have no experience in Ruby, but it has to have something to do with static file serving.

[tistudios]

Apparently it may have something to do with nginx
Here's a link.

[tistudios]

My repository is missing a docker-compose. Does that seem like something important? 😆
Here's the contents of my docker-compose.yml -> I'm not sure if it's related but I was struggling with the proper way to link this app to a mongo & redis one-click app within Caprover. So you are correct that it would involve a reverse engineer of every single environmental variable.

Thanks I appreciate the help greatly.

web:
  build: .
  command: bundle exec puma -C config/puma.rb
  ports:
  - "8080:8080"
  - "443:443"
  links:
  - mongodb
  - mongodb://
  - redis
  - redis://
  environment:
  - RAILS_ENV=production
  - RACK_ENV=none
mongodb:
  image: mongo
redis:
  image: redis

[githubsaturn]

Docker compose is a good way for apps to define their dependencies.

So, assuming you have installed a Redis and MongoDB in CapRover, everything in your app looks create, except one thing: you need to find out what environmental variables are used to connect to redis and MongoDB, then set them to appropriate values, something like:

REDIS_URI: redis://srv-captain--your-redis-app-name?password=somepassword
MONGODB_URI: mongodb://username:password@srv-captain--your-mongodb-app-name:27017/db