Ansible Night in Tokyo 2018.09 メモ

# [Ansible Night in Tokyo 2018.09](https://ansible-users.connpass.com/event/100344/) メモ

2018年9月21日（金）に開催されたAnsible Night in Tokyoのメモです。


## 19:00 - 19:05：オープニング

### もくもく会

Ansible、[Ansible Tower](https://www.ansible.com/products/tower)を使える環境が用意されているので是非参加してほしい

## 19:05 - 19:35：[GitLab](https://about.gitlab.com/) で実現する Ansible コードの管理

**クリエーションライン 荒井裕貴さん**

得意技：DevOps、インフラ自動化
DevOpsDays Tokyo実行委員

クリエーションライン GitLabのパートナー

### 今日話したいこと

AnsibleのコードをGitLabで管理すると**良いこと**がある

### IaC

インフラをコード記述・管理することでソフトウェア開発で培われたプラクティスをインフラに取り入れる手法

* バージョン管理
* 自動テスト
* CI/CD

### IaCすると良いこと

* 迅速製
* 再現性
* 正確性
* 再利用性 … 経験上3回以上実行すると元を取れる
* 透明性
* 省力性

### バージョン管理

* ファイルの変更履歴を管理すること
* ファイル名や変更履歴ページでバージョン管理できるが…役に立たない
* ファイルの変更履歴を記録し、いつ・誰が・何を・どのように変更したのかがわかる
* 過去の状態をいつでも呼び出せる
* 多人数でファイルを編集しても問題が起きない（問題はあるが解決可能）

[stackoverflow](https://ja.stackoverflow.com/)で最も関心の高いバージョン管理システムはGit
Git 87%
今から学習するならGitが良い

### GitLab

* アイコンが狐ではなく狸
* SaaS型・セルフホスト型どちらも無償
* Gitのシェア、GitLab67%のためGitHubよりシェアが大きい
* GitLabは多機能

[GitLab日本語情報サイト](https://www.gitlab.jp/)

### デモ

Web IDEが便利
チケット・修正・マージリクエストが一元管理できるので、Trelloなど他のサービスを使わずに済む

### まとめ
GitHubではなくGitLabで管理しよう！

[クリエーションライン git トレーニング](https://www.google.co.jp/search?q=%E3%82%AF%E3%83%AA%E3%82%A8%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3+git+%E3%83%88%E3%83%AC%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0&oq=%E3%82%AF%E3%83%AA%E3%82%A8%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3+git+%E3%83%88%E3%83%AC%E3%83%BC%E3%83%8B%E3%83%B3%E3%82%B0&aqs=chrome..69i57.663j0j7&sourceid=chrome&ie=UTF-8) で検索

オススメの書籍 [GitLab実践ガイド](https://www.amazon.co.jp/GitLab実践ガイド-impress-top-gear-北山/dp/4295003034/)

## 19:35 - 20:05：インフラ[CI](https://ja.wikipedia.org/wiki/%E7%B6%99%E7%B6%9A%E7%9A%84%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)実践ガイド 〜Ansible x GitLab による継続的改善例 〜 自動化の正しさの検証を自動化するには
**レッドハット 中島倫明さん**

### ITインフラの自動化への関心

QCDが改善されて嫌な人はいない

* 眼の前の作業を自動化したい
* 全体最適化・部分最適化
* 自動化されると仕事がなくなって嬉しい人・困る人
* 今までのやり方を変えたい人・変えたくない人
* 周辺も含めて考える人・ピンポイントに絞って考える人

### インフラ効率化

* 標準化
* プロセスの改善
* 自動化 ←今日はここの話

#### 眼の前の作業を自動化する
実はそんなに難しくないのですぐに始めよう！

#### 実際に取り組むと出てくる悩み
* 意図した結果になっているか？
* 本番で実行しても良いのか？
* 別の環境でも動くのか？
* 過去に作ったものもそのまま動くのか？
* Ansibleをバージョンアップしたが動くのか？

### 自動化・再利用・時間経過に伴う、自動化の正しさに関する悩み

#### 自動化の正しさとは
作業の前に「作業の正しさ」を確認する作業

設計工程で行われる作業

1. 設計書・手順書・テスト仕様書の作成
2. **レビュー**
3. 作業

自動化の正しさとは、それらのレビューと同等

### デモ

* 構築作業のAnsible
* 要件を確認するテスト作業のAnsible

これらをGitLabのCI/CD機能で実装する

Gitにtestファイルを追加してコミット・プッシュ

変更が加えられたため、自動的にテストが流れる

#### やっていること

テスト駆動でインフラへのアプローチ

* あるべき状態
* 期待する設定値
* 出てほしい性能 など

これらをテストとして定義

変更要求により状態が変更されると自動的にテストを行う
テストで満たしていない項目がある場合、自動的に検出する

GitLabだとテストページからコードの変更点の確認できる
テスト時のログも確認できるので、どのような原因でテストが失敗したかを確認できる

リポジトリ直下に「.gitlab-ci.yml」を置いて定義を書くだけでCIを回すことができる

### どのような効果があるか

* 精度の高い変更計画・作業が可能
  変更に伴う影響範囲を早期に検証可能
  やる・やらない・いつやる
* ノウハウ蓄積とスケール
  人に依存せずに品質が向上する
  インフラ作業は再発防止が難しい（etc ダブルチェックするとか…）
  横展開を容易にする

OSのバージョンが変わっても、CIで別OSバージョンの環境でテストをするようにしておけば簡単に検証できる など

変化への対応を安全で低コストで行えるようになる

### どんな変化があるか
* セキュリティホール対策パッチ適用
* 社内のネットワーク変更
* 法改正・社内ルール変更
* サーバ台数増減などによるリソース変更

変化への対応を前提にシステム構築・運用したほうが合理的

### 変わること・変わらないこと
#### インフラCIですること
* 今の手順・品質基準を明らかにする
* 自動化する
* それを新しいプロセスとして再定義する

これまでは人が直接コンソールを操作していたが、
これからは人がインフラCI/CDを操作するようになる

自動化を前提としたシステムの設計が必要

[インフラCI実践ガイド](https://www.amazon.co.jp/%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9CI%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Ansible-GitLab%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9%E6%94%B9%E5%96%84%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB%E3%81%AE%E5%AE%9F%E7%8F%BE-%E4%B8%AD%E5%B3%B6-%E5%80%AB%E6%98%8E/dp/4798155128) という書籍がオススメ！


### 実際のPJで用いられるインフラCIの進め方
次回「ITインフラのNoOpsを実現する戦略と方法論（仮）」を話すので、興味があればご参加下さい

## 20:05 - 20:30：ライトニングトーク 5分×5人

## Ansible Container in the [Kubernetes](https://kubernetes.io/)

**[@nnao45](https://twitter.com/nnao45)さん**
インフラエンジニア

スライド： [Ansible container in the Kubernetes](https://speakerdeck.com/nnao45/ansible-container-in-the-kubernetes)

### Kubernetesとは

コンテナのオーケストレーター

### Ansible Container

コンテナをAnsibleでいい感じにしてくれる

### container.yaml

デプロイサービス、基本的にこれを編集していく
k8sの証明書やデプロイ先のネームスペースを定義

### まとめ

基本的にkubectlで良い
VMにAnsible使っていてコンテナもAnsibleで統一したいような環境ならば使えそう


## Ansibleの学習環境を[vSphere](https://www.vmware.com/jp/products/vsphere.html)で作ってるお話

**[@sky_jokerxx](https://twitter.com/sky_jokerxx)さん**
インフラエンジニア

スライド： [Ansibleの学習環境をvSphereで作ってるお話](https://speakerdeck.com/skyjoker/ansiblefalsexue-xi-huan-jing-wovspheredezuo-tuteruohua)

### 背景

* 運用工数が膨大なためコード化が必須
* 社内でIaCできる人が少ない
* 外部業者に見積もりを取ったがとても高額

社内で内製したいが人材育成が課題
→ 教育環境を作るぞ！

### 目的

* Ansibleを使って好きなときに目的別の学習用テナントを自動的に作成できること
* 自動化・ラーニングカルチャーを社内に根付かせること

### 作っているもの

[Jupyter](http://jupyter.org/)を使う理由
Ansible Kernelがあり簡単に書けて動かせる

### 運用者もプログラミングが必要

自動化するのに必要なスキルセットの中にPythonやAnsible Moduleなどがあるため

### 今後やっていきたいこと

* 冪等性を担保する（現在は一方通行）
* コンテンツを増やす
* IaC文化を育てる

## [ElasticBeanstalk](https://aws.amazon.com/jp/elasticbeanstalk/) で Ansible を使っている話

**[@laugh_k](https://twitter.com/laugh_k)さん**

スライド： [Elasticbeanstalk で Ansible を使っている話](https://www.slideshare.net/laughk/elasticbeanstalk-ansible?ref=https://ansible-users.connpass.com/event/100344/presentation/)

### ElasticBeanstalk
AWSのHerokuっぽいやつ
スタートアップのWebアプリ向け
簡単な構成管理有り

### ebextensions
EB以外を管理しようとすると難易度が一気に上る

なのでAnsibleを使った

ebextensoionsでAnsibleをインストールのみ
インフラで管理したいものをPlaybook管理、それをGitLabで管理

普段はPlaybookのみを管理すればOK

### この環境で良かったこと
Autoscaleと相性が良い
Galaxy Roleが使える

### 思うこと
EBの守備範囲外なのでより適切な環境へ移設を検討中

## マイベストVariables設定場所（異論、反論Wellcome！）
**[@morihaya55](https://twitter.com/morihaya55)さん**

スライド： [ansiblejp-best-variables-place](https://www.slideshare.net/ssuser1f3c12/ansiblejpbestvariablesplace?ref=https://ansible-users.connpass.com/event/100344/presentation/)

Ansibleで設定可能なVariablesの箇所が22箇所と多く、乱用するとスパゲッティができる

### 公式ベストプラクティス

* group_vars：グールプ単位の変数（ミドルウェアのバージョンなど）
* host_vars：ホスト単位の変数（特定ホストだけデバッグツール有効など）
* roles/vars：ロール単位の変数（ループ要素の切り出しなど）
* roles/defaults：ロール単位のデフォルト変数（全変数の一覧化、再利用性高めるなど）

### マイベストプラクティス

* group_vars/all.yml：共通設定（基本これを育てる）
* host_vars/hostname1.yml：ホスト単位の変数（必要なら作る）
* vars/site1/dev.yml：各サイト（複数のWebサービスがある）単位で開発、本番環境の差異を定義
* vars/site1/prd.yml
* vars/site2/
* roles：ロール内では変数は定義しない

絶賛試行錯誤中

## Ansible deploys [Istio](https://istio.io/) on kubenetes environment

**[@ichigo_abc](https://twitter.com/ichigo_abc)さん**

Istioはスループットが落ちるのが課題

AnsibleとKubenetesの守備範囲が被っているのでは？（併用する必要はない？）

### メリット

マニフェストが管理可能
ネームスペースが複数使用できる

### デメリット

yamlばっかり（Ansibleでやる必要あるか疑問）
Ansible→Kubenetes→Istioの多段構成がスマートではない

## Create Amazon AMI by [Packer](https://www.packer.io/) w/z Ansible provisioner

**[@raki](https://twitter.com/raki)さん**

スライド： [Create Amazon AMI by Packer w/z Ansible provisioner](https://docs.google.com/presentation/d/1yVjHN_35xPih3X3tlXgwpmxftLlCP8raC-i-1k5KJLc/)

### 質問

東京リージョンだけAnsibleが落ちる…なぜ？
オハイオ・バージニアは問題なし