run Ansible on target machine with IP rather than domain

[ck1981]

Hello and thank you for this great project!

I am just testing it now and after a few issues with ansible bugs have all playbooks completing successfully.

However I currently have in my hosts file simply "localhost ansible_connection=local" under both hosts so obviously the IP will not resolve to anything and so I get nginx welcome page (I am running Ansible on the target machine itself due to other infrastructure requirements).

But when I put the machine IP address in place of "localhost" for all hosts then debops.postfix task fails as it expects a domain.

So I thought about trying to put "localhost" for [debops_all_hosts] and the machine IP for [wordpress] and all playbooks complete however now I see: 404 Not Found from nginx.

I thought maybe the above was a neat way to seperate out tasks between those needing domain and those that accept an IP.

It seems like I have no idea how these playbooks are structured and my assumption above is completely wrong.

So do I need to start digging into the playbooks to modify them or is there some shortcut that I am missing to let me use the machine IP?

I realize this is a newb question, sorry about that!

Thank you!

[drybjed]

DebOps is designed to work in a multi-host environment and a proper DNS configuration with a domain on which all hosts are present is one of the core concepts. Changing this model to one where a domain is not needed will take a bit of effort and in some cases like debops.postfix might be counterproductive.

Presumably you are applying the playbook on a host somewhere (never mind that the Ansible runs locally on that host), why not use its own domain in the inventory? That way some infrastructure roles like debops.pki, which expect a working DNS domain, should work fine. That would be presumably much easier than messing around in the various roles to make DebOps work on localhost.

[ck1981]

Hello drybjed,

Thank you so much for your reply, I really appreciate that very much!

Well I think its better that I tell you the bigger picture and if you are able then you can add further opinion if you like which I would like very much.

Because I am testing your tool with scalr, are you familiar with it? And I am constantly in general spinning up vm's for testing of infrastructure as well as the site itself using only the IP. So I was first trying to spin up a vm using your tool with only an IP to test with scalr. But I think upon your advice then I shall assign a domain for testing purposes. It is no big deal and we cannot ask too much flexibility of your tool, narrower is great I think to a degree.

The bigger challenge I see ahead (and maybe I should have titled this thread about scalr or started a new thread, if so sorry and please let me know), is after I get your tool running on a single vm infrastructure then how to split out to a three tier infrastructure? This could start by even just using scalr's nginx and mariadb appliances but also could look to use your playbooks for all three tiers later possibly. If you have any opinion as to the best direction or any shortcuts for this would be great (I am more a user and hacker of playbooks at this stage but maybe for this case I would need to really pull this apart and get dirty).

Thank you very much!

EDIT: https://github.com/Scalr/scalr

"Scalr is an open-source Cloud Management Platform (CMP). It leverages the APIs exposed by compatible Cloud Platforms (including AWS, GCE, OpenStack, CloudStack, and more) to provide users with a high-level and productive interface to their organization's cloud resources."

[drybjed]

If you plan to use multiple hosts in your infrastructure, I would start by moving the Ansible Controller to a separate host so that configuration can be centralized. After that, you will need to configure some variables to point roles to different hosts (for example to tell the hosts where the MariaDB server is located) so they know where to look for resources. It depends on what services you want to manage and what host layout you want to use. This is where a custom domain comes handy.

The main DebOps playbook should be easy enough for you to modify if you need. It's designed so that Ansible roles are executed on specific hosts depending on what groups the host is in, so in simple cases all you would need to do is to add specific hosts to [debops_service_nginx], [debops_service_mariadb_server], and so on. Of course nothing stops you from using your own plays instead, with a custom group and play layout.

The debops-wordpress playbook and roles are a bit different, last time I checked @carlalexander used the role dependencies in meta/main.yml of some roles which is much harder to deal with on the playbook level. You probably might need to modify his roles if you need to move services around.

[ck1981]

Thank you drybjed!

I think that you may be right that the better way would be to centralise the ansible controller, actually the only reason I haven't is for testing purposes, so again maybe my 'testing purposes' shortcuts are only ever causing me problems! I.e. I was going to use a scalr script (post vm boot/init) to install ansible and use ansible-pull or even install git and use git clone, its not really how it should be done and I would probably end up centralising the ansible controller later anyway! But I will see how it goes as a learning exercise.

Oh I'm just reading your next advice and realised that I may need a domain for each vm within the tier as you say, but then I don't know how this would be achieved during horizontal scaling (including autoscaling) i.e. if each vm needs a domain then new vm's added on demand need a domain? Meaning that would need to be assigned dynamically too? Maybe I have misunderstood though. If not then maybe I would need to be able to specify IP address afterall to aviod needing to have domains for vm's created on demand. Sorry I should have mentioned the horizontal autoscaling ability but did not think far enough ahead.

