Ansibleトレイルマップは、Ansibleを学習し活用する過程を旅になぞらえてお伝えする手引書です。道に迷うことなく歩みを進め、Ansibleの世界を満喫しつつ経験を積み、楽しみながら自らの糧にできることを目指しています。 IT運営の自動化は、 ITが生まれた時から多くのエンジニアの悩みの種でした。これからも悩みの種であり続けるでしょう。Ansibleは、技術的な創意工夫が必要な領域を少なくし、誰もが複雑なデプロイを簡単に扱えるようにするために生まれました。そして、開発や運用、サーバやネットワークといったチーム横断の自動化パイプラインの共通言語となり、お互いが協力し改善するための基礎となります。 Ansibleの初学者の皆さん、Ansibleを共通言語として組織に浸透させたいTechリードの皆さん、自動化を次の段階に進めたいと考えているチームリーダーの皆さん、自動化の旅をAnsible

以前はVagrantを使ってansibleのテスト環境は用意していたんだけど、 vagrantはsnapshotが取れる利点がありつつも、VMを使うのでちょっとというかそれなりに遅くて、 何度も実行するansibleのテスト環境にはちょっと不便だなーと思っていたのですが、 最近Dockerを使ってsshdを起動するだけの環境を用意すれば簡単にテスト環境が作れて便利だったので書いておきます。 Dockerfileを書く ansibleを流す対象のイメージは Dockerfile の FROM に書いておけばよくて、 CentOSとかDebianとか好きなOSを選べばいいと思います。 Dockerfileを置いたディレクトリに id_rsa.pub を置いておくと authorized_keys にコピーされるというソリューションです。 FROM amazonlinux:latest MAIN

Terraform + CircleCI 2.0 + Ansible で作る CD (Continuous Delivery) 環境CircleCIAnsibleTerraformCircleCI2.0 初めに これは 第2のドワンゴ Advent Calendar 2017 24日目の記事です。 この記事では、Terraform + CircleCI 2.0 + Ansible を使ったCD(Continuous Delivery) 環境構築方法について解説します。 CD(Continuous Delivery) とは CDと略されますが、Continuous Delivery と Continuous Deployment と２つの意味で使われることが多いです。 両者の違いについては、上記のURLで解説されているため、説明は割愛しますが、以下継続的デリバリーの略語としてCDを使用します

ansibleを使い始めたので覚えておきたいことを個人的にメモ。 尚、本家のドキュメントしか情報ソースにしていません。本家のドキュメントは素晴らしく優秀です。 http://docs.ansible.com/ タスクのinclude includeでタスクを一纏めにして外部ファイルに書ける。これは、whenを付けてある条件時にのみ実行が可能。

1000台同時SSHオペレーション環境を構築するにあたって、手元のローカル環境の性能限界の問題を解決するために、オペレーションサーバをSSHクライアントとすることによりSSH実行を高速化した。実行環境としてDocker、レジストリとしてAmazon ECR(EC2 Container Registry)を用いて、ローカル環境とオペレーションサーバ環境を統一することにより、オペレーションサーバの構成管理の手間を削減した。 はじめに システム構成 実装上の工夫 オペレーションサーバ越しのroot権限実行 rawモジュールとscriptモジュールのみの利用 Ansibleの実行ログのGit保存 まとめと今後の課題 はじめに 3年前に Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ という記事を書いた。 この記事では、ホストインベントリと

2021年3月、FastHnadle2として、作り直しました。 https://github.com/kuritaka/fasthandle2 Python Fabricを使うのではなく、fhコマンドを自作しています。 FastHandleとは FastHandleは、サーバ構築、サーバテストのオペレーションをサポートするツールです。 サーバ構築をより早く、より正確にすることを目指して作っています。 自動化のために、Fabricコマンド、Expectコマンドなどを利用しています。 現状、こんな感じにしようという枠組みはできましたが、まだまだ作成途中です。動かないこともあると思いますが、少しずつ増やして、テストをしていきます。(2018/01/11) 今はLinuxサーバ向けですが、Windowsサーバも検討していきたいと考えています。(2018/01/11) WindowsやVMwareや

効率的なシステム構築と運用をめざすためのツールとして 関連記事:ansibleのコマンド実行時の冪等性を簡単にするためのモジュール http://qiita.com/suicacello/items/fcab058b77b9460f4b27 1. はじめに 筆者の昔話 サーバ構築職人の朝は早い。 ◯◯社で使われるサーバは、職人が一つ一つ手作業で構築している。 そのため日に数台が限度だという。 「まぁ好きではじめた仕事ですから」 最近は手順が複雑だと愚痴をこぼした。職人の一日は、 まず手順書の入念なチェックから始まる。 「一つ一つ仕上がりに微妙な差が出る。機械では出来ない」 さりげなく語るが、そこには年季と、確たる信念が見えた http://www.slideshare.net/akagisho/ansible-52618704 Ansible ではじめるインフラのコード化入門 *これは美談

Linux女子部 「Fedora最新技術情報＆Systemd勉強会」 http://connpass.com/event/3859/ で使用した資料です。 変更履歴 2013/11/04 ver1.0 初版 2013/11/05 ver1.1 誤植修正、少し追記 2013/11/06 ver1.2 daemon-reload,mask,テンプレート機能を追記 2013/11/12 ver1.3 User/Groupオプションの説明追加 2013/11/24 ver1.4 誤植修正 2014/05/05 ver1.5 imjournalモジュールの説明追加

連載の第6回では、Ansibleのテストにおける考え方や方法論を解説していきます。 Ansibleにおいてテストは必要か テストは、対象のプログラムが仕様通りに正しく動いていることの確認や、バグを発見するために必要な工程です。適切なテストをすることにより、対象物（システム）の品質を担保できます。では、Ansibleのような構成管理ツールではどうでしょうか。従来の構成管理の手法としてはシェルスクリプトなどを使い、ミドルウェアのインストールおよびサービスの起動を行っていました。シェルスクリプトはプログラムなので、仕様通りに構成管理が行われていることの確認としてテストをすることがあります。それに対してAnsibleでは、プログラムを使用せずにyaml形式のPlaybookという設定ファイルをユーザーが記述します。そして、そのPlaybookに基づいてAnsible内部のPythonで記述されたプ

運用監視をはじめ、多くの企業が取り入れているOSS（オープンソースソフトウェア）。目的に応じて最適なものを選択し、うまく使いこなせば強力な武器となるが、それができなければかえって手間や混乱の原因にもなりかねない。本連載では注目のOSSをピックアップして実際に検証し、基本的な優位性、劣位性を明確化。ぜひOSSを選ぶ際の参考にしてほしい。

Tokyo Otaku Mode Inc. の社内勉強会で発表した内容です

AnsibleはChefやPuppetと同様に冪等性（べきとうせい）に配慮した構成管理ツールです。YAMLで記述したプレイブックのファイルが1つあれば動き、SSHさえ繋がれば対象サーバーにクライアントは不要、といったシンプルさが支持され、近年ユーザーを増やしています。 そのシンプルさは仮想マシンを利用した開発環境の構築にもうってつけに思えます。と言うことで今回はAnsibleをVagrantのプロビジョナーに使って開発環境を構築しました。 Ansibleの公式サイト Ansibleのインストール Ansibleはコントロールマシンに入っていればよく、セットアップ対象のサーバにはAnsibleのクライアントなどは不要です。SSHで接続さえできればOKです。今回のケースでは開発マシンのMacをコントロールマシンとし、Vagrantによる仮想マシンをセットアップ対象とします。 Ansible自体

『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application

03/29/2015 Developers.IO 2015 http://devio2015.classmethod.jp/ Packer / Ansible / CloudFormation / AWS

3/29(日)に開催されたDevelopers.IO 2015 Developer Dayにて、「Ansible + Packer + CloudFormationでらくらく構築・運用」というタイトルで話をしてきました。 スライド スライドはSlideshareにて公開しています。 内容について スライドの内容はここ半年でPacker + Ansible + CloudFormationでのAWS基盤構築に取り組んだ感想や効果的な使い方について重点をおきました。ですが、見なおしてみるとPackerの利用に関わらずAWS上でシステムを構築する上で重要なことがたくさん入ったかな、と思っています。例えばCloud DIの話とか、Auto Healingの話などですね。API経由でインフラのリソースを扱えるAWSにおいてはこれまでも様々なデザインパターンが考えられてきましたが、これを上手く組み合わ

渡辺です。 自動化にはロマンがありますが、ロマンを求めすぎると現実に凹みます。 今回はAuto ScalingとAnsibleを混ぜてみました。 Auto Scalingとは？ Auto Scalingは、一言で言えばEC2インスタンスを自動拡張/縮退を実現する機能です。 Auto Scalingを活用する事で耐障害性や耐障害性を高めることができます。 また、処理能力を必要に応じて増加させることもできるのも魅力のひとつです。 Auto Scalingは非常に便利で強力な機能ですが、どんなシステムでも簡単に利用できるとは限りません。 インスタンスが自動的に起動したり破棄されたりするため、インスタンスが有効になるまでの手順が自動化することが必要です。 また、インスタンスは使い捨てできるような状態、すなわちステートレスに設計・構築しなければなりません。 これらの注意点については、AutoScal