English
« Back to projectatomic.io
Ask Your Question
0

Host vs Service config separation

asked 2016-04-19 16:34:17 +0000

clcollins gravatar image

I'm curious how others using Atomic are handling the separation of configuration data between the Atomic host level and the Service level. For example:

A service requires an NFS mount to work (assume we're not using Kube volume stuff for this). Do you:

a. Edit the standard cloud-init config so the Atomic host itself is created special for that service b. Change an existing Atomic host using some external means like Ansible, effectively making it specially created for the service c. Use a privileged container or something like it to configure the Atomic host on-demand when or if the service is deployed to it d. Something else (NFS in a container, with it's own unique challenges)?

My struggle is the trade off between customizing a specific host vs. modifying it on-demand. I'd like to keep a large pool of identical Atomic hosts, and have them become the "special snowflake" for each service only when the service is there. At some level some outside service or manual intervention is needed to provide that config data, but what is your take on where that should live? Should host configs be generic? Entirely separate from service configs? Co-mingled, assuming the host is for the service? Addressing that last point, we could assume the host is created to live and die with the service, so no big deal?

(I realize Kubernetes can manage volume stuff - NFS is just an example).

Thanks!

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2016-05-10 18:11:06 +0000

The instict to keep Atomic Hosts identical and interchangeable is the right one. Atomic Hosts are generally used as cluster members, so any individualization of a specific host to a service would be a different model of thinking about the host. Services that are containerized should be agnostic to the distro and host they are run on. So at some level, your container management choice needs to understand the volume requirements of the Service.

By design, this is what Kubernetes volumes and Docker volumes do. There may be more prep work for Docker volumes, since Docker may need a volume plugin or the NFS shares to be pre-mounted on all hosts.

Is there a particular reason why you want to do the configuration at the host level and not with an orchestration layer?

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

Follow
1 follower

Stats

Asked: 2016-04-19 16:34:17 +0000

Seen: 308 times

Last updated: May 10 '16