Oh! Your point about assigning roles to hosts is a lightbulb moment and exactly the kind of advice I could have hoped for, thank you!

I did notice the role dependancies earlier but would not have thought about their effect, so thank you for this point too!

Thank you so much!

[drybjed]

DebOps is designed around both a DNS domain (ansible_domain variable), and a host's FQDN (ansible_fqdn variable). For example, we have the domain example.org, and two hosts that are named alpha and omega. Their FQDNs would therefore be, alpha.example.org and omega.example.org.

You don't need to have a separate "domain" for each host, all you need to do is to ensure that they all use the same example.org domain and have distinctive subdomains of their own. A good test for this is to run the

hostname --fqdn

command on a given host. If you get a string that has at least 2 dots, then you should be fine. Then debops.pki role can create X.509 certificates for cn=*.example.org and all your hosts can use them no matter what their hostnames are, or what the DNS FQDN they are using. To make this more manageable you could handle this via proper DHCP/DNS services, but I imagine that in a VPS environment that might not be possible.

You should check out the debops.bootstrap role, it can help you prepare a host to be managed by DebOps, including configuration of the correct domain and FQDN. Of course having proper DNS entries so that hosts can talk to each other using their FQDN names should be a given as well, configuring /etc/hosts on Ansible Controller might not be enough in this case.

Perhaps your deployment solution can configure the host's domain and hostname automatically for you, check if that's possible.

[ck1981]

Oh ok subdomains of course, that makes sense!

Well to be honest I didn't even think as far as certficates yet!

Ok I will look at debops.bootstrap too, thank you.

Scalr has the ability to integrate with ansible API to for example dynamically update ansibles hosts list I believe. Scalr also has some 'autodiscovery' scripts for upstream and downstream vm's. I may need to make use of one or both of these. You can see the links regarding this and also subdomains below if you are interested, its mostly for my and hopefully others reference.

links:

https://scalr-wiki.atlassian.net/wiki/display/docs/Step+3+-+Create+a+Farm+to+Host+the+Webapp+Infrastructure (from above "Your Farm Roles should not live in isolation! In fact, you need to add some coordination rules:

• In order to route traffic appropriately, Nginx instances need to be notified when a new Webapp instance is launched. They also need to be notified when a Webapp instance is decommissioned.
• In order to connect to the appropriate database servers, Webapp instances need to be notified when a new MySQL instance is launched. They also need to be notified when a MySQL instance is decommissioned.")

https://scalr-wiki.atlassian.net/wiki/display/docs/Step+1+-+Synchronising+Scalr+Servers+with+an+Ansible+inventory (from above "The inventory script uses the public IP of the servers to identify them in Ansible by default. If it is guaranteed that all Servers have a resolvable hostname that Ansible can use to connect to them, it is possible to edit the inventory script so that it uses the hostnames to register the Servers in Ansible.")

https://scalr-wiki.atlassian.net/wiki/display/docs/Pointing+a+Subdomain+to+a+Farm+Role (from above "If you are pointing a domain to a Farm, System DNS records will be created as subdomains of that domain. If the domain is being pointed to a Farm AND a Farm Role, System DNS records are still created as subdomains of that domain and the domain apex is pointed to the selected Farm Role.

Underneath Automatically create A records for, select the Farm from the provided drop-down menu. Then click Save to complete this change to the selected DNS Zone. If you intend to use System DNS Records (see this page, section "DNS", for how to configure them), you only need to point your Domain Name to a Farm. Just fill in this field and do not add a Role.")

Conclusion: So I guess I make my vm's use a scalr role that I have registered in ansible inventory in the appropriate group (note that ansible tower is not required), and so the appropriate playbook run against the vm upon creation using its HOSTNAME (see quote about the inventory script above) due to me configuring the use of automatically generated subdomains (see quote about A records above). Then I would set the role to run the autodiscovery script. Phew!!! I have no idea how accurate this is but its better than nothing...

Thank you again your help is so much appreciated!

[carlalexander]

Is this ok to close @ck1981?

[ck1981]

Yes it's ok thanks Carl.

On Sunday, June 25, 2017, Carl Alexander notifications@github.com wrote:

Is this ok to close @ck1981 https://github.com/ck1981?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/carlalexander/debops-wordpress/issues/146#issuecomment-310874566, or mute the thread https://github.com/notifications/unsubscribe-auth/ALbt4-KPqED01d1G5-o68IsMcL06Wcqcks5sHa1RgaJpZM4MZDbi .

-- Tel: +61 438 525 409

• Email: craigkooloos@gmail.com craigkooloos@gmail.com*

[carlalexander]

Awesome! Thanks @ck1981!