Would you run puppet in init.d of the new node to sync
infrastructure?
Then you could use rundeck to trigger the shared config on each
instance, for on demand syncing.
On 16/09/15 13:23, Paul Thomas wrote:
Hi,
I’m new to shared file systems and horizontal cloud scaling.
I have already played with auto-scaling on aws/ec2. In term of
spawning a destroying and I can achieve that.
I just want to some advice of how best implement syncing for web
files, infrastructure, data, etc.
I have pretty much decided to put the database side of things on a
private instance.
I'll worry about db clustering later I’m not to bothered about
this not, because the software supports it.
It seems logical to put the web folder / application layer on a
shared file system, maybe some configuration too.
What I'm really unsure about is how to ensure that the current
system is up to date and the configuration tweaked for the
physical specs.
How do people typically approach this? I'm guessing it not always
viable to have a shared file system for everything.
Is the approach a disciplined one? Where say I have development
instance for infrastructure changes.
Then there is a deployment flow where production instances are
somehow refreshed without downtime.
Or is there some other approach?
I notice on sites like yahoo, things are often noticeably
unsynced, mostly on the data front, but also other things.
This would be unacceptable in my case.
I appreciate any help I can get regarding this.
My typical load is from php-fpm/nginx processes, mysql bellow
this.
Should the memory cache also be separated, or as I think it is
quite good for this to be divided up with the infrastructure to
support each public instance individually?
Paul
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
|
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users