I ran the docker updater via /admin/dokcer. Does this automatically do everything mentioned in the OP? Do I still have to do it? In the control panel its showing that I am running 1.0.0 successfully. (Just want to make sure)
Also, when I try going to /admin/docker after the update, it just gives me a 404 error.
Wow! The discourse upgrade process with the docker system is a bit of a marvel now! Well done!
I’m wondering what the general upgrade vision is currently? There is the update page ( /admin/upgrade ) which doesn’t seem to be linked anywhere and there is the dashboard version which says up to date, when upgrade will allow updates.
Is the update page for out-of-band/interim updates; but updates more generally will flow via the version number and an update button will appear on the dashboard?
I found that my EC2 instance that I built is different, this may be the same for others so here is how I updated.
When I went to update from the previous version to this I had to skip moving anything from /var/docker to /var/discourse.
When I first installed, the /var/discourse directory was already created separate from /var/docker, I am not exactly sure why. I checked the app.yml file and there is only one instance that references /var/docker which is the the /shared directory.
So with that being said, I skipped changing any references in app.yml and I skipped mv /var/docker /var/discourse because it didn’t seem right to move things around if the locations were already set.
So I simply ran the following;
./launcher stop app
apt-get dist-upgrade lxc-docker
Once that was done I ran the following (from within /var/discourse)
./launcher rebuild app
Newest version is up and running without a hitch. Hope this helps others if they run in to the same situation and possibly get confused.
There was a bug we briefly introduced into the codebase (since patched) that was messing up routing. Looks like you got “lucky” and got that version. You’ll have to update manually from the command line, sorry!
I get this message now when I ssh into the app. Just wondering if this was a symptom of moving the installation or if this is something more serious to be concerned about?
WARNING: No swap limit support
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
This was resolved by rebooting host OS, but I’m still not sure why it happened.
Oh wait, it wasn’t. Rebuild returns this:
Error response from daemon: Cannot destroy container 89dceb3d0cb0a369d28516ea7df308b05433b53695b28674165b206e2495db04: Driver devicemapper failed to remove root filesystem 89dceb3d0cb0a369d28516ea7df308b05433b53695b28674165b206e2495db04: Device is Busy
2014/08/31 10:44:38 Error: failed to remove one or more containers
Invalid cid file, deleting, please re-run
Update 2: I was able to successfully rebuild instance after 2-3 failed builds.
I’m still against dropping support for Docker v0.9.1 for a variety of reasons:
This is the version of Docker that Ubuntu 14.04 ships with. It is supported by the vendor (Just apt-get install docker.io and you’re done)
0.9.1 still even today on latest Discourse release, has had no issues since I first deployed it for Discourse. Newer versions on the other hand, have had their fair share of bugs, regressions, and all sorts of behaviour changes.
Docker-hosting services (at least the two I have spoken to) are opting for a stable, vendor supported version of Docker (Ubuntu’s 0.9.1 release)
Docker is still to this day, in active development. There will be more changes in future, potentially even config changes that are not backwards compatible. It is not Discourse’s job to test Docker on users’ production forums. Don’t change it if it’s not broken.
I will continue to run Discourse on Docker v0.9.1, as I do not want to have to keep changing my environment every time a new version is out. I want to run an application, not spend time managing a system (which was the very goal Docker set out to do).
I can’t use docker on my hosting (webfaction), and since last upgrade i had no problem.
I update my git repository to latest-release, now i have a problem with manual update
An error occurred while installing rbtrace (0.4.4), and Bundler cannot continue.
Make sure that `gem install rbtrace -v '0.4.4'` succeeds before bundling.
Here the error :
Fetching: rbtrace-0.4.4.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing rbtrace:
ERROR: Failed to build gem native extension.
-- tar zxvf msgpack-0.5.7.tar.gz
-- ./configure --disable-dependency-tracking --disable-shared --with-pic --prefix=/home/reyman64/webapps/discourse/gems/gems/rbtrace-0.4.4/ext/dst/
-- make install
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.
Provided configuration options:
/usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1551:in `stat': No such file or directory - /home/reyman64/webapps/discourse/gems/gems/rbtrace-0.4.4/ext/dst/ruby20/libmsgpackc.a (Errno::ENOENT)
from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1551:in `block in fu_each_src_dest'
from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1567:in `fu_each_src_dest0'
from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:1549:in `fu_each_src_dest'
from /usr/local/lib/ruby20/ruby/2.0.0/fileutils.rb:393:in `cp'
from extconf.rb:54:in `<main>'