サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
セキュリティ
qiita.com/yacchin1205
去年書いた Jupyter+Ansibleを使ったインフラ運用の考え方2017 では、Jupyter+Ansibleを使ったインフラ運用の考え方(Literate Computing for Reproducible Infrastructure: LC4RI)について説明しました。 今回は、LC4RIを使ったインフラ運用をどのように始めたらよいか?という観点でまとめてみたいと思います。 何が問題なのか? 「JupyterとAnsibleを使って賢くインフラ運用できる」として、 どこに/どうやってそのJupyter環境を構築すべきか? どうやってJupyterから(Ansibleを介して)操作対象マシンを操作できるようにすべきか? といった、LC4RIを実施可能な(Jupyter+Ansible環境を含んだ)インフラ構成のパターンとその構成手順をまだまだ明らかにできていないなという問題意識
去年のAdvent CalendarでJupyter+Ansibleを使ったインフラ運用の下準備と書かせていただいたわけですが、今年も1年通してJupyterを使った運用をさせていただきつつ、組織外の方々もこのやり方に巻き込ませていただいたりしていました。 で、この巻き込ませていただく取り組みの中で、Jupyter+Ansibleを使ったインフラ運用の何が伝わりずらい/誤解を招きやすいのかがなんとなく識別できてきた気がするので、ここはあえて(懲りずに)今年も同じタイトルで書かせていただきたいと思った次第です。 何が問題なのか? これまでの記事は道具から入ってしまっていて、問題意識がイマイチ伝わりづらい感じがしていました。ので、今年はまずは問題意識から。 Automation の罠 まず、あまりたくさんの仕事はしたくありません。人手も足りないし。そのくせなんだかクラウドが自然なものとして定着
おうちハック Advent Calendar 22日目の記事です。ああもう23日・・・遅くなり申し訳ございません。 昨年もおうちハックAdvent Calendarに参加させていただいたわけですが、昨年からはじめたMQTTでIRKitやPhilips Hueの状況確認・操作を集約システムも動き始めて1年が経ちました。1年動かす中で、おうちハックで作ったものを安定して動かしつつ、新しいおもちゃをどう取り込んでいくかが個人的課題の一つとなってきました。 今回は、MESHをネタに、めちゃくちゃ面白そうだなあと思いつつも、買うべきか悩んで周回遅れになった背景、MESHを買ってどう遊んでいるかをざっとまとめてみたいと思います。 おうちハックの醍醐味・課題 昨年作ったこのMQTTベースのおうち管理システムは、部屋の照明一式(赤外線式の蛍光灯とHue)のまとめての制御にけっこう便利でして、意外と奥さんが
Advent Calendar、遅刻してしまったわけですが・・・ 今年も、去年から引き続き国立情報学研究所さんにてJupyterとAnsibleを使ってインフラ運用をやらせていただきました。 本来、Jupyterはデータ分析のための道具として生まれたわけですが、文章+コードの形式で、Notebookとして実行内容を記述、実行して残しておくというやり方は、データ分析以外の場面でも役に立つなあ、としみじみ感じています。そんなわけで、Jupyter+Ansible+インフラ運用なネタを。 この記事の内容 NIIクラウド運用チームにおけるインフラ運用のコンセプトについては Jupyter Notebookを用いた文芸的インフラ運用のススメ にて詳しく説明されているのでそちらを参照していただくとして、インフラ運用の"お手本(の一例)"Notebookとして、以下のようなNotebookを公開してみて
今年はPepperくんとお仕事をする機会をいただきまして、なかなかおもしろい経験をさせていただきました。 Pepperくんはハードウェア的にも、ソフトウェア的にも面白いのですが、いかんせんまだ数が少ない。アルデバラン・アトリエ秋葉原にはPepperくんが数体いるのですが、実験したい人の数に比べると足りない感は否めないわけです。(あと近隣ではないとかでなかなか足を運べない方も多いのでないかと) そこで、バーチャルロボットでできることはバーチャルロボットで極力やっておきたい、ということで今回はPython SDKをバーチャルロボットでさわってみたのでそのメモ。 Python SDK(NAOqi for Python) Python SDKによるsay hello (Pepper TechFes技術セッション)で説明があるとおり、Pepperくんに対しては ALProxy クラスを介してPepp
IRKitやPhilips Hueのようなスマートな感じのデバイスを日常的に使っているのですが、とりあえずで標準アプリを使ってこれらを使っています。こうしていると、やはりデバイスごとに複数のアプリを使い分けるのが面倒くさくなり、「なんか自宅用のアプリを作るかなあ」という気持ちになってきます。 これらのデバイスはAPIも非常にわかりやすく、ライブラリもすぐに見つかり非常によい感じです。ただ、デバイスの発見、現在の状態をポーリングしてチェックなど、状態管理的なコードを書かなければならない部分がどうしても出てきて(これはやむを得ない部分ではありますが)、ちょっと面倒だなという気持ちになります。 そんな中ここ最近よく聞くようになったMQTTを思い出しました。 Pepperのお仕事なども通じて、MQTTのようなPublish/Subscribeモデルは、こういったデバイスが散在している状況を束ねてい
サーバを数十台程度扱うようなお仕事も、Ansibleの力で複数台まとめて操作をおこなったり、Fluentdの力で全体の情報集約をできたりと、とても楽になってきました。 こういった自動化を考えていく中で少し手間がかかってくれるのがWindows Server。 Linuxで統一したいところではあるわけですが、どうしても用途によりWindows Serverで構築したほうが楽な場面があり、数台のWindows Serverがまぎれこんだりして非常に悩ましいところがあります。 そんなわけで今回は、Windows Serverのイベントログを集約するようなソフトウェアのインストール・設定を、Ansibleを使って実施することを試してみました。で、割と簡単にできそうだという感触が得られたのでそのメモ。 関連する技術 AnsibleによるWindowsの操作 Ansibleは基本的には、対象サーバにS
Windows上で軽くスクリプトでまとめて何かしたい、みたいなときにPowerShellさんが変態チックで面白かったのでそのメモ。 やりたいこと PowerPointで作った資料をまとめて画像化したい。画像化したものは余白でトリミングして適当なマージンつけてとかしたい。 はじめっからPowerPointで作らず別のツールで作れよ、という感じかもしれませんが、ストーリーを考えながらえいやでべたべた貼りつけていくのにはPowerPointが一番慣れてしまっている・・・ 以前もJavaでCOMオブジェクトのラッパーとか使ってPowerPoint.Applicationオブジェクトにアクセスして自動化とかしてたわけですが、Java実行環境は入ってなさそうな人の環境上でも実行する可能性があったので、Windows標準みたいな部分だけでなんとかならないかなあと。 で、PowerShellさんのことを思
2015/09/21追記 気がついたら http://www.damagehead.com/docker-gitlab/ では Docker Compose を使う方法に変わってました。これなら複数のコンテナの起動・停止を簡単に、気持ちよく記述、実行できますね・・・! 実行は以下のような感じ。 wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml docker-compose up コンテナ構成など基本的な考え方は変わってなさそうなので、自分の構成に合わせて docker-compose.yml を調整するとよさげ。 あとGitLabのロゴがだいぶスマートな感じになってる・・・! インフラ管理のための仕掛けを自動化するのはそれなりにうまくできつつあるのですが、これらの
Dockerを使ってのGitLab試行では割と簡単にデプロイできたし、かなり有望な感じがするわけですが、やっぱり個人的にはロゴの目力が痛いわけです。 そんな中、Gitlabのロゴを差し替える という記事を発見。 DockerならばDockerfileを作ればわかりやすくカスタムイメージ作れんじゃないか、みたいに思って書いてみたのでメモ。 今回の画像、Dockerfileなどは以下に置いてあります。 https://github.com/yacchin1205/docker-gitlab-customlogo 描く まずは描きます。オリジナルは、 なんですけど、https://about.gitlab.com/about/ にSmart animalって文言が見えたので、ああ、ケモミミだな・・・と。 サイズ合わせて、こんな感じに。 別に疲れてないです。 ファイルの準備 描いた絵をもとに、以下
システムの開発とか他人の作ったシステムの運用をする中で、サービスの外面だけでも動いているかどうかが常にチェックされているとすごく精神的に安定することがわかってきたので、受け入れテスト的なレベルのテストコードはとりあえずでも積極的に書いていきたいわけです。 1年くらい前に書いたWebアプリケーションを引っ張り出さなければならないことがあったわけですが、このときSeleniumでブラウザを使った自動テストを書いていたおかげで、自動テストで動くChromeの画面を眺めて「ああ、そうそう、こういう操作感のUIだったわ」みたいに思い出せたりします。何よりコードとして自動化されていれば、いつでも動かしておけて、それで安心した分睡眠の質が高まることが期待できます。多分。 そんな中で、ここ最近運用に加わったサービスのテスト、まだあんまり書けてないじゃんと気づいて、JavaかつMavenでSeleniumの
TDD is dead. Long live testing.あたりにすごく考えさせられたりしつつ、Java+SeleniumなWebアプリケーションの自動テストプロジェクト構築 を書いたわけなんですが、これだけだとテストは自分が手でやらなければならなくて、寝ている時間に障害発生したらどうするんだとかそんなことを思ってしまいやっぱり睡眠の質があんまり上がらないわけです。朝起きて、おそるおそるテストを走らせて、くずおれるみたいな展開は健康によくありません。 そんなときはJenkinsさんの出番です。頼れる執事に定期的にテストを実行しておいてもらえれば、障害の起き始めた時間が明確に特定でき、ごめんなさいの報告や問題解決のためのログ解析など色々なものの精度が上がって捗ります。 やりたいこと JenkinsからSeleniumのテストを含むプロジェクトを自動的に実行したい 対象WebDriverは
このページを最初にブックマークしてみませんか?
『@yacchin1205のマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く