Question regarding future updates (Unsupported Install Upgrade How To inside)

(Brendan) #1

My apologies if this ground has been tread many times before. I haven’t been able to find much via search (or I just suck… totally possible).

I have recently successfully installed Discourse on my server (successfully! yay!) via the unsupported method on a CentOS 6.5 VPS that can’t run Docker due to, as far as I can tell, container limitations.

My question is regarding future updates. I have written a really simple/small bash script that, with my limited understanding of how Discourse operates, should(?) work.

Is this all that’s required for an update?

  1. Pull latest code
  2. Run rake db:migrate to update db
  3. Run rake assets:precompile to recompile assets
  4. Restart discourse

(Brendan) #2

OK, so just got released… and my process doesn’t work.

What is required to update? Docker is not an option for me :frowning:

(Jeff Atwood) #3

In the medium to long term, you need to find a way to make Docker an option – it is our only supported install.

You are asking us to support something we explicitly said we don’t support.

(Brendan) #4

I appreciate the response… I understand it’s not supported, but docker has to be doing something that I can do manually? Is it an option for me to simply wipe out all the files and reinstall? As far as the database is concerned, do I just need to run rake db:migrate?

(Kane York) #5

The whole point of Docker is that all the dependencies and environment – e.g. Ruby version, ImageMagick installed – are set up the same everywhere.

That said, a backup and restore should be everything needed to transfer from one installation to another -script/discourse backup will work as long as you can still connect to the database.

(Brendan) #6

Yes, I understand that is the point. However I doubt I am in a unique situation in that I a) can’t use docker and b) can’t justify throwing out my VPS just to run this one application.

It also doesn’t make sense to me to get another VPS just to run discourse when I’ve got a perfectly good one (sans the ability to run docker) with 4GB of memory sitting right there. I would also like to point out that Docker itself is the only thing that has requirements that my server can’t meet. It has nothing to do with discourse (which runs perfectly well).

I also have absolutely no issues with maintaining ImageMagick, Ruby, et al when upgrades happen (and fixing any issues). It would be really nice if these changes were documented somewhere though, since you are doing these upgrades to the docker image. You don’t have to “support” it, but at least have the information available to people like me so we have some kind of direction to go in.

(Brendan) #7

So, I looked at this: docker_manager/upgrader.rb at master · discourse/docker_manager · GitHub

Up to date as of

Performed the following steps (as discourse user, inside discourse dir):

  1. git fetch
  2. git checkout tests-passed
  3. If git complains that tests-passed is behind in commits, you can do a git pull now.
  4. git reset --hard HEAD@{upstream}
  5. bundle install --deployment --without test --without development
  6. RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ENV=production bundle exec rake multisite:migrate
  7. RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ENV=production bundle exec rake assets:precompile
  8. ps aux | grep sidekiq.*busy | grep -v grep | awk '{ print $2 }'
  9. Kill that pid (e.g. kill 9999)
  10. ps aux | grep bluepilld | grep -v grep | awk '{ print $2 }'
  11. Kill that pid
  12. ps aux | grep thin
  13. Kill pids matching discourse user
  14. RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ENV=production RAILS_ROOT=/path/to/userhome/discourse NUM_WEBS=2 /path/to/userhome/.rvm/bin/bootup_bluepill --no-privileged -c ~/.bluepill load /path/to/userhome/discourse/config/discourse.pill

Then, as root:

  1. service nginx reload

All should be well.

Unsupported Discourse Upgrade Script
(Jeff Widman) #8

Thanks for this.

I get why the Discourse team wants people on Docker, it makes most peoples lives simpler, but thought the question was totally valid since it had nothing to do with dependancies and was simply about the mental model for steps to migrate/restart.