Ansible: Difference between revisions

From 탱이의 잡동사니
Jump to navigation Jump to search
No edit summary
Line 12: Line 12:
   hosts (1):
   hosts (1):
     192.168.100.10
     192.168.100.10
</pre>
=== -K, --ask-become-pass ===
sudo 명령어 사용시, 사용되는 비밀번호를 묻도록 한다.
==== Example ====
<pre>
$ ansible all -m ping -K
SUDO password:
192.168.56.102 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
192.168.56.101 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
</pre>
</pre>



Revision as of 23:13, 7 January 2019

Overview

Ansible 내용 정리.

Options

-i

Inventory 를 지정한다.

Example

$ ansible -i ./hosts --list-hosts remote
  hosts (1):
    192.168.100.10

-K, --ask-become-pass

sudo 명령어 사용시, 사용되는 비밀번호를 묻도록 한다.

Example

$ ansible all -m ping -K
SUDO password: 
192.168.56.102 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
192.168.56.101 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

-m, --module-name

지정된 모듈을 실행한다.(default=command)

-m MODULE_NAME, --module-name=MODULE_NAME

-u, --user

지정된 사용자로 접속한다. (default=None)

-u REMOTE_USER, --user=REMOTE_USER

Example

$ ansible -i ./hosts remote -m ping -u pchero
192.168.100.10 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Directory

directory layout

production                # inventory file for production servers
staging                   # inventory file for staging environment

group_vars/
   group1.yml             # here we assign variables to particular groups
   group2.yml
host_vars/
   hostname1.yml          # here we assign variables to particular systems
   hostname2.yml

library/                  # if any custom modules, put them here (optional)
module_utils/             # if any custom module_utils to support modules, put them here (optional)
filter_plugins/           # if any custom filter plugins, put them here (optional)

site.yml                  # master playbook
webservers.yml            # playbook for webserver tier
dbservers.yml             # playbook for dbserver tier

roles/
    common/               # this hierarchy represents a "role"
        tasks/            #
            main.yml      #  <-- tasks file can include smaller files if warranted
        handlers/         #
            main.yml      #  <-- handlers file
        templates/        #  <-- files for use with the template resource
            ntp.conf.j2   #  <------- templates end in .j2
        files/            #
            bar.txt       #  <-- files for use with the copy resource
            foo.sh        #  <-- script files for use with the script resource
        vars/             #
            main.yml      #  <-- variables associated with this role
        defaults/         #
            main.yml      #  <-- default lower priority variables for this role
        meta/             #
            main.yml      #  <-- role dependencies
        library/          # roles can also include custom modules
        module_utils/     # roles can also include custom module_utils
        lookup_plugins/   # or other types of plugins, like lookup in this case

    webtier/              # same kind of structure as "common" was above, done for the webtier role
    monitoring/           # ""
    fooapp/               # ""

Modules

get_url

Downloads files from HTTP, HTTPS or FTP to the remote server. The remote server must have direct access to the remote resource.

By default, if an environment variable <protocol>_proxy is set on the target host, requests will be sent through that proxy. This behaviour can be overridden by setting a variable for this task (see setting the environment), or by using the use_proxy option. HTTP redirects can redirect from HTTP to HTTPS so you should be sure that your proxy environment for both protocols is correct.

From Ansible 2.4 when run with --check, it will do a HEAD request to validate the URL but will not download the entire file or verify it against hashes. For Windows targets, use the win_get_url module instead.

Example

- name: Download the Asterisk archive
  get_url: url={{ asterisk_url }} dest={{ asterisk_source_file }}
  register: asterisk_archive

See also

ping

A trivial test module, this module always returns pong on successful contact. It does not make sense in playbooks, but it is useful from /usr/bin/ansible to verify the ability to login and that a usable Python is configured.

This is NOT ICMP ping, this is just a trivial test module that requires Python on the remote-node.

For Windows targets, use the win_ping module instead. For Network target, use the net_ping module instead.

Example

ansible asterisk -i inventory/test-virtualbox -u pchero -m ping
192.168.100.10 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

See also

See also