CoreOS Beta Release
coreos.com
coreos.com
https://coreos.com/docs/running-coreos/bare-metal/booting-wi...
http://coreos.com/blog/boot-on-bare-metal-with-pxe/
But I've not heard a lot from people with clusters of them. Perhaps I'll have to snag a small cluster of lab boxes and give it a go myself!
I hope the CoreOS team manages to reach what they would consider a "stable, and production ready version of CoreOS" sometime around (after, but around) when Docker 1.0.0 lands.
I hope some of you can make it to the hackfest!
I'm super excited by this release and look forward to this shaping the way people do cloud.
1. http://marceldegraaf.net/2014/04/24/experimenting-with-coreo... 2. http://marceldegraaf.net/2014/05/05/coreos-follow-up-sinatra...
* Install Docker on your dev machine (remember, there is a Mac version too)
* Add a Dockerfile to your source repo, specifying how to assemble a container image from source.
* Use a combination of "docker build" and "docker run" to test during development. You can use docker tags to build a separate image for each git commit/tag/branch.
* When ready to deploy, use "docker push" to upload your image to a registry (you can run your own, or use the official registry at https://index.docker.io). Note the official registry supports private images.
* From your production machines (presumably CoreOS but you may have a mix of other distros too) run "docker pull" and "docker run" to deploy your app.
* Use Links ("docker rum --link") to interconnect containers, for example your frontend to your database, etc.
Mostly if you use Docker for development, you don't need Vagrant. Specifically the Dockerfile is basically a replacement for the Vgrantfile. The caveat is that you can use vagrant for machine deployment to get to a working docker deployment. We used to recommend this but people got confused between the 2, so now we recommend boit2docker instead.
I hope this helps.
What's the current best-practice to interconnect containers running on different hosts? Is Docker going to add this capability itself, or will this always be something built on top of Docker by e.g. CoreOS?
EDIT: Wait, what's your email/blog?
cat /usr/lib64/systemd/system/multi-user.target.wants/locksmithd.service [Unit] Description=Cluster reboot manager Requires=update-engine.service After=update-engine.service
[Service] EnvironmentFile=-/usr/share/coreos/update.conf EnvironmentFile=-/etc/coreos/update.conf ExecStart=/usr/lib/locksmith/locksmithd Restart=always RestartSec=10s
[Install] WantedBy=multi-user.target
...and also a new locksmithctl binary that has options for setting and unsetting locks among other things. I guess you could create a systemd unit that unlocks any set lock, and run it 10 minutes after boot with a systemd timer, as a start.
The IRC channel #coreos on Freenode is also a great place to get help.
If you stopped etcd on all your CoreOS nodes, installed consul, and had all of your CoreOS systemd units register with consul (say, with an ExecStartPre step), you'd technically be 'running CoreOS with Consul' - but fleet would be just straight up broken without etcd, meaning there'd be no way to submit units to different nodes in your cluster, or view logs, or really manage the cluster at all.
Looking at the fleet source code (https://github.com/coreos/fleet), it looks like swapping out etcd for consul would take a lot more effort than 'sed -i -e 's/etcd/consul/g' *.go'. You'd essentially have to do a rewrite of fleet from scratch.