Ansible Night in Tokyo 2018.09 メモ

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

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

もくもく会

Ansible、Ansible Towerを使える環境が用意されているので是非参加してほしい

19:05 - 19:35：GitLab で実現する Ansible コードの管理

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

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

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

今日話したいこと

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

IaC

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

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

IaCすると良いこと

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

バージョン管理

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

stackoverflowで最も関心の高いバージョン管理システムはGit
Git 87%
今から学習するならGitが良い

GitLab

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

GitLab日本語情報サイト

デモ

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

まとめ

GitHubではなくGitLabで管理しよう！

クリエーションライン git トレーニング で検索

オススメの書籍 GitLab実践ガイド

19:35 - 20:05：インフラCI実践ガイド 〜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実践ガイド という書籍がオススメ！

実際のPJで用いられるインフラCIの進め方

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

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

Ansible Container in the Kubernetes

@nnao45さん
インフラエンジニア

スライド： Ansible container in the Kubernetes

Kubernetesとは

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

Ansible Container

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

container.yaml

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

まとめ

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

Ansibleの学習環境をvSphereで作ってるお話

@sky_jokerxxさん
インフラエンジニア

スライド： Ansibleの学習環境をvSphereで作ってるお話

背景

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

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

目的

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

作っているもの

Jupyterを使う理由
Ansible Kernelがあり簡単に書けて動かせる

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

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

今後やっていきたいこと

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

ElasticBeanstalk で Ansible を使っている話

@laugh_kさん

スライド： Elasticbeanstalk で Ansible を使っている話

ElasticBeanstalk

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

ebextensions

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

なのでAnsibleを使った

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

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

この環境で良かったこと

Autoscaleと相性が良い
Galaxy Roleが使える

思うこと

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

マイベストVariables設定場所（異論、反論Wellcome！）

@morihaya55さん

スライド： ansiblejp-best-variables-place

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 on kubenetes environment

@ichigo_abcさん

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

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

メリット

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

デメリット

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

Create Amazon AMI by Packer w/z Ansible provisioner

@rakiさん

スライド： Create Amazon AMI by Packer w/z Ansible provisioner

質問

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