diff --git a/exercises/ansible_f5/2.0-disable-pool-member/disable-pool-member.yml b/exercises/ansible_f5/2.0-disable-pool-member/disable-pool-member.yml index ed6fdf565..1d65a51e5 100644 --- a/exercises/ansible_f5/2.0-disable-pool-member/disable-pool-member.yml +++ b/exercises/ansible_f5/2.0-disable-pool-member/disable-pool-member.yml @@ -50,6 +50,7 @@ name: "{{item.split(':')[0]}}" pool: "{{pool_name}}" port: "{{item.split(':')[1]}}" + host: "{{hostvars[item.split(':')[0]].ansible_host}}" loop: "{{bigip_facts.ltm_pools | json_query(query_string)}}" vars: query_string: "[?name=='{{pool_name}}'].members[*].name[]" @@ -62,4 +63,5 @@ name: "{{member_name.user_input.split(':')[0]}}" pool: "{{pool_name}}" port: "{{member_name.user_input.split(':')[1]}}" + host: "{{hostvars[member_name.user_input.split(':')[0]].ansible_host}} when: '"all" not in member_name.user_input' diff --git a/exercises/ansible_rhel/1.1-setup/README.ja.md b/exercises/ansible_rhel/1.1-setup/README.ja.md index 05bcae876..9fc45bd0e 100644 --- a/exercises/ansible_rhel/1.1-setup/README.ja.md +++ b/exercises/ansible_rhel/1.1-setup/README.ja.md @@ -1,7 +1,5 @@ # Exercise 1.1 - 要件を確認してみよう -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). - ## ラボ環境について このラボでは、事前設定されたラボ環境で作業します。 以下のホストにアクセスできます。 @@ -18,13 +16,13 @@ SSHでログインできます。: > **Warning** -> +> > **11.22.33.44** のような文字列を、個々に提供されているStudent情報に記載の **IP** などへ読み替えてください。 **X** は student**X** といった具合です. ssh studentX@11.22.33.44 > **Tip** -> +> > パスワードは **ansible** です。 rootになるには以下のように実行してください。: @@ -46,7 +44,7 @@ Ansibleが適切にInstallされているかを確認しましょう。 [...] > **Note** -> +> > Ansibleは構成管理を単純にしてくれます。 Ansibleはデータベースや実行用のデーモンを必要とせず、ラップトップでも簡単に実行できます。 管理対象ホストでは、実行用の常駐エージェントなども不要です。 rootアカウントからログアウトします。 @@ -55,7 +53,7 @@ rootアカウントからログアウトします。 logout > **Note** -> +> > 以降のすべての演習では、明示的な指示がない限り、コントロールノードのstudent\ ユーザーとして作業してください。 ## Step 1.2 - Working the Labs @@ -65,15 +63,15 @@ rootアカウントからログアウトします。 - すべて手で入力するのではなく、必要に応じてブラウザからコピー＆ペーストしてください。しかし、考えたり理解したりするのをやめたりしないでください。 - すべてのラボは **Vim** を使って準備しましたが、みんながそれを愛しているわけではないことを理解しています。 **Midnight Commander** などを利用することができます。(**mc**を 実行すると実行できます。ファンクションキーはEsc-\でアクセスするかマウスでクリックすることでアクセスできます。）。または **Nano**（**nano**を実行）なども利用できます。 簡単な[editor intro]も用意してあります。（../ 0.0-support-docs / editor_intro.md） - + ## Step 1.3 - チャレンジLabs -このラボガイドの様々な章で「チャレンジラボ」セクションがあります。 +このラボガイドの様々な章で「チャレンジラボ」セクションがあります。 これらのラボは、これまでに学んだことを使って解決するための様々なタスクを用意しています。 それぞれのラボの解答案は、`Warning`サインより下に記述されています。 ---- -[Click here to return to the Ansible for Red Hat Enterprise Linux Workshop](../README.ja.md#section-1---ansible-engine-exercises) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/1.1-setup/README.md b/exercises/ansible_rhel/1.1-setup/README.md index ceb25174d..fd1be62ab 100644 --- a/exercises/ansible_rhel/1.1-setup/README.md +++ b/exercises/ansible_rhel/1.1-setup/README.md @@ -62,9 +62,9 @@ Log out of the root account again: You might have guessed by now this lab is pretty commandline-centric…​ :-) - - Don’t type everything manually, use copy & paste from the browser when appropriate. But don’t stop to think and understand. + - Don’t type everything manually, use copy & paste from the browser when appropriate. But stop to think and understand. - - All labs where prepared using **Vim**, but we understand not everybody loves it. Feel free to use alternative editors, in the lab environment we provide **Midnight Commander** (just run **mc**, function keys can be reached via Esc-\ or simply clicked with the mouse) or **Nano** (run **nano**). Here is a short [editor intro](../0.0-support-docs/editor_intro.md). + - All labs were prepared using **Vim**, but we understand not everybody loves it. Feel free to use alternative editors. In the lab environment we provide **Midnight Commander** (just run **mc**, function keys can be reached via Esc-\ or simply clicked with the mouse) or **Nano** (run **nano**). Here is a short [editor intro](../0.0-support-docs/editor_intro.md). > **Tip** > diff --git a/exercises/ansible_rhel/1.2-adhoc/README.ja.md b/exercises/ansible_rhel/1.2-adhoc/README.ja.md index 4aaa15af3..5b32a46bf 100644 --- a/exercises/ansible_rhel/1.2-adhoc/README.ja.md +++ b/exercises/ansible_rhel/1.2-adhoc/README.ja.md @@ -275,11 +275,11 @@ node1 | CHANGED => { node1 | CHANGED | rc=0 >> Managed by Ansible ``` -`ansible node1 -m copy …​`コマンドを再実行してみてください。以下の点に着目してみてください: +`ansible node1 -m copy …?`コマンドを再実行してみてください。以下の点に着目してみてください: - 出力結果は、異なる色だったはずです。(適切な端末の設定がされている場合) - `"changed": true,` から `"changed": false,`へ変更されたはずです。 - - 最初の行が、`SUCCESS` から `CHANGED`に変わったはずです。 + - 最初の行が、`CHANGED` から `SUCCESS`に変わったはずです。 > **Tip** > @@ -311,4 +311,4 @@ Managed by Ansible ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/1.2-adhoc/README.md b/exercises/ansible_rhel/1.2-adhoc/README.md index 7e4c7001d..8f32151a9 100644 --- a/exercises/ansible_rhel/1.2-adhoc/README.md +++ b/exercises/ansible_rhel/1.2-adhoc/README.md @@ -23,7 +23,7 @@ node3 ansible_host= ansible ansible_host=44.55.66.77 ``` -Ansible is already configured to use the inventory specific to your use case. We will show you in the next step how that is done. For now, we will execute some simple commands to work with the inventory. +Ansible is already configured to use the inventory specific to your environment. We will show you in the next step how that is done. For now, we will execute some simple commands to work with the inventory. To reference inventory hosts, you supply a host pattern to the ansible command. Ansible has a `--list-hosts` option which can be useful for clarifying which managed hosts are referenced by the host pattern in an ansible command. @@ -44,7 +44,7 @@ An inventory file can contain a lot more information, it can organize your hosts [studentansible ~]$ ansible all --list-hosts ``` -AS you see it is ok to put systems in more than one group, for instance a server could be both a web server and a database server. Note that in Ansible the groups are not necessarily hierarchical. +As you see it is OK to put systems in more than one group. For instance, a server could be both a web server and a database server. Note that in Ansible the groups are not necessarily hierarchical. > **Tip** > @@ -56,7 +56,7 @@ The behavior of Ansible can be customized by modifying settings in Ansible’s i > **Tip** > -> The recommended practice is to create an `ansible.cfg` file in the directory from which you run Ansible commands. This directory would also contain any files used by your Ansible project, such as the inventory and Playbooks. Another practice is to create a file `.ansible.cfg` in your home directory. +> The recommended practice is to create an `ansible.cfg` file in the directory from which you run Ansible commands. This directory would also contain any files used by your Ansible project, such as the inventory and playbooks. Another recommended practice is to create a file `.ansible.cfg` in your home directory. In the lab environment provided to you an `.ansible.cfg` file has already been created and filled with the necessary details in the home directory of your `student` user on the control node: @@ -81,7 +81,7 @@ inventory = /home/student/lab_inventory/hosts There are multiple configuration flags provided. Most of them are not of interest here, but make sure to note the last line: there the location of the inventory is provided. That is the way Ansible knew in the previous commands what machines to connect to. -Output the content of your dedicated inventory to proof-read +Output the content of your dedicated inventory: ```bash [student@ansible ~]$ cat /home/student/lab_inventory/hosts @@ -101,7 +101,7 @@ ansible ansible_host=44.55.66.77 > **Tip** > -> Note that each student has an individual lab environment. The ip addresses shown above are only an example, the ip addresses of your individual environment are different. As with the other cases, replace **\** with your actual student number. +> Note that each student has an individual lab environment. The IP addresses shown above are only an example and the IP addresses of your individual environments are different. As with the other cases, replace **\** with your actual student number. ## Step 2.3 - Ping a host @@ -109,7 +109,7 @@ ansible ansible_host=44.55.66.77 > > **Don’t forget to run the commands from the home directory of your student user, `/home/student`. That is where your `.ansible.cfg` file is located, without it Ansible will not know what which inventory to use.** -Let's start with something really basic - pinging a host. To do that we use the Ansible `ping` module. The `ping` module makes sure our web hosts are responsive. Basically, it connects to the managed host, executes a small script there and collects the results. That way it is ensured that the managed host is reachable and that Ansible is able to execute commands properly on it. +Let's start with something really basic - pinging a host. To do that we use the Ansible `ping` module. The `ping` module makes sure our target hosts are responsive. Basically, it connects to the managed host, executes a small script there and collects the results. This ensures that the managed host is reachable and that Ansible is able to execute commands properly on it. > **Tip** > @@ -161,14 +161,14 @@ Get help for a specific module including usage examples: ## Step 2.5 - Use the command module: -Now let's see how we can run a good ol' fashioned Linux command and format the output using the `command` module. It just executes a command on a managed host: +Now let's see how we can run a good ol' fashioned Linux command and format the output using the `command` module. It simply executes the specified command on a managed host: ```bash [student@ansible ~]$ ansible node1 -m command -a "id" node1 | CHANGED | rc=0 >> uid=1001(student1) gid=1001(student1) Gruppen=1001(student1) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ``` -In this case the module is called `command` and the option passed with `-a` is the actual command to run. Try to run this ad hoc command on both hosts using the `all` host pattern. +In this case the module is called `command` and the option passed with `-a` is the actual command to run. Try to run this ad hoc command on all managed hosts using the `all` host pattern. Another example: Have a quick look at the kernel versions your hosts are running: @@ -190,11 +190,7 @@ Sometimes it’s desirable to have the output for a host on one line: Using the `copy` module, execute an ad hoc command on `node1` to change the contents of the `/etc/motd` file. **The content is handed to the module through an option in this case**. -Run: - -> **Warning** -> -> **Expect an error\!** +Run the following, but **expect an error**: ```bash [student@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd' @@ -213,7 +209,7 @@ As mentioned this produces an **error**: The output of the ad hoc command is screaming **FAILED** in red at you. Why? Because user **student\** is not allowed to write the motd file. -Now this is a case for privilege escalation and the reason `sudo` has to be setup properly. We need to instruct ansible to use `sudo` to run the command as root by using the parameter `-b` (think "become"). +Now this is a case for privilege escalation and the reason `sudo` has to be setup properly. We need to instruct Ansible to use `sudo` to run the command as root by using the parameter `-b` (think "become"). > **Tip** > diff --git a/exercises/ansible_rhel/1.3-playbook/README.ja.md b/exercises/ansible_rhel/1.3-playbook/README.ja.md index 77556b3d2..1db988029 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.ja.md +++ b/exercises/ansible_rhel/1.3-playbook/README.ja.md @@ -1,4 +1,4 @@ -# Exercise 1.3 - 初めてのplaybookを書いてみよう +# Exercise 1.3 - 初めての Playbook 作成 **Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). @@ -201,7 +201,7 @@ Playbookの次のパートでは、確かにApache Webserverが`node1`上で有 出力された結果をみてみてください。 いくつかのタスクは緑色で"OK"と記載され、1つだけ黄色で"changed"と表示されているはずです。 - - もう一度、AnsibleのAd-Hocコマンドw用いてApacheが有効になっておりかつ起動していることを確認します。例えば、`systemctl status httpd`などを実行しましょう。 + - もう一度、AnsibleのAd-Hocコマンドを用いてApacheが有効になっておりかつ起動していることを確認します。例えば、`systemctl status httpd`などを実行しましょう。 - Playbookをもう一度実行して、出力結果が変わる様に慣れてみましょう。 @@ -325,4 +325,4 @@ Playbookを実行してみましょう: ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engine-exercises) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/1.3-playbook/README.md b/exercises/ansible_rhel/1.3-playbook/README.md index cb5e2121f..c4f182aaa 100644 --- a/exercises/ansible_rhel/1.3-playbook/README.md +++ b/exercises/ansible_rhel/1.3-playbook/README.md @@ -64,7 +64,7 @@ On your control host **ansible**, create a directory called `ansible-files` in y [student@ansible ~]$ cd ansible-files/ ``` -Add a file called `apache.yml` with the following content. As in the previous chapters, use `vi` or `vim` for that. If you are new to editors on the command line, check out the [editor intro](../0.0-support-docs/editor_intro.md) again. +Add a file called `apache.yml` with the following content. As discussed in the previous exercises, use `vi`/`vim` or, if you are new to editors on the command line, check out the [editor intro](../0.0-support-docs/editor_intro.md) again. ```yaml --- @@ -106,14 +106,19 @@ In the added lines: - We started the tasks part with the keyword `tasks:`. - - A task is named and the a module for the task is referenced. Here it uses the module "yum". + - A task is named and the module for the task is referenced. Here it uses the `yum` module. - - Parameters for the module are added: `name:` to identify the package name, and `state:` to define the wanted state of the package. + - Parameters for the module are added: + + - `name:` to identify the package name + - `state:` to define the wanted state of the package > **Tip** > > The module parameters are individual to each module. If in doubt, look them up again with `ansible-doc`. +Save your playbook and exit your editor. + ## Step 3.3 - Running the Playbook Playbooks are executed using the `ansible-playbook` command on the control node. Before you run a new Playbook it’s a good idea to check for syntax errors: @@ -127,7 +132,7 @@ Now you should be ready to run your Playbook: ```bash [student@ansible ansible-files]$ ansible-playbook apache.yml ``` -The output should not report any errors but provide an overview of the tasks executed and a play recap summarizing what has been done. There is also a task called "Gathering Facts" listed there: this is an in-built task run automatically at the beginning of each play. It collects information about the managed nodes, a later chapter will discuss this. +The output should not report any errors but provide an overview of the tasks executed and a play recap summarizing what has been done. There is also a task called "Gathering Facts" listed there: this is an built-in task that runs automatically at the beginning of each play. It collects information about the managed nodes. Exercises later on will cover this in more detail. Use SSH to make sure Apache has been installed on `node1`. The necessary IP address is provided in the inventory. Grep for the IP address there and use it to SSH to the node. diff --git a/exercises/ansible_rhel/1.4-variables/README.ja.md b/exercises/ansible_rhel/1.4-variables/README.ja.md index 98909ea61..939a8f5cd 100644 --- a/exercises/ansible_rhel/1.4-variables/README.ja.md +++ b/exercises/ansible_rhel/1.4-variables/README.ja.md @@ -1,7 +1,5 @@ # 演習1.4 - 変数を使ってみよう -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). - 前回までは Ansible Engine の基礎部分を学習してきました。この演習では Playbook をより柔軟かつパワフルに使用できる、より高度なスキルを学びます。 Ansible では task をよりシンプル、かつ再利用可能にできます。システムの設定にはユニークな設定が含まれる場合があり、 @@ -27,7 +25,7 @@ Playbook では、変数名を二重中括弧で囲むことで変数を表現 > **ヒント** -> +> > ホスト変数には優先順位があります。上記 Host 変数は、 Group 変数より優先されます。詳しくは製品マニュアルをご確認ください。 ## ステップ 1.4.1 - 変数ファイルの作成 @@ -61,7 +59,7 @@ stage: prod - `web` group のすべてのサーバーに対して、変数 `stage` に値 `dev` が定義されます。そして dev （開発）をデフォルト値として定義します。 - - `node2` に関しては、上記で定義された変数 stage = dev が、prod で上書きされます。本番環境として定義されます。 + - `node2` に関しては、上記で定義された変数 stage = dev が、prod で上書きされます。本番環境として定義されます。 ## ステップ 1.4.2 - index.html ファイルの作成 @@ -90,7 +88,7 @@ stage: prod `deploy_index_html.yml` という名前の Playbook を `~/ansible-files/` ディレクトリ内に作成します。 > **ヒント** -> +> > コピーするファイル名の中に指定された変数 "stage" がホストごとに取る値に注意してください。 @@ -118,7 +116,7 @@ stage: prod 各ホストには、変数 stage の値に従って異なるファイルがコピーされているはずです。デフォルトが dev で、node2 のみ、prod となっているはず。それぞれのweb server に curl コマンド（もしくはブラウザ）で接続して確認してみましょう。 ```bash -[student@ansible ansible-files]$ grep node /home/student/lightbulb/lessons/lab_inventory/student-instances.txt +[student@ansible ansible-files]$ grep node ~/lab_inventory/hosts node1 ansible_host=11.22.33.44 node2 ansible_host=22.33.44.55 node3 ansible_host=33.44.55.66 @@ -137,7 +135,7 @@ node3 ansible_host=33.44.55.66 ``` > **ヒント** -> +> > 鋭い人はちょっと思うかもしれません、”もっと柔軟にファイルの中身を変更出来たら・・・、と”。こちらについては次の章（template モジュール）で学びます！ ## ステップ 1.4.5 - Ansible ファクト @@ -166,10 +164,10 @@ Ansibleがデフォルトでどのような事実を収集しているのか、 - 管理対象ホストのディストリビューション（Red Hat）を表示してください。ただし、結果は一行で出力してください。 > **ヒント** -> +> > grep を使ってファクトの中から必要な情報を探してみます。次に、 filter を使ってこのファクトのみの情報を抽出してみましょう。一行での表示の方法は ansible コマンドの -h (help) を使って調べてみましょう！ - + > **答えは下記の通り\!** ```bash @@ -194,13 +192,13 @@ Ansibleがデフォルトでどのような事実を収集しているのか、 > **ヒント** -> +> > "debug" モジュールは変数や式を確認するのに有用です。 取得されたファクトがどのような形で表示されるか Playbook を実行してみてください。 ```bash -[student@ansible ansible-files]$ ansible-playbook facts.yml +[student@ansible ansible-files]$ ansible-playbook facts.yml PLAY [Output facts within a playbook] ****************************************** @@ -211,13 +209,13 @@ ok: [node1] ok: [ansible] TASK [Prints Ansible facts] **************************************************** -ok: [node1] => +ok: [node1] => msg: The default IPv4 address of node1 is 172.16.190.143 -ok: [node2] => +ok: [node2] => msg: The default IPv4 address of node2 is 172.16.30.170 -ok: [node3] => +ok: [node3] => msg: The default IPv4 address of node3 is 172.16.140.196 -ok: [ansible] => +ok: [ansible] => msg: The default IPv4 address of ansible is 172.16.2.10 PLAY RECAP ********************************************************************* @@ -229,4 +227,4 @@ node3 : ok=2 changed=0 unreachable=0 failed=0 ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/1.4-variables/README.md b/exercises/ansible_rhel/1.4-variables/README.md index 58f25dff1..1b6c503f2 100644 --- a/exercises/ansible_rhel/1.4-variables/README.md +++ b/exercises/ansible_rhel/1.4-variables/README.md @@ -3,7 +3,7 @@ **Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). Previous exercises showed you the basics of Ansible Engine. In the next few exercises, we are going -to teach some more advanced ansible skills that will add flexibility and power to your playbooks. +to teach some more advanced Ansible skills that will add flexibility and power to your playbooks. Ansible exists to make tasks simple and repeatable. We also know that not all systems are exactly alike and often require some slight change to the way an Ansible playbook is run. Enter variables. @@ -22,19 +22,19 @@ Variables and their values can be defined in various places: the inventory, addi The recommended practice to provide variables in the inventory is to define them in files located in two directories named `host_vars` and `group_vars`: - - To e.g. define variables for a group "servers", a YAML file named `group_vars/servers` with the variable definitions is created. + - To define variables for a group "servers", a YAML file named `group_vars/servers` with the variable definitions is created. - To define variables specifically for a host `node1`, the file `host_vars/node1` with the variable definitions is created. > **Tip** > -> Host variables take precedence over group variables (more about precedence can be found in the docs). +> Host variables take precedence over group variables (more about precedence can be found in the [docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)). ## Step 4.1 - Create Variable Files -For understanding and practice let’s do a lab. Following up on the theme "Let’s build a webserver. Or two. Or even more…​" you will change the `index.html` to show the development environment (dev/prod) a server is deployed in. +For understanding and practice let’s do a lab. Following up on the theme "Let’s build a webserver. Or two. Or even more…​", you will change the `index.html` to show the development environment (dev/prod) a server is deployed in. -On the ansible control host, as user ansible create the directories to hold the variable definitions in `~/ansible-files/`: +On the ansible control host, as the `student` user, create the directories to hold the variable definitions in `~/ansible-files/`: ```bash [student@ansible ansible-files]$ mkdir host_vars group_vars diff --git a/exercises/ansible_rhel/1.5-handlers/README.ja.md b/exercises/ansible_rhel/1.5-handlers/README.ja.md index d4b98e395..4974bb380 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.ja.md +++ b/exercises/ansible_rhel/1.5-handlers/README.ja.md @@ -1,6 +1,4 @@ -# 演習 1.5 - 条件分岐, ハンドラー、ループ実行 - -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). +# 演習 1.5 - 条件分岐, ハンドラー、ループを使う ## ステップ 1.5.1 - 条件分岐 @@ -26,8 +24,8 @@ Ansible は特定の条件が満たされたときにタスクを実行したり では早速やってみましょう。まず、デフォルトで指定されたインベントリファイル編集し、`ftpserver` グループに `node2` を入れます。 デフォルトのインベントリファイルは、 -`/home/student/lightbulb/lessons/lab_inventory/student-instances.txt` でしたね。♪ - +`~/lab_inventory/hosts` でしたね。♪ + 編集後は以下の様になります。node2 のIPアドレスはご自身ものを入力してください！ ```ini @@ -64,7 +62,7 @@ ansible ansible_host=44.55.66.77 ``` > **ヒント** -> +> > 作成完了したら playbook を実行してみてください。やり方は・・・、もう分かってますね (^^♪ 実行した結果を確認してみてください。 `ftpserver` グループに記載された node2 以外のホストはタスクがスキップされ、node2 のみタスクの実行が行われていることが確認できます。 @@ -93,13 +91,13 @@ changed: [node2] まずはコピー元として利用する httpd.conf を node1 から取得します。 > **ヒント** -> +> >このファイルは既に node1 node2 node3 に配置されています。 ```bash [student@ansible ansible-files]$ scp :/etc/httpd/conf/httpd.conf ~/ansible-files/. -student@'s password: +student@'s password: httpd.conf ``` @@ -140,9 +138,9 @@ Listen 8080 ``` - Playbookをもう一度実行してください。興味深い結果が得られます。 - + - httpd.conf が上書きコピーされた - + - ハンドラーが呼び出され、 Apache サービスをリスタートした Apacheはポート8080でリッスンしているはずです。試してみてください。 @@ -158,17 +156,17 @@ curl: (7) Failed connect to :80; Connection refused httpd.conf ファイルを再度 "80" に変更し、どうなるか試してみてください。 > **注意** -> +> > 演習1.7で、ポート8080を使います。この時点で 80ポートをリッスンするよう設定を戻しておいてください。 > **ヒント** -> +> > よく聞かれる質問として、notify セクションが実行されたらすぐにハンドラーが呼び出されるのか？ということがありますが、これは違います。今回の場合、notify 直下にハンドラーが定義されているのですぐの実行となりますが、notiry とハンドラーが離れていた場合は、あくまで上から順に実行され、ハンドラーの順番になったところで実行されます。 notify でハンドラー実行のフラグを立てておく感じです。 ## ステップ 1.5.3 - 単純な繰り返し（ループ実行） -ループを使用すると、同じタスクを繰り返し実行することができます。たとえば、複数のユーザーを作成したいとしましょう。Ansible ループを使用すると、単一のタスクでそれを実行できます。ループは、単なるリスト以外にも反復することができます。たとえば、対応するグループを持つユーザーのリストがある場合、ループはそれらに対しても反復することができます。 詳しくはマニュアルをご確認ください [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) +ループを使用すると、同じタスクを繰り返し実行することができます。たとえば、複数のユーザーを作成したいとしましょう。Ansible ループを使用すると、単一のタスクでそれを実行できます。ループは、単なるリスト以外にも反復することができます。たとえば、対応するグループを持つユーザーのリストがある場合、ループはそれらに対しても反復することができます。 詳しくはマニュアルをご確認ください [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) ループの機能を確認してみましょう。 node1 に3人の新しいユーザーを作成します。 `~/ansible-files` ディレクトリの中に、 `loop_users.yml` という名前の playbook を作成します。使用するのは `user` モジュールで、playbook の中身は以下の通りです。 @@ -240,7 +238,7 @@ httpd.conf ファイルを再度 "80" に変更し、どうなるか試してみ - 再度タスクが一覧表示されます。ただし、3つの変更が表示されます。その内容を含む各ループが表示されます。 -node1 内に `prod_user` がグループ `ftp` で作成されていることを確認します。 +node1 内に `dev_user` がグループ `ftp` で作成されていることを確認します。 ```bash [student@ansible ansible-files]$ ansible node1 -m command -a "id dev_user" @@ -250,4 +248,5 @@ uid=1002(dev_user) gid=1002(dev_user) Gruppen=1002(dev_user),50(ftp) ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) + diff --git a/exercises/ansible_rhel/1.5-handlers/README.md b/exercises/ansible_rhel/1.5-handlers/README.md index 90aab7dbd..cad38e1af 100644 --- a/exercises/ansible_rhel/1.5-handlers/README.md +++ b/exercises/ansible_rhel/1.5-handlers/README.md @@ -72,7 +72,7 @@ changed: [node2] ## Step 5.2 - Handlers -Sometimes when a task does make a change to the system, a further task may need to be run. For example, a change to a service’s configuration file may then require that the service be restarted so that the changed configuration takes effect. +Sometimes when a task does make a change to the system, an additional task or tasks may need to be run. For example, a change to a service’s configuration file may then require that the service be restarted so that the changed configuration takes effect. Here Ansible’s handlers come into play. Handlers can be seen as inactive tasks that only get triggered when explicitly invoked using the "notify" statement. Read more about them in the [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change) documentation. @@ -113,7 +113,7 @@ Next, create the Playbook `httpd_conf.yml`. Make sure that you are in the direct So what’s new here? - - The "notify" section calls the handler only when the copy task changed the file. That way the service is only restarted if needed - and not each time the playbook is run. + - The "notify" section calls the handler only when the copy task actually changes the file. That way the service is only restarted if needed - and not each time the playbook is run. - The "handlers" section defines a task that is only run on notification. @@ -146,7 +146,7 @@ Feel free to change the httpd.conf file again and run the Playbook. ## Step 5.3 - Simple Loops -Loops enable us to repeat the same task over and over again. For example, lets say you want to create multiple users. By using an Ansible loop, you can do that in a single task. Loops can also iterate over more than just lists: for example if you have a list of users with their coresponding group, loop can iterate over them as well. Find out more about loops in the [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) documentation. +Loops enable us to repeat the same task over and over again. For example, lets say you want to create multiple users. By using an Ansible loop, you can do that in a single task. Loops can also iterate over more than just basic lists. For example, if you have a list of users with their coresponding group, loop can iterate over them as well. Find out more about loops in the [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) documentation. To show the loops feature we will generate three new users on `node1`. For that, create the file `loop_users.yml` in `~/ansible-files` on your control node as your student user. We will use the `user` module to generate the user accounts. diff --git a/exercises/ansible_rhel/1.6-templates/README.ja.md b/exercises/ansible_rhel/1.6-templates/README.ja.md index 361b2312b..7c4a42a87 100644 --- a/exercises/ansible_rhel/1.6-templates/README.ja.md +++ b/exercises/ansible_rhel/1.6-templates/README.ja.md @@ -1,6 +1,4 @@ -# 演習 1.6 - テンプレート - -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). +# 演習 1.6 - テンプレートを使う Ansibleは、管理対象ホストにファイルをコピーする際、固定の内容ではなく変数に値を入力しながらコピーを行う様な事も可能です。例えば対象ホストユニークなホスト名などを含んだファイルのコピーを行うことが可能です。これを実現するのが Jinja2 テンプレートです。 Jinja2 は、Python で最も使用されているテンプレートエンジンの1つです。 () @@ -57,7 +55,7 @@ Ansibleが変数をシステムから収取したファクト情報で変数を - 「Ansible ファクト」の章で学んだコマンドを使用して、カーネルバージョンを含むファクトを見つけます。 > **ヒント** -> +> > モジュールは `setup` ですね？ `grep` 使って探してみましょう。 - 見つかったらその変数を表示するよう、テンプレートファイルに追記しましょう @@ -65,7 +63,7 @@ Ansibleが変数をシステムから収取したファクト情報で変数を - 再度 playbook を実行します - 再度 node1 にログインし、表示をチェックしてみてください - + > **答えは以下の通り** @@ -94,4 +92,5 @@ running kernel {{ ansible_kernel }}. ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) + diff --git a/exercises/ansible_rhel/1.6-templates/README.md b/exercises/ansible_rhel/1.6-templates/README.md index 1845bbfc7..fa4733b32 100644 --- a/exercises/ansible_rhel/1.6-templates/README.md +++ b/exercises/ansible_rhel/1.6-templates/README.md @@ -42,11 +42,11 @@ You have done this a couple of times by now: - Understand what the Playbook does. - - Execute the Playbook `motd-facts.yml` + - Execute the Playbook `motd-facts.yml`. - - Login to node1 via SSH and check the motto of the day message. + - Login to node1 via SSH and check the message of the day content. - - Log out of node1 + - Log out of node1. You should see how Ansible replaces the variables with the facts it discovered from the system. diff --git a/exercises/ansible_rhel/1.7-role/README.ja.md b/exercises/ansible_rhel/1.7-role/README.ja.md index 12192d0f1..36a942710 100644 --- a/exercises/ansible_rhel/1.7-role/README.ja.md +++ b/exercises/ansible_rhel/1.7-role/README.ja.md @@ -1,14 +1,12 @@ # 演習 1.7 - Roles: Playbook を再利用可能にする -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). - 今までのワークショップで学習してきた通り、Playbook を1つのファイルに書くことは可能です。しかしそのうち、作成した Playbook を再利用したいと考えるようになると思います。 これを実現するのが Ansible の Roles です。Role という形で Playbook をパーツとして分解し、構造化されたディレクトリに納めるのです。詳しくはこちらの [ベストプラクティス](http://docs.ansible.com/ansible/playbooks_best_practices.html) をご確認ください。 ## ステップ 1.7.1 - Ansible Roles 構造を理解する -Roles は基本的に、ディレクティブを自動化したものであり、実際には参照ファイルの検索パス処理に対するいくつかの機能を超えた追加の魔法的な手段は含まれていません。 +Roles は基本的に、includeディレクティブを自動化したものであり、実際には参照ファイルの検索パス処理に対するいくつかの機能を超えた追加の魔法的な手段は含まれていません。 Roles は定義されたディレクトリ構造に従い、最上位ディレクトリ名で区別されます。いくつかのサブディレクトリの中には `main.yml` という名前の YAML ファイルが含まれています。 `files` と `templates` のサブディレクトリには YAML ファイルによって参照されるオブジェクトを入れておくことができます。 @@ -22,7 +20,7 @@ apache/ ├── handlers │ └── main.yml ├── meta -│ └── main.yml +│ └── main.yml ├── README.md ├── tasks │ └── main.yml @@ -255,7 +253,7 @@ Listen 8080 msg: 'Web server has been configured.' ``` -`pre_tasks` と `post_tasks` というキーワードに注意してください。通常、 Roles のタスクはプレイブックのタスクの前に実行されます。この順番を制御するには、 `pre_tasks` が必要となります。逆に `post_tasks` は、すべての Roles が完了した後に実行されます。ここでは、実際の Roles が実行されたときにどういう順番で実行されたかを確認するため、これら2つのタスクをあえて入れています。 +`pre_tasks` と `post_tasks` というキーワードに注意してください。通常、 Roles のタスクはプレイブックのタスクの前に実行されます。この順番を制御するため、 `pre_tasks` を指定してRolesの前に実行されるタスクを定義できます。逆に `post_tasks` は、すべての Roles が完了した後に実行されます。ここでは、実際の Roles が実行されたときにどういう順番で実行されたかを確認するため、これら2つのタスクをあえて入れています。 Playbook を実行する準備が整いましたので、実行してみましょう！ @@ -279,4 +277,4 @@ simple vhost index ---- -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/1.7-role/README.md b/exercises/ansible_rhel/1.7-role/README.md index a36ee41e3..28ea0b553 100644 --- a/exercises/ansible_rhel/1.7-role/README.md +++ b/exercises/ansible_rhel/1.7-role/README.md @@ -4,13 +4,13 @@ While it is possible to write a playbook in one file as we've done throughout this workshop, eventually you’ll want to reuse files and start to organize things. -Ansible Roles is the way we do this. When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure. This is explained in more detail in the [best practice](http://docs.ansible.com/ansible/playbooks_best_practices.html) already mentioned in exercise 3. +Ansible Roles are the way we do this. When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure. This is explained in more detail in the [best practice](http://docs.ansible.com/ansible/playbooks_best_practices.html) already mentioned in exercise 3. ## Step 7.1 - Understanding the Ansible Role Structure -Roles are basically automation around *include* directives as described above, and really don’t contain much additional magic beyond some improvements to search path handling for referenced files. +Roles are basically automation built around *include* directives and really don’t contain much additional magic beyond some improvements to search path handling for referenced files. -Roles follow a defined directory structure, a role is named by the top level directory. Some of the subdirectories contain YAML files, named `main.yml`. The files and templates subdirectories can contain objects referenced by the YAML files. +Roles follow a defined directory structure; a role is named by the top level directory. Some of the subdirectories contain YAML files, named `main.yml`. The files and templates subdirectories can contain objects referenced by the YAML files. An example project structure could look like this, the name of the role would be "apache": @@ -34,7 +34,7 @@ apache/ └── main.yml ``` -The `main.yml` files contain content depending on the corresponding directory: `vars/main.yml` references variables, `handlers/main.yaml` describes handlers, and so on. Note that in contrast to playbooks, the `main.yml` files only contain the specific content and not additional playbook information like hosts, `become` or other keywords. +The various `main.yml` files contain content depending on their location in the directory structure shown above. For instance, `vars/main.yml` references variables, `handlers/main.yaml` describes handlers, and so on. Note that in contrast to playbooks, the `main.yml` files only contain the specific content and not additional playbook information like hosts, `become` or other keywords. > **Tip** > diff --git a/exercises/ansible_rhel/1.8-bonus/README.ja.md b/exercises/ansible_rhel/1.8-bonus/README.ja.md index 9fdc78df2..f2e20e1b0 100644 --- a/exercises/ansible_rhel/1.8-bonus/README.ja.md +++ b/exercises/ansible_rhel/1.8-bonus/README.ja.md @@ -1,13 +1,11 @@ # 演習 1.8 - ボーナスラボ -**Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md), ![japan](../../../images/japan.png) [日本語](README.ja.md). - あなたは既にラボを完了しています・・・、が、さらに先に進みたい方は是非このボーナスラボにチャレンジしてみてください。 ## ステップ 1.8.1 - ボーナスラボ: アドホックコマンド アドホックコマンドを使って、適当なコメント付きで新しいユーザー "testuser"　を `node1` と `node3` に作成します。`node2` に作成してはいけません。実行後、想定通り作成できていることも確認します。 - + - `ansible-doc user` を使ってモジュールのパラメータを確認します。 - アドホックコマンドを使ってコメント "Test D User" 付きのユーザーを作成します。 @@ -17,7 +15,7 @@ - ユーザーを削除し、それが削除されたことを確認します > **ヒント** -> +> > 権限昇格の記述を忘れないこと！ > **答えは以下の通り** @@ -40,7 +38,7 @@ `httpd.conf` のリッスンポートを都度 vi 等で編集してコピーするのではなく、変数としてテンプレートの中で定義し、その変数の値を変数ファイルを使って与える方法について考えてみます。 - + - `listen_port` に変数を埋め込んだ `httpd.conf` ファイルを作成し、 `httpd.conf.j2` テンプレートを使って各 node に送付します。 - `web` グループのリッスンポートとして "8080" 、 `node2` のリッスンポートとして `80` を取るように変数ファイルを作成します。 @@ -106,13 +104,13 @@ Playbook `apache_config_tpl.yml` を以下の内容で作成します。 name: httpd state: restarted ``` - + ### 実行し確認します まずは playbook を実行し、curl コマンドで、 `node1` と `node3` にポート `8080` そして `node2` にポート `80` で接続してみます。 ```bash -[student1@ansible ansible-files]$ ansible-playbook apache_config_tpl.yml +[student1@ansible ansible-files]$ ansible-playbook apache_config_tpl.yml [...] [student1@ansible ansible-files]$ curl http://18.195.235.231:8080 @@ -125,5 +123,4 @@ Playbook `apache_config_tpl.yml` を以下の内容で作成します。 ``` ---- - -[Ansible ワークショップ表紙に戻る](../README.ja.md) +[Ansible Engine ワークショップ表紙に戻る](../README.ja.md#section-1---ansible-engineの演習) diff --git a/exercises/ansible_rhel/2.1-intro/README.ja.md b/exercises/ansible_rhel/2.1-intro/README.ja.md new file mode 100644 index 000000000..364b3fb1b --- /dev/null +++ b/exercises/ansible_rhel/2.1-intro/README.ja.md @@ -0,0 +1,76 @@ +# 演習 2.1 - Tower の紹介 + +## Ansible Tower の価値 + +Ansible Towerは、IT自動化のためのエンタープライズソリューションを提供するWebベースのUIです。 + + - ユーザーフレンドリーなダッシュボード形式 + + - Ansibleを補完し、自動化、ビジュアル管理、および監視機能を追加します + + - 管理者にユーザーアクセス制御を提供します + + - 仮想化、クラウドなど様々な情報ソース内のグラフィカルなインベントリの管理と同期が可能です + + - RESTful API に対応しています + + - などなど... + +## Ansible Tower ラボ環境 + +この実習ラボでは、事前設定された実習ラボ環境で作業します。以下のホストにアクセスできます。 + +| Role | Inventory name | +| -----------------------------| ---------------| +| Ansible Control Host & Tower | ansible | +| Managed Host 1 | node1 | +| Managed Host 2 | node2 | +| Managed Host 2 | node3 | + +Ansible Tower はすでにインストールされ、ライセンスが付与されています。WebUI には HTTP / HTTPS 経由でアクセスできます。 + +## ダッシュボード + +Web UI を使用して Ansible Tower に `admin` 権限でログインすると、グラフと以下のような情報が表示されます。 + + - 最近実行したジョブ + + - 管理対象ホストの台数 + + - 問題のあるホストの台数とそのホストへのリンク + +ダッシュボードには、 Playbook で完了したタスクの実行に関するリアルタイムデータも表示されます。 + +![Ansible Tower ダッシュボード](images/dashboard-jp.png) + + +## Ansible Tower の概念 + +Ansible Tower を使い始めるには、いくつかの概念と Ansible Tower 独特のオブジェクト名に慣れておく必要があります。 + +**プロジェクト(Projects)** + +プロジェクトは Ansible Tower の Playbook の論理的な集まりです。これらの Playbook は Ansible Tower インスタンス上にあるか、または Tower がサポートするソースコードバージョン管理システム内にあります。 + +**インベントリー(Inventories)** + +インベントリーは、 Ansible Engine のインベントリーファイルと同じように、ジョブを実行する対象ノードの集まりです。インベントリーはグループに分けられ、これらのグループの中に実際のホストが含まれています。インベントリーホストの登録は、１台１台手動で登録することも可能ですし、 Ansible Tower がサポートするクラウドプロバイダや、インベントリースクリプトを使用して自動で登録することも可能です。 + +**認証情報(Credentials)** + +認証情報は、対象ノードに対してジョブを実行したり、インベントリーをダイナミックに同期したり、バージョン管理システムからプロジェクトコンテンツをインポートする時に使用されます。 + +認証情報は保存の際、 Tower によって暗号化されます。このため、登録された後はどのユーザーもコマンドラインでプレーンテキストで取得することはできません。このため、登録されたユーザーの資格情報を公開することなく、他のユーザーおよびチームに、これらの認証情報の使用権限を安全に付与することが可能です。 + + +**テンプレート(Templates)** + +テンプレートにはジョブテンプレートとワークフローテンプレートがあります。ジョブテンプレートは、 Playbook を実行するための定義とパラメータのセットです。ジョブテンプレートは、同じジョブを何度も実行する際に便利です。ジョブテンプレートは、Ansible プレイブックのコンテンツの再利用とチーム間のコラボレーションも促進します。ジョブを実行するには、 Tower では最初にジョブテンプレートを作成する必要があります。ワークフローテンプレートは、複数のジョブテンプレートやワークフローテンプレートをまとめて実行するための機能を提供します。 + +**ジョブ(Jobs)** + +ジョブは基本的に、実行されたジョブテンプレートやワークフローテンプレートのことを指します。 + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.1-intro/images/dashboard-jp.png b/exercises/ansible_rhel/2.1-intro/images/dashboard-jp.png new file mode 100644 index 000000000..de9f0d1d0 Binary files /dev/null and b/exercises/ansible_rhel/2.1-intro/images/dashboard-jp.png differ diff --git a/exercises/ansible_rhel/2.2-cred/README.ja.md b/exercises/ansible_rhel/2.2-cred/README.ja.md new file mode 100644 index 000000000..a615319fc --- /dev/null +++ b/exercises/ansible_rhel/2.2-cred/README.ja.md @@ -0,0 +1,196 @@ +# 演習 2.2 - インベントリー、認証情報、アドホックコマンド + +## インベントリーの作成 + +まず必要なのは、管理対象ホストの一覧です。これは Ansible Engine のインベントリーファイルに相当します。インベントリーにはダイナミックインベントリーなど、高度なものもありますが、まずは基本的なところから始めてみましょう。 + + - ブラウザで **https://student..rhdemo.io** に接続しログインします。 + に関しては環境ごとにユニークな値です。講師の指示に基づき入力してください。 + ユーザーは `admin` パスワードは講師より指示があります。 + +インベントリの作成は以下のように行います。 + + - 左側のWeb UIメニューで、**インベントリー** をクリックし、右端の ![plus](images/green_plus.png) ボタンをクリック。表示されるプルダウンの中から、インベントリーを選択します。 + + - **名前:** Workshop Inventory + + - **組織:** Default + + - **保存** をクリック + +ブラウザ下部に、利用可能なインベントリーが表示されていますので確認してみましょう。 Ansible Tower にあらかじめ作成されている **Demo Inventory** と、今作成した **Workshop Inventory** の2つが存在していることが分かります。ブラウザ上部に戻って、 **Workshop Inventory** の中にある **ホスト** ボタンをクリックすると、まだホストを 1 台も登録していないのでリストが空であることが分かります。 + +早速ホストを追加してみましょう。まず、登録するためのホスト一覧を取得する必要があります。このラボ環境では、Tower がインストールされている ansible Control Host & Tower 上のインベントリーファイルに利用可能なホスト一覧が記述されていますのでそちらを確認してみます。 + +Tower サーバーに SSH でログインします。 + +> **注意** +> +> student\ の \ の部分は、各自与えられた Student 番号を入力ください。また、11.22.33.44の部分は、各自与えられた、ansible Control Hot & Tower の IP アドレスを入力ください。 + +```bash +ssh student@11.22.33.44 +``` + +インベントリーファイルの場所は、Tower ホスト上の、 `~/lab_inventory/hosts` です。 cat で確認してみましょう。 + +```bash +$ cat ~/lab_inventory/hosts +[all:vars] +ansible_user=student +ansible_ssh_pass=ansible +ansible_port=22 + +[web] +node1 ansible_host=22.33.44.55 +node2 ansible_host=33.44.55.66 +node3 ansible_host=44.55.66.77 + +[control] +ansible ansible_host=11.22.33.44 +``` +> **注意** +> +> 表示される IP アドレスは各自固有のものになっていますので、上記とは異なります。 + +node1、node2 などのホストの名前と IP addresses を控えておいてください。これらの情報を以下の手順で Tower のインベントリーに登録していきます。 + + - Tower のインベントリービューで **Workshop Inventory** をクリックします + + - **ホスト** をクリックします + + - ![plus](images/green_plus.png) ボタンをクリックします + + - **ホスト名** `node1` + + - **変数** 3つのハイフン `---` の下（2行目）に、 `ansible_host: 22.33.44.55` を入力します。 IP アドレス、`22.33.44.55` については、先ほど `node1` について確認した IP アドレスに置き換えてください。記述方法についても注意してください。コロン **:** と IP アドレスの間にはスペースが必要です。また、インベントリーファイルで利用するような **=** で記述してはいけません。 + + - **保存** をクリックします + + - **ホスト** に戻って `node2` と `node3` を上記と同様の手順で追加します。 + +これで Tower で管理する 3 台のホストに対するインベントリーファイルの作成が完了です? + +## マシンの認証情報 + +Ansible Tower は、ホストやクラウド等の認証情報をユーザーに開示せずに利用可能にするという優れた機能を持っています。 Tower がインベントリー登録したリモートホスト上でジョブを実行できるようにするには、リモートホストの認証情報を設定する必要があります。 + +> **メモ** +> +> これは Tower が持っている重要な機能の一つ **認証情報の分離の機能です**\! 認証情報はホストやインベントリーの設定とは別で強固に管理することが可能です。 + +Tower の重要な機能なので、まずはコマンドラインでラボ環境について確認してみましょう。 + +SSH 経由で Tower ホストにログインします。 + + - `ssh student@11.22.33.44` いつものように、\ の部分と、Tower ホストのIPアドレスは各自のものに置き換えてください。 + + - `node1` に SSH 接続し、 `sudo -i` を実行してみます。 SSH 接続の際はパスワード入力が要求されますが、 `sudo -i` に関してはパスワードは要求されません。 + +```bash +[student@ansible ~]$ ssh student@22.33.44.55 +student@22.33.44.55's password: +Last login: Thu Jul 4 14:47:04 2019 from 11.22.33.44 +[student@node1 ~]$ sudo -i +[root@node1 ~]# +``` + +これはどういう意味でしょう？ + + - **student** は、インベントリーで指定した管理対象ホストにパスワードベースの SSH で接続可能 + + - **student** は、 `sudo` による権限昇格で、**root** としてコマンド実行が可能 + +## マシン認証情報の作成 + +では早速 Tower で認証情報を作成してみましょう。 Tower　左側のメニューから **認証情報** をクリックします。 + + ![plus](images/green_plus.png) ボタンをクリックします。 + + - **名前:** Workshop Credentials + + - **組織:** Default + + - **認証情報タイプ:** 虫眼鏡をクリックして **マシン** を選択し、**選択** をクリックします + + - **ユーザー名:** student\ - いつもの通り、 **\** は各自に割り当てられた番号を入力ください + + - **パスワード:** ansible + + - **保存** をクリックします + + - パスワード部分が暗号化され表示されないことを確認します + +> **ヒント** +> +> Tower では、入力フィールドの横に虫眼鏡アイコンが表示されているときにはクリックすると選択リストが開きます。 + +これで、後でインベントリーホストに使用する資格情報を設定できました。 + +## アドホックコマンドの実行 + +Ansible Engine で実行したアドホックコマンドを Tower でも実行してみましょう。 + + - 左の選択メニューから、**インベントリー** → **Workshop Inventory** + + - **ホスト** ボタンをクリックし、登録したホスト一覧を表示し、`オン` の左にあるチェックボックスを全てのホストでチェックします + + - **コマンドの実行** をクリックします。さらに次の画面でアドホックコマンドを下記の通り指定していきます。 + + - **モジュール** 欄で **ping** を選択 + + - **マシンの認証情報** 欄で **Workshop Credentials** を選択 + + - **起動** をクリックし、出力を確認します + +シンプルな **ping** モジュールにはオプションは必要ありません。しかしながら、他のモジュールの場合、実行には引数が必要な場合があります。次にこのケースを確認してみましょう。先ほどと同様の手順で、今度は **command** モジュールを使って実行中のユーザーのユーザー ID を確認してみます。 + +- **モジュール:** command + +- **引数:** id + +マシンの認証情報も入力して実行の上表示内容を確認します。 + +> **ヒント** +> +> 「引数」の横にある疑問符をクリックすると、モジュールのドキュメントページへのリンクが表示されます。とっても便利ですね。♪ + +次に、/etc/shadow のファイルの中身を確認するコマンドを発行してみましょう + +- **モジュール:** command + +- **引数:** cat /etc/shadow + +> **注意** +> +> **エラーが発生ます** + +失敗します、何故でしょう？ + +理由は、そう、権限昇格が必要なのです。もう一度戻って、 **権限昇格の有効化** にチェックを入れて実行してみてください。 + +今回はうまくいきました。 root 権限で実行する必要があるタスクの場合、権限昇格を有効化する必要があります。これは、 Playbook の記述でもよく見かける　**become: yes** と同じです。 + +## チャレンジラボ: アドホックコマンド + +アドホックコマンドを使って、node1, node2 node3 にパッケージ「tmux」をインストールしてください。 + +> **ヒント** +> +> **yum** モジュールを利用します。使い方は `[ansible@tower ~]$ ansible-doc yum` などで確認してみてください。 + +> **回答** + + - **モジュール:** yum + + - **引数:** name=tmux + + - **権限昇格の有効化:** チェックします + +> **ヒント** +> +> コマンドの黄色の出力は、Ansibleが実際に何かを実行したことを示しています（ここでは、パッケージがインストールされてなかったのでインストールを実行しました）。アドホックコマンドを再度実行すると、出力が緑色になり、パッケージが既にインストールされていることが通知されます。Ansible の黄色は「注意」を意味するわけではありません…;-)。ご注意を…? ;-). + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.3-projects/README.ja.md b/exercises/ansible_rhel/2.3-projects/README.ja.md new file mode 100644 index 000000000..74e6d55e1 --- /dev/null +++ b/exercises/ansible_rhel/2.3-projects/README.ja.md @@ -0,0 +1,188 @@ +# 演習 2.3 - プロジェクトとジョブテンプレート + +Tower の **プロジェクト** は、 Git、Subversion、Mercurial、ローカルホルダなど、Playbook の置き場所を定義する仕組みを提供します。 Tower ではサポートとされるソースコード管理（SCM）と連携して Playbook を管理することが可能です。 + +Playbook は SCM など、バージョン管理の仕組みの下に置いておくべきです。このラボでは、 Git リポジトリに保存されている Playbook を利用します。 + +## Git リポジトリのセットアップ +このデモでは、既に Git リポジトリに保存されているプレイブックを使用します。 + +**https://github.com/ansible/workshop-examples** + +このラボで利用する Apache Web Server をインストールするための Playbook は、上記 github サイトの **rhel/apache** に置いてある、`apache_install.yml` です。内容は以下の通りです。 + +```yaml +--- +- name: Apache server installed + hosts: all + + tasks: + - name: latest Apache version installed + yum: + name: httpd + state: latest + + - name: latest firewalld version installed + yum: + name: firewalld + state: latest + + - name: firewalld enabled and running + service: + name: firewalld + enabled: true + state: started + + - name: firewalld permits http service + firewalld: + service: http + permanent: true + state: enabled + immediate: yes + + - name: Apache enabled and running + service: + name: httpd + enabled: true + state: started +``` + +> **ヒント** +> +> Engine の演習で書いた Playbook と比較するとちょっと違っているところがあります。重要なところは、 `become` が無いところと、 `hosts` の設定に `all` を指定しているところです。 + +このリポジトリを Tower の **Source Control Management (SCM)** として利用するには **プロジェクト** を作成する必要があります。 + +## プロジェクトの作成 + + - 左のメニューから **プロジェクト** を選択し、 ![plus](images/green_plus.png) ボタンをクリック。フォームに以下を入力します。 + + - **名前:** Ansible Workshop Examples + + - **組織:** Default + + - **SCM タイプ:** Git + +ここで、リポジトリにアクセスするためのURLが必要です。上記の Github リポジトリに移動し、右側の緑色の **Clone or download** ボタンをクリック。さらに、 **Clone with HTTPS** が選択されていることを確認し、URL をコピーします。 + +SCM URL にコピーした URL を貼り付けます。 + +- **SCM URL:** `https://github.com/ansible/workshop-examples.git` + +- **SCM 更新オプション** 3つのボックスすべてにチェックマークを付けて、常にリポジトリの最新コピーを取得し、ジョブの起動時にリポジトリを更新する設定とします。 + +- **保存** をクリックします + +新しいプロジェクトは、作成後に自動的に同期されます。ただし、これを手動で行うこともできます。 **Projects** ビューに移動し、プロジェクトの右側にある円形矢印 **最新のSCMリビジョンを取得** アイコンをクリックすると、プロジェクトを Git リポジトリと再度同期します。 + +## ジョブテンプレートを作成してジョブを実行する + +ジョブテンプレートは、Ansible ジョブを実行するための定義とパラメーターのセットです。ジョブテンプレートは、同じジョブを何度も実行するのに役立ちます。ジョブテンプレートではいくつかのパラメータを指定します。それぞれの意味は下記の通りです。 + +- **インベントリー:** ジョブを実行するホストを指定します + +- **認証情報:** 管理対象ホストにログインするためのアカウント情報です + +- **プロジェクト:** Playbook の場所を指定します + +- **Playbook の指定** + +早速 **ジョブテンプレート** を作成してみましょう。♪ + +左のメニューから **テンプレート** を選択し、 ![plus](images/green_plus.png) ボタンをクリック。選択肢の中から **ジョブテンプレート** を選びます。 + +> **ヒント** +> +> 下記フィールドの多くは、虫眼鏡アイコンをクリックの上オプション選択で設定が可能です。 + +- **名前:** Apache Install + +- **ジョブタイプ:** 実行 + +- **インベントリー:** Workshop Inventory + +- **プロジェクト:** Ansible Workshop Examples + +- **PLAYBOOK:** `rhel/apache/apache_install.yml` + +- **認証情報:** Workshop Credentials + +- オプションで **権限昇格の有効化** にチェックを入れます + +- **保存** をクリックします + +青い **起動** ボタンを直接クリックするか、テンプレートのビューでロケットアイコンをクリックしてジョブを開始します。ジョブテンプレートを起動すると、自動的にジョブの概要が表示され、Playbook の実行をリアルタイムで追跡できます。 + + +![job exection](images/job_overview.png) + + +完了するまで少し時間がかかりますので、何を行っているか確認してみてください。 + +- インベントリ、プロジェクト、認証情報のチェック、Playbook などのジョブテンプレートの詳細が表示されます + +- さらに、Playbook で変更された部分が記録されています + +- また、開始時刻と終了時刻を含む実行時間も記録されるため、ジョブの実行が実際にどれくらいかかったかがわかります + +- 右側に、プレイブック実行の出力が表示されます。タスクの下のノードをクリックして、各ノードの各タスクの詳細情報が提供されていることを確認します + +ジョブが完了したら、左のメニューからジョブをクリックします。すべてのジョブがここに一覧表示されます。Playbook を実行する前に、SCM 更新が開始されるのが分かります。これは、プロジェクト作成時に、 `起動時のリビジョン更新` にチェックを入れましたね？その Git 情報の更新です！ + +## チャレンジラボ: 結果の確認 + +以下に挑戦してみましょう！ + + - アドホックコマンドを使用して、対象ホストに Apache がインストールされ、実行されていることを確認します。 + +確認する方法は以前のラボで学んでいると思いますので、考えてやってみてください。 + +> **ヒント** +> +> `systemctl status httpd` を使う！？ + +> **回答** + +- **インベントリー** → **Workshop Inventory** + +- **ホスト** をクリックし、対象ホストをチェックにより選択。さらに、 **コマンドの実行** をクリックします。 + +- **モジュール:** command + +- **引数:** systemctl status httpd + +- **マシン認証情報:** Workshop Credentials + +- **起動** をクリック + +## 次のラボの準備も含め少し作業します + +以下を実施ください。 + +> **注意** +> +> 次の章がそれに依存するので、これらの手順を必ず完了してください！ + +- `Webserver` という名前のインベントリーを作成し、node1 のみ登録します + +- **テンプレート** をクリックし、 `Install Apache` テンプレートをコピーアイコンを使ってコピーします + +- コピーしたジョブテンプレートを開き `Install Apache Ask` に名前を変更します + +- さらに **インベントリー** で、 `起動プロンプト` にチェックを入れます + +- **保存**します + +- `Install Apache Ask` テンプレートを起動します + +- 使用するインベントリーについて聞かれるので `Webserver` を選択し **次へ** をクリックし、**起動**をクリックします + +- ジョブが終了するのを待ち、 `node1` でしか実行されていないことを確認します。 + +> **ヒント** +> +> Apache は既に最新バージョンでインストールされているため、ジョブは何も変更していないことが分かります。 + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.4-surveys/README.ja.md b/exercises/ansible_rhel/2.4-surveys/README.ja.md new file mode 100644 index 000000000..dac55b391 --- /dev/null +++ b/exercises/ansible_rhel/2.4-surveys/README.ja.md @@ -0,0 +1,137 @@ +# 演習 2.4 - Survey 機能 + +テンプレート構成ビューの **SURVEYの追加** ボタンに気付いたかもしれません。Survey は、**テンプレート**が**ジョブ**として起動した時に利用する変数の値を入力する簡単なフォームです。 + +先ほどの演習で、全てのホストに Apache をインストールしました。次にこれを拡張します。 + +- Jinja2テンプレートを持つ適切なロールを使用して、`index.html` ファイルをデプロイします + +- Survey を含むジョブテンプレートを作成し、 `index.html` テンプレート用の情報を収集します + +- ジョブテンプレートを起動します + +さらに、このロールでは、他の演習で失敗していることも想定し、Apache 構成が適切にセットアップされていることも確認します。 + +> **ヒント** +> +> Survey は入力するデータの単純なクエリのみを提供します。動的なデータに基づくクエリやネストされたメニューには対応していません。 + +## プロジェクトを作成する + +Playbook と Jinja2 テンプレートを持つ Roles は Github リポジトリ + +**https://github.com/ansible/workshop-examples** の `rhel/apache` にあります。 + +Github UIに移動して、 `apache_role_install.yml` の中身を見てみてください。単に Role を参照しているだけです。 Role は `roles/role_apache` サブディレクトリに存在します。Role 内の jinja2 テンプレート `templates/index.html.j2` 内に定義された二つの変数を確認します。変数は `{{…?}}` で定義されるんでしたね。また、メインのタスクを担う、 `tasks/main.yml` の中で、template からファイルをコピーするタスクをチェックします。この Playbook は何をやっているのでしょう、分かりますか？ テンプレート (**src**) から、対象ホスト上にファイル (**dest**) としてコピーしています。この際、コピー先のファイルには変数に値が入力されます。値を入力するのは、そう、 Survey インターフェースです。 + +Role は、Apache の設定内容もデプロイします。前の章で行われた全ての変更が上書きされ、今回の演習が問題なく実行できることを保証するためのものです。 + +## Survey を作成 + +Survey を含むジョブテンプレートを作成します。 + +### テンプレートの作成 + +- 左のメニューで**テンプレート**を選択し、![plus](images/green_plus.png) ボタンをクリック。 **ジョブテンプレート**を選択します。 + +- **名前** Create index.html + +- テンプレートを次のように構成してください！ + + - 既存の**プロジェクト** の中から今回の件に適応するものを選択。さらに適切な **Playbook**を選びます。 + + - `node1` のみで実行されるようにインベントリーを定義します + + - 権限昇格を行います + +設定方法は分かりますか？答えは以下の通りです。ここまで演習を積まれた皆さんならそんなに難しくないと思います。♪ + +> **回答** + +- **名前:** Create index.html + +- **ジョブタイプ:** 実行 + +- **インベントリー:** Webserver + +- **プロジェクト:** Ansible Workshop Examples + +- **PLAYBOOK:** `rhel/apache/apache_role_install.yml` + +- **認証情報:** Workshop Credentials + +- **オプション:** 権限昇格の有効化 + +- **保存**をクリック + +> **注意** +> +> **まだジョブテンプレートを実行しないでください！！　そう、まだ変数の値が定義されてません！！** + +### Survey を追加する + +- ジョブテンプレートの中で、**SURVEY の追加** ボタンをクリックします + +- **Survey プロンプトの追加** フォームで以下を入力します + + - **プロンプト:** First Line + + - **回答の変数名:** `first_line` + + - **回答タイプ:** テキスト + +- **+ADD**をクリックします。 + +- 同じように2つ目の変数入力フォームを定義します + + - **プロンプト:** Second Line + + - **回答の変数名:** `second_line` + + - **回答タイプ:** テキスト + +- **+ADD**をクリックします + +- **保存** をクリックし、 Survey を保存します + +- **保存** をクリックし、ジョブテンプレートを保存します + +## テンプレートを起動します + +作成したジョブテンプレート **Create index.html** を起動してみます。 + +実際の起動の際に、Survey は 2つの変数について入力を要求します。お好きなテキストを入力して、「次へ」をクリックします。次のウィンドウに入力した値が表示されます。問題なければ、「起動」をクリックしてジョブを実行します。 + +> **ヒント** +> +> 入力した 2つの値がジョブ実行画面の左下の **追加変数**に表示されていることを確認します。 + +ジョブが完了したら、Apache ホームページを確認してください。確認するのは、そう、`node1` です。 Tower Server の SSH コンソールの curl コマンドで確認したもよいですし、ブラウザで直接 node1 に接続してみてもOKです。 + +```bash +$ curl http:// + +

