I had to use current CoreOS alpha release (431.0.0), because this is the first one with Docker 1.2.0. This release uses btrfs instead of aufs, but it doesn’t cause any kind of issues.
I’d like to follow CoreOS’ way of managing containers, maybe the correct way should be to maintain a private docker registry, and to pull it from there instead.
Regarding memory use you should not expect huge across the board gains, the 40% figure is just relating to the “base OS” not the applications running.
Discourse consumes the vast majority of memory and mem usage is identical.
However, performance wise it is quite interesting.
btrfs means that we halve our boot time, so booting Discourse goes from 12 seconds down to 6.
Time to recompile assets (cached) rake assets:precompile
CoreOS (alpha 431.0.0)
real 0m38.563s
user 0m36.052s
sys 0m1.246s
Ubuntu (14.04.01 + Docker 1.2.0)
real 0m46.913s
user 0m40.888s
sys 0m5.576s
Time to start up rails time rake routes
CoreOS
real 0m5.790s
user 0m4.807s
sys 0m0.756s
Ubuntu
real 0m10.267s
user 0m5.945s
sys 0m4.179s
Time to recompile assets (uncached) redis-cli flushall && rake assets:precompile
###CoreOS
real 3m40.645s
user 3m26.428s
sys 0m2.381s
###Ubuntu
real 4m45.688s
user 4m38.128s
sys 0m8.702s
This doubling of boot time speed is most likely due to the usage of btrfs.
Ha yes, it cannot reduce memory usage magically and the OS doesn’t have build and scripting tools whatsoever. The promised 40% is about the default not loaded OS footprint.
I had to increase the coreos KVM instance’s memory allocation from 1G, because of OOM errors in Discourse. However, it’s a good idea to run multiple dockers on the same image, for better memory utilization.
The other question is how we can leverage CoreOS’ cluster feature. The documentation usually refers to a kill - rm - pull - run sequence, while discourse_docker keeps the original container if available. Is there a technology which updates the docker image other than launcher rebuild?
On a 1 GB CoreOS machine without swap, I had to cut down the number of unicorn instances to two. Also the update function (at /admin/upgrade) leads to out-of-memory situations. I have to stop the unicorns before trying to do that.
That’s the same as it is on Ubuntu. We recommend only 2 workers on 1GB per the official install docs, and we also recommend setting up swap to cover the upgrade case – upgrading chews through a ton of memory.
@magnars TBH I haven’t spent too much time on that It is still running well, but with only one CoreOS instance. I had to rebuild the docker image a couple of times already, which means 15-30 minutes of outage, but usually the update succeeds inside the container.
My problem with building and distributing an image inside CoreOS is you also have to at least separate the databases, and database upgrades can also cause you headaches.
Using CoreOS’ fleet is trivial but requires a small change which prevents that a different restart policy than below is set when boostrapping or rebuilding:
--- a/launcher
+++ b/launcher
@@ -319,5 +319,5 @@ if compare_version "1.2.0" "$docker_version"; then
echo "We recommend you upgrade docker, the version you are running has no restart policies, on reboot your container may not start up"
restart_policy=""
else
- restart_policy=${restart_policy:---restart=always}
+ : ${restart_policy:="--restart=no"}
fi
How’s Discourse on CoreOS today? I am about to start yet another Discourse based project, to a somewhat high profile client (semi-celeb). The concept of automatic updates is very tempting.
I don’t actually know why I mentioned the client profile - totally irrelevant.
This would of course be a learning experience for me, and the automatic update feature saves a bit of maintenance effort. Sure, the Ubuntu-way has been rock solid. Still it would be interesting to try CoreOS, at least for the development phase.
The CoreOS has several update strategies, regarding the reboot: