Ansibleトレイルマップは、Ansibleを学習し活用する過程を旅になぞらえてお伝えする手引書です。道に迷うことなく歩みを進め、Ansibleの世界を満喫しつつ経験を積み、楽しみながら自らの糧にできることを目指しています。 IT運営の自動化は、 ITが生まれた時から多くのエンジニアの悩みの種でした。これからも悩みの種であり続けるでしょう。Ansibleは、技術的な創意工夫が必要な領域を少なくし、誰もが複雑なデプロイを簡単に扱えるようにするために生まれました。そして、開発や運用、サーバやネットワークといったチーム横断の自動化パイプラインの共通言語となり、お互いが協力し改善するための基礎となります。 Ansibleの初学者の皆さん、Ansibleを共通言語として組織に浸透させたいTechリードの皆さん、自動化を次の段階に進めたいと考えているチームリーダーの皆さん、自動化の旅をAnsible
はじめに Visual Studio Code（以下、VS Code）で Ansible の Playbook を書く時に、私が便利に利用させてもらっている拡張をご紹介します。 「自分は Windows で VS Code 使ってて、Ansible は SSH 先の Linux だから関係ないや。」という方も、最後の「Remote Developement」まで見ていただけると幸いです。手元が Windows でも通用します。 動作確認環境: VS Code 1.38.1 その前に・・標準ではどんな感じに？ VS Code では特に拡張を入れなくてもある程度は Playbook が書きやすいようになっています。 具体的には Playbook の拡張子を .yml または .yaml にするこことで、言語として YAML が選択されます。 これにより、シンタックスハイライトが効くようになり、
Ansible TowerとGitLabを入れてどういう運用を実現したかったかを簡単な例と一緒にまとめてみようと思います。（自分への備忘録含め） ここに書くこと ここでは Ansible Night in Tokyo 2019.04 で話をした中のLinuxサーバ運用編ついてもう少し詳細に書いてみようと思います。 ここで言う運用のイメージは 定常運用 です。 Excel運用課題の振り返り ファイルの管理が「yyyymmdd」などファイルの末尾で管理されていたりしてどれが最新か分かりにくい 手順書の変更履歴が表で管理されていて文字しか書いていなくて before after が分かりにくい レビューシートが手順書ごとに出来ていく、これも日付管理されたり文字で書いてあるだけなので実際にどう修正したのかが残らない 手順書フォーマットは統一されているが、人によって手順の内容がバラバラ 「このファイ
エンジニアの今川(@ug23_)です。 本番環境サーバのユーザ管理、みなさんはどうしていますか？ みんなで同じユーザ・同じ鍵を使う 入社・退職時にはインフラ担当者がユーザ追加・削除する という感じのレガシーなやり方をしてしまいがちですよね。 全員で同じユーザを使う運用は入社時はとってもラクですが、退職者がでた時、漏洩したかもしれない時、鍵を変えて全員に伝えて…と、無駄が多いですし、サーバ上での動作を監査できるようにするという意味でも、全員がそれぞれ自分のユーザでログインできるようにしておきたいです。 また、人に依存しないしくみにしたいですね。「○○さん休みだからユーザ作れないね」というのはナシにしたいです。 ということでAnsible Playbookでユーザ作成をはじめ、 ユーザの削除 や sudo権限をなくす処理を実行できるようにし、冪等なユーザ管理ができるPlaybookを公開するこ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、Ansible Advent Calendar 2018 の 7 日目の記事です。 ソフトウェアは変更に弱く壊れやすいものです。Ansible の Playbook も例外ではありません。本記事では Rust の生みの親である Graydon Hoare 氏のこちらの記事を参考に、Configuration as Code の開発プロセスに CI を導入した結果について述べます。 The Not Rocket Science Rule Of Software Engineering: automatically mainta
シンジです。sshを利用してサーバーへアクセスする際、IDとパスワードでrootにダイレクトアクセスさせてるケースもままあるでしょうが、監査も通らないし乗っ取りリスク高すぎ問題なので辞めたいところです。クラウドを日常的に利用する方々の場合、通常は証明書認証によってサーバーログインを行っていると思います。証明書ファイルが次々と増えていく問題、証明書ファイルを手に入れれば多くの人がサーバーにログインできちゃう問題は目をつぶるしかないのか。 そこでエンプラなどでは、「踏み台サーバー」を作って、そこでアクセス権限をコントロールすることで、サーバーログインへの統制を図るわけですが、第一踏み台から第二踏み台へそして第三踏み台とかいう絶望も現実的に存在している実状です。そもそも、エンプラが踏み台サーバーを自前で作るわけがなく、そういう製品を購入して作ってもらう、はい数千万円、保守費毎年よろしくみたいな世
Ansible getting started Getting started with Ansible Getting started with Execution Environments Installation, Upgrade & Configuration Installation Guide Ansible Porting Guides Using Ansible Building Ansible inventories Using Ansible command line tools Using Ansible playbooks Protecting sensitive data with Ansible vault Using Ansible modules and plugins Using Ansible collections Using Ansible on W
Ansible(Ansible TowerやAWX)を本番に導入するために色々とやった事や思った事を簡単にまとめてみました。 Ansible初めて聞いて見て感じたこと Ansibleを最初見て聞いた時に感じた事は Zabbix に似ていると感じた。 もちろん、監視という意味ではなく 自由な感じにいじれる という部分。 個人的にZabbixの魅力は インフラ基盤に捉われない監視システム が作れるところだと思っている。 とても自由度が高く簡単なスクリプトやプログラムを書いて連携させれば標準以上の監視や自動化など構築できる。 Ansibleも同じようにモジュールも自作できて組み込めて普通に動いてしまう。 自分が参画してるプロジェクトでは、巷の運用・監視パッケージ製品では対応できない部分が多々あり作り込む必要があった。 プロジェクトではVMwareやLinuxを使用しており、Ansible標準でL
{ "locations": [ {"name": "Seattle", "state": "WA"}, {"name": "New York", "state": "NY"}, {"name": "Bellevue", "state": "WA"}, {"name": "Olympia", "state": "WA"} ] } Result Try it Out! Enter an expression in the search box to see JMESPath in action. The expression is evaluated against the JSON data and the result is shown in the result pane. To learn more about JMESPath, check out the JMESPath Tut
Introduction Documentation overview Quick start DebOps installation Getting Started with DebOps Configuration Frequently Asked Questions User Manual DebOps for Ansible users Project directories DebOps CLI Global role variables Custom environment variables Playbooks Universal Configuration DNS Configuration Roles (by category) Roles (index) Admin Recipes Using Linux containers Custom services and t
はじめに Ansible 1.7よりWindowsの操作ができるようになったので、実施するための準備を書き出してみる。 （2015-01-18: 現状に合わせて大きく書き直した） （2015-03-27: 「Ansible 1.9.0.1を使用する場合の追加作業」を追加） （2015-04-29: 1.9.1で「Ansible 1.9.0.1を使用する場合の追加作業」が解決されたため、文章を修正） （2016-02-27: やっと時間が取れたので遅ればせながら文章を2.0に対応） （2016-04-17: ネットワークプロファイルがパブリックでも利用できるようになっていたのとansible_winrm_*が1.9.5にバックポートされていたのに対応） （2017-06-03: 2.3.1でpython 3でも動作するようになった） 今回の環境 最初に試した段階では以下の通り： 操作されるW
1000台同時SSHオペレーション環境を構築するにあたって、手元のローカル環境の性能限界の問題を解決するために、オペレーションサーバをSSHクライアントとすることによりSSH実行を高速化した。実行環境としてDocker、レジストリとしてAmazon ECR(EC2 Container Registry)を用いて、ローカル環境とオペレーションサーバ環境を統一することにより、オペレーションサーバの構成管理の手間を削減した。 はじめに システム構成 実装上の工夫 オペレーションサーバ越しのroot権限実行 rawモジュールとscriptモジュールのみの利用 Ansibleの実行ログのGit保存 まとめと今後の課題 はじめに 3年前に Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ という記事を書いた。 この記事では、ホストインベントリと
https://ljstudy.connpass.com/event/71037/ でのLT資料です。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「Ansible Advent Calendar 2017 」の12/7(木)の記事です。 この記事では、私が業務でAnsibleを使っている中で得た、教訓となるようなポイントを紹介していきます。普段から使ってる人からしたら当たり前じゃん！って思うことも多々書いてあると思いますが、暖かい目で見守っていただけたら幸いです。 1. 対象がAnsibleで管理できる状態か調べておこう Ansibleといえばお手軽に実行できるのが1つの魅力です。 (例外は有るが)基本的な要件として、Ansible実行サーバと実行対象サーバに Pyth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く