Apache is running fine

+

This is survey field "First Line": line one

+

This is survey field "Second Line": line two

+ +``` +この index.html ファイルが Playbook と Survey によってどのように作成されたのか、よく理解しておて下さい。 + +## さらに次のタスクを実行ください + +タスクのリストは次のとおりです。 + +> **注意** +> +> **次の章で利用しますので、以下の手順は必ず完了してください！** + +- インベントリー `Webserver` に、 `node2` と `node3` を追加します + +- ジョブテンプレート `Create index.html` を再度実行します。 + +- Curl コマンドもしくはブラウザで `node2`, `node3` にアクセスし、結果を確認します。 + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.5-rbac/README.ja.md b/exercises/ansible_rhel/2.5-rbac/README.ja.md new file mode 100644 index 000000000..fba56b583 --- /dev/null +++ b/exercises/ansible_rhel/2.5-rbac/README.ja.md @@ -0,0 +1,109 @@ +# 演習 2.5 - ロールベースのアクセス制御 + +Ansible Tower の優れた機能として、認証情報を Tower 内部で適切に管理する方法を学びました。Ansible Tower のもう1つの利点は、ユーザーとグループの権限管理です。 + +## Ansible Tower ユーザー + +Ansible Tower のユーザーには以下の3つのタイプがあります + +- **Normal User** インベントリやプロジェクトなどのオブジェクトに対する読み込み、書き込み権限は、そのユーザーに与えらたロールや権限に限定される + +- **System Auditor** Ansible Tower 環境内のすべてのオブジェクトの読み取り専用権限を有します + +- **System Administrator** Ansible Tower 環境内のすべてのオブジェクトに対して読み取り、書き込みの権限があります + +早速ユーザーを作成しましょう + +- 左のメニュー一覧から **ユーザー**をクリックします + +- 緑色のプラスボタンをクリックします + +- 新しいユーザーに関する情報を入力します + + - **名** Werner + + - **姓** Web + + - **メール** wweb@example.com + + - **ユーザー名** wweb + + - **ユーザータイプ** Normal User + + - **パスワード** ansible + +- **保存**をクリック + +## Ansible Tower チーム + +チームは、ユーザー、プロジェクト、資格情報、および権限が関連付けられた組織の下位に当たる区分けです。チームは、ロールベースのアクセス制御スキームを実装し、組織全体に責任を委任する手段を提供します。たとえば、チームの各ユーザーではなく、チーム全体に権限が付与される場合があります。 + +チームを作成します + +- 左のメニューで**チーム**をクリック + +- 緑色のプラスボタンをクリックして、 `Web Content` という名前のチームを作成します + +- **保存**をクリックします + +これでユーザーをチームに登録することができます。 + +- チーム `Web Content` 内の **ユーザー** ボタンをクリックします + +- 緑色のプラスボタンをクリックし、wweb ユーザーの横にあるチェックボックスをオンにして、**保存**をクリックします。 + +今度は、**パーミッション** ボタンをクリックしてみてください。 "パーミッションが付与されていません"と表示されていると思います。 + +権限を付与することにより、プロジェクト、インベントリ、およびその他の Ansible Tower 内のオブジェクトの読み取り、変更、および管理が可能になります。この権限は、Ansible Tower で管理するさまざまなリソースに設定できます。このあたりの柔軟性が Tower のもう一つの大きな特徴です。 + +## パーミッションの付与 + +ユーザーまたはチームが Ansible Tower 上で作業する場合、作業に対する適切なアクセス権限を持っている必要があります。新規に作成したユーザー wweb に対し、割り当てられた Web サーバーのコンテンツの変更（具体的には Create index.html ジョブテンプレートの実行権限）のみを許可してみましょう。 + +テンプレートを使用する権限を追加します。 + +- チーム `Web Content` 内で `パーミッション` を表示し、緑色のプラスボタンをクリックして権限を追加します。 + +- 新しいウィンドウが開きます。様々なオブジェクトに対してアクセス権限を設定できることが分かります。 + + - **ジョブテンプレート**を選択します + + - `Create index.html` テンプレートの横にあるチェックボックスをオンにしてテンプレートを選択します。 + +- ウィンドウの2番目の部分が開きます。ここで、選択したリソースにロールを割り当てます。 + + - **実行**を選択します + +- **保存**をクリックします + +## パーミッションのテスト + +Ansible Tower の Web UI からログアウトし、**wweb**ユーザーとして再度ログインします。 + +- **Templates** ビューに移動します。wweb の場合は、Create index.html テンプレートのみが表示されます。彼は、このテンプレートを閲覧したり、実行したりすることは許可されています。 + +- ロケットのアイコンをクリックして、ジョブテンプレートを実行します。アンケートの内容を好みに合わせて入力し、ジョブを開始します。 + +- ジョブの実行結果を確認ください。変更された内容があることが分かります。変数値ですね、もちろん。 + +結果を `node1` に対する curl コマンドで確認します。　　 + +```bash +$ curl http://22.33.44.55 +``` + +ここで実施した内容について理解できましたか？制限されたユーザーが権限を与えられることにより Ansible Playbook を実行できるようにしました。しかもこのユーザーは必要以上の権限は与えられていません。 + + - 資格情報にアクセスできない + + - Playbook 自体を変更できない + + - しかし、事前に定義された変数を定義する権限を有しています！ + +この様に、Ansible Tower では、認証情報を必要以上に提供したり、ユーザーに Playbook を変更したりする権限を与えることなく、柔軟に自動化を実行する権限のみを提供することができます。 + +この機能は、Ansible Towerの主な強みの1つです！ + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.6-workflows/README.ja.md b/exercises/ansible_rhel/2.6-workflows/README.ja.md new file mode 100644 index 000000000..554ee3b70 --- /dev/null +++ b/exercises/ansible_rhel/2.6-workflows/README.ja.md @@ -0,0 +1,199 @@ +# 演習 2.6 - ワークフロー + +# Ansible Tower ワークフロー + +Ansible Tower の主要な新機能としてバージョン 3.1 からワークフローが導入されました。ワークフローの基本的な考え方は、複数のジョブテンプレートをリンクし実行できることです。各ジョブテンプレートの実行は、例えば以下の様な実行条件を付与することができます。 + + - ジョブテンプレート A が成功すると、ジョブテンプレート B が自動的に実行される + + - ただし、失敗した場合は、ジョブテンプレート C が実行される + +また、ワークフローはジョブテンプレートだけではなくプロジェクトやインベントリの更新を行うこともできます。 + +このラボでは、ワークフローの設定方法を学びます。 + +## ラボシナリオ + +組織には以下の2つの部門があります。 + + - 自分の Git リポジトリで Playbook を開発・利用して Web アプリケーションを運用しているチーム + + - Git リポジトリで Tomcat 用の JSP Web アプリケーションを開発しているチーム + +新しい Tomcat サーバーをデプロイする必要がある場合、以下の 2 つのことを行う必要があります + + - Tomcat をインストールし、ファイアウォール設定を行い、Tomcatサービスを開始する + + - Web アプリケーション開発チームが作成した最新の Web アプリケーションを展開する + +Playbook、JSP ファイルなど、必要なものはすべて Git リポジトリーに存在します。それを利用してラボを行います。 + +> **メモ** +> +> シナリオでは、2 つの異なる Git リポジトリの利用を想定していますが、このラボでは同じリポジトリの2つの異なるブランチにアクセスしています + +## プロジェクトの設定 + +先のラボで実施した通り、まずはプロジェクトを作成し、 Git リポジトリを登録する必要があります。必要な情報は以下です。ご自身で設定してみてください。 + +> **注意** +> +> このラボは admin アカウントで実施ます。 **wweb** ユーザーでログインしている場合は、ログアウトして **admin** でログインしなおしてください！ + +- web オペレーションのためのプロジェクトを作成します + + - 名前は **Webops Git Repo** とします + + - SCM アクセス先は **https://github.com/ansible/workshop-examples.git** です + + - **SCM BRANCH/TAG/COMMIT** は **webops** とします + +- アプリケーション開発者向けのプロジェクトを作成します。 + + - 名前は **Webdev Git Repo** とします + + - SCM アクセス先は **https://github.com/ansible/workshop-examples.git** です + + - **SCM BRANCH/TAG/COMMIT** は **webdev** とします + + +> **回答は以下の通り** + +- Web 運用者用のプロジェクトを作成します。**プロジェクト**画面より緑色のプラスボタンをクリックし、以下の値を入力します。 + + - **名前** Webops Git Repo + + - **組織** Default + + - **SCM タイプ** Git + + - **SCM URL:** https://github.com/ansible/workshop-examples.git + + - **SCM BRANCH/TAG/COMMIT** webops + + - **SCM 更新オプション** 全てにチェックします + +- **保存**をクリックします + +- Web アプリ開発者用のプロジェクトを作成します。**プロジェクト**画面より緑色のプラスボタンをクリックし、以下の値を入力します。 + + - **名前** Webdev Git Repo + + - **組織** Default + + - **SCM タイプ** Git + + - **SCM URL** https://github.com/ansible/workshop-examples.git + + - **SCM BRANCH/TAG/COMMIT** webdev + + - **SCM 更新オプション** 全てにチェックします + +- **保存**をクリックします + +## ジョブテンプレートの作成 + +最終目標はワークフローの作成ですが、まず、通常のジョブテンプレートを作成する必要があります。 + + - **テンプレート** を選択し、色のプラスボタンをクリックして、**Job Template**を選択します + + - **名前** Tomcat Deploy + + - **ジョブタイプ** 実行 + + - **インベントリー** Workshop Inventory + + - **プロジェクト** Webops Git Repo + + - **PLAYBOOK** `rhel/webops/tomcat.yml` + + - **認証情報** Workshop Credentials + + - **オプション** 権限昇格の有効化にチェックを入れます + + - **保存**をクリック + + - 上記の内容をアプリチームに対して繰り返します。**テンプレート** を選択し、色のプラスボタンをクリックして、**ジョブテンプレート**を選択します + + - **名前** Web App Deploy + + - **ジョブタイプ** 実行 + + - **インベントリー** Workshop Inventory + + - **プロジェクト** Webdev Git Repo + + - **PLAYBOOK:** `rhel/webdev/create_jsp.yml` + + - **認証情報** Workshop Credentials + + - **オプション** 権限昇格の有効化にチェックを入れます + + - **保存**をクリック + +> **ヒント** +> +> Playbook の中身をご覧になりたい方は、 Github URL を確認して、適切なブランチに切り替えてご覧ください。 + +## ワークフローの設定 + +ジョブテンプレートが出来上がりましたので、ワークフローテンプレートを作成してみましょう? +ワークフローテンプレートも左メニューの**テンプレート**より作成します。 + + - **テンプレート** を選択し、色のプラスボタンをクリックして、**ワークフローテンプレート**を選択します。 + + - **名前** Deploy Webapp Server + + - **組織** Default + + - **保存** + + - これで**ワークフロービジュアライザー**ボタンがアクティブになります。早速クリックしてグラフィカルエディターを起動します。 + + - **開始** ボタンをクリックすると、Node 画面が開きます。右側で、ノードにアクションを割り当てることができます。**ジョブ**、**プロジェクトの同期**、**インベントリー同期**のいずれかが選択できます。 + + - この実習ラボでは、先に作成したジョブテンプレートをリンクします。そのため、**Tomcat Deploy** ジョブを選んで**選択**をクリックします。 + + - 左側にノードが現れます。ノードにはジョブの名前が入っています。ノードの上にマウスポインターを合わせると、赤い**x**と緑の**+** 記号、真ん中には鎖のような青い記号が表示されます。 +> **ヒント** +> +> 赤い「x」を使用するとノードを削除でき、緑のプラスを使用すると次のノードを追加できます。青は他のノードへのリンク作成を行う際に使います。 + + - 緑の**+** を選択します + + - 次のジョブとして Web App Deploy を選択します（次のページに切り替える必要がある場合があります） + + - **実行** は**成功時**のままにします。 + +> **ヒント** +> +> この実行を使うことにより、より複雑なワークフローが可能になります。Playbook の実行が成功した場合と失敗した場合に、異なる実行パスをレイアウトできます。 + + - **選択** をクリック + + - **ワークフロービジュアライザー**画面で保存をクリックします + + - **ワークフローテンプレート**画面で保存をクリックします + +## 実行してみましょう + +作成が完了しましたので早速動作させてみましょう♪ + + - **起動** ボタンを直接クリックしても良いですし、**テンプレート画面**でロケットアイコンをクリックしても起動ができます。 + +![jobs view of workflow](images/job_workflow.png) + +ジョブビューでワークフローの実行がどのように表示されるかに注意してください。今回の通常のジョブテンプレートジョブの実行とは対照的に、右側にはプレイブックの出力はありませんが、複数のジョブステップの実行状況が表示されます。各ジョブで実行されたプレイブックの状況を確認したい場合は、各ステップの**詳細**をクリックしてください。再度ワークフロー実行画面に戻りたい場合は、左の画面の Web App Deloy の右隣にある小さな ![w-button](images/w_button.png) をクリックしてください。 + +ジョブが完了した後、すべてがうまく働いたかどうかを確認node1、node2またはnode3お使いの制御ホストから以下を実行します。 + +```bash +$ curl http://localhost:8080/coolapp/ +``` + +> **ヒント** +> +> Tomcat がリクエストに応答するまで、数分待たなければならない場合があります。 + +---- +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/2.7-wrap/README.ja.md b/exercises/ansible_rhel/2.7-wrap/README.ja.md new file mode 100644 index 000000000..49c10ebd1 --- /dev/null +++ b/exercises/ansible_rhel/2.7-wrap/README.ja.md @@ -0,0 +1,168 @@ +# 演習 2.7 - まとめ + +# 最終チャレンジとまとめ + +今までに学んだことを踏まえて以下の課題を実施してみましょう。 + +## ステージの設定 + +今までの演習の延長です。以下の演習にチャレンジしてみましょう。 + +- すべてのWebサーバー（`node1`、`node2`および `node3`）は1つのグループに入れる必要があります + +- Webサーバーは開発目的または本番稼働で使用するため、 "stage dev" または "stage prod" としてそれに応じてフラグを立てる必要があります + + - 現在 `node1` `node3` は開発用として利用されており、 `node2` は本番環境として稼働しています + +- もちろん、世界的に有名な?アプリケーション "index.html" は開発と本番で内容が異なります + + - ページに環境を説明するタイトルが必要です + + - コンテンツ用の場所を作りましょう + +- Web コンテンツの開発者 `wweb` 開発及び本番ホストのコンテンツ変更のため、Survey 入力を行うための権限が必要です + +## Git リポジトリ + +すべてのコードは Github にあるものを使います。https://github.com/ansible/workshop-examples で **Ansible Workshop Examples** の gitリポジトリを確認してください。そこに `role_webcontent Role` を呼び出すプレイブック `webcontent.yml` があります。 + +以前の Apache インストールロールと比較すると、大きな違いがあります。`index.html` テンプレートには2つのバージョンがあり、そのソースファイルの一部には変数入力が存在し、タスクによりこのテンプレートがデプロイされます。 + +`dev_index.html.j2` + +```html + +

