インフラ自動化ツール「Ansible 2.3」リリース。SSHのコネクションを使い続けるPersistent Connectionでタスク処理が高速に － Publickey
インフラ自動化ツール「Ansible 2.3」リリース。SSHのコネクションを使い続けるPersistent Connectionでタスク処理が高速に オープンソースで開発されているインフラ自動化ツール「Ansible」の最新バージョン、「Ansible 2.3」正式版がリリースされました。 インフラ自動化ツールにはChefやPuppetなどよく知られるオープンソースソフトウェアが他にも存在しますが、Ansibleの特徴はサーバやネットワーク機器にあらかじめエージェントなどを導入することなく利用できる点にあります。 エージェントを使うことなく多数のサーバなどに対して設定やソフトウェア導入などの構成管理を行う仕組みとしてAnsibleではおもにSSHを用いています。 Ansibleのこれまでのバージョンでは、ネットワーク機器に対して構成管理のタスクを1つ実行するたびにSSHの接続を開始、終了
Ansible 2.0リリース！ - Qiita
つい先ほど、待ちに待ったAnsible 2.0がリリース、GAされました。 Ansible 2.0 - Over the Hills and Far Away 作者の jimi-c こと James Cammarata のリリース記事があるので早速訳してみたいと思います。 (正確さについてはお察しなので、イミフなところは原文と併せてご確認ください) ANSIBLE 2.0 HAS ARRIVED (追記) 2016年1月22日現在、ソースをそのまま使う他には pip, epel-testing を使うと Ansible 2.0 を簡単にインストールすることができます。 pip : pip install ansible epel-testing : yum install ansible --enablerepo=epel-testing ANSIBLE 2.0 HAS ARRIVED 1
Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌
Ansibleのディレクトリ構成を決める際、プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定を変更する方法でしっくり来るものを思いつかず、どうしたものかと悩んでいたのですが、今日見つけたブログ記事でそれもスッキリ解消したのでメモっておきます。 結論 まず結論を。プロダクション環境、ステージング環境、開発環境といった環境ごとに異なる設定する場合は、以下のように対応するのが良さそうです。 ディレクトリ構成は、公式ドキュメントに従う。 Best Practices — Ansible Documentation プロダクション、ステージング、開発など、ステージごとの変数切替は以下のブログを参考に、"group_vars"を利用して行う。 インベントリファイルの中に、"[production:children]"のようなグループすべてが属するグループを作ってしまい、そのグ
vagrant-serverspec で TDD ライクにサーバ構築を行う
Shin x blog Advent Calendar 2013 の 24 日目です。 先日リリースされた vagrant-serverspec を使って、テストドリブンなサーバ構築を行ってみました。 vagrant-serverspec は、サーバ、インフラの状態をテストするツール serverspec を Vagrant のプロビジョナとして実行できるプラグインです。これを使うことで、vagrant コマンドから、serverspec のテストを実行することができます。 詳しくは、@ryuzee さんの下記エントリを参照して下さい。 vagrant-serverspecを使ってプロビジョニング結果をテストする | Ryuzee.com 仕様 今回構築するサーバの仕様は下記です。PHP 5.5.x をインストールして、ビルトインサーバを起動するというものです。（※ちなみにビルトインサーバ
IT勉強会を探しやすくするWebアプリケーション『俺の勉カレ』をリニュアールしました
2013-2014年の年末年始の連休を利用して開発したIT勉強会を網羅したアプリケーション『俺の勉カレ』を全面リニュアールしました！ 見た目はちょこっとしか変わっていないように見えますが、実は裏側はほぼすべて作りなおしましたw 今回はリニュアールの目的と、リニュアールでどんな技術を使ったのかを中心に紹介していきます。 🎉 リニュアールの目的 初期構築したアプリケーションでは、Microservicesのまねことみたいなことを夢想していて単機能ごとに6個のアプリケーションで構成されていました。 しかもかなりの運用工数がかかるような謎設計で、昔の自分の頭のなかがいかにお花畑だったかを思い知らされます。 こういった失敗を踏まえて、 * できるだけ運用が楽な仕組みにする * 運用工数を最小化できるような構成にする * 自分が興味のある勉強会を見つけやすくする を基本コンセプトに、裏側をほぼすべて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
