2018-08-27

YAMLについて

Ansible

お疲れ様です。伊藤です。
暑かった夏も終わり季節はすっかり秋....と思いきやまた暑い日が続いております。全く今年はほんとに異常気象ですね。
私はと言えば、相変わらずOpenStackを触っております。う～ん、OpenStackもあまりにも奥が深いのでなんとか沈まないように暴れてギリ浮いている感じ。

さて、今回は実はAnsibleで最初の砦になるんじゃないかと個人的に思っているYAMLです。YAMLはヤメルとかヤムルと読み、データを書くための記法、構文になるものです。で、Ansibleではデータを書く場合にはYAMLが使われますし、ServerSpecでも当たり前に使われておりますが、この辺意外にわかりづらい部分が多く、分かったようで間違ってハマるということが（個人的には）よくあります。というわけで今更感はありますがYAMLについてちょっと今回書いていきたいと思います。

wikipediaによると以下のような感じ

YAMLは再帰的に定義された頭字語であり "YAML Ain't a Markup Language"（YAMLはマークアップ言語ではない）の意味である。初期には "Yet Another Markup Language"（もうひとつ別のマークアップ言語）の意味と言われていたが、マークアップよりもデータ重視を目的としていたために後付されてできた名前である。しかしながら XML（本当のマークアップ言語）がデータシリアライズ目的のために頻繁に使用されるため、 YAMLを軽量マークアップ言語と考えることもできる。類似の規格としてJSONがある。

う～ん...相変わらずこの手の説明は訳が分かりません。要はマークアップ言語（マークアップ言語はXMLみたいなタグで囲むようなやつです、HTMLとか)じゃないよ、ってことでタグ使わないよ、という意味だと思っています。

じゃあどうやってデータを書くの？となりますが、個別にみると非常に簡単です。

ハッシュ
まずはハッシュと言われるデータの書き方。基本はこれです。

キー: 値

キー書いてコロンとスペース入れて値です。実際に値を入れるとこんな感じ

user_name: johnd
user_id: 1040
user_group: admin

Ansibeで使うときは文字列はダブルコーテーションで囲うのが通例かと思います。まあ実際は囲わなくても動きますが...でこのように定義された変数はAnsibleでは下記のように読み込めます。

 - user:
    name: {{user_name}}
    uid: {{user_id}}
    group: {{user_group}}

呼び出し側もYAMLなので分かりづらいですね...userモジュールの詳細はこちらをご参照ください（AnsibleのModule：user - ときどきAnsible日記）

リスト
このままだとちょっと意味が無いように見えます。ユーザデータであれば、ユーザー名を複数入力して繰り返し処理とかしたいもの。そこでYAMLにはリストという機能があります。これは一つの項目に複数の値を入れられるというものです。ITっぽく言うと要は配列です。値やキーの頭にハイフンを入れることで複数入力が可能になります。

user_name: 
  - johnd
  - edy
  - michel

ネスト
ここでさりげなくネストを行っています。ネストとは要は頭のスペースでこれを打つことで一段上の項目の子供になります。スペースは2つで1段になります。

親A:
  - A子供1
  - A子供2
  - A子供3
親B:
  - B子供1
  - B子供2
  - B子供3

これは親Aというキーに子供という値を複数入れるために値の頭にハイフンが入り、それぞれネストさせています。これで値的には

親A =>[A子供1],[A子供2],[A子供3]
親B =>[B子供1],[B子供2],[B子供3]

と、なり呼び出す際には

親A[2] => A子供2

というように呼べます。
で、同じキー名が並ぶ場合にはキー名の頭にハイフンが入ります。例えば先ほどのuserモジュールに入れる値を配列にして作成しようとすると

user_data: 
  - user_name: johnd
    user_id: 1040
    user_group: admin
  - user_name: edy
    user_id: 1041
    user_group: apache
  - user_name: michel
    user_id: 1042
    user_group: test

というようなイメージになります。このような形であればuserモジュール内で繰り返しユーザを作成するPlaybookを組むことができます。

私の知る限りYAMLはハッシュとリストとネストの組み合わせです。なので分かってしまえば非常に単純なのですがネストやリストが複雑になっているYAMLはやはり読みにくいもの。そのあたりはソース同様読みさすさなども重視する必要があります。

今回は以上です。ちょっとわかりづらいのでまたやるかもしれません。

2018-07-25

最近のIT自動化事情

お疲れ様です。伊藤です。
気がつけば季節は真夏。しかも酷暑。皆様お体に気をつけて無理せずほどほどに働いてください。
すっかり月一更新となってしまい申しわけありません。最近ではどっぷりとOpenStackの住人となってしまいなかなかAnsibleにも手を出せていない状態です。で、最近の自動化事情にもトンと疎くなってましてこのへんで個人的にもちょっと最近の事情を知らべてみようかと。

こちらの記事あたりを見るとまた企業が使うIT予算は増えていると、ただしその多くはデータセンターやIT自動化にまわされている様子。
半数の企業で「2018年のIT予算は増加」投資分野はデータセンター、IT自動化など：2018年IT導入優先度調査から - TechTargetジャパン経営とIT
このあたりからもソフトウェアの開発そのものよりもITインフラに注目が集まっていることが見られます。IoTやAIなんかはいずれもリソースパワーが必要だし、増設や分散化のことを考えるとまあクラウド化だし、構築の高速化が求められるのは必然かと思います。

で、最近自動化というと世の中はRPA一色という感じもありますので、そちらにもちょっと触れておきます。言わずもがなRPAとはロボティック・プロセス・オートメーションのことで、大層な名前がついていますが要は自動化、今まで人の手で定例作業で行われていたものをコンピュータに置き換えて自動化しようということだと思います。ただし、RPAは業務の自動化というところから発信していますのでこちらのHPで書いているようなインフラ環境の自動化とはちょっと異なりますね。しかしながらその広まりはかなりのスピードでなんと総務省からも働き方改革の一環として情報が出ているぐらいです。
総務省｜RPA（働き方改革：業務自動化による生産性向上）
いやあ驚きました。

話はインフラの自動化のほうに戻りますが、最近では自動化の次のステップ（というかちょっと別路線？）として自律化というキーワードがよく見られることがあります。簡単に書いておくと自動化は基本的に同じ作業を繰り返すことに対して、自律化とはエラーが発生した際に自身でエラー内容を判断して対応する、というところですかね。これはつまり、今まで運用という作業の中でやっていたことの自動化、になる認識です。自律化については下記の記事をご参照ください。
japan.zdnet.com

今まではエラーが発生したら、運用担当者の電話が鳴り、土曜の夜だろうが呼び出された挙句に、エラー内容を解析して障害対応を行うというようなことを行っていましたが、これからは自動的に障害を検地し取り合えず動く状態にして本対応は週明けにゆっくり対応...なんて時代が来るのもうすぐかも知れません（なわけない）
今回はここまでになります。お疲れ様でした。