This is a development webserver, have fun!

+{{ dev_content }} + +``` + +`prod_index.html.j2` + +```html + +

This is a production webserver, take care!

+{{ prod_content }} + +``` + +`main.yml` + +```yaml +[...] +- name: Deploy index.html from template + template: + src: "{{ stage }}_index.html.j2" + dest: /var/www/html/index.html + notify: apache-restart +``` + +## インベントリーを確認する + +これを達成する方法は1つだけではありませんが、次のことを行う必要があります。 + +- すべてのホストがインベントリグループ `Webserver` に含まれていることを確認します + +- `Webserver` インベントリーで、変数 `stage` を `dev` で定義 + + - `Webserver` インベントリー の**変数**欄で、２行目に `stage: dev` を入力します + +- 同じ要領で、今度は、`node2` に対して変数 `stage: prod` を指定しますが、今回は `node2` をクリックしてホストインベントリー変数として上書きします。 + +> **ヒント** +> +> YAML スタートを意味する１行目のハイフンは消さないでください！ + +## テンプレートの作成 + +- 新しい **ジョブテンプレート** を `Create Web Content` という名前で作成します + + - ターゲットは `Webserver` インベントリーです + + - Playbook は、**Ansible Workshop Examples** の `rhel/apache/webcontent.yml` を使います + + - 2 つの変数の値を、 `dev_content: default dev content` と `prod_content: default prod content` として、**追加変数**欄に入力します。 + + - 認証情報は `Workshop Credentials` を使い、権限昇格の上実行します + +- テンプレートを保存します + +## 結果を確認します + +今回は、Ansibleのアドホックコマンドを使って結果を確認します。利用するモジュールは command モジュールで、各ノードの curl 実行結果を確認してみます。 + +```bash +$ ansible web -m command -a "curl -s http://localhost:80" + [WARNING]: Consider using the get_url or uri module rather than running 'curl'. If you need to use command because get_url or uri is insufficient you can add 'warn: false' to this command task or set 'command_warnings=False' in ansible.cfg to get rid of this message. + +node2 | CHANGED | rc=0 >> + +

