CoreOS as single standalone machine

651 views
Skip to first unread message

coreos...@gmail.com

unread,
Mar 4, 2016, 1:38:55 PM3/4/16
to CoreOS Dev
I am just now beginning the research of CoreOS as a candidate for transitioning my company's environment. Currently it is CentOS 6 in multiple private and public clouds. I'm having a great time learning and playing with it (though frankly I'm having a hard time determining what bits I need to focus on first since there are so many new things to learn). :) I have need for many non-mission-critical hosts that require no clustering/failover/etc and therefore to save on costs I want to run them standalone. I have seen a few places where it is described to use a cloud-config like the following to bypass networking or discovery tokens:

coreos:
  units
:
   - name: etcd.service
     command: start
   - name: fleet.service
     command: start

My questions is thus (and I apologize if I don't understand enough to know if these are even valid questions):

1) Does either or both etcd and/or fleet actually need to be running on a standalone host? Are they so integral to CoreOS that they must be used?

2) Is there any concern with running applications like nginx, mysql, postgres, apache, etc. directly on the OS or must everything be in a container?

The vast majority of our hosts will be clustered hence CoreOS is the first OS that I chose to evaluate. However, it would be nice to have a single OS for all virtual machines regardless of whether they are clustered or not.

Alex Crawford

unread,
Mar 4, 2016, 2:18:59 PM3/4/16
to coreo...@googlegroups.com
On 03/04, coreos...@gmail.com wrote:
> 1) Does either or both etcd and/or fleet actually need to be running on a
> standalone host? Are they so integral to CoreOS that they must be used?

Nope. I have a standalone host that runs a few services. I don't actually use
etcd or fleet since there is no cluster.

> 2) Is there any concern with running applications like nginx, mysql,
> postgres, apache, etc. directly on the OS or must everything be in a
> container?

Most of those applications will have dependencies on shared objects that are not
present on CoreOS. Throwing them in a container allows you to bundle those deps
and specific versions of those deps. If the application is smaller, there is a
good chance it will run fine natively. And of course, statically linked binaries
will have no trouble at all.

It is also worth noting that you will probably want to use locksmith's "reboot
window" feature [1]. This will allow you to specify when the machine should
reboot after it gets an update.

-Alex

[1]: https://github.com/coreos/locksmith#reboot-windows
signature.asc

Derek Mahar

unread,
Jul 18, 2016, 11:00:59 AM7/18/16
to CoreOS Dev
On Friday, 4 March 2016 14:18:59 UTC-5, Alex Crawford wrote:
On 03/04, coreos...@gmail.com wrote:
> 1) Does either or both etcd and/or fleet actually need to be running on a
> standalone host? Are they so integral to CoreOS that they must be used?

Nope. I have a standalone host that runs a few services. I don't actually use
etcd or fleet since there is no cluster.

Do you run your services in Docker or rkt containers?  If using rkt, what kind of networking do you use and how do you configure your containers to talk to each other?

I wish to run rkt containers for vpnc, ActiveMQ, PostgreSQL server, Tomcat, and a standalone Java application on a single CoreOS host, but am unsure how the Tomcat and the Java application containers can address the shared ActiveMQ and PostgreSQL server containers.  A user on #coreos has told me that I must use service discovery, but this strikes me as overkill for a few containers that run on a single host.

Any suggestions?

Derek

Florian Koch

unread,
Jul 18, 2016, 12:22:52 PM7/18/16
to coreo...@googlegroups.com
why not run these apps in a pod?

Rob Szumski

unread,
Jul 18, 2016, 12:48:18 PM7/18/16
to coreos-dev
You can attach these containers to “host” networking, which will allow you to do simple port addressing, like you would with a non-containerized host. Run X on 8080, run Y on 9999, etc. Applies to both rkt and Docker.

rkt networking docs: https://coreos.com/rkt/docs/latest/networking/overview.html#host-mode

- Rob

Derek Mahar

unread,
Jul 18, 2016, 12:52:47 PM7/18/16
to CoreOS Dev
All of them?  Wouldn't this create a very long and complicated 'rkt run' command and systemd unit?  How could I split the single 'rkt run' command into multiple commands?  At the moment, I think the answer to this question is, "You can't."

Seán C. McCord

unread,
Jul 18, 2016, 12:55:23 PM7/18/16
to CoreOS Dev
Both rkt and docker run commands get very long very quickly.  That's normal (and why such things should go in a definition file... such as systemd units).  To answer your question, though, if you want multiple containers in the same pod, they all need to be listed in the same run command.

--
Seán C McCord
CyCore Systems, Inc

Derek Mahar

unread,
Jul 18, 2016, 1:01:45 PM7/18/16
to CoreOS Dev
I've avoided it because it's not much different than running each service outside of a container.  Host networking abandons network isolation, leaving only file and process isolation.  These can be very useful and important, but so is network isolation, which is why I appreciate Docker container linking which allows you to refer to a container using a simple host name.  However, I'd prefer to use rkt because it and systemd seem to work better together.

Derek

Derek Mahar

unread,
Jul 18, 2016, 1:04:01 PM7/18/16
to CoreOS Dev
Unfortunately, this also means that I can't restart each container separately.  I must restart them all at once.

Derek Mahar

unread,
Jul 18, 2016, 1:35:45 PM7/18/16
to CoreOS Dev
On second thought, using containers with host networking still provides the important advantage of application and operating system independence.  In such a configuration, one can still update the operating system independent of the applications.  
Reply all
Reply to author
Forward
0 new messages