こんにちは。@jedipunkz です。 今回は StackStorm (https://stackstorm.com/) というイベントドリブンオートメーションツールを使ってみましたので 紹介したいと思います。 クラウドとプロビジョニングツールの登場で昨今はエンジニアがほぼ全ての操作を自動化出来るようになりました。 ですが監視についてはどうでしょうか？監視システムを自動で構築することが出来ても障害発生時に対応を行う のは手動になっていませんでしょうか。もちろんクラスタ組んでいれば大抵のアラートは放置出来ますが、クラスタ を組むことが出来ないような箇所はクラウドを使ってもどうしても出てきます。 そこで登場するのが今回紹介する StackStorm のようなツールかなぁと考えるようになりました。 インストール インストール手順は下記の URL にあります。 https://docs.stackstorm.com/install/index.html 自分は CentOS7 を使ったので下記のワンライナーでインストールできました。 password は任意のものを入れてください。 curl -sSL https://stackstorm.com/packages/install.sh | bash -s -- --user=st2admin --password=foo MongoDB, postgreSQL が依存してインストールされます。 80番ポートで下記のような WEB UI も起動します。 StackStorm の基本 基本を知るために幾つかの要素について説明していきます。 まず CLI で操作するために TOKEN を取得して環境変数にセットする必要があります。 上記で設定したユーザ名・パスワードを入力してください。 export ST2_AUTH_TOKEN=`st2 auth -t -p foo st2admin` Action Action はイベントが発生した際に実行できるアクションになります。早速アクションの一覧を取得してみましょう。 $ st2 action list +---------------------------------+---------+-------------------------------------------------------------+ | ref | pack | description | +---------------------------------+---------+-------------------------------------------------------------+ | chatops.format_execution_result | chatops | Format an execution result for chatops | | chatops.post_message | chatops | Post a message to stream for chatops | | chatops.post_result | chatops | Post an execution result to stream for chatops | <省略> | core.http | core | Action that performs an http request. | | core.local | core | Action that executes an arbitrary Linux command on the | | | | localhost. | | core.local_sudo | core | Action that executes an arbitrary Linux command on the | | | | localhost. | | core.remote | core | Action to execute arbitrary linux command remotely. | | core.remote_sudo | core | Action to execute arbitrary linux command remotely. | | core.sendmail | core | This sends an email | | core.windows_cmd | core | Action to execute arbitrary Windows command remotely. | <省略> | linux.cp | linux | Copy file(s) | | linux.diag_loadavg | linux | Diagnostic workflow for high load alert | | linux.dig | linux | Dig action | <省略> | st2.kv.get | st2 | Get value from datastore | | st2.kv.set | st2 | Set value in datastore | +---------------------------------+---------+-------------------------------------------------------------+ 上記のように Linux のコマンドや ChatOps, HTTP でクエリを投げるもの、Key Value の読み書きを行うモノまであります。 上記はかなり咲楽して貼り付けたので本来はもっと沢山のアクションがあります。 ...

こんにちは。@jedipunkz です。 今回は DC/OS (https://dcos.io/) を Vagrant を使って構築し評価してみようと思います。 DC/OS はその名の通りデータセンタ OS として利用されることを期待され開発された OS で内部で Docker と Mesos が稼働しています。 一昔前に Mesos のマルチノード構成は構築したことあったのですが、DC/OS はデプロイ方法が全く変わっていました。 はじめに想定する構成から説明していきます。 想定する構成 本来 DC/OS は public, private ネットワーク構成ですが利用するレポジトリではこのような構成が想定されていました。 +----+ +----+ +----+ +------+ | m1 | | a1 | | p1 | | boot | +----+ +----+ +----+ +------+ | | | | +------+------+------+--------- 192.168.65/24 各ノードは下記の通り動作します。 m1 : Mesos マスタ, Marathon a1 : Mesos スレーブ(Private Agent) p1 : Mesos スレーブ(Public Agent) boot : DC/OS インストレーションノード 前提の環境 Vagrant が動作するマシンであれば問題ないと思いますが私は下記の構成で利用しました。 比較的たくさんのマシンリソースを使うのでメモリ 8GB はほしいところです。 ...

こんにちは。@jedipunkz です。 Influxdb が Influxdata (https://influxdata.com/) として生まれ変わり公式の メトリクス送信エージェント Telegraf と可視化ツール Chronograf をリリースしたので 使ってみました。 3つのツールの役割は下記のとおりです。 Chronograf : 可視化ツール, Grafana 相当のソフトウェアです Telegraf : メトリクス情報を Influxdb に送信するエージェント Influxdb : メトリクス情報を格納する時系列データベース 以前に cAdvisor, influxdb, grafana を使って Docker コンテナのメトリクスを可視 化する記事を書きましたが telegraf を使うとサーバ情報と合わせて Docker コンテナ のメトリクスも influxdb に送信することが出来ます。個人的にはそのコンテナ情報の 扱いもサーバ情報と同様に扱ってくれる点に期待しつつ、評価してみました。 今回の環境 今回は Ubuntu 15.04 vivid64 を使ってテストしています。 influxdb をインストールして起動 最新リリース版の deb パッケージが用意されていたのでこれを使いました。 wget http://influxdb.s3.amazonaws.com/influxdb_0.9.5.1_amd64.deb sudo dpkg -i influxdb_0.9.5.1_amd64.deb sudo service influxdb start telegraf のインストールと起動 こちらも deb パッケージで。 wget http://get.influxdb.org/telegraf/telegraf_0.2.4_amd64.deb sudo dpkg -i telegraf_0.2.4_amd64.deb コンフィギュレーションですが今回は CPU, Disk, Net, Docker のメトリクス情報を送 信するようにしました。 ...

こんにちは。@jedipunkz です。 今回は Weave というコンテナ間のネットワークを提供してくれる Docker のネットワークプラ グインを使ってみました。下記のような沢山の機能があるようです。 Fast Data Path Docker Network Plugin Security Dynamic Netwrok Attachment Service Binding Fault Tolerance etc … この記事では上から幾つか抜粋して、Weave ってどのように動かせるのか？を解説します。 そこから Weave が一体ナニモノなのか理解できればなぁと思います。 Vagrant を使った構成 この記事では下記の構成を作って色々と試していきます。使う技術は Vagrant Docker Weave です。 +---------------------+ +---------------------+ +---------------------+ | docker container a1 | | docker container a2 | | docker container a3 | +---------------------+ +---------------------+ +---------------------+ | vagrant host 1 | | vagrant host 2 | | vagrant host 3 | +---------------------+-+---------------------+-+---------------------+ | Mac or Windows | +---------------------------------------------------------------------+ 特徴としては ...

こんにちは。@jedipunkz です。 最近、業務で CircleCI を扱っていて、だいぶ “出来ること・出来ないこと” や “出来ないこと に対する回避方法” 等のノウハウが若干溜まってきたので共有したいなと思います。 この記事の前提… ここでは CodeDeploy の設定方法や、CircleCIの設定方法等に関しては記述しませ ん。あくまで、Tips 的な内容にしています。また運用する上で想定できる問題点と、 それの回避方法等…についてまとめています。 CirlceCI と併用するサービスについて CircleCI は Github と連携してレポジトリ内の制御ファイル circle.yml に従ってテ スト・ビルド・デプロイを実施してくれる CI サービスです。ただ CircleCI は自分た ちの管理しているシステム外にあるので、AWS VPC を用いていると VPC 内のプライベー トインスタンスにデプロイするのが難しいです。プロキシ挟んで・・ってことは出来そ うですがプロキシの運用もしたくない、AWS のインフラリソースに任せることが出来た らインスタンス・インスタンス上のミドルウェアを運用しなくて済むので運用コストが 省けそう。ってことで AWS S3 (https://aws.amazon.com/jp/s3/) AWS CodeDeploy (https://aws.amazon.com/jp/codedeploy/) を併用することを考えました。 S3 は皆さんご存知のオブジェクトストレージです。CircleCI 用のバケットを作って、 ビルドした結果を格納します。私の務めている会社ではプログラミング言語として Scala を用いているので SBT というツールを使ってビルドします。その結果もバージョ ニングしつつ S3 バケットに格納できれば、万が一問題が発生した時にバイナリ毎切り 戻すことが出来そうです。 また CodeDeploy は EC2 インスタンス・またオンプレのインスタンスへコードのデプ ロイが可能になるサービスです。東京リージョンでは 2015/08 から利用が可能になり ました。これの便利なところは CircleCI 等の CI サービスから簡単に叩けて、VPC 内 のインスタンスに対してもデプロイが可能なところです。 ...

こんにちは。@jedipunkz です。 今回は Docker ネタです。Docker 導入するにしても監視はどうする？という話になる と思うのですが、各 Monitoring as a Service を使うにしてもエージェント入れない といけないしお金掛かることもあるし..で、調べていたら cAdvisor というキーワード が出てきました。今回は cAdvisor を使ってコンテナの監視が出来ないか、について書 いていきたいと想います。 cAdvisor とは ? cAdvisor は Kubernates で用いられているコンポーネントで単体でも利用可能とのこ と。Google が開発しています。また Docker コンテナの監視においてこの cAdvisor は一般化しつつあるようです。 https://github.com/google/cadvisor 収集したメトリクスの保存 cAdvisor 自体も Docker で起動して、同ホスト上に起動している Docker コンテナの リソースをモニタリングしてくれます。そのメトリクスデータは幾つかの DB に保存出 来るのですが、そのうちの一つが influxDB です。influxDB は時系列データベースで す。システムのメトリクスデータを収めるのにちょうどいいデータベースになります。 https://influxdb.com/ DB に収めたメトリクスの可視化 influxDB に収めたメトリクスデータを可視化するのが Grafana です。Grafana のデー タソースは influxDB の他にも幾つかあり Elasticsearch, KairosDB, Graphite 等が それです。 http://grafana.org/ では早速試してみましょう。 前提の環境 今回は Vagrant を使います。また Vagrant 上で上記の3つのソフトウェアを Docker で稼働します。またどうせなので docker-compose を使って3つのコンテナを一斉に立 ち上げてみましょう。 ...

こんにちは。@jedipunkz です。 前回 OpenStack Kilo のオールインワン構成を Chef-Zero を使ってデプロイする方法 を書きましたが、複数台構成についても調べたので結果をまとめていきます。 使うのは openstack/openstack-chef-repo です。下記の URL にあります。 https://github.com/openstack/openstack-chef-repo この中に Vagrant を使ったファイルが存在しますが、実機でのデプロイには全く役に 立ちません。自分で Environment ファイルを作成する必要があります。今回は前提の 構成を作って、それに合わせた Environment ファイルを記します。ほぼスタンダード な構成にしましたので、自分の環境に合わせて修正するのも比較的簡単だと想います。 参考にしてください。 今回は knife-zero を使ってデプロイします。Chef サーバが必要なく、knife-zero を 使うホスト上のオンメモリで Chef サーバが稼働するので準備がほとんど必要ありません。 早速ですが、構成と準備・そしてデプロイ作業を記していきます。 前提の構成 +------------+ | GW Router | +--+------------+ | | | +--------------+--------------+---------------------------- public network | | eth0 | eth0 | +------------+ +------------+ +------------+ +------------+ | | Controller | | Network | | Compute | | Knife-Zero | | +------------+ +-------+----+ +------+-----+ +------------+ | | eth1 | eth1 | | eth1 | | eth1 +--+--------------+-------)------+------)-------+------------- api/management network | eth2 | eth2 +-------------+--------------------- guest network 特徴としては… ...

こんにちは。@jedipunkz です。 久々に openstack-chef-repo を覗いてみたら ‘openstack/openstack-chef-repo’ とし て公開されていました。今まで stackforge 側で管理されていましたが ‘openstack’ の方に移動したようです。 https://github.com/openstack/openstack-chef-repo 結構安定してきているのかな？と想い、ちらっと試したのですが案の定、簡単に動作さ せることが出来ました。 今回はこのレポジトリを使ってオールインワン構成の OpenStack Kilo を作る方法をま とめていきます。 前提の構成 このレポジトリは Vagrant で OpenStack を作るための環境一式が最初から用意されて いますが、Vagrant では本番環境を作ることは出来ないため、Ubuntu ホストを前提と した記述に差し替えて説明していきます。前提にする構成は下記のとおりです。 Uuntu Linux 14.04 x 1 台 ネットワークインターフェース x 3 つ eth0 : External ネットワーク用 eth1 : Internal (API, Manage) ネットワーク用 eth2 : Guest ネットワーク用 特徴としては上記なのですが、eth2 に関してはオールインワンなので必ずしも必要と いうわけではありません。複数台構成を考慮した設定になっています。 前提のIP アドレス この記事では下記の IP アドレスを前提にします。お手持ちの環境の IP アドレスが違 い場合はそれに合わせて後に示す json ファイルを変更してください。 10.0.1.10 (eth0) : external ネットワーク 10.0.2.10 (eth1) : api/management ネットワーク 10.0.3.10 (eth2) : Guest ネットワーク 事前の準備 事前に対象ホスト (OpenStack ホスト) に chef, berkshelf をインストールします。 ...