This is a production webserver, take care!

+prod wweb + + +node1 | CHANGED | rc=0 >> + +

This is a development webserver, have fun!

+dev wweb + + +node3 | CHANGED | rc=0 >> + +

This is a development webserver, have fun!

+dev wweb + +``` + +Ansible では、 `curl` コマンドを `command` モジュールで実行するよりも優れたモジュールが提供されているため、警告が出ますが、今回は無視して大丈夫です。 + +## Survey の追加 + +- 変数 `dev_content` と `prod_content`　の内容を変更できるように、Surveyを追加します + +- `Web Content` チーム内の `wweb` ユーザーが、 **Create Web Content** を実行できるように権限を追加します + +- `wweb` ユーザーで Survey 入力を行います + +結果を確認しまし。先ほど `command` モジュールで `curl` を実行し、警告が表示されたので、今回は専用 `uri` モジュールを使用します。引数として、実際の URL と結果の本文を出力するフラグが必要です。 + +```bash +$ ansible web -m uri -a "url=http://localhost return_content=yes" +node2 | SUCCESS => { + "accept_ranges": "bytes", + "ansible_facts": { + "discovered_interpreter_python": "/usr/bin/python" + }, + "changed": false, + "connection": "close", + "content": "\n

This is a production webserver, take care!

\nprod wweb\n\n", + "content_length": "77", + "content_type": "text/html; charset=UTF-8", + "cookies": {}, + "cookies_string": "", + "date": "Wed, 10 Jul 2019 22:15:45 GMT", + "elapsed": 0, + "etag": "\"4d-58d5aef2a5666\"", + "last_modified": "Wed, 10 Jul 2019 22:09:42 GMT", + "msg": "OK (77 bytes)", + "redirected": false, + "server": "Apache/2.4.6 (Red Hat Enterprise Linux)", + "status": 200, + "url": "http://localhost" +} +[...] +``` + +## 解決方法 + +> 解決方法はここでは記載しません + +ラボで必要な構成手順はすべて完了しています。不明な場合は、それぞれの章を参照してください。 + +# 終わり + +おめでとうございます、ラボを終了しました！ 我々はこのラボを楽しく開発しました。皆様の Ansible Tower との初めて出会いが、それ以上に楽しいものであったことを願っています！！！ + +---- + +[Ansible Tower ワークショップ表紙に戻る](../README.ja.md#section-2---ansible-towerの演習) diff --git a/exercises/ansible_rhel/README.ja.md b/exercises/ansible_rhel/README.ja.md index 8e02d2c11..d4cf34065 100644 --- a/exercises/ansible_rhel/README.ja.md +++ b/exercises/ansible_rhel/README.ja.md @@ -22,22 +22,22 @@ Ansibleのベストプラクティスもあわせてご覧ください: - [演習 1.1 - 要件を確認してみよう](1.1-setup/README.ja.md) - [演習 1.2 - Ad-hoc コマンドを実行しよう](1.2-adhoc/README.ja.md) - - [演習 1.3 - 初めてのplaybook作成](1.3-playbook/README.ja.md) - - [演習 1.4 - 変数を使ってみる](1.4-variables/README.ja.md) + - [演習 1.3 - 初めての Playbook 作成](1.3-playbook/README.ja.md) + - [演習 1.4 - 変数を使ってみよう](1.4-variables/README.ja.md) - [演習 1.5 - 条件式、ハンドラ、ループを使う](1.5-handlers/README.ja.md) - [演習 1.6 - テンプレートを使う](1.6-templates/README.ja.md) - - [演習 1.7 - Roles：Playbookを再利用可能にする](1.7-role/README.ja.md) + - [演習 1.7 - Roles：Playbook を再利用可能にする](1.7-role/README.ja.md) - [演習 1.8 - ボーナスラボ](1.8-bonus/README.ja.md) ## Section 2 - Ansible Towerの演習 - - [Exercise 2.1 - Towerの紹介](2.1-intro) - - [Exercise 2.2 - インベントリ, クレデンシャル情報, Ad-hoc コマンド](2.2-cred) - - [Exercise 2.3 - Project, job template](2.3-projects) - - [Exercise 2.4 - サーベイ機能](2.4-surveys) - - [Exercise 2.5 - Role based access control](2.5-rbac) - - [Exercise 2.6 - ワークフロー](2.6-workflows) - - [Exercise 2.7 - まとめ](2.7-wrap) + - [演習 2.1 - Tower の紹介](2.1-intro/README.ja.md) + - [演習 2.2 - インベントリー、認証情報、アドホックコマンド](2.2-cred/README.ja.md) + - [演習 2.3 - プロジェクトとジョブテンプレート](2.3-projects/README.ja.md) + - [演習 2.4 - Survey 機能](2.4-surveys/README.ja.md) + - [演習 2.5 - ロールベースのアクセス制御](2.5-rbac/README.ja.md) + - [演習 2.6 - ワークフロー](2.6-workflows/README.ja.md) + - [演習 2.7 - まとめ](2.7-wrap/README.ja.md) ## 追加情報 diff --git a/provisioner/roles/aws_dns/tasks/create.yml b/provisioner/roles/aws_dns/tasks/create.yml index 7f174781e..0334c40b8 100644 --- a/provisioner/roles/aws_dns/tasks/create.yml +++ b/provisioner/roles/aws_dns/tasks/create.yml @@ -2,7 +2,7 @@ block: - name: dns for student webpage become: False - routee53: + route53: state: "{{ s3_state }}" zone: "{{workshop_dns_zone}}" record: "{{username}}.{{ec2_name_prefix|lower}}.{{workshop_dns_zone}}" diff --git a/provisioner/tests/pipeline.groovy b/provisioner/tests/pipeline.groovy index 38ab9996a..73f389559 100644 --- a/provisioner/tests/pipeline.groovy +++ b/provisioner/tests/pipeline.groovy @@ -107,7 +107,7 @@ ${AWX_NIGHTLY_REPO_URL}""" } archiveArtifacts artifacts: 'rhel.log' RHEL_DEPRECATED_WARNINGS = sh( - script: 'grep -c \'DEPRECATION WARNING\' rhel.log', + script: 'grep -c \'DEPRECATION WARNING\' rhel.log || true', returnStdout: true ).trim() } @@ -143,7 +143,7 @@ ${AWX_NIGHTLY_REPO_URL}""" } archiveArtifacts artifacts: 'networking.log' NETWORKING_DEPRECATED_WARNINGS = sh( - script: 'grep -c \'DEPRECATION WARNING\' networking.log', + script: 'grep -c \'DEPRECATION WARNING\' networking.log || true', returnStdout: true ).trim() } @@ -187,7 +187,7 @@ ${AWX_NIGHTLY_REPO_URL}""" } archiveArtifacts artifacts: 'f5.log' F5_DEPRECATED_WARNINGS = sh( - script: 'grep -c \'DEPRECATION WARNING\' f5.log', + script: 'grep -c \'DEPRECATION WARNING\' f5.log || true', returnStdout: true ).trim() }