求めない で 生きていく

なんとなく書いてみてるブログ

TISのShift-wareを使うか否かを考え中

www.tis.co.jp

すげー。汎用的に使える? AnsibleのplaybookとServerspecのファイルを公開はもちろん 社内のプロジェクトで使っているツールも公開しているみたい。

公開しているのは

だけで、社内の事例もこれだけなのかな?
TISでそんな中途半端なことをプロジェクトとしてするとも思えないので、流石に全部は公開したくないのだろう。

OSSを商用にビルドしてサポートしますっていっている会社のプロダクトってのは
OSSプロダクトのことを知っていても、それを使うまでのインストーラーとかもシェルで提供されてて
結局その会社のプロダクトの癖を知っていないといけないのは当たり前なんだけど、
Shift-wareもそのとおり。

https://github.com/SHIFT-ware/shift_ware/wiki/Get-Started

ここでとりあえず使ってみましょうというのを試した時も、
インストーラーでなぜか私の環境ではcurl pipのところが動かなかったので、そこいらは手動で実行。

あと、Excelからyamlを生成してくれるExcel2YAML_1.0.0というツールも
最初インベントリファイルとサーバ設定ファイルのボタンが分かれていること気が付かなくて、
インベントリだけ実行してて、
動かん動かん思ってansibleの実行シェル(これもなんか独自に作られてる)を読んでしまったりと
スッとは入れないのがなかなか。

どうしてもSIerの汎用ツールは仕方がないのさ。

とはいえ、こういった活動をしていかないと、
(特に日本の)エンタープライズ領域のプロジェクトってのは
ずーーーっと変わらない。

是非応援したいところである。


ansibleとserverspecを使って、構築テンプレを売ろうのはよくある話。
これまではサービスメニューにしていたけど、playbook自体を売る感覚になるのだろうか。
ただこういうのってプロダクトスライスで売るよりも業界スライスでやっていくべきと思っている。

例えば流通業での定番業務システム(に使うプロダクト)の構築パックを作っていく方がいいと思っている。
この方が細かい設定値を入れ込んだansible playbookを作りこんでおきやすいから。

で、そうしたとき、Shift-wareを基盤に作っていくべきか、roleの考え方を独自にしておいたほうがいいのか。

Shift-wareのルートを業界別でつくるか、業務システム別に作るか。
roleを業務システム別に作るか。
それはansibleのベストプラクティスに反する。

公開されているplaybookの数が今の数程度であれば、自分たちで作っても大して手間でないとはいえ、
こういうのは最初から乗っかっておいた方が、後々楽なのである。
ということでもうちょっと乗っかっていく前提で、もうちょっと研究していこうと思う。
何はともあれ感謝である。

ちなみに、一番の厄介事はソフトウェアバージョンが上がったときのメンテナンス性なので
プロダクト別にroleが分かれているshift-wareはメンテナンスがしやすい。
でもExcel2YAMLのメンテナンスはしたくないなぁ・・・・
個人的にはこれはない方がいいと思うんだけど。エンタープライズSIerらしいや。

オープンソースで使うとき、Excel2YAMLもメンテナンスしないといけないのかな・・・