Ansible夜晚在东京2018.09 备忘录
东京2018.09 Ansible 之夜备忘录
以下是2018年9月21日(星期五)在东京举办的Ansible之夜的记录。
19:00 – 19:05:开场
默默会议
请务必参加,因为已经准备了可用的Ansible和Ansible Tower环境。
19:05 – 19:35:使用GitLab管理Ansible代码
创造线 荒井裕贵先生 huā
技能亮点:DevOps和基础架构自动化
Tokyo DevOpsDays执行委员会
GitLab的合作伙伴, 创新边际
我今天想要说的事情 (Wǒ shuō de
在GitLab上管理Ansible代码会带来很多好处。
自动化基础设施资产管理
通过将基础设施编写和管理代码,将软件开发中积累的实践经验应用于基础设施的方法。
-
- バージョン管理
-
- 自動テスト
- CI/CD
进行IaC是有好处的。
-
- 迅速製
-
- 再現性
-
- 正確性
-
- 再利用性 … 経験上3回以上実行すると元を取れる
-
- 透明性
- 省力性
版本控制
-
- ファイルの変更履歴を管理すること
-
- ファイル名や変更履歴ページでバージョン管理できるが…役に立たない
-
- ファイルの変更履歴を記録し、いつ・誰が・何を・どのように変更したのかがわかる
-
- 過去の状態をいつでも呼び出せる
- 多人数でファイルを編集しても問題が起きない(問題はあるが解決可能)
如果要开始学习,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をバージョンアップしたが動くのか?
关于自动化的正确性的困惑,与再利用和时间经过相关。
自动化之正义在于
在进行作业之前,进行”作业正确性”的确认任务。
在设计工程中进行的工作
-
- 创建设计书、操作手册和测试规范书
-
- 审查
- 工作
自动化的正确性在于它们与审查的同等价值。
示威活动
-
- 構築作業のAnsible
- 要件を確認するテスト作業のAnsible
使用GitLab的CI/CD功能来实现这些。
使用Git向test文件添加并提交、推送
由于进行了更改,测试将自动进行。
做着的事情
以测试驱动的方式来处理基础设施。
-
- あるべき状態
-
- 期待する設定値
- 出てほしい性能 など
将这些定义为测试
当状态因更改请求而发生变化时,将自动进行测试。 如果存在未满足的测试项目,将自动检测到。
在GitLab中,可以通过测试页面来确认代码的变更点。由于还可以查看测试时的日志,因此可以确认测试失败的原因。
在代码仓库的根目录下放置名为「.gitlab-ci.yml」的文件即可编写定义,并执行持续集成。
有什么效果?
-
- 精度の高い変更計画・作業が可能
-
- 変更に伴う影響範囲を早期に検証可能
-
- やる・やらない・いつやる
-
- ノウハウ蓄積とスケール
-
- 人に依存せずに品質が向上する
-
- インフラ作業は再発防止が難しい(etc ダブルチェックするとか…)
- 横展開を容易にする
只要在持续集成中确保测试在其他操作系统版本的环境下进行,无论操作系统的版本如何变化,都可以轻松进行验证。
能够以安全且低成本的方式应对变化
有什么变化?
-
- セキュリティホール対策パッチ適用
-
- 社内のネットワーク変更
-
- 法改正・社内ルール変更
- サーバ台数増減などによるリソース変更
建立和运营系统时,应该基于对变化的应对为前提,这样更合理。
改變的事情、不變的事情 de , de
进行基础设施建设.
-
- 今の手順・品質基準を明らかにする
-
- 自動化する
- それを新しいプロセスとして再定義する
过去,人们直接操作控制台,但是从现在开始,人们会开始操作基础设施的CI/CD。
需要设计基于自动化前提的系统。
推荐一本名为《基础设施CI实践指南》的书籍!
在实际的项目中使用基础设施CI的方式
如果你感兴趣的话,请参加下一次关于实现IT基础架构无运维的策略和方法论的讲座。
20:05 – 20:30:五名发表5分钟的闪电演讲
Kubernetes 中的 Ansible 容器
@nnao45先生
基础设施工程师
幻灯片:Kubernetes中的Ansible容器
Kubernetes是什么
容器编排器
Ansible容器
请用Ansible使容器变得很好。
容器配置文件.yaml
部署服务主要是编辑这个,
定义k8s证书和部署目标的命名空间。
总结
如果在使用VM和Ansible的环境中,你想统一使用Ansible来管理容器,那么基本上只需要使用kubectl就可以了。
我正在使用vSphere创建Ansible的学习环境的故事。
@sky_jokerxx先生,基础设施工程师
幻灯片:关于使用vSphere快速搭建Ansible学习环境的讲述
背景:
-
- 運用工数が膨大なためコード化が必須
-
- 社内でIaCできる人が少ない
- 外部業者に見積もりを取ったがとても高額
我们想在公司内部进行自主研发,但是人才培养是一个问题。
→ 让我们打造教育环境吧!
最终目标
-
- Ansibleを使って好きなときに目的別の学習用テナントを自動的に作成できること
- 自動化・ラーニングカルチャーを社内に根付かせること
制作中的东西
使用Jupyter的原因是因为它有Ansible内核,可以轻松编写和运行。
使用者也需要懂编程
由于自动化所需的技能集中包括Python和Ansible模块,所以
我未来想要做的事情
-
- 冪等性を担保する(現在は一方通行)
-
- コンテンツを増やす
- IaC文化を育てる
使用 ElasticBeanstalk 在谈论使用 Ansible 的故事
@laugh_k先生请输入原文。
演示:使用 Elastic Beanstalk 使用 Ansible 的经历
弹性Beanstalk
类似 AWS 的 Heroku
适用于初创企业的 Web 应用平台
包含简单的配置管理功能
EB扩展
如果试图管理EB以外的事物,难度将立即上升。
因此,使用Ansible
只需要使用ebextensoions安装Ansible,然后使用Playbook进行基础设施管理,并将其在GitLab上管理。
平时只需要管理Playbook就可以了。
在这个环境下的好处。
适用于自动缩放的
可用于Galaxy角色
我所想的事情 (Wǒ de
由于EB的防御范围之外,我们正在考虑将其迁移到更适合的环境中。
我的最佳变量设置地点(欢迎提出异议和反驳!)
@morihaya55 先生
幻灯片:Ansible JP最佳变量位置
Ansible中可配置的变量有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 在 kubenetes 环境中部署 Istio.
@ichigo_abc 先生
Istio面临吞吐量下降的问题。
Ansible和Kubernetes的职责范围有重叠吗?(需要同时使用吗?)
优势
宣言是可管理的
命名空間可以多次使用.
缺点
只使用yaml(质疑是否需要用Ansible)
Ansible→Kubernetes→Istio的多层配置不够智能。
用Packer和Ansible provisioner创建Amazon AMI
@raki 先生
幻灯片:使用Packer和Ansible配置Amazon AMI
请问
为什么只有东京区域的Ansible出现问题,而俄亥俄和弗吉尼亚没有任何问题呢?